Re: Naive question on redirection.

I agree with Alan that the way the Cool URIs doc is worded doesn't  
exactly clarify this situation.

And to answer Phil's original question...
"Do I know what colour http://www.example.org/home.asp is?"

Short answer --
No. 'http://www.example.org/home.asp' is at that point an information  
resource, a document, that was retrieved instead of the requested  
document. It's important to make careful distinctions between URIs as  
UR-Identity and URIs treated as UR-Location when dereferenced.

Way longer answer --
A server that responds to a URL with a 302 is providing an ambiguous  
response and is saying simply (anthropomorphizing a server) "I found  
the document you requested somewhere other than the location you  
requested." Full stop. That should have no effect on what you can or  
cannot infer about the URI that was dereferenced. It's only talking  
about the document you requested from a URL. The 303 and 307 status  
codes were added to clear up _some_ of this ambiguity. [1]

As Tim Berners-Lee pointed out [2], a 303 response, "... separates a  
thing from a document about a thing". In "Best Practice Recipes for  
Publishing RDF Vocabularies" [3], we recommend responding with a 303  
rather than a 302 when providing a content negotiated response for  
just this reason -- a 303 response is explicit about the fact that  
you're getting back a different document than the one requested (if a  
'document' even exists at that location). Again the actual URL of the  
served document implies no relationship to the original URI except to  
say "Here's another document that I've been instructed to return when  
that URL (with that Accept-header) is requested, do with it what you  
will." Not nearly as ambiguous a response as a 302, although it's  
still not officially quite as explicit a relationship to the original  
requested document as Tim's 'about'.

The 307 response is also explicit about the fact that even though the  
server was instructed to return a document from a different location  
than you requested, it's still the same document you asked for, this  
location is just temporary, and you should keep asking for the  
document at the original location in the future.

When we're talking about content negotiation we're talking about  
_content_ rather than identity, so I don't think it's reasonable to  
make inferences about relationships between URIs based on a server  
response to a URL. Well, with the possible exception of a 301 status  
code which basically says "I have been instructed to inform you that  
the document you requested no longer exists at the requested location  
and will _never, ever_ be at that location again. It's now at an  
entirely different location." This certainly _implies_ that the URI  
that's being dereferenced may no longer be the correct identity of  
that resource, but I don't think you can even infer that.

Just my $.02. Hmmm, more like $1.95.

Jon Phipps
Co-editor "Best Practice Recipes for Publishing RDF Vocabularies"

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
[2] http://lists.w3.org/Archives/Public/public-awwsw/2008Feb/0027.html
[3] http://www.w3.org/TR/swbp-vocab-pub/

On Jun 6, 2008, at 4:09 PM, Alan Ruttenberg wrote:

>
>
> On Jun 6, 2008, at 3:11 PM, Lee Feigenbaum wrote:
>
>> I should have prefaced my comments by saying that I've never dug  
>> deeply into this, and have just tried to learn from what I've  
>> heard and seen from others. So I'm speaking from a position of  
>> inexperience.
>>
>> Alan Ruttenberg wrote:
>>
>>>> <http://thefigtrees.net/id> a foaf:PerosnalProfileDocument .
>>>>
>>>> 302's based on Accept: headers to either
>>>>
>>>> http://thefigtrees.net/id.n3
>>>> http://thefigtrees.net/id.rdf
>>> That's not how CN is supposed to work. You respond to the request  
>>> with the representation, not with a redirection. The Location  
>>> header is where the resource is. 302 is different.
>>
>> I got my example from the recent SWEO publication, "Cool URIs for  
>> the Semantic Web". Please see:
>>
>> http://www.w3.org/TR/cooluris/#conneg
>>
>> is that example incorrect?
>
> This one, I presume.
>> Content negotation is often implemented with a twist: Instead of a  
>> direct answer, the server redirects to another URL where the  
>> appropriate representation is found:
>>
>> HTTP/1.1 302 Found
>> Location: http://www.example.com/people/alice.en.html
>> The redirect is indicated by a special Status Code, here 302  
>> Found. The client would now send another HTTP request to the new  
>> URL. By having separate URLs for different representations, this  
>> approach allows Web authors to link directly to a specific  
>> representation.
>>
>>
>
> It looks incorrect to me. But what do I know? I just read the specs.
>
> Also incorrect: One doesn't link to (awww) representations, one  
> links to resources.
>
> They also say:
>
>> Note that the URI of this representation is passed back in the  
>> Content-Location header, this is not required but a recommended  
>> good practice
>>
>>
> I'd say in your case it would be required ;-)
>
> -Alan
>
>
> (You are in a maze of twisty passages, all alike.)
>
>>
>> Lee
>>
>>> 302 Found
>>> The requested resource resides temporarily under a different URI.  
>>> Since the redirection might be altered on occasion, the client  
>>> SHOULD continue to use the Request-URI for future requests.
>>> Not: you can find a different resource - a fixed resources, which  
>>> happens to have an awww:representation that is the same as the  
>>> one redirected from.
>>>> What if I wanted to include an ex:mimeType triple about the  
>>>> latter ones?
>>> Go ahead. However I don't think 302 is appropriate in that case.  
>>> Respond with the representation to the original request, and put  
>>> these URLs in the Location: header. Then there is no encumbrance.
>>>>
>>>> <http://thefigtrees.net/id.rdf> a foaf:PerosnalProfileDocument ;  
>>>> ex:mimeType "application/rdf+xml" .
>>>>
>>>> Or are you suggesting that this is some strange one-way  
>>>> equivalence? (If X -- 302 --> Y and X p q then Y p q?)
>>> I'm not trying to suggest anything. I'm trying to answer  
>>> according to what the specs say. I'd be happy to be shown to be  
>>> wrong, either because the specs don't mean what I think they do,  
>>> or because there is contradictory information somewhere else, or  
>>> with an assertion that the specs need to be fixed.
>>> -Alan
>>> (don't you just love those "naive" questions?)
>>>> Lee
>>>>
>>>>> On Jun 6, 2008, at 4:57 AM, Phil Archer wrote:
>>>>>>
>>>>>> Suppose I have this triple
>>>>>>
>>>>>> <http://example.org/> ex:colour "red"
>>>>>>
>>>>>> and when I dereference the URI I get a 302 redirect to http:// 
>>>>>> www.example.org/home.asp.
>>>>>>
>>>>>> Do I know what colour http://www.example.org/home.asp is?
>>>>>>
>>>>>> I'm pretty sure the answer's no, but has anyone else grappled  
>>>>>> with the joys of redirects in this way?
>>>>>>
>>>>>> Phil.
>>>>>>
>>>>>> -- 
>>>>>> Phil Archer
>>>>>> Chief Technical Officer,
>>>>>> Family Online Safety Institute
>>>>>> w. http://www.fosi.org/people/philarcher/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
>

Received on Friday, 6 June 2008 22:26:23 UTC