W3C home > Mailing lists > Public > public-webid@w3.org > November 2012

Re: #URIs and redirections

From: Nathan <nathan@webr3.org>
Date: Thu, 29 Nov 2012 00:37:50 +0000
Message-ID: <50B6AE5E.9090405@webr3.org>
To: Henry Story <henry.story@bblfish.net>
CC: Ted Thibodeau Jr <tthibodeau@openlinksw.com>, Jόrgen Jakobitsch <j.jakobitsch@semantic-web.at>, WebID Group <public-webid@w3.org>
Henry Story wrote:
> On 28 Nov 2012, at 23:59, Henry Story <henry.story@bblfish.net> wrote:
> 
>> On 28 Nov 2012, at 21:25, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>>
>>> All --
>>>
>>> A potentially interesting bit here, since one of the major
>>> points of all this discussion is interoperability of tools
>>> and the power of follow-your-nose...
>>>
>>>
>>> On Nov 24, 2012, at 05:52 AM, Henry Story wrote:
>>>
>>>> - http://xmlns.com/foaf/0.1/knows
>>>> - http://xmlns.com/foaf/0.1/mbox
>>>> - http://xmlns.com/foaf/0.1/Person
>>>> - http://xmlns.com/foaf/0.1/Agent
>>> The above all look right in my Mail.app, and I can click any
>>> of them and get redirected to <http://xmlns.com/foaf/spec/>.
>>>
>>> (
>>> Tangentially, this redirection seems overly broad.  
>>>
>>> Remembering that 303s can be applied to the document portion 
>>> of a URI, but cannot take the fragment ID into account [while 
>>> 303 *targets* *can* include a fragment ID.], I would expect 
>>> the first URI above to redirect to either 
>>> <http://xmlns.com/foaf/spec/#knows> or
>>> <http://xmlns.com/foaf/spec/knows> [which could then
>>> redirect again to <http://xmlns.com/foaf/spec/#knows>] ...
>>> and actually, I'd expect the generic /spec/ to redirect to
>>> a specifically versioned target, not the other way around...
>>> )
>>>
>>>
>>>
>>> But the following, which Henry initially seemed to be 
>>> suggesting as better (though his conclusion seems otherwise)?
>>>
>>>> - http://xmlns.com/foaf/0.1/knows#•
>>>> - http://xmlns.com/foaf/0.1/mbox#•
>>>> - http://xmlns.com/foaf/0.1/Person#•
>>>> - http://xmlns.com/foaf/0.1/Agent#•
>>> These URIs don't look right in Mail.app.  
>>>
>>> The URI highlighting stops at the last solidus ("/"), so 
>>> they all look like links to the same page -- 
>>> <http://xmlns.com/foaf/0.1/> -- and that is where clicking
>>> them takes me. 
>> Does the following work better? I had perhaps wrongly used a unicode character
>> right after the # .
>>
>> - http://xmlns.com/foaf/0.1/knows#it
>> - http://xmlns.com/foaf/0.1/mbox#it
>> - http://xmlns.com/foaf/0.1/Person#it
>> - http://xmlns.com/foaf/0.1/Agent#it
> 
> Mhh. No they don't as each of them redirect to the
> same URI it seems:
> 
>   http://xmlns.com/foaf/spec/#it
> 
> $ curl -I http://xmlns.com/foaf/0.1/knows
> HTTP/1.1 303 See Other
> Date: Wed, 28 Nov 2012 23:23:34 GMT
> Server: Apache/2.2.14 (Ubuntu)
> Access-Control-Allow-Origin: *
> Location: http://xmlns.com/foaf/spec/
> Vary: Accept-Encoding
> Content-Type: text/html; charset=iso-8859-1
> 
> That seems unfortunate.

Sorry for the slow response, as I could have saved some time.

By HTTP(bis), the fragment must be recombined "If the original URI, as 
navigated to by the user agent, did contain a fragment identifier, and 
the final value does not, then the original URI's fragment identifier is 
added to the final value."

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-8.1.2

so if you have <http://xmlns.com/foaf/0.1/knows#it> and you GET 
<http://xmlns.com/foaf/0.1/knows> which redirects 303 to 
<http://xmlns.com/foaf/spec/> then the final URI (by HTTP) is ...
...
  <http://xmlns.com/foaf/spec/#it>
... for every property in the above scenario

BUT that's by HTTP.

By RDF you'd just look to see what the representation ultimately 
received after the chain of redirects said about 
<http://xmlns.com/foaf/0.1/knows#it>.

Of course, this does raise a few nuances.. like by HTTP all the URIs you 
suggested would be equivalent to <http://xmlns.com/foaf/spec/#it> ;)

Best,

Nathan
Received on Thursday, 29 November 2012 00:39:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:46 UTC