W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

Re: subgraph/entailment

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Wed, 7 Sep 2005 01:49:31 +0200
Message-Id: <A542439B-5C66-49CE-9A6B-E4F4026BDB37@inf.unibz.it>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT