Re: [Fwd: URL +1, LSID -1]

Hello,

I've certainly missed parts of the debate regarding LSID, but I don't
understand what they add to 'http' URIs. How would 'http' URIs prevent 
linking to the greater world and data held elsewhere?

I think this document makes the case for 'http' URIs better than I
would: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50

The problem with 'urn:lsid:' (or any other custom URI prefix) is that it
is not easily generalisable. It seems unrealistic to have each and every
possible project ask for the registration of a label (life science,
physics, chemistry, ... where to stop? Who has authority on the whole of
"life science"?).

In contrast, 'http' URIs (not that it has anything to do with the HTTP
protocol), give the opportunity to make this extensible, as well as
provide de facto authority on this type of URI.

I can see two ways to go about this:

1/ The LSID community as a whole chooses to have a domain name (say
lifesciencecommunity.net). In this case
'urn:lsid:ipni.org:names:30000959-2' could work very well as
'http://id.lifesciencecommunity.net/ipni.org:names:30000959-2'. There is
no loss compared with the 'urn:lsid' prefix. Worries about the authority
could be addressed by having whoever owns lifesciencecommunity.net
establish a charter saying that the first part after the slash (in this
example 'ipni.org') should be reserved for the "sub-authority" as part
of the LSID community.

2/ A less regulated approach where knowing the URI is an LSID would be
less obvious: leaving each institution that was an authority in the
'urn:lsid' scheme define its own "host name", for example
lsid.mygrid.info, lsid.ipni.org. In this case, the example above could 
be equivalent to 'http://lsid.ipni.org/names:30000959-2'.

Dealing with legacy LSIDs should not be a major problem, since it could
be easy to implement a resolver to convert LSIDs to and from something
like 
'http://id.lifesciencecommunity.net/urn:lsid:ipni.org:names:30000959-2',
for example.

Having an actual "default" resolver under the form of an HTTP server
becomes an accessory matter which can however be solved rather easily.
This could be handy if some of these LSID URIs where included in
documents retrieved with a web browser. The user-agents would not need 
to be extended to learn a new prefix, but could just use HTTP as they 
know it.


Best wishes,

Bruno.

Received on Monday, 16 July 2007 03:04:00 UTC