- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Tue, 24 Jan 2006 12:33:27 +0100
- 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" and "Every blank node in the range of S occurs in the scoping graph DSScope". 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 graph. 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 design. 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 dataset. 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 closures" 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. cheers --e.
Received on Tuesday, 24 January 2006 11:33:36 UTC