Life sciences identifier

(see also Response to Good and Wilkinson 2006)

The Life Sciences Identifier (LSID) naming scheme, described here, was set up around 2004 to meet the following requirements:
 * (a) must have a formally defined APIs for computational use
 * (b) identifiers must be names, not locators (persistent name-to-object association)
 * (c) global uniqueness with local identifier control
 * (d) object attributes defined using a formal ontology (stated in Clark et al although I confess I don't get what they mean)

LSIDs are URIs under the urn: URI scheme. A software stack for the protocol is maintained at lsids.sourceforge.net.

The LSID system incorporates a number of useful features, such as the notion of local control over name resolution, a clean separation of data and "metadata" forks, and a theory of document versioning that prevents confusion over provenance when a computational analysis needs to be repeated.

Although LSIDs natively handle two functions we find lacking in http:, namely standardized transparent access to mirrors and a clean data/metadata distinction, we find that the advantages of using HTTP for documentation access (and document access, when the URI names a document) outweigh the annoyance of having to specify a new URI documentation protocol that extends HTTP by adding roughly equivalent functionality (see Documentation source overrides and Link header).

We are satisfied that http: URIs meet our needs better than LSIDs. This is not necessarily a criticism of LSIDs but may be reflective of different concerns. Most of our URI requirements, especially persistent access to URI documentation (via mirrors if necessary), cannot be solved by any technical protocol alone and are more a function of a community's ability to organize itself.