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: h
ttp://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:30
000959-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.ipn
i.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.
|
