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

Hello David,

> -----Original Message-----
> From: Booth, David (HP Software - Boston)
> Sent: 08 February 2008 08:33
> To: Jonathan Rees; Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org; Graham Klyne; Jonathan Borden
>
> > 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.
> > ...
> >
> > 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 HTTP.
>
> 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
>
>       http://example/doc/ir
>
> can be used to denote an awww:InformationResource, and when
> it is dereferenced, it can 303-redirect to something like
>
>       http://example/doc/metadata
>
> 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

I think you meant the second of these to end "/bits".

> denote the same awww:InformationResource.

Ok... that's neat... though it does mean 3 round-trip to get the 'bits' for resources deployed in that way (probably the 90% case for information resources), and folks are already unhappy about 2-round trips (t-d-b.org and its no-opaque optimization notwithstanding) to get descriptions. Neither this nor Resource-Description: of themselves reduce the round-trip to obtain descriptions, but adding a 3rd to get representation bits would be a tough sell... and if the representation bits of the descriptions themselves can have descriptions... getting the bits of a description involves a (probably not terminating) depth first recursion...

        <xxx> ==303==> <xxx/metadata>
      <xxx>/metadata ==303==> <xxx/metadata/metadata>
        ...
      <xxx>/.../metadata ==303==> <xxx/.../metadata/metadata>

Ok... in practice that would probably bottom out... and probably v.quickly... then there is unwinding to get the all the bits.

BTW: this scheme could be argued as to go against the "Avoid URI aliases" GPN in AWWW depending on how you read "arbitrarily different" in the expansion of the GPN.

RD header and doesn't suffer the recursion problem because in the case of an IR, you retrieve the representation 'bits' first - and you only have to get to the metadata about metadata in those cases that you actually want to persue those deeper links.

On cardinalities wrt to description references: I don't know whether multiple Location: headers are allowed, each bearing a single target, if not then 303 and friends can have only a single traget description. "Resource-Description:" could be spec'd to allow a space separated list of URI and/or multiple occurences - allowing reference to be made to multiple descriptions in cases where more than one are known. That could be both blessing and curse...

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

Fair enough... but writing a spec for a new header has the potential to establish an intention that folks using the header would be indicating that they subscribe to.

The/a 'trick' is to try to establish a dominant/single convention (call it a standard) that people predominantly use so that in the main one doesn't have to write code that anticipates all the different conventions that people might create (all the different properties that different people might create to directly or indirectly relate an information resource with a second resource or an alias that serves its representation bits).

<snip/>

> 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
> http://www.hp.com/go/software
>
> Opinions expressed herein are those of the author and do not
> represent the official views of HP unless explicitly stated otherwise.
>

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

(Tracker, this is ISSUE-57)

Received on Friday, 8 February 2008 10:50:35 UTC