W3C home > Mailing lists > Public > semantic-web@w3.org > July 2009

Re: Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

From: David Booth <david@dbooth.org>
Date: Thu, 09 Jul 2009 09:43:34 EDT
Message-ID: <56673.1247147014@dbooth.org>
To: <david@dbooth.org>, "Olivier Rossel" <olivier.rossel@gmail.com>
Cc: "Pierre-Antoine Champin" <swlists-040405@champin.net>, "Pat Hayes" <phayes@ihmc.us>, "Hugh Glaser" <hg@ecs.soton.ac.uk>, "Danny Ayers" <danny.ayers@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>, "semantic-web@w3c.org" <semantic-web@w3c.org>, "Richard Cyganiak" <richard@cyganiak.de>, "Leo Sauermann" <leo.sauermann@dfki.de>
(Discussing 303-redirect services, such as  http://t-d-b.org/ or http://thing-described-by.org/ )

 On Thu 09/07/09  6:12 AM , Olivier Rossel olivier.rossel@gmail.com sent:
> Externalizing the 303 feature is the good idea, imo.
> 
> But such a service should also handle the content negociation feature.
> So the 303 may redirect to different URLs depending on the content
> negociated. This makes the service more complex internally but
> provides a very relevant service for RDF publishers (i.e they just
> have to take care of one config on their server : mime-types).

That sounds like an interesting idea.  It would require that URIs be registered in advance with the t-d-b.org server, so that it would know where to forward, depending on the Accept header (content negotiation), in a similar way that URIs are registered in advance with the purl.org server.   Correction:  come to think of it, that would not be necessary.  Instead the t-d-b.org server could be configured to have one or more standard recipes available for converting a generic URI to a specific URI depending on the content type requested.

For example t-d-b.org might have a recipe called conneg1 such that, given a GET request for URI
    http://t-d-b.org/conneg1?http://example/mydata
if the Accept header indicates that RDF is preferred, then the server could 303-redirect to
    http://example/mydata.rdf
(Note that the owner of that URI would still have to ensure that the MIME type is served correctly.)  But if the Accept header indicates that HTML is preferred, then the server could 303-redirect to
    http://example/mydata.html

Annother recipe, conneg2, might use a URI pattern, such that {} in the target URI is replaced by rdf or html.  So for example, given a GET request for URI
    http://t-d-b.org/conneg1?http://example/{}/mydata
if the Accept header indicates that RDF is preferred, then the server could 303-redirect to
    http://example/rdf/mydata
But if the Accept header indicates that HTML is preferred, then the server could 303-redirect to
    http://example/html/mydata

Note that a key advantage of this recipe-based approach is that it does not require the target URIs to be registered with the server.  This is beneficial in three ways:

 - Easier to implement the server.
 - Easier for URI owners to use.
 - The initial HTTP request can be safely optimized away by smart clients, as described here:
http://thing-described-by.org/#optimizing 

What kinds of recipes would be most useful to foks?

> Plus managing the redirect  is as easy as changing the xml:base of
> their RDF/XML.

That sounds like a somewhat different design than I sketched above.  Can you describe in more detail what you mean, with an example?  What would the t-d-b.org server do, and how would it know to do it?

David Booth
Received on Thursday, 9 July 2009 13:44:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:13 UTC