- From: Jonathan A Rees <rees@mumble.net>
- Date: Fri, 2 Mar 2012 09:29:44 -0500
- 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 descriptions 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: http://lists.w3.org/Archives/Public/public-awwsw/2011Jan/0021.html 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 http://odontomachus.wordpress.com/2012/01/25/how-to-apply-a-cc0-waiver-to-an-ontology/ ) 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. Best Jonathan
Received on Friday, 2 March 2012 14:30:15 UTC