- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Sun, 15 Jan 2006 23:58:06 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 15 Jan 2006, at 21:34, Seaborne, Andy wrote: >> 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. But if you want a enxtension which is backward compatible, you need to have the proper semantics for them. If your community does not accept the proper semantics, I propose to leave them out exactly for the sake of exensibility. > I'm trying to find a safe (and restrictive) thing to do now, and > leave space for later work. So do I. > 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. I guess. If SPARQL2 can not have backward compatibility *by definition* that is a failure, and the user's community is not going to like that. >>> 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. No. Because the semantics of bnodes would be different and not extensible anyway. See our example on RDF entailment: one bnode, one BGP, as simple as that. > 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. You decide what you want, I just warn that it will not scale up. > 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. The problem of SPARQL2 will appear just when considering plain positive RDF entailment - again, see our example. --e.
Received on Sunday, 15 January 2006 22:58:15 UTC