 Longitude concepts from a model such as the Darwin Core. A client application can then send standard requests (as XML documents or a set of parameters encoded in a URL) to each of these resources and receive the results back as an XML response document. The format of the response document and the data elements to be inserted into this format can be defined by the client requesting the data. This makes it possible, for example, for the client to request the results as a KML file which can be displayed directly in Google Earth or Google Maps.
TAPIR supports five types of request:
Several implementations of the TAPIR protocol are available. The TAPIR server implementations all include configuration interfaces to assist data providers in mapping their relational databases to standards such as Darwin Core, ABCD and the TDWG TaxonOccurrence vocabulary. Available software includes:
The ALA is working with GBIF and others to simplify the installation and use of these tools.
For more information on TAPIR, see:
TAPIR is a powerful tool for supporting remote access to a database but some data providers may not need the flexibility it offers, or may be unable to run the TAPIR software on a web server. In such circumstances it may be simpler to share a flat file representation of the data. The simplest approach, supported by database and spreadsheet software, is to export the content as tab-delimited or comma-separated data and then to register a URL from which the data file can be downloaded. This makes it possible to associate the data with any relevant descriptive metadata. Note that data should always be shared using UTF-8 as the character encoding.
One possible weakness in such an approach is that it may be difficult for users to interpret the significance of the various columns in such a data set. The ALA makes the following recommendations to address this problem:
The property identifiers should be constructed using either the short or long form specified in this table. The long forms are formal URIs and are preferred 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 standa