- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Wed, 7 Sep 2005 01:49:31 +0200
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 6 Sep 2005, at 19:51, Seaborne, Andy wrote: > I agree with the objective of "do not stand in the way" - that is a > good decision criterion. We are at the intersection of several > communities - we have to reflect all concerns. > > The formalisation of SPARQL proposed makes various changes (e.g. no > bNodes in results) no, no - this is just our simplification in our first semantics paper, which makes some simplification. As far as the SPARQL document is concerned, bnodes in the results are fine, we are not asking any change about that. > which have implications beyond the subgraph/entailment wording The subgraph/entailment wording request is a completely autonomous request that has no impact anywhere else. > as does the use of non-distiguished variables in query patterns Re safeness of variables in queries (i.e., disallowing variables in the head that do not appear in the body): This is our 3rd request - the second one being on minimality of answers; the three requests are independent on each other. The safeness request is based on the consideration that if you have unsafe queries, the problem of unbound values in answers becomes hairy, and I can easily imagine that no implementation will be able to handle them correctly. However, it is not a strong request - in our implementation we will have safe queries only anyway. It would be nice at least to have in the document the definition of safe queries, so that implementors may refer to that if they want to limit the scope of the query evaluation engines. But try to understand fully the consequences of allowing unsafe queries (we made a lengthy justification for that). > - these would seem to have interactions with the algebra of the > SPARQL operators but I haven't got that clear yet. Well, we propose just a simple syntactical restriction about he use of variables in the head of a query. So, I guess that this shouldn't change the algebra, but I may be wrong. By the way, I don't see any use case where you need unsafe queries (nowhere in any DB or information system unsafe queries are ever allowed: having just safe queries is customary everywhere). > I noted a proposal to change OPTIONAL but I haven't worked through > whether this is a separable change or linked. no, no - this was in our first message, but you kindly explained us that we were wrong and we got it. > It is not clear to me that we have scoped the changes yet but it is > evident they extend beyond just s/subgraph/entailment/. If it were > just that, and if the previous concerns about the use of > "entailment" debate were met, then fine. Since our three comments are independent on each other, I take this as an OK to have the word changing :-) cheers --e.
Received on Tuesday, 6 September 2005 23:49:42 UTC