- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 16 Jan 2006 10:20:00 +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 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. Sorry - I fail to see why a restriction that a bNode can not appear in two separate BGPs is in anyway a conflict with anything you have said. I suggested because it was the clearest way I could think of to give you the *exact* and *complete* behaviour you have been wanting. The case I am considering is where the same bNode name is used in two different BGPs. I can't find anywhere in your document or your emails as to what happens in this case so I worked an example. The example has some consequences which might catch people out. Furthermore, I don't see any value in having that situation - in your definitions it is equivalent to a syntactic rewrite to a new name anyway so I suggested that we use that (that is, don't allow { ... _:a ... } { ... _:a ... } union { ... } where the name "_:a" is used twice. instead have { ... _:a ... } { ... _:b ... } union { ... } > >> 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. Plain RDF entailment is covered because then a bNode only occurs in a single BGP. No constraints. (Further, as there is no #owlDisjunction, the graph queried can be the calculated logical closure of the input anyway.) Andy > > --e. >
Received on Monday, 16 January 2006 10:20:12 UTC