Re: Can we have interoperability without a formal semantics? (Was RE: Comments list comments)

Thompson, Bryan B. wrote:
> Steve,
> 
> Don't you think that we will need to have a formal semantics in order to
> achieve interoperability?  Test cases at the inputs and outputs level can
> go some distance toward identifying problems, but there are always the 
> possible misunderstandings and edge conditions that are not covered by the
> test cases, are not part of any conformance suite, and will be the source
> of interoperability failure.  Without a formal semantics for SPARQL, how
> can we hope to have vendor interoperability?
> 
> Our other concern arising from the absence of a formal semantics, is that
> SPARQL may be difficult to optimize, as was recently raised on the comments
> list[1,2], 

Those messages don't lead there.

SQL very carefully puts the constraints syntactically and semantically separate 
from the joins.  SPARQL does the same - it does not do it the same way.

SPARQL happens to allow the application writer to place constraints close to the 
point where they are used rather than syntactally separately.  The "A filter 
constraint must have the variables it uses bound to values first, if possible 
..." is merely to explain what happnes when the application writer writes:

    ?v < 3 .
    :x :p ?v .

If we take cwm, it does not blindly execute "?v math:lessThan 3" just because it 
came first.  A SPARQL query processor can move them around to its hearts content 
providing it gets the same answers.

One way of defining "same" is by having a canonical order.

Taking /2005Mar/0042, I understood Steve is planning outer join for optionals. 
That is a well understood area - even better, some system can use existing 
systems directly.


There is a tradeoff in expressivity and performance.  We don't write assembler 
yet it does faster.  We could choose to optimize the design solely for the 
implementer - but the support costs will be very significant.  We could choose 
to purely optimize the design for exprssivity of user problems - but then we end 
up in a mess as ragrads to interaction of features.  What we have so far is a 
balance of thw two.

 Andy


 > or difficult to extend.  Reliable query performance at scale is a
> key concern for our customers as they are seeking to federate large
> databases
> using semantic web technologies.  A failure to deliver here could spoil the
> entire "semantic web upswell" with a few "no, you can't do that with SPARQL"
> case studies.  Equally, if we do not have a formal semantics, how can we be
> certain that we can extend the syntax, e.g., to new features such as you
> have
> mentioned, without violating the existing semantics?
> 
> Thanks,
> 
> -bryan
> 
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0035.ht
> ml
> [2]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0042.ht
> ml
> [3]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0048.ht
> ml
>

Received on Tuesday, 22 March 2005 12:29:41 UTC