Hi All,
Just a quick comment now, and I hope to find more time later to respond to many other comments made on this thread.
From what I've seen of alternatives to LSIDs, I tend to agree with Jason and
Kevin on this. The fundamental outstanding issues need to be sorted out within our community, independent of the GUID technology implemented -- I don't see how the choice of GUID will affect these sorts of decisions much.
Having said that, though, I do strongly share Rod's apprehension about "committing to a technology" -- any technology. At this point in history, we simply do not know what the techno-network-webservices infrastructure will be like in ten years, let alone 100 years; so the last thing we want to do is commit too deeply to anything that we can't back out of reasonably painlessly down the road.
Nevertheless, I'm strongly inclined to run with LSIDs for now, and see how they pan out over the next couple of years. DOIs are a non-starter on fiscal parameters alone (even if they cost a penny a piece, I don't have the budget to apply them to all of the specimens, identification events, taxon name usages, and a myriad of other things I want to assign GUIDs to).
I am thinking about ways to "hedge my bets" a bit, though. One idea I had, which I discussed with Rod recently, was to register a Handle prefix, and incorporate that prefix as part of the ObjectID for the LSIDs we generate. So, suppose I established a Handle prefix of 1234, and my internal identifier for a data record is 9876543. I would then format my LSID as something like:
urn:lsid:bishopmuseum.org:specimen:1234/9876543
I know that LSIDs are semantically opaque (sort of), but the point is that the ObjectID alone is effectively a GUID by itself. If we ever decided to abandon LSIDs, it would be a very simple matter to strip the non-objectID LSID syntax and be left with a legitimate (and presumably resolvable) Handle. Even if we don't switch to Handles per se, the fundmantal practicality of generating GUIDs as a two-part <IssuerID>/<LocalObjectID> generic approach is very attractive. The only thing we, as a community, would need to coordinate on is ensuring uniqueness of the "<IssuerID>" part.
Food for thought, anyway. A longer response forthcoming....
Aloha, Rich
Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef@bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html
________________________________
From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Jason Best Sent: Tuesday, June 05, 2007 10:39 AM To: Roderic Page; Chuck Miller Cc: tdwg-guid@lists.tdwg.org; WEITZMAN@si.edu Subject: RE: [tdwg-guid] First step in implementing LSIDs Rod, I've only had a chance to quickly skim the documents you reference, but it seems to me that the alternatives to LSIDs don't necessarily make the issues with which we are wrestling go away. We still need to decide WHAT a URI references - is it the metadata, the physical object etc? URIs don't explicitly require persistance, while LSIDs do so I see that as a positive for adopting a standard GUID that is explicit in that regard. I think the TDWG effort to spec an HTTP proxy for LSIDs makes it clear that the technical hurdles of implementing an LSID resolver (SVR records, new protocol, client limitations etc) are a bit cumbersome, but I don't think the underlying concept is fatally flawed. In reading these discussions, I'm starting to believe/understand that RDF may hold the key, regardless of the GUID that is implemented. Now I have to go read up more on RDF to see if my new-found belief has merit! ;) Jason
________________________________
From: Roderic Page [mailto:r.page@bio.gla.ac.uk] Sent: Tuesday, June 05, 2007 2:10 PM To: Chuck Miller Cc: Bob Morris; Kevin Richards; tdwg-guid@lists.tdwg.org; WEITZMAN@si.edu; Jason Best Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned] Maybe it's time to bite the bullet and consider the elephant in the room -- LSIDs might not be what we want. Markus Döring sent some nice references to the list in April, which I've repeated below, there is also http://dx.doi.org/10.1109/MIS.2006.62 .
I think the LSID debate is throwing up issues which have been addressed elsewhere (e.g., identifiers for physical things versus digital records), and some would argue have been solved to at least some people's satisfaction.
LSIDs got us thinking about RDF, which is great. But otherwise I think they are making things more complicated than they need to be. I think this community is running a grave risk of committing to a technology that nobody else takes that seriously (hell, even the http://lsid.sourceforge.net/ web site is broken).
The references posted by Markus Döring were:
(1) http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf "Cool URIs for the Semantic Web" by Leo Sauermann DFKI GmbH, Richard Cyganiak Freie Universität Berlin (D2R author), Max Völkel FZI Karlsruhe The authors of this document come from the semantic web community and discuss what kind of URIs should be used for RDF resources.
(2) http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 This one here is written by the W3C and addresses the questions "When should URNs or URIs with novel URI schemes be used to name information resources for the Web?" The answers given are "Rarely if ever" and "Probably not". Common arguments in favor of such novel naming schemas are examined, and their properties compared with those of the existing http: URI scheme.
Regards
Rod