RE: Review of "Cool URIs for the Semantic Web" - please confirm

> From: Richard Cyganiak [mailto:richard@cyganiak.de] 
> [ . . . ]
> Thanks for the careful review. Responses inline.
> 
> On 26 Aug 2007, at 04:44, Booth, David (HP Software - Boston) wrote:
> > [ . . . ]
> > Consequently there is a trade-off in using hash URIs to identify
> > non-document resources, because the hash URI limits the future media
> > types that you can serve.  If you only ever wish to serve 
> > RDF, then hash URIs will work fine.  But if you think you may 
> > someday wish to serve HTML in addition or instead, then you should 
> > use 303 URIs.
> 
> I think you allege a limitation that does not exist. Let's take the  
> example from the document, starting with the no-conneg solution.
> 
>      http://www.acme.com/about#alice
> 
> The racine serves only RDF/XML, thus /about#alice can 
> identify a person.
> 
> Now if we decide to add HTML later on, our document proposes to 303- 
> redirect from the racine to either of these URIs
> 
>      http://www.acme.com/about.rdf
>      http://www.acme.com/about.html

You are absolutely right.  I hadn't noticed that you made the racine do
a 303.  The limitation I mentioned only applies when the racine serves
the representations.   This hybrid approach of combining the hash style
with 303 redirects bypasses that limitation.  Good idea! 

> [ . . . ]
> > 6. In your example of 303 URIs, http://www.acme.com/id/alice
> > 303-redirects either to http://www.acme.com/data/alice (for RDF) or
> > http://www.acme.com/people/alice (for HTML).  Since the RDF and HTML
> > versions are in some sense intended to provide different  
> > representations
> > of the same information (either for machine or human consumption), I
> > would think it would be administratively more natural to instead use
> > something like:
> > 	http://www.acme.com/description/alice.rdf  and
> > 	http://www.acme.com/description/alice.html
> > for the two document URIs.  Obviously the choice is up to the
> > adminstrator, but I thought I would mention it, because the example
> > looks a little odd to my eyes in this way.
> 
> I sympathize with this. But file extensions in URIs are somewhat  
> frowned upon: "You may not be using HTML for that page in 20 years  
> time, but you might want today's links to it to still be 
> valid." This  
> quote is from Tim's "Cool URIs don't change" piece, which is the  
> inspiration for the title of our document. So it didn't feel 
> right to  
> advocate the use of file extensions in our example scenario.

I think the rationale for avoiding file extensions in the URI is to
avoid inadvertently coupling the URL to the format, when you really want
the URL to identify the information in general.  But in your example,
the explicit intent is not to identify the information in general, but
to identify each format, so I think having the format in the URL makes
sense in this case.  But again, I do not think your naming approach is
wrong, it just seems a little awkward to me, but it is a matter of
personal taste.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.

Received on Thursday, 30 August 2007 04:39:07 UTC