Re: Explaining the benefits of http-range14 (was Re: [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs) )

Leigh and all, hello.

On 2011 Oct 21, at 12:52, Leigh Dodds wrote:

> Hi,
> 
> On 21 October 2011 08:47, Dave Reynolds <dave.e.reynolds@gmail.com> wrote:
>> ...
[...]
>> Suppose you have been using http://example.com/lovelypictureofm31 to denote
>> M31. Some data consumers use your URI to link their data on M31 to it. Some
>> other consumers started linking to it in HTML as an IR (because they like
>> the picture and the accompanying information, even though they don't care
>> about the RDF). Now you have two groups of users treating the URI in
>> different ways. This probably doesn't matter right now but if you decide
>> later on you need to separate them then you can't introduce a new URI
>> (whether via 303 or content-location header) without breaking one or other
>> use. Not the end of the world but it's not a refactoring if the test cases
>> break :)

[...]
> But I don't see how I'm breaking people linking to it as if it were an
> IR. That group of people are using my resource ambiguously in the
> first place. Their links will also still resolve to the same content.


There's always, in practice, going to be ambiguity in this space, either because data providers are ambiguous about what their URIs denote, or because data consumers misunderstand or misuse them.  The 200/303 distinction is about trying to force providers to making their URIs unambiguous (in an IR/NIR sense).

It's starting to sound, to me, as if the costs of this are subtle but messily real, and may well outweigh the benefits of a goal which is receding as more information providers produce ambiguous URIs, simply because their priorities are elsewhere (for example OGP or Facebook, if I'm understanding those two examples correctly).  This is an argument for conceding defeat on the 200/303 thing.

I think we've been here before.

Back in November 2010, there was a thread about Ian Davis's suggestion that NIRs should simply return RDF with a 200, explaining in that RDF that they're NIRs <http://blog.iandavis.com/2010/11/04/is-303-really-necessary/>.  My understanding of that was <http://lists.w3.org/Archives/Public/public-lod/2010Nov/0115.html>:

> httpRange-14 requires that a URI with a 200 response MUST be an IR; a URI with a 303 MAY be a NIR.
> 
> Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI.

The list of references after that message provide very interesting reading (the whole thread is good, and this current one is recapitulating lots of it).  David Booth, in a couple of messages including <http://lists.w3.org/Archives/Public/public-lod/2010Nov/0235.html>, focuses on the ambiguity created by Ian's suggestion.

What this current thread seems to be suggesting is that this ambiguity is there anyway, and it's just going to get worse, so that the solutions are (a) that any "information architect" should be clear in their own mind about the IR/NIR distinction, and (b) that there should be ways of resolving the ambiguity in a non-heuristic way.  Ian's November 2010 suggestion seems to do that.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

Received on Friday, 21 October 2011 14:14:17 UTC