Re: Address Bar URI

On 18/10/2011 12:26, "Dave Reynolds" <dave.e.reynolds@gmail.com> wrote:

> 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
> at.
> 
> 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:
> 
> http://environment.data.gov.uk/id/bathing-water/ukc2102-03600
> 
> This redirects to the generic IR URI:
> 
> http://environment.data.gov.uk/doc/bathing-water/ukc2102-03600
> 
> 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:
> 
> http://location.data.gov.uk/doc/ef/SamplingPoint/bwsp.eaew/03600
> 
> 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.

Yes, I can see the problem. Some data sets are primarily aimed at the
research community and some of those researchers are going to be primarily
interested in NIRs

Not sure how you solve that except specifying up front the geek quotient
level of the intended user community and publishing different ways for
different folks

But if we do want linked data to be adopted more generally and not confined
to the lab then we do need publishing guidelines that work for <normal>
sites and <normal> users. I think that means following the patterns of
data.gov.uk and the rest is developer education?!?
> 
> Dave
> 
> 


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Tuesday, 18 October 2011 14:17:01 UTC