Re: A precedent suggesting a compromise for the SWHCLS IG Best Practices

Hello Henry,

>   HST> With respect to the upcoming W3C Semantic Web Health Care and
>   HST> Life Sciences Interest Group f2f discussion of LSIDs, I wonder
>   HST> if you might think seriously about adopting an approach similar
>   HST> to that used by the ARK (Archival Resource Key) naming scheme
>   HST> [1].

This is a great paper. Many thanks for pointing to it. I wish I had known 
of it earlier.

You may well be correct in your thinking that a similar approach offers a 
good compromise. In fact to my mind it may actually leave everyone with 
something that is significantly stronger than what we have currently and 
the fact is that the software required to support it already exists [1] 
modulo a few tweaks.

> 
>   HST> _Very_ roughly, this would involve Semantic Web uses of LSIDs
>   HST> to use an http-scheme version of LSIDs, along the following
>   HST> lines:
> 
>   HST>  URN:LSID:rcsb.org:PDB:1D4X:22
> 
>   --> 
> 
>   HST>  http://lsids.org/lsid:rcsb.org:PDB:1D4X:22

My feeling is that this suggestion is far more likely to succeed than the 
second one. The reason for this is that there is no real "center" to the 
Life Sciences (there are actually many and they don't always get on!) - 
and consequently there might be significant difficulty in establishing and 
managing the directory of authorities it would require. There would also 
likely be resistance by those who don't want to be bothered by any kind of 
red tape. The existing scheme was chosen in part because it allowed any 
data provider to establish themselves as an LSID authority for their data 
simply by creating a single SRV record in their domain server and piggy 
backing on that. No central registration required, cost of entry free 
using the domain name you already have. 

The thinking was that this method of establishing an authority name is the 
default case and any registry entries required later where a separation of 
DNS domain and LSID authority name became necessary or where the authority 
name had be a string that was not a domain name, would be by exception and 
only as needed. At the time there was absolutely no stomach to put 
together an ICANN type organization with associated administration, costs, 
liabilities etc and I would be surprised if this has changed. 

As far as I can tell all that would be required to adopt the ARK approach 
is that someone (who?) registers the appropriate (what?) domain and 
provides the service machinery. Data providers would continue to name and 
provide data/metadata service for their digital objects in the same 
totally distributed manner. 

> 
>   HST> or, alternatively, as per my recent suggestion to Sean
> 
>   HST>  http://rcsb.org.lsids.org/lsid:PDB:1D4X:22
> 
>   HST> I strongly recommend studying the ARK approach in any case, as
>   HST> it seems to me that although starting from a different subject
>   HST> area, its requirements are very close to your own.
> 
> 
> I don't want to get "domainist" about this, but if it is broadly
> similar can you give a quick outline as to why ARK is better than
> LSIDs. 
> 
> I am starting to think that the main difficulty with LSIDs is that it
> has the phrase "Life Sciences" in the title which makes it domain
> dependant. 
> 
> My proposal is that we rename LSID to ARID for Archival Resource
> ID. Would this solve the difficulties? 

Phil, there is one very significant advantage to it being LS domain 
specific.. and that is that it has an accompanying social contract  that 
meets the LS requirements (er... well more or less :)


Kindest regards, Sean

[1]   See 
http://lsid.biopathways.org/resolver/data/urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank:30350027 
 for a sequence and
http://lsid.biopathways.org/resolver/metadata/urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank:30350027 
for its metadata.  Obviously you would replace "lsid.biopathways.org" with 
whatever the Name Mapping Authority" domain name is.


--
Sean Martin 
IBM Corp