Re: comments on SPARQL Query Language for RDF

Lee,

Apologies for a slow response.  Below I have answered the two  
questions you posed.


On Jun 5, 2007, at 1112, Lee Feigenbaum wrote:

>
> Hi Bob,
>
> Bob MacGregor <bmacgregor@siderean.com> wrote on 06/04/2007  
> 09:49:45 PM:
>
>> Hello Lee,
>>
>> On Jun 4, 2007, at 1300, Lee Feigenbaum wrote:
>>
>> Bob MacGregor wrote on 05/31/2007 07:52:26 PM:
>>
>> My argument is against the choice of an algebraic semantics instead
>> of a declarative
>> semantics.  Unless I am mistaken, OWL has a declarative semantics,  
>> and I
>> would assume that SWIRL and RuleML have or will each have a
>> declarative semantics.
>> Suppose X would like to implement rules from one of these languages
> using
>> SPARQL to evaluate the rule bodies.  If the semantics of SPARQL  
>> aligns
> with
>> the rule language, or perhaps with a subset of it, then X can
> comfortably use
>> SPARQL for this task.  However, comparing a declarative (rule)
>> semantics with an
>> algebraic (SPARQL) semantics is an apples and oranges comparison.   
>> To be
>> sure that SPARQL properly implements the rules, X would have to  
>> produce
>> the declarative semantics on her own.
>>
>> A declarative semantics forms a bedrock on which to build a logic
>> pyramid.  An algebraic semantics is essentially a dead-end.
>
> Thanks for your comments. We're recording your feedback as a formal
> objection. To help us properly record and represent the objection,  
> please
> let me know if there are any example queries that illustrate a  
> difference
> in the declarative semantics you are looking for compared to the  
> current
> semantics in the document.

Its is conventional that a semantic account for a logic to include a  
specification of
the semantics for a (single) conjunction operator and, if it has one,  
for a single disjunction
operator.   The SPARQL spec appears to treat the "." and "&&" operators
as distinct semantic cases. The same goes for UNION and "||".  My  
guess is that
a much simpler semantics could be formulated for SPARQL, patterned  
after,
for example, CommonLogic, that treats each of these pairs as  
syntactic variants
of a common (conjunction or disjunction) operation.  So, queries  
containing both "." and "&&",
or "union" and "||" would be examples.

I believe we came close to formulating a model-theoretic semantics  
for OPTIONAL
a while back, but that tack was abandoned, and now we have the overly- 
complex left-join
account of its semantics.  Any query containing OPTIONAL constitutes  
another example.

In general, I would prefer to see a core semantics for those SPARQL  
operators that have direct
counterparts in traditional logic, and perhaps an algebraic semantics  
to cover
those operations that fall outside of the core.

One tack for arriving at a conventional semantics would be to map  
SPARQL to an abstract
(FOL-like) syntax that, for example includes explicit existential  
quantifiers.

>
>> I wasn't recommending eliminating UNBOUND from the language; I was
>> recommending
>> relegating it to secondary status within the language, i.e.,  
>> making it
>> a computed predicate and not according it a reserved word.  Its  
>> easily
> the
>> most egregious hack in the language.
>
> We'll also note this objection. I'm unclear as to whether you are
> objecting to the existence of the bound operator altogether, or to the
> potential combination of the bound operator and the logical-not  
> operator.
> If you could clarify this, it would help me best represent your  
> objection
> as the WG seeks advancement along the Rec. track.

Members of the committee have previously claimed (informally) that  
UNBOUND plus OPTIONAL
is a complete solution to implementing a negation-as-failure  
operation.  If this
were true, then potentially there could be a cook-book prescription  
describing how to
represent a cwa negation in SPARQL.  However, I will take the recent  
silence in response to
my double negation example as an indicator that this SPARQL device  
falls short of
a true cwa negation.  That raises several troubling issues.  For one,  
it indicates
that the committee members appear to have an incomplete understanding  
of how to use
these operators, when they are applicable, and when they fall short,  
and if its difficult for them to
comprehend, imagine the difficulties that ordinary users will have.   
Second, there would seem to
be no semantic account of what the UNBOUND/OPTIONAL pairing can and  
cannot represent.
Finally, it means that there is no obvious scheme for implementing a  
rule language containing
cwa negation in SPARQL.

Cheers, Bob

Received on Wednesday, 13 June 2007 05:49:35 UTC