- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Sun, 15 Jan 2006 20:34:10 +0000
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Enrico Franconi wrote: > On 15 Jan 2006, at 19:01, Seaborne, Andy wrote: > >> Enrico Franconi wrote: >> >>> 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. The >>> reason is that Pat considers bnodes in the query restricted to be >>> bound only to URIs and bnodes explicitly appearing in the graph. >> >> This hinges on the different definitions of 'pattern solution'. The >> scoping >> graph proposal maps variables and bNodes; the ordered-merge proposal maps >> just variables. Each has consequences. > > The main consequence of Pat's latest proposal, as pointed out by FUB, is > that SPARQL can never be extended - not even to RDF entailment - as you > can see from the example above. > > Moreover, if you want to map both variables and bnodes, you better > disallow bnodes in the query and consider only variables in the query: > there wouldn't be any noticeable difference. Wouldn't that disallow the extensions you are interested in such as OWL-disjunction? With no bNodes, there would be no syntax for them :-) Seriously, to put them in the syntax so extensibility is possible, we need an account of them. I'm trying to find a safe (and restrictive) thing to do now, and leave space for later work. In SPARQL 2, we will have a service description which can say whether a query processor does things better/differently to SPARQL 1 (this version - simple entailment only but it can be over a derived graph.. Your rdfD1 example works). This use of the service description gives a lot of room for extensibility in my opinion. Different approach to extensibility, I guess. > >> If bNodes are bound by pattern solutions, then the algebra works out >> as per >> the current document. > > And bnodes would behave *exactly* as variables, and therefore when > considering the extension of SPARQL with just RDF entailment, the > semantics would not be compatible, and the behaviour would be wrong. Entailment-extensibility is possible on BGPs that do not share bNodes with other BGPs. Otherwise they do behave as the variables do if a bNode occurs in two different BGPs in the same query. That's the minimal change to the design. We could ban them from spanning BGPs - that "flexes" the design more but if that is the way forward, then so be it. I think it is true to the original WG decision on syntax from F2F/Boston. I found the consequences on FILTER, and rewriting generally, quite surprising when there is no connection for bNodes of the same name across BGPs. A later WG can work on reducing or removing this restriction if it can down. I happen to also think there will be a lot more features in SPARQL 2 so the interactions here will be more than we can conceive at this point in time. E.g. aggregation, subqueries, negation. Andy > >> If bNodes are not bound at all, as in the ordered-merge proposal, then >> there >> is a change to the algebra. > > Unless you forbid the use of bnodes in queries, which wouldn't be at all > a loss, since the behaviour you want for bnodes is the behaviour we have > for variables. > >> (...) >> >> The algebra works if a bNode in occurring in two or more BGPs in a graph >> pattern is bound by the pattern solution [*]. > > Exactly: you expect bnodes to behave like variables, which is > semantically wrong for any type of entailment which is not just the > reading of the syntax (like simple entailment). > >> This is a conservative approach and, like any extension to the level of >> entailment, more solutions might become possible when relaxed. It >> would allow >> all entailments for queries consisting of a single BGP. It would >> leave open the possibility of the rdfD1 use case above as an extension. > > This is acceptable only if bnodes are forbidden in queries. > > cheers > --e.
Received on Sunday, 15 January 2006 20:34:19 UTC