W3C home > Mailing lists > Public > public-lod@w3.org > October 2011

Re: Address Bar URI

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Tue, 18 Oct 2011 12:26:34 +0100
To: Michael Smethurst <michael.smethurst@bbc.co.uk>
Cc: Linking Open Data <public-lod@w3.org>
Message-ID: <1318937194.2359.49.camel@Obsidian3>
Hi Michael,

On Tue, 2011-10-18 at 10:57 +0100, Michael Smethurst wrote:

> All of the problems mentioned in this thread could be solved with the
> addition of a *generic* information resource URI that does the conneg
> separately from the 303. Target the *generic* information resource in
> your links and expose that in the address bar, keep the details of the
> specific representation URL tucked away in content location headers
> and just use the non-information resource as something to talk about.
> So you don't split the URIs you expose to the web and don't bounce
> every request through a 303 and don't need to use replaceState to
> replace the representation URL with something more sharable
> In the absence of a generic information resource URI you've only got
> two choices about what ends up in the address bar: the NIR URI or the
> specific representation URL. IMO it should be none of the above. The
> latter breaks sharing and the former doesn’t make sense

I agree with all you say about the separation of concerns between IR/NIR
and representation choice, that you should not confuse redirection (for
the former) and conneg (for the latter) and that you should have a
generic IR URI.

However, that does not solve all the presenting user problems.

The problem, as I see it, is that developers start from the NIR but then
use web browsers to find their way round the data and then cut paste the
browser locations they find, thus ending up with IRs where they should
have had NIRs. At least that's what I took Hugh's proposal be be aimed

To make it concrete ... the linked data from data.gov.uk follows the
same pattern as you recommend. For example the NIR for one particular
bathing water is:


This redirects to the generic IR URI:


The representation is chosen via conneg (there are
representation-specific uris such as .rdf and .json available but simply
following [NIR -> IR -> representation] does not expose them in the
address bar).

The problem is that a developer trying to use this data starts off with
an NIR from some data set. They want to find some connected resource
they can use in their app. They have been told that an advantage of
linked data is that the URIs are deferenceable and return useful
information like onward links. So they put the NIR in their browser.
They click round to find the information they want, say, the Sampling
Point for the that Bathing Water. They then cut that URI from the
browser bar:


and paste it in their app and/or publish more RDF referring to it. 

I've lost track of the number of times I've seen in published RDF links
to (generic) IR URIs instead of the NIR URIs, presumably as a result of
this pattern of use. I've even done it myself, at least in email
discussions, and I'm definitely supposed to know better!

This is especially painful for this sort of abstract data where the IR
URI isn't really of much use to anyone. It can't see many people writing
web pages linking to the IR. For them the html pages are just a more
readable rendering of the underlying data to help them understand what's
in there. So Hugh's suggestion would actually work quite nicely in such
cases, while being rather inappropriate for the BBC case.

Received on Tuesday, 18 October 2011 11:27:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:17 UTC