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: Pat Hayes <phayes@ihmc.us>
Date: Fri, 28 Sep 2007 18:13:02 -0500
Message-Id: <p06230932c32338ed42e7@[]>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: "Chimezie Ogbuji" <chimezie@gmail.com>, www-tag@w3.org

>On 28 Sep 2007, at 23:05, Chimezie Ogbuji wrote:
>>On 9/28/07, Richard Cyganiak <richard@cyganiak.de> wrote:
>>>>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".
>>Okay then, you are comparing apples to oranges.  Saying RDF
>>'identifies' things is an abuse of notation as far as I'm concerned.
>The terms ≥denote≤, ≥identify≤, ≥indicate≤ and 
>≥mean≤ are used interchangeably throughout the 
>RDF specs. It's unfair to blame me for this.
>The mechanism by which fragment URIs in RDF 
>*identify* (not my choice of term) are spelled 
>out quite clearly in section 7 of rdf-concepts 
>>RDF denotes 'things' (the mechanics for this are very well-defined -
>>/TR/rdf-mt ), web-arch "identifies".  These are not equivalent
>>mechanisms, or at least their definitions do not correspond. If *we*
>>are serious about consistency between 'classic' web architecture and
>>the semantic web, we need to fix this disconnect *before* suggesting
>>best practices prematurely.
>Is there really that much of a disconnect?
>URIs are governed by a paper trail of RFCs, 
>starting at RFC 3986 and leading through the 
>IANA scheme and media type registries, then 
>through the RFCs for the different URI schemes 
>such as http: and urn: and tag:, and through a 
>whole bunch of media type registrations, and 
>from there it bottoms out at specific data 
>format specs such as those for HTML and RDF. 
>Thus, webarch gives us a framework that defines 
>URI-space, how the space is managed, what 
>operations we can perform on URIs, what they 
>identify, and so on.
>That's the framework within which RDF has to 
>operate. In terms of rdf-mt, I take this to mean 
>that the denotation of many URIs (those that 
>have representations, according to httpRange-14) 
>is fixed by the Web.

Well, that is the effective content of 
httpRange-14, but its not by any means implied by 
anything in the RDF specs. If we temporarily 
ignore http-Range-14, then there is no connection 
at all between what RDF means by "denote" and 
what all other W3C or IETF specs mean by 
"identify". As far as RDF semantics is concerned, 
URIs are just blank names with no associated 
structure or meaning.

>There is a school of thought that wants to see 
>URI-space as a blank slate for the purposes of 
>RDF, completely disconnected from the role of 
>URIs on the Web. Personally, I have trouble 
>seeing the advantage of this view. If you want 
>to operate in a universe parallel to the Web, 
>then why use URIs in the first place? Why not 
>simply use KIF or CL?

There are reasons, connected with the global 
uniqueness of URIs. But I tend to agree about CL 
(which can use URIs as names, if one wishes to.)

>(Although, in defense of the ≥parallel universe≤ 
>school, this view is legitimized by a passage in 
>rdf-mt [2], which, it appears, directly 
>contradicts rdf-concepts [1].)

I don't think it does. Where do you see the contradiction arising?


>>>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;
>>Yes, I gathered this from Dan's follow-up response about the HTML RFC
>>being the source of the 'problem'.  Still, the ambiguity you are
>>speaking about is between two completely orthogonal mechanisms for
>>reference ("identification" versus denotation).
>>Frankly (and this has been my perpetual theme), if there is serious
>>concern about ambiguity, then a language well-equipped to handle
>>ambiguity should be used.
>I do not believe that such a language can resolve the ambiguity.
>Quoting RFC 3986:
>≥If the primary resource has multiple 
>representations, as is often the case for 
>resources whose representation is selected based 
>on attributes of the retrieval request (a.k.a., 
>content negotiation), then whatever is 
>identified by the fragment should be consistent 
>across all of those representations.≤
>Combining a text/html representation with an 
>application/rdf+xml representation makes it hard 
>to achieve this consistency, unless additional 
>webarch trickery is used (303).
>The ambiguity arises on the webarch level, and can only be resolved there.
>[1] http://www.w3.org/TR/rdf-concepts/#section-fragID
>[2] http://www.w3.org/TR/rdf-mt/#urisandlit
>>A vacuous notion of "identification" is
>>simply not sufficient.
>>>the registration for
>>>RDF says that fragments can identify things outside of the document.
>>>Thus the ambiguity.
>>See above.
>>  -- Chimezie

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Friday, 28 September 2007 23:13:19 UTC

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