[tdwg-guid] First step in implementing LSIDs

Richard Pyle deepreef at bishopmuseum.org
Wed Jun 6 00:20:31 CEST 2007


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 at bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html




________________________________

	From: tdwg-guid-bounces at lists.tdwg.org
[mailto:tdwg-guid-bounces at lists.tdwg.org] On Behalf Of Jason Best
	Sent: Tuesday, June 05, 2007 10:39 AM
	To: Roderic Page; Chuck Miller
	Cc: tdwg-guid at lists.tdwg.org; WEITZMAN at 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 at bio.gla.ac.uk] 
	Sent: Tuesday, June 05, 2007 2:10 PM
	To: Chuck Miller
	Cc: Bob Morris; Kevin Richards; tdwg-guid at lists.tdwg.org;
WEITZMAN at 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






More information about the tdwg-tag mailing list