 since it should allow other clients to interpret the data correctly. The short forms are suggested standard abbreviations likely only to be interpreted correctly by the ALA and similar biodiversity informatics projects.
|Vocabulary||Long form||Short form|
|Dublin Core||Element URI (e.g. “http://purl.org/dc/elements/1.1/description“)||Prefix property name with “dc:” (e.g. “dc:description”)|
|TaxonOccurrence||Prefix property name with “http://rs.tdwg.org/ontology/voc/TaxonOccurrence#” (e.g. “http://rs.tdwg.org/ontology/voc/TaxonOccurrence#catalogueNumber”)||Prefix property name with “to:” (e.g. “to:catalogueNumber”)|
|TaxonConcept||Prefix property name with “http://rs.tdwg.org/ontology/voc/TaxonConcept#” (e.g. “http://rs.tdwg.org/ontology/voc/TaxonConcept#nameString”)||Prefix property name with “tc:” (e.g. “tc:nameString”)|
|TaxonName||Prefix property name with “http://rs.tdwg.org/ontology/voc/Taxonname#” (e.g. “http://rs.tdwg.org/ontology/voc/TaxonName#year”)||Prefix property name with “tn:” (e.g. “tn:year”)|
|Other vocabulary||Property URI||N/A|
|Unmatched term||Plain text column name||N/A|
This approach will allow relatively simple (“flat”) database structures to be shared. It will however not accommodate all needs. Two particular issues need to be considered:
It would be possible for the ALA to develop more complex recommendations on ways to use tab-delimited/comma-separated formats to overcome these issues. At present the recommendation is to avoid the use of these formats for these more complex situations. In one special case, sharing of synonymised checklist data, the ALA recommends the use of the SPICE Common Data Model properties to supply column headings. This model includes separate sets of properties for the accepted name and for the synonym and therefore avoids the general problems described above.
Life Science Identifiers (LSIDs) are globally unique identifiers which can be used both uniquely to identify a particular data object and also to assist users with retrieving associated metadata in a standard format.
An LSID is a string with the following format: urn:lsid:<Authority>:<Namespace>:<ObjectID>[:<Version>]
Example LSIDs include:
TDWG has adopted LSIDs as its recommended standard for assigning globally unique identifiers to data records and has developed a range of software components to assist data providers and users in exchanging data via LSIDs. This software is listed on the TDWG wiki and includes:
Note that web browsers cannot directly resolve an LSID. When presenting an LSID for display to humans, it is recommended that the identifier should be prefixed with the address for the LSID Web Resolver web site, e.g. instead of showing urn:lsid:ipni.org:names:302735-2, show http://lsid.tdwg.org/urn:lsid:ipni.org:names:302735-2.
Responses to requests for LSID metadata are expected to return this information encoded as RDF. The TDWG TaxonOccurrence, TaxonConcept and TaxonName vocabularies were in part developed to make it possible to use them in RDF documents. See the TDWG wiki page on LSID Vocabularies for more details.
For more information on LSIDs, see:
The Open Archives Initiative (OAI) has developed a simple protocol for harvesting of metadata from web repsitories. OAI-PMH is a set of six request types which allow clients to browse the contents of such a repository and, at a later date, to be able to discover more recent changes. These requests are:
Essentially OAI-PMH can be seen as a more sophisticated and flexible version of RSS. A data provider can advertise a set of resources via their metadata, and can optionally use Sets to subdivide these resources into categories of importance to users. Users can browse all metadata documents or the documents for a single Set and can limit requests to those metadata documents added, modified and even deleted since a specified date.
The ALA recommends the use of OAI-PMH particularly for repositories of images, documents, etc. It is highly suited to situations in which data records can be represented with plain Dublin Core and in which the contents of the reposi