W3C home > Mailing lists > Public > www-tag@w3.org > March 2012

either strengthen or retract httpRange-14(a)

From: Jonathan A Rees <rees@mumble.net>
Date: Fri, 2 Mar 2012 09:29:44 -0500
Message-ID: <CAGnGFMJjMM5W9MLnSuLUp=YefV2_huDH22VcfrrZfYsA2TqwwA@mail.gmail.com>
To: www-tag@w3.org
This message says what I think about the mess we're in. I
hope to be transparent regarding possible conflict of interest between
my role as moderator of any consensus process around httpRange-14, and
my role as a contributor with technical opinions.  I have said much of
this before but want to be clear, now that the present change proposal
process has started.

Personally I feel that the (a) clause of the httpRange-14(a)
resolution MUST NOT stand as it is. It must be either strengthened or
retracted.  It is terribly confused, does not solve the problem the resolution
claims to solve, and has divided the community in very
destructive ways.

The supposed purpose of the (a) clause was to resolve an ambiguity
between a URI being interpreted as being the retrieved content (or
something close), vs. being interpreted by reading and understanding
the retrieved content.  That is, if what is retrieved (i.e. 200) is a
description of some resource R, is the URI to be understood to
identify R, or to identify a description of R (the same as, or similar
to, what was retrieved)?

This problem is described in
http://www.w3.org/2001/tag/2011/09/referential-use.html .  A "landing
page" is retrieved from, say, Flickr or Jamendo, and then the URI that
is used for retrieving the landing page is used in RDF on the landing
page to refer not to the landing page, but to the resource that the
landing page describes.

httpRange-14(a) does not help relieve the ambiguity in this case
because both the landing page and what it describes are information
resources.  So Flickr and Jamendo are "compliant" but still ambiguous
in respect to the ambiguity that was supposed to be addressed.

If you are going to say that what Jamendo does is perfectly fine, then
there is no reason not to agree that URIs yielding landing pages that
describe things that *aren't* information resources refer to what
is described.  Knowing only that something is an information resource
has zero practical utility.

(Some say that ambiguity is inherent in communication, so
disambiguation is futile, but this is rhetorical trickery.  This is
like saying democracy should not be attempted because perfect
democracy is impossible.  In fact particular ambiguities such as this
one can be, and are often, addressed.)

So I think we need to either strengthen HR14(a), or retract it.
Here's how one would strengthen it.  One would say that if there is
retrieval (200), then the retrieved representation is an instance -
not just a representation, which could mean a mere description - of
the identified resource.

I am not being precise in this email; refer to the theory of instances
in http://www.w3.org/2001/tag/awwsw/ir/latest/ if you are going to
pick at the details of what I'm saying.

How would this help?  Well, it has inferential power.  It means that
if you say certain things about <U>, then they carry over to retrieved
representations, and vice versa.  For example, if you know or believe
that <U>'s title is "Ducks", then you can know or believe that
"Ducks" is also the title of a representation retrieved using U.  (So this
would be inconsistent with retrieving a landing page whose title was
not "Ducks".)  Similarly, knowing things about the representations can
tell you properties of the identified resource.  Details are spelled
out in the Generic Resources memo.

This gives a logical justification for writing ordinary Dublin Core and FOAF
metadata, and similar kinds of RDF.  It means you can easily refer to
ordinary Web things in RDF without having to deploy secondary URIs for
them with hash or 303.  It aligns reference in RDF with
"identification" at the protocol level.  I think this would be a good
thing because I think easily talking about things on the Web is useful
and natural.  This is what RDF was originally designed for.

People write this kind of metadata all the time, but it is currently
without justification at the level of any published specification.
That the retrieved representations have this particular close relation
to the resource is not implied by RFC 3986, RFC 2616, by Roy
Fielding's REST writings, by AWWW, or by the httpRange-14 resolution.
There is nothing in these sources that would say that there might be
that are not OK as retrievable representations (because they have
properties that what's described doesn't).

(There is one particularly pedantic reading of HTTPbis that might have
httpRange-14(a) as a consequence, but it is a longshot.  I have asked
the HTTP WG for clarification but have not yet received an answer.)

Of course a strengthening of the (a) clause leaves open TAG ISSUE-57,
and if people can't be convinced to use hash URIs or to suffer with
303's defects, then we'd need an alternative discovery mechanism, such
as /.well-known/meta/ or one of the other ones I list in
http://www.w3.org/2001/tag/awwsw/issue57/latest/ .

But I am more interested in consensus than in strengthening in
particular.  I would also be happy with retraction of HR14(a) and an
admission that mere descriptions make perfectly fine retrievable representations
of anything, for all the reasons that Harry Halpin gives here:

I should disclose another potential conflict of interest, which is my
connection with Creative Commons.  Its instructions to authors and
publishers http://labs.creativecommons.org/2011/ccrel-guide/
http://wiki.creativecommons.org/Web_Statement (also my
) implicitly assume a strengthened version of HR14(a) (as I think many
people do).  If that interpretation does not prevail then CC will have
to change its tools and documentation to use some other means for
removing the landing page / document ambiguity, such as the
instanceURI property described in
http://www.w3.org/2001/tag/awwsw/ir/latest/ .  This might be a fine
outcome technically, but it would be a burden on CC.

Received on Friday, 2 March 2012 14:30:15 UTC

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