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

Re: SPARQL Semantics document

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 31 Oct 2005 16:51:09 -0600
Message-Id: <p06230913bf8c502097ec@[]>
To: Enrico Franconi <franconi@inf.unibz.it>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

>Hi Pat,
>have you checked this document? What do you think? Can be a 
>reasonable starting point?

OK, finally I am emerging from a pile of... never mind what the pile 
was a pile of.

Some quick comments.

1. First, I think we can use this as a basis, yes, modulo some 
questions. Most of the comments are more to do with 'style' than 
actual content.

2. I would prefer to not use translations to 'external' logical 
forms, as in your definition 3, unless they are absolutely necessary 
(and I don't think they are). The RDF documentation should provide 
enough terminology to do most of this, I think.

In fact, I have trouble following definition 3, particularly that of 
L(AS). What is the purpose of introducing the relation R at all? 
Since the definition refers to logical equivalence, and R is an 
arbitrary nonlogical formula, the logical redundancy can only arise 
from a structural redundancy, i.e. an instantiation of bnodes 
producing an identical pattern substitution. This could be stated 
directly, and would IMO be far clearer. So: an instance mapping is a 
function from bnodes to RDF terms (previous definition in RDF), and a 
pattern solution is a partial function from V to RDF terms 
(definition 2). A set of answers is redundant when there are answers 
A1 and A2 in it such that for some instance mapping I, A1 = A2oI, 
where o is functional composition; that is, speaking loosely, when 
one answer A1 is an instance of another answer A2, which we will call 
a redundant answer.

3. RDF merge is already defined, but your definition adds an ordering 
requirement on the bnode re-namings. Is that important?

4. We have to rephrase definition 5 because of course an RDF graph 
does NOT contain query variables, but that is just wording.

5. In definition 6, line 4, should be G |= (G U Q[s]) rather than G 
|= (G U Q)[s]  (??)

6. I don't want to say or imply that the list of four entailments are 
the only possible well-defined entailment relations.  Also, Im not 
sure what 'well-defined' means here.

7. (Substantive). Why, in line 2, are the bnodes in the range of S 
restricted to bnodes in G? Surely it should be possible for an answer 
service to use 'new' bnode labels in an answer? I see no need for 
this restriction on bnodes, in any case.

8. Is Lemma 1.3 really correct? The query might fail to notice the 
structure which keeps the graph lean. For example, the query

?v ex:p ex:a

against the lean graph

{ex:b ex:p ex:a
_:1 ex:p ex:a
_:1 ex:q ex:c}

will produce the answers ?v/ex:b and ?v/_:1, which I think are 
redundant by your definitions, no? (If not, please explain what I 
have missed in the definition of redundancy, which as I said I have 
trouble following in detail.)

9. I do not understand the terminology used in lemma 1.4. What is a 
subgraph isomorphism? What is a projection over bnodes? What is the 
query variable of an isomorphism?

Is it possible to express these ideas using existing terminology, 
rather than inventing new terms that need to be defined?


OK, more later, but this will get us started.


>On 24 Oct 2005, at 21:10, Enrico Franconi wrote:
>>we have tried to summarise the discussions on the semantics of the 
>>last month in a document [1], which presents the very abstract 
>>semantics of SPARQL. By now, it focuses mostly on basic query 
>>patterns, but we will expand it further to cover the algebra as 
>>well. We hope that we can agree on this first part soon, so that 
>>this can be the basis for the official documents.
>>Comments are very welcome and desirable!
>>[1] The Semantics of SPARQL <http://www.inf.unibz.it/krdb/w3c/sparql/>

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 31 October 2005 22:51:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:37 UTC