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

Hello Richard,

> -----Original Message-----
> From: Richard Cyganiak [mailto:richard@cyganiak.de]
> Sent: 08 February 2008 13:03
> To: Williams, Stuart (HP Labs, Bristol)
>
> Stuart,
>
> On 7 Feb 2008, at 14:59, Williams, Stuart (HP Labs, Bristol) wrote:
> >> There seem to be two issues worth discussing here:
> >>
> >> 1. The perceived need for a generic "metadata channel" in HTTP,
>
> Regarding this issue, a lot of motivating use cases and
> points of pain have now been shown elsewhere in the thread,
> and I was wrong to dismiss it.
>
> I still prefer
>
>     Link: <foo>;rel=meta
>
> over
>
>     Resource-Description: <foo>
>
> because the Link header seems much easier to explain and
> lobby for than Resource-Description. "It's just like the
> <link> element in HTML, but it also works on JPEG files and
> ZIP archives. The header has been around since HTTP 1.0, but
> was removed in HTTP 1.1 because in the late 1990s almost no
> one used it."

>
> Resource-Description, on the other hand, is in danger of
> being dismissed as yet another silly semantic web idea.
>
> So, why not promote the existing and familiar solution,
> instead of reinventing this particular wheel?

FWIW, I don't at present have a preference or a prejudice for or against either. I was ignorant of the "Link: <foo>;rel=meta" pattern until you pointed out.

I will say that the RFC in which it is specified, RFC2068 (via [1] and RFC 4229) has been obsoleted by RFC 2616, the HTTP 1.1 spec (which, AIUI, is now itself the subject of possible revision). That obsolesence leaves me questioning the standing of the Link: header in RFC 2068 as a 'wheel'.

RFC 2068 defines the Link header as follows:

<quote>
19.6.2.4 Link

   The Link entity-header field provides a means for describing a
   relationship between two resources, generally between the requested
   resource and some other resource. An entity MAY include multiple Link
   values. Links at the metainformation level typically indicate
   relationships like hierarchical structure and navigation paths. The
   Link field is semantically equivalent to the <LINK> element in
   HTML.[5]

          Link           = "Link" ":" #("<" URI ">" *( ";" link-param )

          link-param     = ( ( "rel" "=" relationship )
                             | ( "rev" "=" relationship )
                             | ( "title" "=" quoted-string )
                             | ( "anchor" "=" <"> URI <"> )
                             | ( link-extension ) )

          link-extension = token [ "=" ( token | quoted-string ) ]

          relationship   = sgml-name
                         | ( <"> sgml-name *( SP sgml-name) <"> )

          sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

   Relationship values are case-insensitive and MAY be extended within
   the constraints of the sgml-name syntax. The title parameter MAY be
   used to label the destination of a link such that it can be used as
   identification within a human-readable menu. The anchor parameter MAY
   be used to indicate a source anchor other than the entire current
   resource, such as a fragment of this resource or a third resource.

   Examples of usage include:

       Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"

       Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"

   The first example indicates that chapter2 is previous to this
   resource in a logical navigation path. The second indicates that the
   person responsible for making the resource available is identified by
   the given e-mail address.
</quote>

which is a pretty big Swiss-army knife.

wrt to web architecture it concerns me that "relationship" (certainly in the case of the "rel" param) are not URI.

ok for 'Resource-Description:' v 'Link: <foo>;rel="meta"', the "rel=meta" piece is just plain boiler plate... so why worry.

I'm bothered at the apparent lack of registry for "rel" and "rev" values (cf the Atom Link Relation registry [2] - which I guess could be overloaded for this. FWIW "meta" doesn't); there doesn't appear to be a "meta" relations specified in the HTML 4.01 <LINK rel="%LinkType%  .../> "%LinkTypes% [3],[4].

Just found the wikipage at [5] and the Link header revivalist thread at [6]... so more to absorb wrt current thinking.

Fwiw, if general form: Link: <objectURI>; rel="property" is but a syntactic variation of the property-value header idea modulo 'property' being a controlled value outside of URI space (that being the issue mentioned above.

Rambling through thread at [6]: ...missed grounding through profile... but what about "rel=" values in header space rather than document content... and an expired draft [7]

[1] http://www.iana.org/assignments/message-headers/perm-headers.html
[2] http://www.iana.org/assignments/link-relations.html
[3] http://www.w3.org/TR/html401/types.html#type-links
[4] http://www.w3.org/TR/html401/struct/links.html#adef-rel
[5] http://esw.w3.org/topic/LinkHeader
[6] http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/thread.html#msg46
[7] http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt

On the whole there is no-point in "Resource-Description:" and 'Link <foo>;rel="meta"' competing. IMO the world would be worse off with two ways of doing the same thing.

The question I have, perhaps for Jonathan and Alan, is: Are such commitments as are implied by the use of 'Link <foo>;rel="meta"' strong enough for your proposes?
It does bring symmetry to the metadata channel; but to 'complain' of 303 as a heuristic, is Link going to be met with the same complaint? And if so... can you elaborate more on the 'strength' of what you need?


> >> 2. the perceived need for stronger semantics than 303's
> >> "try-over- there".
> >
> > 3. Validating conformance with the architecture - which is
> >   roughly I think what Jonathan/Alan have been asking about
> >   (here and elsewhere).
>
> Rest of this mail deals with these issues.
>

<snip/>

> Are objective conformance tests really core to this question?
> The arguments I hear are:
>
> a) HTTP lacks a generic metadata channel, which creates pain
> in scenarios where metadata records are to be associated with
> arbitrary web resources

I think we're and principally you have now agreed on that point... yes.

> b) There's a clear way to associate descriptions with
> representationless resources; shouldn't we have one for
> resources that have representations too?

ditto:

> I don't hear:
>
> c) There is no objective means of determining wether the
> thing at the end of a 303 makes sense.

<snip/>
>
> > 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.
>
> You (and/or Alan) ask: When does a deployment conform to 'the
> architecture'?
>
> I'm quite satisfied if that question can be answered by
> referring to guidelines and best practices. I don't care at
> all if it can be objectively measured or not.

That it is of no interest to you does not mean that it is not a legitimate need for others... I can't represent that need for them, and I'm scratching around (currently without success) to find pointers to discussions/arguments that I've seen.

> Why would that matter?

For some, comformance with standards, specifications, conformance, it is an factor deciding to trust a source of information (whether or not to polute ones knowledge base). In such cases a machine (agent) needs away of making an objective assessment - it's likely to have a hard time with "pirate code" (they're more like guidelines).


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

Cheers,

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

Received on Friday, 8 February 2008 15:05:59 UTC