Internal References with key/ref constraints

In the TCS it was originally proposed that three top-level elements would be provided with key IDs to allow their reuse within a document by reference.

These are:

Following discussions with the SEEK team at KU who are developing implementations using TCS we have added

For re-use issues they also expressed an interest in making further internally referenceable top level Elements

Currently we see no immediate value in following this proposal for AccordingTo, which may have little reuse potential, (especially when the MicroReference child element is used). Repository is a better candidate for reuse – although currently it is not clear that this would be simple in the absence of a standard representation of a Repository (though repositories are probably good candidates for GUIDs)

Each of the four 'top level' elements has an @id attribute to provide the constraint key – (now proposed to be of datatype NMToken to allow essentially any string (change from v0.7)). Each of the elements referencing this key contains an @ref element. The XSD Key constraints ensure that a valid document contains keys (@id) matching the keyrefs (@ref).

Representing GUIDs

Resolvable GUIDs are desirable for any global resource with reuse potential – so that the GUID can be provided as a reference for the data resource – rather than including (multiple) representations of the data itself. This should contribute to efficiency of storage, transfer and reuse and improve data reliability. However, these benefits rely on the existence of GUIDs, their maintenance and resolution, and means that a client may receive data including unresolved GUIDs, which they then need to resolve.

The future availability of GUIDs should assist efficient transfer and reuse of taxonomic concept data. TCS proposes to accommodate GUIDs as alternatives to the internal refs – held in the same @id attribute of the four top-level elements and used as key/refs in exactly the same fashion as internal references.

In order that transfer documents are capable of transfering ONLY GUIDs (ie empty TaxonConcept Elements, Voucher Elements etc), that only contain the @id (GUID), each of the top level elements has an optional @empty attribute of type Boolean, which can be set to 'true' when providers wish to explicitly state that they are not transferring information content, just the GUID (all child element content then should be empty or disregarded). (@empty is new fom v0.71). However, it is possible to pass information content alongside a GUID, which would be necessary when resolving GUIDs. In these cases business rules would be necessary to decide whether to use the data transferred – or resolve the GUID as a more reliable alternative.

It is also possible to reference GUIDs for objects not carried in a transfer document, by use of the @gref attribute (NMToken from v0.71) in those elements of reference type (ToConcept ToTaxonConcept FromTaxonConcept CirucmscribedBy PublishedIn).