Re: Address Bar URI

Hi Michael

Let me try to write down your case as I understand it, trying to avoid
Capitalized Buzzwords ;-)
Seems a good idea to me, although it introduces yet another level of
indirection in the picture, but maybe we need it.

We have three different types of animals to identify by URI

1. Something known as 'foo' in the "real" (or not) world :
http://example.org/thing/foo
2. A generic information resource binding the various representations of
'foo' on my server(s) : http://example.org/resource/foo
3. Representations/renderings of 'foo' in various formats (html, rdf, xml,
json, ...) / languages etc : http://example.org/resource/foo.html

The first URI is used in RDF descriptions of the thing, that I get for
example at http://example.org/resource/foo.rdf
The second URI is not used in the RDF descriptions whatsoever. It's a webby
trick enabling easy copy-paste, caching, display in address bar, whatever
deal with Web conversation only interested in information resources. It's my
IR proxy to 1.

The conneg for 1 is a systematic 303 to 2, whatever the query.
The conneg for 2 indirects to the desired type of representation.

Using 2 in Web dialogue avoids confusion : the URI in the browser is not
misleading. You've asked for an IR, here it is, and in the format you've
asked.

Do I get your point correctly?

Bernard

2011/10/18 Michael Smethurst <Michael.Smethurst@bbc.co.uk>

> **
>
> Hi Richard
>
> (Again top post courtesy of webmail. sorry)
>
> I'm saying dbpedia is missing the concept of a *generic* information
> resource URI and it's that URI that should show up in the address bar and be
> used in link targets. Ignoring the linked data aspect for a moment if you
> publish your data in various serialisations like:
>
> - /foo.html
> - /foo.xhtml-mp (mobile profile xhtml for feature (non-smart) phones)
> - /foo.json
> - /foo.xml
>
> you want to allow people to copy and paste the address bar into email /
> twitter etc and for someone clicking the resulting link to get back an
> appropriate representation (depending on their accept headers + a bit of
> messy device detection in the case of the html and xhtml-mp)
>
> So you need a generic IR URI that does the conneg / device detection and
> sends back the appropriate serialisation without a redirect. The generic IR
> URI (/foo) stays in the address bar and the full location (/foo.json etc) is
> only exposed in the content location header (not in the address bar)
>
> All links then target the generic IR resource (not the NIR and NOT the
> specific representation (.html etc))
>
> So link targets are to generic ir uri and the address bar always shows the
> generic ir uri. Which gives you two benefits:
> - you only expose one set of uris to crawlers (google etc)
> - the uri in the address bar becomes universally sharable with copy + paste
>
> It's reasonable / necessary to expect publishers to take a conneg / device
> detection hit for every request because you want your content shared and the
> ability to send back an appropriate representation and it's all nicely
> cachable (even in cdn mode) with varies
>
> It's not reasonable / necessary to expect publishers to take an uncachable
> 303 hit for every request
>
> When you start writing rdf you just need the ability to talk about
> something that can't be sent down the wires. So you add in the nir uri. If
> someone requests the nir then:
>
> nir > 303 > *generic* ir > conneg > ir representation (url only exposed as
> location header)
>
> lots of linked data seems to do the 303 and conneg as one step but they're
> not happening for the same reason. the job of the conneg is to return an
> appropriate representation from the ir; the job of the 303 is to say "i
> can't send you that but here's some information that will hopefully be
> useful". conneg is needed regardless of whether you're doing linked data and
> linked data only adds in the 303 when the nir is requested. i think the two
> steps tend to get conflated in linked data publishing patterns and we should
> attempt to separate them
>
> hth
> michael
>
>

-- 
*Bernard Vatant
*
Vocabularies & Data Engineering
Tel :  + 33 (0)9 71 48 84 59
Skype : bernard.vatant

--------------------------------------------------------

*Mondeca**          **                   *
3 cité Nollez 75018 Paris, France
www.mondeca.com
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>