- From: Susie M Stephens <STEPHENS_SUSIE_M@LILLY.COM>
- Date: Tue, 18 Mar 2008 17:12:52 -0400
- To: Leo Sauermann <leo.sauermann@dfki.de>
- Cc: Dan Connolly <connolly@w3.org>, Danny Ayers <danny.ayers@gmail.com>, Norman Walsh <Norman.Walsh@Sun.COM>, "public-sweo-ig@w3.org" <public-sweo-ig@w3.org>, Richard Cyganiak <richard@cyganiak.de>, "www-tag@w3.org" <www-tag@w3.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
The world clock indicates that there is currently a 5hr time difference between Boston and Berlin, so if the TAG call is at 11am in Boston it would be at 4pm in Berlin. You should verify this though... http://www.timeanddate.com/worldclock/ Susie "Williams, Stuart (HP Labs, Bristol)" To <skw@hp.com> Leo Sauermann <leo.sauermann@dfki.de> 03/18/2008 12:05 cc PM 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> Subject RE: checking "Cool URIs for the Semantic Web" comments... would like more time [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 21:13:51 UTC