- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 27 Jan 2006 15:47:49 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
>These change requests are the outcome of discussions with external >semweb people. >They are purely editorial, the definitions stay the way they are in >v1.623, and their purpose is to have a clearer explanation of the >definitions. > >1) The definition of graph-equivalence between BGPs should be either >really formal (option a, adapted from ><http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-graph-equality>), >or informal in the text (something like option b). The way it is now >is semi-formal and incorrect. >option a) >""" >Two basic graph patterns BGP and BGP' are graph-equivalent if there >is a bijection M between the sets of nodes of the two basic graph >patterns, such that: > 1. M maps blank nodes to blank nodes. > 2. M(lit)=lit for all RDF literals lit which are nodes of BGP. > 3. M(iri)=iri for all RDF IRI references uri which are nodes of BGP. > 4. M(var)=var for all query variables var which are nodes of BGP. > 5. The triple ( s, p, o ) is in BGP if and only if the triple ( >M(s), M(p), M(o) ) is in BGP'. >""" > >option b) >""" >Two basic graph patterns are graph-equivalent if they are the same >up to bnode renaming. >""" I suggest we use the informal version, but include a link to the normative formal version already published. Its a good idea generally to link to other specs rather than repeat content: Two basic graph patterns are <ahref="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-graph-equality> graph-equivalent</a> if they are the same up to bnode renaming. >2) Definition of scoping set does not emphasise the simple fact that >in general it is an arbitrary subset of the RDF terms. So I propose: > >""" >A Scoping Set B is an arbitrary subset of the RDF terms. >""" But this could be understood as saying that B is required to be arbitrary, i.e. cannot be further restricted by other specs, which would be very misleading. How about being even more explicit: ''''' A scoping set B is some set of RDF terms. This is an arbitrary parameter in this definition. The contents of B should be restricted to correspond appropriately to different entailment regimes. ''''' > >3) Typo in the definition of scoping graphs (s/The/A/). > >""" >The Scoping Graph G' for RDF graph G, is an RDF Graph that is >graph-equivalent to G >""" >--> >""" >A Scoping Graph G' for RDF graph G, is an RDF Graph that is >graph-equivalent to G. Actually that was not a typo. I prefer the definite article, to emphasize that we are talking about a single scoping graph for all answers. >""" > >4) The role of E-entailment is too fuzzy. >I propose the following at the beginning of the Section. > >""" >A basic graph patterns is a set of triple patterns and forms the >core of SPARQL queries. Matching a basic graph pattern is defined in >terms of some unspecified entailment regime to allow for future >extension of the language. > >Definition: E-entailment regime >An E-entailment regime is a relation between a subset of RTD graphs >and a subset of basic graph patterns. >A basic graph pattern in the range of an E-entailment is called >well-formed for the E-entailment. > >Examples of E-entailment are simple entailment [RDF-MT], RDF >entailment [RDF-MT], RDFS entailment [RDF-MT], OWL entailment >[OWL-Semantics]. This specification covers only simple entailment >[RDF-MT] as E-entailment. >""" > >The "Definition: Basic Graph Pattern" should be called "Definition: >Basic Graph Pattern E-matching". > >""" >Definition: Basic Graph Pattern E-matching >Let E-entails be an E-entailment regime, >BGP a basic graph pattern, >G an RDF graph, >G' a scoping graph for G, >B a scoping set, and >S a pattern solution. >BGP E-matches G with pattern solution S with respect to a scoping >graph G' and scoping set B, >if there is a basic graph pattern BGP' that is graph equivalent to BGP, I know I lost the vote, but since we are now tinkering with this yet again, let me explain why having this clause in the definition is a mistake. During the telecon, I thought it was just a gratuitous complication that didn't change the effect of the definition - which would itself have been sufficient reason to reject it - but in fact it is broken, since it allows the bnodes in BGP to overlap with those in G'. Example: G' is :a :p _:b . :a :q :e . and BGP is {?x :q _:b}. With this definition, this succeeds with x bound to :a, since there is a bnode variant of BGP, say {?x :q _:bb} , which satisfies the conditions; but the corresponding instance of BGP itself, when unioned with the scoping graph, is not entailed by the scoping graph. If we try to use instances of BGP to CONSTRUCT an answer graph, these bnode clashes will cause problems. (The same problem will occur if one tries to use the original graph instead of the scoping graph.) The point is that the use of a single scoping graph, together with the union operation, keeps a single bnode scope for all the answer bindings for all the BGPs. It is important that this single scope is kept apart from the bnode scopes of the pattern instances. Putting this clause in the definition makes it impossible to ensure this. And, to repeat, the original definition was not broken, and did not need to be fixed. The complication noted by Sergio, which I believe was the motivation for this suggested change, arises when defining CONSTRUCT, and the solution he offered works there very nicely. Tinkering with other basic definitions is not the right way to fix that. Pat >such that: >1/ G' and BGP' do not share any blank node labels, >2/ (G' union S(BGP')) is a well-formed graph for the E-entailment, >3/ G E-entails (G' union S(BGP')), >4/ The range of S is equal to B. >""" > >Comments? >--e. -- --------------------------------------------------------------------- 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, 27 January 2006 21:48:02 UTC