- From: Jonathan A Rees <rees@mumble.net>
- Date: Mon, 23 Apr 2012 08:33:28 -0400
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
Dear signers, On Sun, Mar 25, 2012 at 5:47 AM, Jeni Tennison <jeni@jenitennison.com> wrote: > Hi, > > Please find below a Change Proposal for the consideration of the TAG > [2] https://docs.google.com/document/d/1ognNNOIcghga9ltQdoi-CvbNS8q-dOzJjhMutJ7_vZo/edit I find that this proposal (and some of the others) as written beats around the bush a bit. As written it does not seem it will make anyone happy, either the 'informationists' (who want to use URIs to refer to the content) or the 'descriptionists' (who want the content to be taken at face value, i.e. you read the content to figure out what the URI refers to). If you just withdraw one prior agreement (httpRange-14) and do not replace it with something else, then there is no prior agreement between sender and receiver, and a responsible sender would have to assume the worst, i.e. that the receiver is hostile and predisposed to interpret the URI in a way different from whatever might be intended. (I'm referring to the important case where there is no describedBy articulated in a way that can be found by all receivers.) That means not using hashless retrieval-enabled http: URIs at all in <...> in the absence of a describedby, which I don't think is what you intend. (There can still be a way to clearly express what's meant - that's what 'contentUri' and 'descriptionUri' are about - but it is ugly.) [The presumption of hostility might be good engineering practice in any case, but that would argue against most referential uses of http: URIs, which is not a position I want to argue either for or against in this message.] The proposals that support the use of hashless 2xx <http:...> in RDF, which include both "no change" and "no longer implies", essentially differ in what a receiver is supposed to do in order to interpret <http:...>. According to httpRange-14 you interpret it to be the content, if there is content, regardless of what the content says. But under "no longer implies" (without describedby) as written there is no guidance, even though I assume you have some idea in mind, based on the rationale you've provided. Here is what I think you mean: To interpret the URI, read the content. If the content says something (such as a describedby statement, or anything else) to the effect that that URI refers to something, take the URI to refer to that thing. Otherwise, either some default behavior kicks in, or else the URI has no agreed meaning and shouldn't be used in <...> at all. In the stilted language of the baseline, you're saying that every nominal representation from a URI is a nominal URI documentation carrier for that URI. This is not the case in the baseline. The status quo is that the URI refers to the content regardless of what the content says. If you want read-the-content to be the prior agreement, then the proposal really needs to say it. In the case where the content does not say what the URI means (using describedby or any other mode of expression), I do not know what default behavior you would like. It could be either that the URI is to be understood to refer to the primary topic of the content (as some have advocated); or it could be that it refers to the content (the status quo). As written, this is unspecified, so again, a responsible RDF-writer cannot use these URIs in communication and have confidence that they will be understood. This will deprecate any RDF that currently uses such URIs (whether in the httpRange-14 way or not), and will not support the new refer-to-primary-topic use case. There are many ways to resolve this, including "punning", so this is not an insoluble problem, but without a shared algorithm for choosing between read-the-content, content, and primary topic, the URIs will be useless. Perhaps a reason for the hedging may be that different clients will have different abilities to rat out a 'describedby' statement within the content (which may or may not be understood as a serialization of an RDF graph), and you're trying to avoid interoperability problems resulting from this. For example, if there is a default rule and the describedby statement is expressed using Manchester syntax, then receivers who can parse Manchester syntax will understand the URI differently from those who can't. This would be an interoperability failure. By leaving it as "no longer implies" you avoid interoperability failures by saying one client will know what's meant and the other one will know that it doesn't know what is meant, and therefore at least won't get wrong answers. But without a common, actionable way to discover description links and agreement on what to do in case there isn't one, as I say, these URIs are not going to be useful for communication when there is no such link, and any use case where content is deployed without one will not be supported. Saying that the meaning of X is unspecified but it's OK to write X anyhow is terrible advice. A side issue: in the case that there is a <U> describedby <V> and V is meant to refer to an information resource, there is no indication in the proposal as to *which* information resource is meant. This is a defect that is shared with the baseline. Any proposal that retains this sort of language ought to say that the URI is to be understood as referring to the information resource whose content is found *using that URI*, not a randomly selected information resource. Another side issue: The proposal imbues the 'describedby' relation with meaning it does not have as documented (i.e. that in <U> describedby <V>, U refers to what the content at V says U refers to (as opposed to any of the other things that might be described) and that V refers to the content retrieved using V). For FYN transparency you would be better off defining a new relation with the stronger semantics you require. Jonathan
Received on Monday, 23 April 2012 12:34:06 UTC