- 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