W3C home > Mailing lists > Public > www-tag@w3.org > February 2008

RE: [httpRedirections-57] Resource-Decription Header: a possible proposal to consider.

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 8 Feb 2008 08:32:52 +0000
To: Jonathan Rees <jar@creativecommons.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
CC: "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
Message-ID: <184112FE564ADF4F8F9C3FA01AE50009DED0FC6B55@G1W0486.americas.hpqcorp.net>

> From: Jonathan Rees
> On Feb 6, 2008, at 8:11 AM, Williams, Stuart (HP Labs, Bristol) wrote:
> > Resource-Description: http://example.org/site.rdf
> ...
> > This is stronger than the "303 'try-over-there <Location:>' 'hint'"
> > because the intention of the Resource-Description: is (or would be)
> > clear.
> ...
> > (Tracker, this is ISSUE-57)
> I think Link: as suggested by Richard is very similar, and has the
> advantage that it is already part of an HTTP spec. The suggestion has
> come up before. Unfortunately Link: disappeared in the move from 1.0
> to 1.1, if I remember my previous research on this correctly.
> The other advantage over 303, to me probably more important than the
> ability to adopt a rule saying that the target is supposed to be a
> description, is that it gives you a standard channel for
> communicating metadata for information resources (200) that don't or
> can't carry their own. This would be important for a wide variety of
> applications, including provenance, versioning, licensing, and site
> policy, that currently have to be layered in awkward ways on top of

You don't have to bake anything in to HTTP to do that.  A 303 redirect can be used with an awww:InformationResource just as it can be used with anything else.  So for example, a URI such as


can be used to denote an awww:InformationResource, and when it is dereferenced, it can 303-redirect to something like


and when that is dereferenced it can return a 200 OK with the RDF metadata that you want, such as (in n3):

        <http://example/doc/ir> hasProvenance prov:whatever .
        <http://example/doc/ir> hasVersion "1.20" .
        <http://example/doc/ir> hasMd5Checksum "567990020087678940" .
        <http://example/doc/ir> hasBitsAt "http://example/doc/bits" .
        <http://example/doc/ir> owl:sameAs <http://example/doc/bits> .

And dereferencing http://example/doc/bits can yield a 200 OK with whatever bits you were trying to denote.  Note that http://example/doc/ir would be the URI that you would want to publish -- not http://example/doc/ir , even though they denote the same awww:InformationResource.

Anyone (or any group) can write a specification that details exactly what conforming implementations should do to follow these conventions.  People may or may not follow them, just as they may or may not use a new HTTP header if it is added to the HTTP spec.  Defining a new HTTP header will not force people to adopt it, just as defining conventions like these will not force people to adopt them.

> [ . . . ]
>  The only other route I can think of
> (other than variant GETs, which have been ruled out) is a
> deterministic syntactic rule to go from a thing's URI to the URI of a
> description of the thing, in the situation where the first URI has no
> #. You would then "go" from the first URI to the second on the
> client, and do a GET of the second. I think it's probably too late in
> the game for this.

No it isn't.  Anyone can (nondestructively) layer their own syntactic conventions on top of http URIs, as I have previously described:

A good example of this is http://thing-described-by.org .  Suppose you come across the RDF triple

        _:foo _:fum <http://thing-described-by.org?http://dbooth.org/2005/dbooth/> .

and you want to find metadata about the resource denoted by
http://thing-described-by.org?http://dbooth.org/2005/dbooth/ .  If you dereference the URI, you will find that it 303-redirects to
which is a page containing such metadata.  (The page happens to be written in English, but it could just as well have been written in RDF.)  However, as described in
if you know thing-described-by.org's conventions, which could certainly be written into a specification if desired, there is no need to dereference
to determine that
contains the desired metadata.  Instead, the URI prefix
can be stripped off automatically to yield the desired metadata URI.

There may still be some benefit of convenience in adding a Resource-Description:  HTTP header, but all of the stated problems that such a header solves can be solved in other ways.

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Friday, 8 February 2008 08:33:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:55 UTC