Re: "Hash URIs" and content negotiation

Hi, Richard!

Here is, what I believe. My consideration does not fully answer your 
question ("a or b?"), but perhaps it is a little help to you.

I try to think of meaningful use cases, where one wants to have both an 
HTML file and RDF data with the same base URI, and the only relevant use 
case I can see for now is, to have the HTML file as the primary object 
(some web page), with the RDF data closely related to this web page. 
E.g. in your example, it would probably be some personal homepage (that 
of John) together with some metadata and a machine readable version of 
the web page's content.

Now, AFAIK, there are actually two ways to associate RDF data with a web 
page: Either by building a "<link rel='alternate'>" to an external RDF
file, or by embedding the RDF into the (X)HTML (microformats, or RDFa in
some near future) of the web page. Note, that it is even possible, to 
combine these two techniques, and the RDF data would then be the sum of 
both parts.

If this was the situation, than I believe that there is no need for 
special handling on the server side (neither a) nor b)). Just place the 
web page at that URL ("http://.../john"), and let the client do the 
whole job:

   * If the URI was inspected by some traditional web browser,
     all it does is loading the web page (HTML), jumping to the
     given anchor (".../john#me") and render the page from this
     position on.

   * If the URI was inspected by some kind of semantic web browser,
     it would /also/ just load the HTML of the web page, then
     extract the RDF (the client will of course know how to extract
     embedded RDF or follow the <link>), and finally fetch the
     RDF resource specified by URI "..../john#me".

Bye,
Michael


Richard Cyganiak wrote:

> Hi all,
> 
> One good practice for identifying non-document resources is to use  
> "hash URIs" like http://example/john#me, and to serve a description  
> at the URI obtained by taking the part before the hash, e.g. http:// 
> example/john.
> 
> Now let's say I want to serve both RDF and HTML descriptions of John.  
> That is, both formats should be available from http://example.org/ 
> john, depending on the request's Accept: header. How to do this?
> 
> a) Just return the requested type of content right at http:// 
> example.org/john
> 
> b) Redirect to two different URLs, depending on the requested type,  
> e.g. http://example.org/john.html and http://example.org/john.rdf
> 
> I notice that the SWBP Vocabulary Recipes [1] suggest b). I have a  
> hunch that a) is problematic because it's a bit ambiguous, http:// 
> example.org/john#me could refer either to John, or to an anchor  
> within an HTML page, if there's no 303 redirect in between. So, is  
> only b) allowed, or is a) fine too?
> 
> Comments?
> 
> Cheers,
> Richard
> 
> [1] http://www.w3.org/TR/swbp-vocab-pub/#recipe3

Received on Tuesday, 7 November 2006 22:50:00 UTC