- From: David Booth <david@dbooth.org>
- Date: Thu, 09 Jul 2009 09:43:34 EDT
- 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