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

On Tue, 2005-03-22 at 06:27 -0500, Thompson, Bryan B. wrote:
> Steve,
> 
> Don't you think that we will need to have a formal semantics in order to
> achieve interoperability?

We're chartered to write a formal spec..

"the WG will enter the second phase in which it will write a formal
specification and test cases for this language."
  -- http://www.w3.org/2003/12/swa/dawg-charter


And at least to some extent, we have. The definitions in the spec give
a formal specification; e.g.

[[[
Definition: Pattern Matching (Disjunction)

Given graph patterns GP1 and GP2, and graph G,  then a disjunction
pattern solution of GP1 and GP2 is any pattern solution S such that
either S(GP1) matches G or S(GP2) matches G with substitution S.
]]]

A while back I reviewed them by translating to mathml and
then to N3, but I didn't get all the way thru the spec...
  http://www.w3.org/2001/sw/DataAccess/mathml-rules.xml

Pat Hayes did an extensive review of the definitions a while
back... 6 Dec
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0419

I don't know to what extent he's tracked changes since then.

Everybody is welcome to suggest improvements to the formal definitions.
Much of the spec has been reviewed and basically judged "formal enough"
by the WG. Anybody who isn't satisfied with the level of formality
owes text to fix it (except for the new drafty sections, where the
editors owe the fixes).

Text that changes the design (in such a way that
would be observable from a test case) is another thing... in
many cases it involves re-opening a WG decision, so be prepared
to justify doing so in those cases.

>   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], or difficult to extend.

I don't think the problem pointed out in [1,2] is a lack of formal
semantics; it's just an argument against the design we've chosen.
OK, we could be a bit more mathematically squeaky clean in some
places, but I don't think that's what he's asking for.

His argument is reasonably coherent, I think; I'm still mulling
it over. I'm considering re-opening the disjunction issue as a result
of it. I encourage everybody to look at those comments.

>   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

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 22 March 2005 14:14:03 UTC