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

I like this! :)

However, some people will still be concerned about naming their 
resources under a domain that is not theirs. That is not only a matter 
of URI-prettiness, but also of relying on an external service, which may 
cease to exist tomorrow.

However, this could easily be solved. All we would need is a PHP script 
that would behave just like t-d-b.org -- PHP having the advantage of 
working without any .htaccess fiddling, at least in most cases.

So I could basically achieve the same thing with a URI like
   http://example.com/tdb.php?mydata.rdf
or
   http://example.com/a_path/tdb.php?/another_path/mydata.rdf

Of course, this would not prevent the use of specific recipies, like
   http://example.com/tdb1.php?mydata
or
   http://example.com/tdb2.php?/{}/mydata


   pa

Le 09/07/2009 14:43, David Booth a écrit :
> (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 15:47:04 UTC