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

The debate generic recipe vs custom redirections is still open.
Probably both should be available (KISS for beginners, but advanced
options for experts).

So when you are behind a paranoid server (i.e no right to manage a
.htaccess) then you add http://t-d-b? at the beginning of the xml:base
of your RDF, and either you stick to the recipes for content
disambiguation or you customize the 303 rules on TDB.


On Thursday, July 9, 2009, David Booth <david@dbooth.org> wrote:
> (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 17:51:28 UTC