W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

RE: Request for feedback: HTTP-based Resource Descriptor Discovery

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Thu, 29 Jan 2009 16:12:33 +0000
To: Jonathan Rees <jar@creativecommons.org>, Eran Hammer-Lahav <eran@hueniverse.com>
CC: "www-tag@w3.org WG" <www-tag@w3.org>
Message-ID: <CD2B872281385A439B98164F5351E6DD41432BD684@GVW1144EXB.americas.hpqcorp.net>

> From: Jonathan Rees
> > http://tools.ietf.org/html/draft-hammer-discovery-00
> [ . . . ]
> - I anticipate some confusion as to whether the link relates the
>    resource to the DR (as in the POWDER 'describedby' definition you
>    quote), the URI to the DR, or the URI to the DR's URI (as in the
>    second sentence of section 6).  In RDF, <resource> describedby <dr>
>    is most natural to write, but RDF semantics rules out the
>    possibility that this might say anything specific to a particular
>    URI naming the resource[*].  This protocol is an 
>    opportunity for the
>    URI owner to say things not only about the resource but about the
>    URI/resource binding itself, such as its authority, provenance, and
>    stability, and that will vary with URI, not resource, as each URI
>    might have a different "owner".
>    This issue may be esoteric enough that addressing it might be more
>    confusing than not, but I want you to consider yourself forewarned.

But this is *exactly* the issue that arises when one wishes, for example, to indicate that one URI has been deprecated by another URI: you need to talk about the *URI*, not about the resource *denoted* by the URI.  So I do think it is important to raise this point.  This has come up in other discussions, BTW, such as

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
Received on Thursday, 29 January 2009 16:13:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:26 UTC