Re: httpRange-14 Change Proposal

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