- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 28 Sep 2007 23:22:19 +0200
- To: Dan Connolly <connolly@w3.org>
- Cc: "Henry S. Thompson" <ht@inf.ed.ac.uk>, www-tag <www-tag@w3.org>
On 28 Sep 2007, at 21:28, Dan Connolly wrote: > On Fri, 2007-09-28 at 21:09 +0200, Richard Cyganiak wrote: >> On 28 Sep 2007, at 20:24, Dan Connolly wrote: >>> The 303 redirect stuff is almost always more trouble than it's >>> worth. >>> I can't think of any cases other than legacy when I'd recommend it. >>> Using doc#term is much more straightforward. >> >> I'm surprised to hear that. >> >> As I understand it, <doc#term> without 303 can't handle content >> negotiation. >> >> If RDF is served at <doc>, then <doc#term> identifies whatever the >> RDF says about it (so it could be anything). If HTML is served at >> <doc>, then <doc#term> clearly identifies a section of an HTML >> document. To me, that seems like an unacceptable ambiguity. A 303 >> from <doc> to <doc.rdf> and <doc.html> is needed to resolve this. >> >> So, are you saying that content negotiation is not worth the trouble, >> or that the ambiguity doesn't matter? > > Some combination of the two. > > (a) I'm inclined to update the HTML media type spec to say > that in a document with head/@profile present, what > fragments refer to is not necessarily sections of the document; > it's whatever the profile says it is (e.g. baseball players > discussed in the document, etc). I like this. But at the moment the RFC doesn't allow this interpretation, and I hear that @profile is at risk in HTML5. So, your inclination isn't quite enough to stop me from worrying about the ambiguity. > (b) publishing only RDF without the HTML is pretty useful. Yes, sure, no disagreement here. But content negotiation can be pretty useful too. That's why I'm surprised to hear that you never recommend 303s. > If you decide later that you want HTML, you can add it. > Note that it suffices to do a 303 redirect for .html; > you don't need to redirect in both cases. You can > just return the RDF in a 200 response to GET /doc . I had suspected it could be done like this -- thanks for confirming. This “asymmetrical” approach is quite subtle though, and also hard to implement and everything but straightforward. If you 303-redirect for both variants, then there isn't any benefit left over slash URIs. My conclusion from this: Hash URIs are preferred only if you are sure that you never will need content negotiation. Otherwise, you simply have to swallow the bitter 303 pill, no matter if you go hash or slash. And since slash URIs are often shorter (no <#it> warts) and more flexible, they are the preferred choice if you want content negotiation. For the purposes of the Cool URIs for SW document, I'm inclined to continue to defend this position. Richard > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > > >
Received on Friday, 28 September 2007 21:22:43 UTC