W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

Re: datatypes and MT (#rdfms-graph)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 15 Nov 2001 16:35:30 -0600
Message-Id: <p05101071b819f087cc90@[]>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Cc: w3c-rdfcore-wg@w3.org
>At 09:03 AM 11/15/01 -0600, Dan Connolly wrote:
>>No? Why not? How is it that you conclude that bnodes
>>in different graphs are different? I don't see it stated
>>in the model theory.
>It appears it's not stated directly, and probably should be since 
>that was (to me) clearly the intent of our discussions.  Also, the 
>final sentence of this text from section 2.0 pretty clearly signals 
>that intent:
>This effectively treats all unlabeled nodes as existentially
>quantified in the RDF graph in which they occur. Notice that since
>two nodes cannot have the same label, there is no need to specify
>the 'scope' of the quantifier within a graph. (However, it
>is local to the graph.) If we were to apply the semantics
>directly to N-Triples syntax, we would need to indicate the
>quantifier scope, since in this lexicalization syntax the same bNode 
>identifier may occur several times. The above rule amounts to
>the N-triple convention that would place the quantifiers just
>outside, i.e. at the outer edge of, the N-triple document
>corresponding to the graph.

The reason why this issue is treated rather elliptically in the MT is 
that the great merit of the graph syntax, as I see it, is that the 
issue simply *does not come up*.  There are no quantifiers, no bound 
variables and no scopes to keep track of, it all works out 
automatically. The merging conditions are a joy to state (merge nodes 
required to be tidy, ie urirefs; don't merge anything else.) It's 
beautiful. It seemed perverse to introduce the clunky logical 
notation only to be able to say that we don't have those problems.

If people feel that this issue should be aired more thoroughly, I 
would suggest that I write a slightly fuller account of how the graph 
syntax makes local scoping unnecessary, maybe with a couple of 
examples, and put it into the 'mapping into logic' section, and then 
refer to that from elsewhere in the document as needed. Any 


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Thursday, 15 November 2001 17:35:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC