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

Hi,

as a starting compromise for the telco, I could envision a document 
where we describe both approaches with their advantages and disadvantages,
see below

It was Williams, Stuart (HP Labs, Bristol) who said at the right time 
18.03.2008 17:05 the following words:
>> == 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.
>   

Assuming your decision in TAG, and your explanation, I would propose to 
describe both as following:

Solution "generic document" to be used when 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).

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


Solution "different documents" to be used when RDF and HTML 
representations are conceived as being different. For example, when 
using different information sources with different provenance, then the 
URIthing will redirect to different version using conneg:

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


Both cases can happen in the wild and best practice by *CLIENTS* should 
be to always define "Accept:" headers when GETing RDF data.

 From the practical side for developers,
the "Content-Location:" header field is not so intuitive
--> firefox does not show the "Content-Location" in the page info ....
when redirecting to the different URIS [URIrdf | URIhtml] you see the 
uri obviously in the browser bar,
which may be good for debugging and understandig the magic behind....

alas,
see you thursday
Leo




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


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________