W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2007

Re: identifier to use

From: Eric Jain <Eric.Jain@isb-sib.ch>
Date: Thu, 23 Aug 2007 17:18:58 +0200
Message-ID: <46CDA562.2010809@isb-sib.ch>
To: Hilmar Lapp <hlapp@duke.edu>
CC: Phillip Lord <phillip.lord@newcastle.ac.uk>, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>

Hilmar Lapp wrote:
> I'm not sure what you mean by "closed archive."

If the UniProt consortium decided to set up an archive for all their data, 
that's what I mean by "closed". Obviously much easier than getting the 
entire life sciences community to agree on implementing one scheme :-)

> Almost no database, data center, or publisher uses HTTP URIs for 
> identifying their digital objects, and stable HTTP URIs at present 
> aren't adopted or the common denominator for identifying digital objects 
> in the life science domain either. And that's not b/c it is technically 
> difficult to do so, or because nobody knew that stable URIs are desirable.

There are over a hundred databases I have to deal with in the context of 
UniProt [see http://beta.uniprot.org/docs/dbxref], and the one common thing 
they all have are URLs for their resources. True, most URLs are not as 
stable and nice as we'd like them to be, but it seems a lot easier to 
encourage them to have nicer URLs (or do it for them, e.g. with HCLS 
PURLs), than get them to adopt some new, sophisticated identifier system.

> I think that's where the requirements of digital archives and those of 
> the semantic web probably deviate. 404s are rampant (and not because 
> nobody would care anyway) but the web is still useful. Using HTTP URIs 
> for the semantic web will result in the same abundance of resources that 
> fail to resolve although they could, and maybe that's just fine. But for 
> digital archives it's not.

The hard problem here, in my opinion, are not the identifiers, but actually 
keeping track of replaced/obsolete data (we *try* to do this for our data).
Received on Thursday, 23 August 2007 15:19:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:29 UTC