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

Re: Relevancy of RDF model theory to the Web [was: Re: XML Schema draft ...]

From: Pat Hayes <phayes@ihmc.us>
Date: Sat, 29 Sep 2007 23:59:30 -0500
Message-Id: <p06230901c324d4d7d923@[]>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: "Chimezie Ogbuji" <chimezie@gmail.com>, www-tag@w3.org

>On 29 Sep 2007, at 01:13, Pat Hayes wrote:
>>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".
>Let's be accurate, Pat. There is no connection 
>at all between what *rdf-mt* means by ³denote², 
>and what all other W3C or IETF specs -- 
>including other parts of RDF -- mean by 
>³denote², ³identify², ³indicate², and ³mean².

The model theory of RDF isn't a 'part" of RDF. It 
is the (only official) specification of the 
meaning of RDF. The RDF semantics document is 
normative. The words cited mean the same thing 
throughout the RDF specification documents. And 
"denote" means there what it means throughout all 
of logic and linguistics, and has done for almost 
a century. I don't think other W3C or IETF specs 
(except OWL) even use the word.

>The border between the Web and that weird 
>parallel URI universe isn't between RDF and the 
>rest of W3C/IETF. It's between rdf-mt and the 
>rest of the world.

Without its semantics, RDF is just a notation for 
graphs represented in XML. It uses URIs to denote 
things, and that is ALL it uses them for (with a 
few borderline exceptions).  The same applies to 
RDFS and OWL and will apply to the SWeb Rules 

>There are many examples throughout the various 
>RDF specs that make the intention quite clear: 
>RDF statements about 
><http://www.example.org/index.html> are intended 
>to be statements about that which is identified 
>(in the RFC sense) by that URI -- the web page.

Yes, that was (and is) a reasonable assumption, 
and I have no quarrel with it. (The RDF semantics 
does not stipulate this for two reasons: it is 
not part of the RDF design as such; and at the 
time the RDF spec was being written, this had not 
in fact been universally agreed, although it was 
widely understood informally to be a de facto 
convention.) My point has been only to get the 
terminology clear. These two notions, denotation 
and 'identifies', are different notions. I agree 
it makes sense to stipulate that for cases where 
'identification' succeeds, that they should be 
understood to coincide: but that does not make 
them the same notion.

>>As far as RDF semantics is concerned, URIs are 
>>just blank names with no associated structure 
>>or meaning.
>I assume by ³RDF semantics² you mean the rdf-mt document.

Yes, as that is the title of that document.

>Sure, rdf-mt takes the syntax of URIs from RFC 2396 but ditches the semantics.

There are no semantics for URIs given in RTFC 
2396. I read it very carefully, many times, 
looking for some.

>This is one of the gaping holes left by the WG.
>I do understand why the was made -- a coherent 
>account of reference on the Web was perhaps 
>impossible prior to httpRange-14. But that 
>account is now possible, and the hole can -- and 
>ought to -- be filled, by the semantic extension 
>alluded to in [1].

We filled this in the CL design a couple of years 
ago. The ISO CL documents have a complete 
semantic specification for this. Its similar to 
the idea we used in the 'named graph' proposal. 
One has to assume that 'network identifiers', a 
subclass of logical names, are somehow associated 
with a unique (in this case) CL text, call this 
text(name). Then the semantic condition is that 
in any interpretation I, I(name)=text(name) 
whenever name is a network identifier. This makes 
identifiers denote what they identify. This is of 
course very simple to state, but it does need to 
be stated. (We actually made it a bit more 
complicated to handle logical equality properly, 
since it is possible to have two different copies 
of the exact same text.)

>Don't give me any of that ³It's that way by design² crap.
>>>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 
>>>(Although, in defense of the 3parallel 
>>>universe2 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?
>If you take the position that ³denote² in rdf-mt 
>means something different from ³identify² in 
>rdf-concepts or rdf-primer, then there is of 
>course no contradiction. I call that the ³RDF 
>model theory is irrelevant to the Web² position.

They don't mean the same thing, and there is 
still no contradiction between the RDF semantics 
and concepts documents. The section you cite, 
section 7 on fragIDs, is not normative (unlike 
the model theory)  and is consistent with the 
semantics; though it does, as it says, go 
slightly beyond it. It was, as I recall, an 
attempt by the editors to precisely state what 
all of us had begun to realize was a widely 
accepted convention for interpreting URIs, but 
had not at that time been drawn clearly enough to 
be uncontroversial: what Dan C calls the hash 

>I'd much rather like to know what an extension 
>of the RDF semantics that takes the Web into 
>account would look like.

It would require that someone give a clear, 
formal specification of what a URI 'identifies', 
and then it would stipulate that 
I(uri)=identifiedBy(uri) for any URI and any 
interpretation I. I havn't yet seen a precise 
specification of what a URI 'identifies', 
however. For example, if http://ex.ample/someRDF
is an RDF/XML document, does the URI denote the 
textual document? The XML structure? The RDF 
graph? We decided to punt on issues like this, 
but they need to be answered. The CL spec is 
quite precise about this, since 'text' is a 
grammatical terminal in the syntax.


>[1] http://www.w3.org/TR/rdf-mt/#urisandlit
>>>>>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:
>>>3If 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 
>>>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

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 Sunday, 30 September 2007 05:00:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:18 UTC