On Jul 11, 2007, at 3:20 AM, Eric Jain wrote:
Alan Ruttenberg wrote:
from http://www.w3.org/2001/tag/doc/alternatives-discovery.html
>
[...]
While I'm not always a fan of TAG findings, I think this one makes
a TON of sense.
I'll agree with that, but where do they talk about having canonical
URIs for each specific representation?
Don't know - I didn't quote that part on purpose. I took canonical
URI to mean "record without commitment to format".
I understand well the need for representation-independant URIs, but
I don't see the use of a generic identifier for e.g. P12345 in
FASTA format: If you really wanted to make any statements about
that representation, you'd better attach them to the actual URL,
given that there are many ways to represent P12345 in FASTA format
(every server seems to do so differently).
Yup.
Are there any standards/tools that know what to do with 303
responses?
Some. An influential tool by a certain Tim Berners Lee called
Tabulator does. I've understood that it is considered a courtesy
to respond 303 to things which are not gettable as such, and to
provide information about related information, in this case the
specifically formatted versions.
I don't feel comfortable with showing a minimalistic page with some
weird acronyms when someone enters e.g. http://purl.uniprot.org/
uniprot/P12345.
How is someone to know, then, that you mean that the name denotes a
class of proteins, rather than a page of html?
Ideally there would be a standard way for a client to request "what
representations are available". Perhaps I could return 303 if no
Accept header is set, don't know if that is a good idea?
I think content negotiation is a bad idea because it confuses the
issue of what the name identifies. It effectively allows the GET to
return many different things that *appear* to have the same name,
because the bit that differentiates it (the accept header) has no
representation in the rdf.
I think we should define, as a community, what sort of document we
expect the 303 to redirect to (RDF) and what the contents of that RDF
should be, e.g. minimally class, pointers to representations, where
to get more information (e.g. endpoints).
Remember, most of this kind of information will eventually live at
SPARQL endpoints. Providing this information is to enable discovery/
follow your nose navigation - which is inefficient, but polite.
-Alan
