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

> From: Williams, Stuart (HP Labs, Bristol)
>
> Hello David,
>
> > From: Booth, David (HP Software - Boston)
> > [ . . . ]
> > 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".

Oops, yes.  Sorry for the typo.

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

Okay, but lest there be any misunderstanding, as explained in
http://dbooth.org/2006/urn2http/#WhyOpacity
the use of a specialized URI prefix like http://t-d-b.org? does NOT violate the AWWW principle of URI opacity.

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

Okay, if you want fewer round trips, then the following technique could be used instead.   Publish the URI http://example/doc#ir to denote your desired awww:InformationResource.  When an app attempts to follow its nose to learn what resource that URI denotes, it will dereference the racine http://example/doc , whereupon you can serve RDF saying something like this (in n3):

  <http://example/doc#ir> hasResourceDescriptionAt "http://example/doc/metadata" .
  <http://example/doc#ir> hasBits "... [bits go here] ..." .

which of course would be nearly equivalent to returning a Resource-Description HTTP header, and it would be just as easy to check conformance.

But if you want to reduce round trips, this could be further improved by returning the metadata directly along with the bits, like this:

  <http://example/doc#ir> a awww:InformationResource .
  <http://example/doc#ir> hasProvenance prov:whatever .
  <http://example/doc#ir> hasVersion "1.20" .
  <http://example/doc#ir> hasMd5Checksum "567990020087678940" .
  <http://example/doc#ir> hasBits "... [bits go here] ..." .

That technique uses only *one* round trip to get both the metadata *and* the bits.  Of course, if the bits are too big to return them all at once (along with their metadata) then you could instead return RDF like:

  <http://example/doc#ir> a awww:InformationResource .
  <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 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...

If you want to do that, then all you need to do is also return RDF like:

  <http://example/doc> a awww:InformationResource .
  <http://example/doc> hasProvenance prov:whatever2 .
  <http://example/doc> hasVersion "3.09" .
  <http://example/doc> hasMd5Checksum "020400876567990789" .
  <http://example/doc> hasBitsAt "http://example/doc" .

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

That advice is a SHOULD, not a MUST:
http://www.w3.org/TR/webarch/#uri-aliases
And in conformance with RFC2119 definition of "SHOULD", this is an good example of a case where a URI alias is justified.

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

Of course, one could also have more than one triple involving hasResourceDescriptionAt.

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

Similarly, anyone asserting

  <http://example/doc#ir> hasResourceDescriptionAt "http://example/doc/metadata" .

would be indicating that <http://example/doc#ir> conforms to such a spec.  Well, to be more precise, it is the URI "http://example/doc#ir" that would be conforming -- not just the resource <http://example/doc#ir>, so the assertion may instead need to be written something like this instead:

  MetadataSpecURIs hasInstance "http://example/doc#ir"^^xsd:anyURI .

where MetadataSpecURIs is the class of URIs that conform to your spec, and hasInstance is the inverse of rdf:type.  I would have written this as

  "http://example/doc#ir"^^xsd:anyURI rdf:type MetadataSpecURIs .

but for RDF's silly restriction that a literal cannot be the subject of a triple.

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

Hmm, that sounds an awful lot like publishing an ontology, now doesn't it?  :)

> (Tracker, this is ISSUE-57)


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.

Received on Saturday, 9 February 2008 22:00:38 UTC