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

FUB on Pat's proposal for BGP matching (please read)

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Tue, 24 Jan 2006 12:33:27 +0100
Message-Id: <5371E8CA-3580-4411-99FE-7373875B0A62@inf.unibz.it>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

[This message is intended for the group, not for Pat, since finally we
  have now some text from him.  Please read, since today we have to
  make the final choice, according to the agenda.]

We believe that <http://www.ihmc.us/users/phayes/Section2.4revized.html>
is not an answer to our requests, that led to the issues rdfSemantics
and owlDisjunction. The main concern of FUB within the DAWG is to
guarantee the upward compatibility of the normative SPARQL with
entailment-based extensions; this is not guaranteed by Pat's
proposal. On the other hand, the current rq23 text does fully satisfy
our requirements (modulo the fact that in the normative SPARQL only
simple entailment is allowed - but it is said explicitly that this may
be overridden by extensions). Moreover, the current rq23 text
guarantees the equivalence with subgraph matching as introduced in the
LC design.

We read in Pat's text:

"Extensions to SPARQL may modify this definition by using other forms
of entailment and imposing extra restrictions on answer sets, while
retaining the essential form of the definition and the rest of the
SPARQL constructions."

This is exactly our primary concern. It is not true in Pat's text that
we can introduce extensions by just imposing extra conditions on the
definitions. We would really like that this were the case, like it is
the case in the current rq23 text.

If the DAWG ends up with a set of normative definitions that have to
be (arbitrarily) changed in order to accommodate the extensions that
we already know about and that W3C cares about, then we consider
SPARQL to be a major failure.


Why Pat's text does not allow smoothly for *any* extension we may want
to define elsewhere?

1) Extension with RDF/RDFS/OWL entailment.

The text says:

"The purpose of the scoping graph is to define a common scope for all
blank node identifiers in answers"


"Every blank node in the range of S occurs in the scoping graph

This is no more true if you have RDF/RDFS/OWL entailment, since the
range of S can be any URI or bnode name *independently* on the scoping

Moreover, the only known kind of query answering mechanism for OWL-DL
has only URIs in the answer set (what Pat called OWL-DL data query).

2) Extension with told-bnode simple entailment.

The text says:

"the scoping graph DSScope is an RDF graph which is graph-equivalent
to DS and shares no blank nodes with GP."

This is no more true in the case of told-bnode simple entailment,
since in this extension the crucial bit is that the bnodes names in
the dataset may be relevant.


To sum up: we believe that the extensions that will be introduced
elsewhere in a non normative way (and that many users will be using
since day one) have to be restrictions over the normative SPARQL
(modulo the fact that in the normative sparql only simple entailment
is allowed - but it is said explicitly that this may be overridden by
extensions), but this is not possible with Pat's proposal.


Other problems we found in Pat's text:

a) SPARQL LC design.

The text says:

"Simple entailment by a graph can be checked by matching directly
against the structure of the graph itself; nothing that is not already
in the graph needs to be inferred or constructed, even implicitly."

We all agree that this is the basic principle that guides the SPARQL

The current text does not guarantee the equivalence with subgraph
matching on the dataset as introduced in the LC design, but only the
weaker equivalence with subgraph matching on the *scoping graph*.  In
fact, the text allows for bnodes renaming, which is based on the
inference that the scoping graph is equivalent to the original

The text allows to be normative implementations that do arbitrary
renaming of bnodes in the answer, without allowing the possibility to
recognise systems that actually do return the bnodes in the answer as
they do appear in the graph. This is not the problem of re-using told-
bnodes, it is just against the declared principles of what SPARQL
should be: a system that does syntactic-based graph pattern matching.

b) Closure vs entailment

The text says:

"Some SPARQL extensions may be identified with SPARQL applied to RDF
graphs derived from the dataset graph, such as the RDF or RDFS

This is not an extension, it is using plain SPARQL over a (infinite)
dataset (the closure).

The text apparently suggests that computing the rdf/rdfs closure of an
rdf/rfds graph and then using SPARQL is equivalent to having rdf/ rdfs
entailment. However, (even forgetting by now the problem of infinite
closures) the answer sets in the two cases are different, in
particular the answer set in the former case is included in the answer
set of the latter case.

Received on Tuesday, 24 January 2006 11:33:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC