W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Editorial changes in Section 2.5

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 27 Jan 2006 15:47:49 -0600
Message-Id: <p06230922c0003b13b461@[10.100.0.23]>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:25 GMT