Re: "Hash URIs" and content negotiation

Hi, again!

I want to give some addition to my last post (and by this also finally 
answer your question "a or b?" :) ).

An alternative to demanding each client to know how to handle HTML/RDF 
mixtures would be to take variant a): Here the job of extracting the RDF 
is done by the /web server/ instead of the client, after the client 
explicitly told him to send RDF from the given URL (by 'Accept:'). This 
logic, together with the RDF extraction code, could be part of the web 
server's implementation (perhaps as a plugin). If such a plugin becomes 
standard in the web server world, the editor of the web page would not 
have to think much about server issues.

Now, using both the server side approach above and the client side 
approach discussed below, all possible scenarios would comfortably work, 
as far as I can see: Each semantic web client would either need to know 
how to extract RDF from a web page itself, or how to tell a web server 
to send the RDF from the given URL. The client side approach is more 
flexible, because the client has the freedom of choosing whatever 
information he wants to extract. And the client would also get the HTML: 
This is faster (network access), if HTML and RDF are both needed. On the 
other side, the server side approach is easier for the client to 
realize: It needs just a little knowledge about HTTP.

Bye,
Michael


Michael Schneider wrote:

> 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 Wednesday, 8 November 2006 10:00:20 UTC