Re: Uniform access to descriptions

Thanks Jonathan,

    I do think it is *important* for the the TAG to ratify a way for
some sort of normative description to be attached to a resource.  The
current suggestion, to revive the "Link" header, is a good one. However,
it would be a mistake to "just" let a revived Link header do all the
work. Just like in the case of 303 redirection, many average people do
not understand HTTP headers in general. What would be best would be a
general purpose solution that deploys a new RDF predicate (something
stronger than rdfs:seeAlso and resembling foaf:primaryTopic) with
"normative" import, so that an application can expect to find
"authoritative" metadata there. This would be like the distinction
between informative references in W3C specs (much like rdfs:seeAlso) and
normative ones (what in RDF already covers this?).

This new predicate, let's call it ex:describedBy, should be able to
instantiate itself in 3 ways:

1) As a typed link header, as in "Link:

This should be equivalent to some RDF.

2) As a normal RDF statement, as "

This RDF should be able to be embedded in any HTML page, in case user
does not know about HTTP headers or RDF.

3) In HTML (and arbitrary XML):
<LINK rel=""
More detail to follow, but I think we're generally on the right track
with reviving the Link header. But we need to be careful about
inscribing distinctions like "information resource" and so on into
Webarch forever, and make sure any solution can operate on the most
common levels of the Web equally. We also should make sure any solution
is *easy* to deploy over various levels and makes it perfectly clear
what's going on (somewhat unlike 303, which is rather hard to deploy and
minimalist). Hope this helps!


Jonathan Rees wrote:
> Dear all,
> The issue of uniform access to metadata (or "descriptions", see wiki
> page below) has resurfaced recently on the www-tag mailing list and
> elsewhere.  In case this characterization doesn't ring a bell, this is
> the problem that the revival of the Link: header is supposed to solve
> - given a URI, obtain information about, or associated with, the
> document / resource / thing.
> At the risk of delaying progress I think it's worthwhile to verify
> that we have the right solution, and to consider benefits (and costs)
> of possible improvements.  We may never get another chance to get this
> right.
> I have done some research to locate as many interested parties as
> possible, and now invite you all to discuss this issue on the
> mailing list.  Information about subscribing is at [2].
> Subscribing is probably a more reliable way to participate than
> inclusion in a cc: , but if you prefer to participate without
> subscribing we'll do our best to include you.
> At Dan Connolly's suggestion I would like to start by collecting use
> cases, which I volunteer to collate, and use them to drive discussion
> of exactly what form the solution should take and what process should
> be used to standardize it.  So please send your uses cases to www-tag.
> I have started gathering materials on this topic on a wiki page [3],
> which you are invited to browse.  This is a followon to a similar page
> started by TimBL [4].
> I'm happy to do what I can to coordinate the effort and drive it to a
> speedy conclusion.
> Best
> Jonathan Rees
> Science Commons and TAG
> [1]
> [2]
> [3]
> [4]
> Bcc:
>   Stuart Williams, TAG
>   Jonathan Rees, TAG
>   Tim Berners-Lee, TAG
>   Dan Connolly, TAG, HTML5
>   Ian Hickson, HTML5
>   Harry Haplin, GRDDL
>   Phil Archer, POWDER
>   Sean Palmer
>   Jonathan Borden
>   Mark Nottingham, HTTP WG
>   Ed Davies
>   Mikael Nilson
>   Ian Davis
>   Patrick Stickler
>   Graham Klyne
>   Alan Ruttenberg


Harry Halpin,  University of Edinburgh 6B522426

Received on Thursday, 20 March 2008 12:21:16 UTC