- 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