Re: Proposal to amend the "httpRange-14 resolution"

Thanks for your proposal and comments.

Please be aware that the document is not meant as a defense of the
status quo, but rather as an opportunity to fix it. So it isn't really
necessary to provide general criticisms; many of these are well known.

I understand that the document is not an introduction to linked data,
or a general guide for linked data publishers, or an attempt to
address the problems (a)-(d) that you rightfully point out, but it was
not meant to be. The community can and should fix these separately.

I wrote my document from the receiver's point of view side - "what
does this URI mean", and by implication the sender's point of view
"what can I write so that I'll be understood". You seem to be arguing
for a presentation from the URI owner side "if I want senders and
receivers to have a particular understanding among one another, what
do I need to do." I don't think this is necessarily the best way to
couch the problem, as the URI owner doesn't always have a stake in the
sender/receiver interaction, but it is a legitimate question and your
approach might be better, so I will place it in my list of editorial
issues. One of the sticky points is what the receiver should do if the
URI owner didn't have any particular intention at all for how the
sender was supposed to use the URI (other than as the target-URI of an
HTTP request, or in @href). The httpRange-14(a) clause starts to cover
this case, in a way that obviously not everyone agrees with (I
certainly find it flawed since it doesn't help in the Flickr/Jamendo
situation).

Thanks for the input - I found it quite valuable - and I hope you stay
engaged. If I sound critical it's only because I've been staring at
this for too long, not because I mean any harm. It is really important
I think for the TAG to hear a diversity of views.

A few comments inline below.

Best
Jonathan

On Wed, Feb 29, 2012 at 9:05 PM, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote:
> As a brief follow-up to the previous message, a couple of points:—
>
> The document “Understanding URI Hosting Practice as Support for URI Documentation Discovery” is as written one which nobody who is perceived to be hindered by the httpRange-14 issue will ever read. Even the title is massively off-putting.

Hmm, if so that is unfortunate; I was hoping at least two or three
such people would read it. My motivation was that since people have
been talking past each other, mostly due to lack of a common
vocabulary and framework, setting the situation out precisely was
important. This was a gamble, and I hope it doesn't backfire.

> More pressingly, however, it appears be to be written to answer the question “how can I tell, given a representation, whether the URI I had refers to a thing, or the document describing that thing?” — this is a question which crosses problem domains, and I’m not convinced is the actual problem at all. Maybe I've misunderstood the document; it is rather unwieldy.

Hmm. I thought the problem was clearly stated: people are saying 303s
have performance and deployment problems, they don't like hash as an
alternative, consensus threatens to unravel, what should we do? Live
with 303 as you suggest, and advocate hash URIs to avoid the 303
problems? That's certainly fine by me, but then I'm going to be
pleased by any consensus. Not everyone agrees, so how can we bring
them around and get consensus around that answer? Is there any other
answer that is more likely to get consensus?

Certainly there are many other problems relating to linked data, but
it was not my aim to take them on.

> The answer to that specific question is “interpret the assertions associated with the requested URI”; they might be false, but that applies to any assertions on the Web. QED. After all, this is all focussed on the naming of things which have machine-readable descriptions; it’s not up to the name nor the HTTP response to make that distinction. We don’t have well-defined mechanisms to distinguish by name whether something is a cat or a dog, after all, even if we might have individual conventions about how we might name them.

How do we name things that are on the web, which do *not* have
machine-readable descriptions and for which nobody is following either
Recommendation A or Recommendation B? For example, what Turtle term
would you use to refer to the document found at
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ ? Your Recommendation A
says to use that URI, but your Recommendation B says to deploy and
then use 303 (as is done at dx.doi.org), which would have to involve a
second URI.

This is the kind of question that led me to a receiver-centric
presentation. To me the real technical question is, how does the
receiver interpret what the sender says? Having answered that, sender
and URI owner behavior can then be deduced, as whatever it needs to be
in order for the sender to be understood by the receiver. This
receiver-centric presentation is in fact the way most format and
protocol specs are written.

> The actual question is: ”as a publisher, how can I name resources such that consumers of my data can differentiate between my descriptions of documents, representations, and NIRs while also allowing the descriptions of my NIRs to be retrieved by derefrencing the URIs I assign to them?”

Once a description (documentation) is available, those distinctions
can be made in RDF. The hard parts are things like agreeing on where
to find that documentation, how to tell whether it's there in the
first place, what to do if it's not found, and so on.

You are inspiring me to prepare a set of test cases, since the same
ones keep coming up: dx.doi.org, Flickr, Jamendo, Manchester syntax,
data:, and so on.

> It’s this question which most looking to httpRange-14 — and subsequent discussions — have sought an answer to, what the functioning of linked data is predicated upon, and so this is what my proposal was written to answer, albeit in rather rough form.
>
> Given that, I'd suggest a new title of “Guidance for linked data publishers: Choosing URIs”.

But we already have such guidance, in many places, such as the "Cool
URIs for the Semantic Web" note. If these documents aren't working
that's too bad but it's not the problem I'm trying to solve. Are you
saying the TAG ought to take on more leadership in this area? Good
exposition is a hot potato but I'm not sure the TAG is the best place
to do the work, and it is not being urged on us.

> Further, the premise for this exercise seems to be the notion that both 303-based redirects nor hash-URIs have horrible fatal flaws which make them unworkable, when it's not all that clear that this is the case (particularly in the case of hash URIs, the criticisms at http://www.w3.org/2001/tag/awwsw/issue57/20120202/#hash seem pretty weak from a linked data consumer’s perspective, all told).

No, the premise is that there is weak consensus and it is desirable to
get strong consensus. I agree completely that the merits of those
arguments are unclear - I was only trying to record what other people
were saying. (I could have done better with the attributions.) But the
opponents of hash+303 are respectable and have some good points. How
do you think is the best way to bring the community together on these
issues? The TAG could dig in its heels and try to advance a  document
on Rec track that doesn't give an efficient and easily deployed way to
do discovery for hashless URIs, do you think this would help get
consensus, even if combined with additional how-to guidance? I don't
know.

> M.
>
> --
> Mo McRoberts - Technical Lead - The Space,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Thursday, 1 March 2012 17:23:48 UTC