- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 22 Mar 2005 08:14:01 -0600
- To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>
- Cc: Steve Harris <S.W.Harris@ecs.soton.ac.uk>, RDF Data Access Working Group <public-rdf-dawg@w3.org>, "Bebee, Bradley R." <BRADLEY.R.BEBEE@saic.com>, "Personick, Michael R." <MICHAEL.R.PERSONICK@saic.com>
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