Re: Address Bar URI

On Tue, 2011-10-18 at 15:16 +0100, 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.

[snip]

> > 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

[I think we agree but I couldn't let that phrasing pass unchecked...]

You don't have to be a researcher to be interested in data :)

The developers using the bathing water data are doing things like
building consumer apps to enable people check water quality at beaches
they are near. Not academic research.

There may be a distinction between data sets that are generally
consumed as "pure" data and data sets which mostly augment "normal" web
pages. But I don't think that's necessarily a research/real-world
distinction. 

> 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?!?

Probably.

[Personally I think we'd be better off without the IR/NIR distinction,
failing that stick to fragids for NIRs. But I see no value in going
round the block on those arguments yet again!]

Dave

Received on Tuesday, 18 October 2011 14:57:39 UTC