Re: URL +1, LSID -1

Alan Ruttenberg wrote:
> Regarding "Don't quite see any benefit in having another set of 
> redirectable identifiers for the actual representations".
> 
> I have tried to explain this many times and I guess that I am just not 
> good at it. Let me try again, by asking you to review some statements, 
> and perhaps spend a few moments answering some questions about them, and 
> providing the reasoning behind your answers:

I'm not at all saying that you wouldn't want to attach any statements to a 
specific representation, but that if you did, you'd better use the actual 
URL of the representation, not some PURL. For example, if you wanted to 
state that http://beta.uniprot.org/uniprot/P12345 validates as XHTML 1.0:

<http://beta.uniprot.org/uniprot/P12345>
   validatesAs <http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>

...seems better than e.g.

<http://purl.org/commons/html/uniprotkb/P12345>

...of which you can't be quite as certain that it will always point to the 
specific page you wanted to describe! You could argue that this URI is 
meant to represent the more general concept of "an HTML representation of 
P12345", but at that point I really start to wonder...


> I suppose it might be possible to represent which header should be used 
> in the content negotiation as part of the RDF, but a) It's got to be 
> easier to just put that information in the name and b) In the case that 
> you want to, e.g. mirror some contents of Uniprot on a file system, you 
> will have to make up distinct names anyways? Maybe I'm dense, but I fail 
> to see how content negotiation is of any use on the semantic web.

Note that the content negotiation is done *at the level of the resolver*, 
all the different representations have their own URLs:

http://beta.uniprot.org/uniprot/P12345
http://beta.uniprot.org/uniprot/P12345.xml
http://beta.uniprot.org/uniprot/P12345.rdf
http://beta.uniprot.org/uniprot/P12345.fasta

Content negotiation could be a useful mechanism for bypassing the HTML 
representation (which is what the PURL resolves to by default, greatest 
common denominator etc), important if a lot of requests need to be made.


> ps. LSIDs vs URI's aside, it's admirable (and greatly appreciated) that 
> Uniprot is on the way to providing stable identifiers. I do hope you 
> will be continuing in this effort to the bitter end:) For instance on 
> the html page, we have URLs such as 
> http://srs.ebi.ac.uk/srsbin/cgi-bin/wgetz?-e+[HSSP-ID:'7aat'] which 
> could be profitably hidden behind a redirect using the same mechanism 
> that you are already using.

You'll notice that in the RDF representation, this HSSP resource is 
represented with the URL http://purl.uniprot.org/hssp/7aat. The main reason 
for pre-resolving the PURLs in the web pages is that many people (been 
there, done that) like to see where they are going before they click.

btw this is an example of a resource that won't work with the HCLS PURL 
resolver at the moment, as this resolver can also only append to a path!

Received on Saturday, 14 July 2007 14:27:14 UTC