- From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Date: Wed, 23 Jan 2013 08:30:32 +0100
- To: Pat Hayes <phayes@ihmc.us>
- CC: RDF WG <public-rdf-wg@w3.org>
"This effectively treats all blank nodes as having the same meaning as existentially quantified variables in the RDF graph in which they occur, and which have the scope of the entire graph." and "Merging two graphs treats the blank nodes in each graph as being existentially quantified in that graph, so that no blank node from one graph is allowed to stray into the scope of the other graph's surrounding quantifier. This is appropriate when the graphs come from different sources and there is no justification for assuming that a blank node in one refers to the same entity as any blank node in the other." [RDF Semantics. Section 1.5.] Le 22/01/2013 06:47, Pat Hayes a écrit : > > On Jan 21, 2013, at 8:10 AM, Antoine Zimmermann wrote: > >> You can find my proposal at: >> >> http://www.w3.org/2011/rdf-wg/wiki/User:Azimmerm/Blank-node-scope > > OK, let me pick up on this. Your second sentence is wrong, if it is > supposed to be talking about current RDF as defined by the 2004 > specs: > > "The same blank node can appear in an infinity of RDF graphs and > depending on which graph is considered, the blank node may indicate > the existence of different things." > > In current (2004) RDF, this is not correct. Each blank node is > essentially an existential variable with a *global* scope. It is not > limited to the particular graph in which it occurs. That is precisely > the problem, in fact. > > Perhaps you know this, and your wording is intended to be a > re-formulation which is aimed at solving this problem, by making > blank nodes back into "local" variables. If so, I would argue > strongly against this proposal, as it would introduce a two-level > notion of scoping. We would have 'surface' scopes for blank node > identifiers, and also 'graphical' scopes for blank nodes, and they > might not coincide. This is baroque, unmotivated and almost certain > to lead to widespread confusion. It is also unnecessary. We (now) > have a simple, clear and workable definition which assigns scopes to > bnode *identifiers* (which is exactly what should happen, since > identifiers are the kind of lexical items for which the notion of > scope was originally invented) and which guarantees that graphs > described by two different bnodeID scopes cannot share a bnode (which > is exactly what is required, and what the original 2004 design was > supposed to achieve, but failed to do so), and which retains the > essentials of the 2004 notion of blank nodes as being simply an > 'empty' category of items which participate in the set-theoretic > abstract graph syntax model. This requires no change (a slight > extension, but no actual change) to the 2004 syntax model, and works > perfectly, so I submit that it solves all the remaining issues > convetrning blank nodes, and the discussion is closed. > >> I thought about adding some things, making the definition of scope >> more explicit, but that will do for now to start the discussion. >> The idea is simply translating Pat's definition of a scope: it is a >> region in which variables have a certain meaning. In RDF, a >> "region" is a set of triples. That's what I do, I assign a set of >> triples to scopes. It leads to definig the concept of concrete >> graph, which is a set of triples "in a scope", formally a pair >> (scope,graph) which indicates that, according to that scope, the >> same blank node in any of the triples in the graph is assumed to >> indicate the existence of the same thing. The same blank node in a >> different scope would indicate the existence of a different thing. >> >> For instance, given a bnode b > > Are you here using 'b' as a bnode identifier in RDF syntax, or are > you intending to indicate an actual bnode, using a meta-syntactic > convention which goes beyond RDF syntax? (Do you see how awkward this > gets, when we have two levels to discuss?) > >> , consider the two triples: >> >> (b, owl:sameAs, 1) (b, owl:sameAs, 2) >> >> the concrete graph: >> >> (s1, {(b, owl:sameAs, 1)}) >> >> indicates that there is something that is number one. >> >> (s2, {(b, owl:sameAs, 2)}) >> >> indicates that there is something that is number two. These two >> graphs > > But you have put one bnode into two distinct graphs. This ought to be > impossible, IMO. Unless you intended 'b' to be a bnode identifier, in > which case the two occurrences might identify different bnodes, > making your point moot. It all depends on what level you are talking > at, and what scope rules you are assuming. > > Pat > > >> are both tautologically true, in OWL semantics. However, >> >> (s3, {(b, owl:sameAs, 1),(b, owl:sameAs, 2)}) >> >> indicates the existence of something that is 1 and 2 at the same >> time, which is necessarily false. >> >> I also indicate that the scope of concrete graphs must be >> determined by the application that consumes the data, although >> publishers have conventional ways of indicating the scope, e.g., by >> putting the triples in the same file or in between the curly >> brackets in TriG syntax. However, several files may have the same >> scope, e.g., if a single graph is too large to be conveniently >> published as one file. -- Antoine Zimmermann ISCOD / LSTI - >> Institut Henri Fayol École Nationale Supérieure des Mines de >> Saint-Étienne 158 cours Fauriel 42023 Saint-Étienne Cedex 2 France >> Tél:+33(0)4 77 42 66 03 Fax:+33(0)4 77 42 66 66 >> http://zimmer.aprilfoolsreview.com/ >> >> > > ------------------------------------------------------------ IHMC > (850)434 8903 or (650)494 3973 40 South Alcaniz St. > (850)202 4416 office Pensacola (850)202 > 4440 fax FL 32502 (850)291 0667 > mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > > -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03 Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
Received on Wednesday, 23 January 2013 07:32:43 UTC