- 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