Re: Address Bar URI

On 18 Oct 2011, at 15:16, Michael Smethurst wrote:

> 
> 
> 
> 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
I like the idea of a geek quotient!
Actually, quite seriously we should always think who the consumers are when constructing mechanisms and patterns.
> 
> 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?!?
Yes, we can follow the data.gov.uk patterns.
But when we defined those, we never discussed what should be displayed in the address bar - and in fact a choice was not easily possible.

I really appreciate all this discussion.
My summary is that for a site doing vanilla 303 as I do on RKB etc., and as dbpedia and data.gov.uk do, some people are quite in favour, and the reservations of others are centred around whether the vanilla 303 is the right way to do it at all.

I'm going to do it, or rather Ian is going to do it for me.

Many thanks.
>> 
>> 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.
> 					
> 

-- 
Hugh Glaser,  
              Web and Internet Science
              Electronics and Computer Science,
              University of Southampton,
              Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

Received on Tuesday, 18 October 2011 14:41:45 UTC