- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 29 Nov 2012 23:21:58 +0100
- To: nathan@webr3.org
- Cc: Ted Thibodeau Jr <tthibodeau@openlinksw.com>, Jόrgen Jakobitsch <j.jakobitsch@semantic-web.at>, WebID Group <public-webid@w3.org>
- Message-Id: <5AB60FEC-C39D-478A-9B6C-C95707B77AC7@bblfish.net>
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/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 30 November 2012 00:20:05 UTC