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

Hello Richard,

> -----Original Message-----
> From: Richard Cyganiak [mailto:richard@cyganiak.de]
> Sent: 07 February 2008 11:36
>
> Stuart,
>
> There seem to be two issues worth discussing here:
>
> 1. The perceived need for a generic "metadata channel" in HTTP,
>
> 2. the perceived need for stronger semantics than 303's
> "try-over- there".

That seem's a reasonable framing to me.

I think there's perhaps a third:

3. Validating conformance with the architecture - which is
   roughly I think what Jonathan/Alan have been asking about
   (here and elsewhere).

> More inline.

<snip/>

> Resurrecting the Link: header has been proposed in a couple
> of places, and has some appeal because of it's similarity to
> HTML's <link> element.

Ok... thanks. Anyway I'd be happy to regard "Link: <?u>; rel=meta" as at least equivalent in spirit to "Resource-Description:"

> [snip]
> > Secondly, it was not about solving a problem of efficent exchange of
> > representation  - but about providing a means of, given <?u> (a URI)
> > finding a description of ?u (a resource/thing) (which may be
> > definitive or not) rather than a representation of <?u>.  Compared to
> > 303, Resource-Description: works uniformly for both 200 responses
> > (=>IRs) and 303 (=>not known to be IR) - which is nice.
>
> Good point.

Is that:
        - "hummmm... yes the symmetry is nice."
or
        - "yes... I can see a need to be able to (reliably?) get
          descriptive information about IR as well (as distinct
          from representations)?"

> > Some have been complaining that the httpRange-14 resolution does not
> > reliably allow you to find metadata *about* an IR (unless it is self-
> > describing) - this is away of getting to metadata about ?u.
>
> On the other hand it's not evident to me that HTTP *should*
> have the ability to locate metadata about IRs. This problem
> can be addressed by layering another mechanism on top of
> HTTP, e.g. by embedding the metadata in the IR's
> representation, or linking to the metadata from the IR's
> representation, or by providing the metadata in an external
> well-known location a la sitemaps or POWDER.

I think those with a perceived need have a legitimate concern. It is certainly should be given serious consideration. System's such as Patrick Stickler's URIQA, handles, doi: info: and xri: all exhibit a need to obtain information *about* a thing - which for some of those systems includes information about *where* to find replica so that inorder to obtain bits - absense of such metadata then causes a clear boostrapping problem.

Viz sitemaps, the TAG has an open issue siteMetadata-36 (which has languished for some time). IIRC the general disposition last time we discuss it was not positively disposed to the likes of robots.txt and friends effectively ceasing authority over (albeit thin) tracts of webspace delegated to a given authority.

> I would like to see more evidence that shows a need for a
> generic protocol-level mechanism. Elsewhere in this thread,
> Jonathan cites experiences with LSIDs as one data point. Is
> there more?
>
> >> Your argument seems to be that 303 redirects are too weak; that the
> >> redirect doesn't imply anything more than "try-over-there".
> >
> > There are some who make that complaint about 303. They want to be able
> > to make stronger assertions at least about what is at the end of the
> > redirect chain - in particular they like to be able to assert that
> > some (architectural) conformance requirement has been violated
> > *if* following the chain does not yield a description of (amongst
> > other things) ?u. IMO 303 does not and cannot give such an assurance.
> >
> >> I would like to know why more than this weak implication is necessary
> >> on the transport layer.
> >
> > Others will have to speak up on that... but roughly AFAIUI its about
> > what it would mean to conform and detecting when a source has failed
> > to conform.
> >
> >> Strong
> >> "aboutness" and similar relationships can be expressed, if necessary,
> >> in a representation made available at the redirection target URI.

Missed this one before... with an IR how do you propose that you'd obtain a reference to such a target?

> >> ...
> >
> > I agree... but if no such expressions are found after diligently
> > following such a chain, one has no basis for complaint, no stick to
> > wield to say that any one did anything wrong... one can only complain
> > that they weren't as helpful as the could have been.
>
> I don't think that HTTP should come with conformance
> requirements for the content transported with it.

Firstly, in this respect I was trying to confine the notion of conformance to the definition of a specific header - and not the whole of HTTP. So that *use* of the header in a response is an implicit undertaking to conform with what may be required of its use. That gives a legitimate basis for 'complaint' if for a given use there is a failure to meet those undertakings. Secondly, if there are such undertakings, then there should be an objective means to test whether they have been met. I would couch those in terms of relations that must hold between resources eg. "A :hasDescription B . " (and yes :hasDescription could be used directly in other retrievable representations). The tricky edge case is an apparent description that the recipient is unable to parse/comprehend.

> AFAIK, HTTP doesn't have any language that discourages
> 302-redirecting into a 404-responding resource, although
> obviously doing so is not helpful.
>
> AFAIK, HTTP doesn't have any language that discourages
> serving representations that are wildly inconsistent over
> time, although obviously doing so is not helpful.
>
> IMHO, HTTP shouldn't have any language that discourages
> serving totally off-topic stuff at the end of a 303, although
> obviously doing so is not helpful.
>
> HTTP is concerned with the transport of representations of resources.
> The nature and relationships of those representations are a
> separate concern.

I sort of hear you thumping the table here - maybe that just me hearing the leading CAPs.

The question I hear Alan ask (I'll find a reference if you need one) is how can an agent tell if some deployment (of resources and descriptions) conforms to 'the architecture'. I'm sympathetic to that question... and at present I don't have an answer... do you.... or maybe you don't think it's a relevant question.


regards

Stuart

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

Received on Thursday, 7 February 2008 15:02:44 UTC