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.ros...@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
