On 23/02/2012, at 9:37 PM, Roderic Page wrote:
I've recently written an number of posts on the implications of the lack of specimen-level identifiers, which makes it very hard to link different sources of data together, such as GBIF and Genbank http://iphylo.blogspot.com/2012/02/linking-gbif-and-genbank.html , and are also a factor in creating duplicate records in GBIF http://iphylo.blogspot.com/2012/02/how-many-specimens-does-gbif-really.html
This is definitely an issue. In AFD (which is not a specimen database), we hold a "museum code" and an "accession number" for types specimens. Ideally, I would like to be able to get from these two fields to a URI. For instance, given the data nameT typeTypeT museumT museumDesc accessonNo materialElement latLong locality comments Holothuria bivittata Mitsukuri, 1912 Syntype TIU Tokyo Imperial University, Tokyo, Japan 1217 Okinawa, Riu Kiu and Yayeyana Ils, Japan Holothuria bivittata Mitsukuri, 1912 Syntype TIU Tokyo Imperial University, Tokyo, Japan 1218 I would like the AFD type specimen records (which are anonymous nodes in our profile data) to point to "http://collections.tiu.edu.jp/colleciton-X/1217" (or whatever), which could be generated from the data we already have. The key is the individual institutions holding collections. The only way I can imagine this happening is for each institution with collections to state "you construct URIs from our accession numbers like so". With that declaration, stores exposing data (such as the boa silos) can perform the mapping when the news reaches them. Once this is in place, anyone handling (for instance) TIU accession numbers can publish correct URIs in their RDF. Most particularly, other institutions accepting specimens from TUI could publish that their new URI for the item is "owl:sameAs" the TUI one. And the whole thing begins to knit together. Importantly: it is not necessary to actually make these URIs resolvable. Hopefully, one day there *would* be something at that URL which would issue a 303 redirect, but the existence of the identifier as an identifier doesn't rely on it. All that is needed is that commitment to the namespace on the part of the issuer. My point is first, that this can be done in stages, and doesn't depend on everybody implementing a big and expensive solution right away or in synchrony; and second, that we don't need a top-down assignment of identifiers. A bottom-up solution can work. Perhaps the main thing missing is a forum on which an institution can announce its creation and assignment of a URI namespace for persistent identifiers. Having said all that, Rod's point is about identification of individuals. An accession number is put on a "token", of course, a given individual may have many "tokens". A case in point is this record in AFD: nameT typeTypeT museumT museumDesc accessonNo materialElement latLong locality comments Bregmaceros pseudolanceolatus Torii, Javonillo & Ozawa, 2004 Paratype URM University of the Ryukyus, Nishihara, Okinawa, Japan P. 12156, 27508–27511, 29172, 29620, 33056 The type specimen has 8 URM accession numbers, and there's really no way around that. Even then, however, the question of identifying the individuals comes down to the same solution: if it's to happen, then it will have to be done by the curators of the collections - it's only the curators who actually know what items are from the same individual. A third party generating UUIDs for all these things just isn't going to work out - they won't get it right. What is needed is for the curator to announce, for instance, "individuals shall be identified by http://specimens.mymuseum.edu/<collection id>/<collector's field number for the individual>". It really doesn't matter how the URIs are done, as long as it's consistent, persistent, and public. If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email.