Globally Unique Identifiers (GUID)

There seems to be no stated recommendation that identifiers be either unique identifiers or  persistent identifiers in the sense of the Definitions.

The definitions offered of unique identifier and of persistent identifers ambiguously overlap by virtue of the text "associated with a single object" in the definition of persistence. Probably the definition of persistence would be less problematic if only the point of the second sentence were made.  Perhaps the definition would be simply "A persistent identifier is one which is never assigned to a different object, whether or not the object to which it is assigned persists."

------

In the definition of unique identifier:

   (a)what would be an example of an ambiguous name?

   (b)what would be an example of a duplicated name?

If there are no such examples, there is no point to mentioning those attributes. The definition misses an opportunity to clarify the main thing that confuses neophytes, which is that uniqueness doesn't mean that an object must  have only one identifier.  Perhaps a better first clause might be "an identifier that names at most one object at any point in time."

"The primary digital catalog record of a specimen may be identified with the specimen’s identifier or may have its own identifier."
According to the definition of uniqueness offered, if a catalog record is also identified with the specimen's identifier, it is not unique, since the record and the specimen are not the same object. The sentence "Each distinct digital object should have its own identifier." does admit the possibility that it is not unique in the sense of the definition, but then it will not be an IETF/W3C compliant URI, which is probably not the intent.

It is easy to construct a use-case where making the primary specimen record identifier be that of the specimen may raise issues. Consider a specimen on loan to another institution.  In that case, the institution holding the specimen record will not be the same as that holding the specimen. In turn, if dereferencing provenance is important, that might impose a burden on the derferencing service to provide data about both the record and the specimen, which it may be unwilling or unable to do.

Most of the section "What to Identify" conflates specimens with specimen records.  I think this is a bad idea and unnecessary.

The first paragraph of the document almost treads on the wide misuse confusing URI resolution with URI dereferencing.  As described in the Appendix, the proxy server is indeed a resolution service in the IETF and W3C sense, but an insufficiently informed reader of the Guidelines might come to believe that the URI string itself holds information for retrieving the information without actually going through a resolution service. A resolution (in the IETF/W3 sense) that is based on parsing the URI string may be correct at some point in time, but not in the future (e.g. if the dereferencing service changes, requring a resolution service to return a different URL). Hence the form of the http URI matters not one whit. But some stakeholders may behave as though it does, and it is probably difficult to convince people that this is a bad idea if the string appears meaningful to a human.

If I am understanding the proposal correctly, a URI should reference uniquely either an object or a digital representation of the object.  Given the format of the proposed URI, how does one distinquish them if you are using the barcode as the object name for both?  What if you have digital images of the same object stored in two formats (e.g., DNG and JPG) - how do you distinguish them? 

The TDWG DarwinCore defines a term occurranceID  http://rs.tdwg.org/dwc/terms/index.htm#occurrenceID.  The definition of this term specifies that it is an identifier for the occurrance, not a digital representation of the occurrance.    The commentary for the term also suggests a scheme for identifying specimens that don't have a GUID with the scheme: urn:catalog:[institutionCode]:[collectionCode]:[catalogNumber].   There is another term, drawn from DublinCore, dcterms:references http://rs.tdwg.org/dwc/terms/index.htm#dcterms:references, which could be used to reference a digital representation of an Occurrance.

Elaborating on the point made in the document that a darwin core triplet of institution, catalog number series, and catalog number is non-unique:  It is very likely that catalog numbers assigned to collection objects from workflow processes that involved cataloging into ledgers have cases that can be seen as permanently non-unique.  We know that cataloging into ledgers has produced runs of duplicate catalog number assignments (more than one different collection object being assigned the same catalog number), often in blocks of pairs of ledger pages where the starting number on a new page was copied from the page before the previous page, rather than the previous page.  Anecdotaly, I've encountered cases where two different specimens sharing the same number were type specimens of different taxa, and those numbers have been published.  In the presence of an institutional policy that prohibits the recataloging of types, such specimens would permenantly bear the same non-unique number.  

I'd like to elaborate on the following quote from the Guidelines for Managing Unique Resource Identifiers document, paragraph 3.

We recommend that providers adopt the http URI scheme for all identifiers. It should be noted that although this pattern resembles a URL (Universal Resource Locator), it does not have to be actionable or resolvable directly through a web browser.

Several conversations in the collections community indicate there is perhaps still some confusion regarding URIs and URLs. In reality, a URL is a special type of URI. A URL is a type of URI in that it must uniquely identify something AND when you click on it (or enter it in a browser), you get something back (a web page, a downloable file, some metadata...). So, a URL is both a URI (a unique identifier) and a locator (actionable and resolvable).

A URI is (hopefully) unique and persistent,but does not need to be actionable or resolvable (not a locator). Nothing is necessarily expected to happen when one "clicks" on this. A URI is an identifier, it is not required to be a locator in the sense of a URL. In the suggested format, the organization chooses and registers a domain name string as desired to create a unique URI pattern when put together with the other elements (prefix + domain + collection identifier + object name). The entire string represents the unique identifier for a given object. Another way to say this is, the string is atomic.

I am assuming that IdigBio will provide assistance to providers in selecting and registering URI schemes with both IdigBio and IANA?  I can see this as being a difficulty in collections with only limited IT experience and little or no web presence for their digital objects.

 
Some general comments from my colleagues about the proposed GUIDs guidance:

• There is a need for a GUID directory service. URLs change. That means GUIDs based on URLs are likely to fail (not be persistent). Collections' management changes (and may cause someone to mistakenly reuse a specimen number and/or a collection code). Without GUID services and their related libraries, identifiers won't fulfill the requirements.

• iDigBio is proposing a resolvable system of persistent identifiers. However, in all likelihood iDigBio will end up having exactly the same problems as the GBIF concatenation because the easy way to generate them is just the way that GBIF does - in the distribution database - and not put them on the specimen or anything that would make them robust.  iDigBio does have a grip on reality as they will have to take what they get, and the URI is the easiest to generate and it’s free.

• We can agree on use of URIs as identifiers, the only problem with that will be the “persistent” issue.  In addition to URIs, iDigBio should consider the possibility of using Digital Object Identifiers (DOIs) as valid identifiers.