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

Re: Issue with top-down and bottom-up semantics

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Fri, 26 Oct 2007 02:55:49 -0400
Message-ID: <47218F75.2080601@thefigtrees.net>
To: Francis McCabe <frankmccabe@mac.com>
CC: public-rdf-dawg-comments@w3.org

Please note that the two URLs to the relevant objections should actually be:

[4] http://www.w3.org/2001/sw/DataAccess/obj108#optional
[5] http://www.w3.org/2001/sw/DataAccess/obj108#algebraicsemantics

my apologies,

Lee Feigenbaum wrote:
> Frank,
> Thank you for your comment. This is an issue that has been discussed 
> many times by the working group, and I do not see any new information in 
> your message that should cause the Working Group to reconsider the 
> design at this point in time. OPTIONAL, in particular, has been in the 
> language since July of 2004[1], and is in extremely wide use by the 
> SPARQL user community and is widely implemented. [2] Note that the 
> Working Group has on record a long-standing objection [3] about the 
> adoption of OPTIONAL [4], and also an objection to the use of an 
> algebraic rather than declarative semantics [5].
> Please let us know if you are satisfied with this response. If not, I 
> will be glad to add your comment in support of either or both of the 
> above objections.
> Lee
> [1] http://www.w3.org/2001/sw/DataAccess/ftf2#initdn3
> [2] http://www.w3.org/2001/sw/DataAccess/tests/implementations
> [3] 
> http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection
> [4] http://www.w3.org/2001/sw/DataAccess/crq350#optional
> [5] http://www.w3.org/2001/sw/DataAccess/crq350#algabraicsemantics
> Francis McCabe wrote:
>> I believe that is important that SPARQL have a declarative semantics. 
>> This both reflects the fundamental purpose of a query language -- it 
>> is not a programming language -- and will make it easier to 
>> communicate to non-professionals the merits and benefits of using it.
>> In the case of a query language for RDF, this is doubly the case as 
>> the base language is inherently declarative. (It even has a model 
>> theory!)
>> It is therefore something of a disappointment to discover that SPARQL 
>> does not have a truly declarative semantics. It is not possibly to 
>> firmly state that the results of satisfying a SPARQL query are based 
>> on some sound inference process backed up by a model theoretic 
>> interpretation.
>> I believe that the OPTIONAL feature may be one of the causes of this. 
>> Following a recent email conversation, I became aware that its 
>> semantics do not fit well with the current model for the 
>> quantification of variables. Certainly, the idea that a top-down 
>> evaluation (or a left-to-right versus left-to-right) would give 
>> different answers than a bottom-up evaluation is strong evidence of 
>> the weakness of the semantic framework.
>> The specification hints at this, the query:
>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>> PREFIX dc:   <http://purl.org/dc/elements/1.1/>
>> SELECT ?name
>>  WHERE { ?x foaf:givenName  ?name .
>>          OPTIONAL { ?x dc:date ?date } .
>>          FILTER (!bound(?date)) }
>> is described as being equivalent to negation-as-failure. Giving NAF a 
>> declarative semantics is a non-trivial task (first done by Keith 
>> Clark). It involves assuming a 'completion semantics' for the 
>> predicates: the definitions must be interpreted as if-and-only-if; and 
>> furthermore, inequality of symbol must become inequality of denoted 
>> individuals.
>> Both of these assumptions are antithetical to the nature of the 
>> semantic web which depends on the so-called Open World assumption -- 
>> primarily because information on the SW can never be assumed to be 
>> complete.
>> Although there may appear to be compelling pragmatic reasons for 
>> retaining the OPTIONAL feature; I believe that they are outweighed by 
>> the conflicts that they raise with the fundamental nature of the 
>> Semantic Web.
>> Thank you for your attention
>> Frank McCabe
Received on Friday, 26 October 2007 06:55:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:09 UTC