W3C home > Mailing lists > Public > www-tag@w3.org > September 2007

Re: XML Schema draft populates the intersection of Language and InformationResource [ISSUE-14 httpRange-14]

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 28 Sep 2007 22:28:32 +0200
Message-Id: <670618E6-1BD8-48F1-9AB2-6455ABAD9507@cyganiak.de>
Cc: www-tag@w3.org
To: "Chimezie Ogbuji" <chimezie@gmail.com>


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:54 UTC