W3C home > Mailing lists > Public > www-tag@w3.org > March 2008

RE: checking "Cool URIs for the Semantic Web" comments... would like more time

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Tue, 18 Mar 2008 16:05:20 +0000
To: Leo Sauermann <leo.sauermann@dfki.de>
CC: Richard Cyganiak <richard@cyganiak.de>, Susie M Stephens <STEPHENS_SUSIE_M@LILLY.COM>, "public-sweo-ig@w3.org" <public-sweo-ig@w3.org>, Dan Connolly <connolly@w3.org>, Danny Ayers <danny.ayers@gmail.com>, Norman Walsh <Norman.Walsh@Sun.COM>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <9674EA156DA93A4F855379AABDA4A5C6119EDA1A48@G5W0277.americas.hpqcorp.net>

[switched to www-tag since public-sweo-ig is already er... public]

Hello Leo, Richard,

> -----Original Message-----
> From: Leo Sauermann [mailto:leo.sauermann@dfki.de]
> Sent: 12 March 2008 09:45
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Richard Cyganiak; Susie M Stephens;
> public-sweo-ig@w3.org; Dan Connolly; Danny Ayers; Norman
> Walsh; tag@w3.org
> Subject: Re: checking "Cool URIs for the Semantic Web"
> comments... would like more time

<snip/>

> Richard and I have looked at the diagram and discussed about
> it, the approach as depicted on above image [3] is confusing
> us, is seems to be different from the photo at [2], and also
> to what is written in http-range-14.
>
> In the *worst* way, I could intentionally mis-interpret [3] as the
> following:
> == worst case===
> * URIthing identifying the thing
> * URIgen identifying a forwarder uri
> * URIrdf identifying a rdf document
> * URIhtml identifying a html document
>
> On a GET to URIthing
> it makes a  303 redirect to URIgen,
> which will do another 303 (based on conneg) to either, URIrdf
> or URIhtml.
> == /worst case ==
>
> 3 http roundtrips - this is not what you had in mind!?

No... that's not how conneg is supposed to work

GET on {URIthing, Accept:=[RDF|HTML]} -> {303, Location: URIgen}
GET on {URIgen, Accept:=[RDF|HTML]} -> {200, [RDFBits|HTMLBits], Content-Location:=[URIrdf | URIhtml]}

Two round trips... as before.

> I would guess that other readers may also mis-interpret the
> provided graphic [3] and therefore would NOT use it as is in
> the document.
>
> My understanding of the decision was:
> == we assumed ==
> Assuming we start with graphic [4], the content-negotiation
> and 303 redirect is handled:
> On a GET to URIthing
> make a 303 redirect from URIthing to URIrdf or URIhtml based
> on conneg, defaulting to "URIhtml" for browsers that do not
> pass RDF as "accept"
> == /we assumed==
>
> YES?

We discussed this at the recent TAG F2F, whether 1) the accept header should influence a choice of redirection target (as shown in [4]), or whether 2) redirection should be to a generic resource and then conneg based on the accept header when performing a retrieval on that generic resource (note same number of round trips).

I believe that we decided that the later (ie. 2) ) is a better pattern in the case where the RDF and HTML representations variant representations of the same resource(information) because it encodes the relation that URIrdf and URIhtml are variants of URIgen (if indeed they are).

Of course 'the same' is tricky - and conceivably RDF and HTML representations could arise from different information sources with different provenance etc. in which case 1) is more correct and avoids encoding the variant relations.

> Out of sheer curiosity, I wonder if using a method indicated
> on [5] may also work for semantic-web redirects... but we
> will stick to 303 in the document, we only wanted to explain
> the http-range-14 decision.

Looking at [5] that seems to be conneg as indicated above - ie. using a Content-Location: header to provide the location of the specific (variant).

> [3] http://www.w3.org/DesignIssues/diagrams/tag/HTTP303.png
> [4] http://www.w3.org/TR/cooluris/img20071212/303.png
> [5] http://www.w3.org/TR/chips/#cp5.2


Regards

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Tuesday, 18 March 2008 16:08:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:53 GMT