- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 28 Sep 2007 22:28:32 +0200
- To: "Chimezie Ogbuji" <chimezie@gmail.com>
- Cc: www-tag@w3.org
On 28 Sep 2007, at 21:41, Chimezie Ogbuji wrote: > Richard Cyganiak writes: >> 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. > > Is this really such a bad thing? I think of content negotiation as > nothing more than additional mechanism for client/server handshaking > and not a *necessary* component for well-engineered, RESTful ('Cool') > URIs. Content negotiation is rarely necessary, but often useful. >> 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. > > Well, I'm not sure it follows that it 'clearly' identifies a section > in the HTML case - unless you are using the web-arch notion of > 'identifies' and not denotation but even so... *Of course* I'm using the web-arch notion of “identifies”. > As I understand it, the 200 response (as well as the payload recieved) > is a protocol-level cue to the 'nature' of <doc> but not <doc#term>. > It is the web client that interprets the frag Id as a visual cue for > shifting focus, but this is heuristic at best and certainly not more > authoritative than an assertion in RDF such as: > > <doc#term> rdf:type <html:fragmentIdentifier> No, you are wrong. RFC 3986 says that the “nature” of <doc#term> is determined by the media type of <doc>, governed by the RFC that has registered that media type. The registration for HTML says that fragments identify parts of the HTML document; the registration for RDF says that fragments can identify things outside of the document. Thus the ambiguity. See RFC 3986 and the registry at [1]. Best, Richard [1] http://www.iana.org/assignments/media-types/ >> To me, that seems like an unacceptable ambiguity. > > I don't agree. The ambiguity (IMHO) is due to the fact that nothing > authoritative can be inferred about what is 'denoted' by the frag > identifier from an HTML representation alone, whereas (in the case of > RDF), an authoritative conclusion about what is denoted *can* be > reached (with the right assertions) since RDF is a KR and HTML is not. >> A 303 from <doc> to <doc.rdf> and <doc.html> is needed to resolve >> this. > > That's one approach. Note, however, this can also be resolved without > the need for protocol-level trickery (which doesn't even contribute > any additional cues to the nature of the <doc#term>): <doc> can > respond with an HTML reprsentation which has an authorized mapping to > RDF (via GRDDL). The GRDDL result can include 'authoritative' > assertions about <doc#term>. > >> So, are you saying that content negotiation is not worth the >> trouble, or that the ambiguity doesn't matter? > > I can't speak for Dan, but I'd say it is not worth the trouble - at > least for scenarios where the problem being addressed is providing > both human and machine readable content from the same URI > > -- Chimezie >
Received on Friday, 28 September 2007 20:28:48 UTC