Re: #URIs and redirections

On 29 Nov 2012, at 01:37, Nathan <nathan@webr3.org> wrote:

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

No problem. Many thanks for the helpful response below. I was thinking about this today,
but had no time to look it up. I'll use your input to send a mail to the tag mentioning
your points.

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

yes. Thanks for pointing out those nuances. These are difficult issues,
but it looks like my proposed potential solution to http-range-14 can
is still alive ...

> 
> Best,
> 
> Nathan

Social Web Architect
http://bblfish.net/

Received on Friday, 30 November 2012 00:20:05 UTC