- From: Dan Connolly <connolly@w3.org>
- Date: Sat, 14 Jan 2006 19:51:40 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Sat, 2006-01-14 at 16:11 +0100, Enrico Franconi wrote:
> Hi,
> we ask to finalise the text of Section 2.5.
>
> The new proposal of Pat <http://lists.w3.org/Archives/Public/public-
> rdf-dawg/2006JanMar/0061.html> does not work for any approach where
> bnodes are implicit, and this happens not only for OWL-Lite
> entailment, as we already pointed out in <http://lists.w3.org/
> Archives/Public/public-rdf-dawg/2006JanMar/0064.html>, but also for
> RDF entailment. For example, given the graph
> :john :age "25"^^xsd:decimal .
> the query
> ASK { _:b rdf:type rdf:XMLLiteral }
> should clearly return YES if RDF entailment is considered. However,
> according to the latest proposal from Pat the answer to the query
> would be NO regardless of the type of entailment considered.
I thought we were approaching consensus on having just one
kind of entailment in this first version of SPARQL. Did something
change?
> The
> reason is that Pat considers bnodes in the query restricted to be
> bound only to URIs and bnodes explicitly appearing in the graph.
>
> At this point it is becoming too late. We ask that either our text is
> used (with possible editorial changes to discuss), or that the DAWG
> does not conclude the work on the 31st of January and we'll have a
> F2F during the W3C tech plenary in France at the end of February.
> We recall that our text provides the use of entailment, the
> correspondence with the subgraph matching based implementations, and
> uniqueness of solutions for interoperability; its core definitions
> are stable since its appearance on the 2nd of November 2005 <http://
> www.inf.unibz.it/krdb/w3c/sparql/>.
>
> So, the latest version of our proposed text for Section 2.5 (having
> minor changes wrt our previous proposal <http://lists.w3.org/Archives/
> Public/public-rdf-dawg/2006JanMar/0018>) is below.
>
>
> """
> 2.5 Basic Graph Patterns
>
> Definition 4 (OrderedMerge)
> The OrderedMerge of a sequence of graphs is the ordered merge-union
> of the graphs, where repeated bnodes are substituted with fresh ones,
> by keeping the names of the bnodes coming first in the sequence
> order. Note that, w.r.t. the standard definition of RDF merge [RDF-
> MT], if any of the graphs contains variables, then those are not
> renamed (i.e., variables are treated as URIs).
>
> The above OrderedMerge definition is totally compatible with the RDF
> merge definition given in [RDF-MT]. In particular, if the graphs do
> not contain any variable or they are considered simply as IRIs, then
> OrderedMerge is a RDF merge. The other way around is not true in
> general, since the original definition does not specify which bnodes
> are renamed. From the semantic point of view OrderedMerge is
> equivalent to RDF merge; moreover, if the graphs do not share any
> bnode name, then the two results are ´syntactically¡ identical, in
> the sense that they contain the same triples.
>
> Definition: Basic Graph Pattern matching.
> A Basic Graph Pattern is a set of Triple Patterns.
> A basic graph pattern, BGP, matches on graph G with pattern solution
> S if:
> - G simply entails S( G OrderedMerge BGP )
> - the graph S( G OrderedMerge BGP ) is an RDF graph
> - the bnodes involved in S are among the bnodes appearing in G.
>
> Simple entailment (as defined in [RDF-MT]) is the default choice of
> entailment in SPARQL, since it allows for the basic operation of
> querying the "syntax" of RDF graphs, completely neglecting its
> semantics. In this way, the basic option for SPARQL is to manipulate
> graphs, rather than involving reasoning on knowledge bases; the
> latter may be possible by choosing another form of entailment, among
> the current standards of W3C. In fact, with the proviso that bnodes
> are not allowed to appear in pattern solutions, SPARQL may be
> extended to provide a way to override the default "simple entailment"
> with "RDF entailment", "RDFS entailment" (as defined in [RDF-MT]),
> and "OWL entailment" (as defined in [OWL-Semantics], where the
> syntactic restrictions in OWL-DL or OWL-Lite should be reflected in
> suitable syntactic restrictions on the form of basic graph patterns).
>
> In the default case of simple entailment, Basic Graph Pattern
> matching corresponds really to the expected operation of subgraph
> matching from the basic graph pattern (the query) to the graph (the
> dataset). So, querying a dataset with a basic graph pattern
> corresponds to find all the assignments for variables and bnodes in
> the query pattern such that the resulting graph is a subgraph of the
> dataset. This provides a connection for the formal definition of
> basic graph pattern matching to the practices adopted in SPARQL
> implementations.
>
> Implementational hint: Simple Entailment as Subgraph Matching.
> In the case of simple entailment, a pattern solution can be
> equivalently defined as follows: for each subgraph matching between
> BGP and G, where bnodes and variables in BGP are mapped to any node
> in G, a pattern solution is the mapping of variables in BGP to nodes
> in G.
>
> Moreover, the uniqueness property of pattern solutions guarantees the
> interoperability between SPARQL systems: given a graph G and a basic
> graph pattern query BGP, the set of all the pattern solutions is unique.
> """
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Sunday, 15 January 2006 01:51:45 UTC