W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2007

Re: comments on SPARQL Query Language for RDF

From: Lee Feigenbaum <feigenbl@us.ibm.com>
Date: Mon, 4 Jun 2007 16:00:49 -0400
To: Bob MacGregor <bmacgregor@siderean.com>, public-rdf-dawg-comments@w3.org
Message-ID: <OF7F0F7840.4BC00F5B-ON852572F0.006DADF2-852572F0.006DEE5B@us.ibm.com>

Bob MacGregor wrote on 05/31/2007 07:52:26 PM:

> With respect to quads, I agree with you.  But it took this discourse
> with Richard, Pat, and Jeen to convince me
> that SPARQL has come about as far as triples will allow it.

> I still think that SPARQL ought to have a declarative semantics, and
> I still think that UNBOUND should not
> be integral to the language, for the reasons described earlier.  

Hi Bob,

I wanted to address these remaining two issues on behalf of the Working 
Group.

To make the trail easier to follow, your original comments message is:

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007May/0026.html

I'll quote a bit from that message but please refer back to it for more 
context.

1. Model-theoretic declarative semantics

"""
The current SPARQL semantics apparently derives from an algebraic 
specification that says what you get when you run a SPARQL query, rather 
than what the answer actually "means".  The SPARQL spec is procedural 
rather than declarative...
"""

In the DAWG's most recently published Last Call working draft, the group 
adopted (as you say) an algebra to specify the semantics of SPARQL query 
patterns and query modifiers. This part of the specification is based on 
the work within The Semantics and Complexity of SPARQL by Perez, Arenas, 
and Gutierrez ( http://arxiv.org/abs/cs/0605124 ).

It's unclear to me if you are unhappy with the presentation of SPARQL's 
semantics or with the semantics itself. If you are not satisfied with the 
presentation of the semantics, the editors would welcome references to 
specific parts of the specification where the text is unclear. We will 
continue to make editorial improvements to the documents during CR.

If you have concerns about the semantics, it would greatly help the 
Working Group if you could share an example of a query, data, and results 
that illustrate your preferred semantics. 


2. Bound (actually the third point in your original message)

"""
UNBOUND is strictly less expressive than UNSAID (or whatever you may call 
the negation-as-failure) operator.  In Seamark,
we implement a closed-world version of universal quantification using a 
double negation (e.g., there does not exist value that does not have type 
X).  This construct cannot be emulated using UNBOUND...
"""

Perhaps I don't understand your scenario. This query:

PREFIX : <http://example.org/>
SELECT DISTINCT ?s
FROM <http://thefigtrees.net/lee/sw/data/bound.n3> {
 ?s a ?type .
 OPTIONAL {
   ?s2 a :x .
   FILTER (?s = ?s2)
 }
 FILTER (!bound(?s2))
}

will find all the resources in a dataset that do not have type X. (For 
example, you can run this query at http://sparql.org/sparql.html against 
the dataset at http://thefigtrees.net/lee/sw/data/bound.n3 .) If you're 
interested in finding out that there are no such resources, you can use an 
ASK query and negate the results in your application. With the ASK query 
form, this query is asking "are there any values that do not (in the RDF 
dataset, under a CWA) have type X?".

Could you outline a use case (or give an example query in your language) 
in which this technique is not sufficient? 

As a related note, you could assert that ?s was not (universally, CWA) 
bound within the framework of a larger query by using a COUNT aggregate 
function. Aggregate functions are an issue that the DAWG has postponed 
(see http://www.w3.org/2001/sw/DataAccess/issues#countAggregate ) for 
future work.

In any case, the BOUND operator has been part of the SPARQL specification 
for quite some time, and is included in many implementations and regularly 
used by SPARQL users. I would need to see significant new information at 
this point in our schedule to warrant bringing this issue back to the WG.


thanks,
Lee
Received on Monday, 4 June 2007 20:01:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:51 GMT