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

>I believe that is important that SPARQL have a declarative semantics.

It does, at least for basic graph pattern matching.

>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 disagree. I don't think that querying should be seen as an 
inference. Querying is not about entailment: it is about probing a 
knowledge base to see what it contains (and does not contain.) It is 
an essentially syntactic business, based on matching patterns so as 
to satisfy constraints. Hopefully the results will be of use to an 
inference process, but querying and inference are distinct processes 
with different design constraints. To use a rather far-fetched 
analogy, querying is like fishing, while inference is like cooking. 
Hopefully, the cook can use the fish, but its a mistake to take a 
trawler into a kitchen.

>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.

Yes, and I wish it did not say this, as it is strictly false. What 
such a query does allow you to do is to DETECT 'failure', i.e. to get 
a positive response when the KB does NOT contain a matching pattern. 
This is not only semantically harmless, it is also extremely useful 
in practice: so useful, in fact, that it would be irresponsible to 
not support it.

>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.

True. But (1) this query does not make those assumptions - it detects 
F, not NAF -  and (2) in some cases, of real pragmatic use right now, 
information of certain kinds CAN be assumed to be complete, and 
SPARQL needs to be able to support such applications.

>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.

I don't believe there are any such conflicts, other than a kind of 
doctrinal one, along the lines of "if it isn't semantically definable 
then its evil". And in that particular debate, I'm firmly on the side 
of the pragmatists. Formal semantics - formal methods generally - are 
valuable, but they should be our servants rather than our masters.

Pat Hayes (speaking entirely for himself here, not as SPARQL representative)

>
>Thank you for your attention
>
>Frank McCabe


-- 
---------------------------------------------------------------------
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 Friday, 26 October 2007 18:13:00 UTC