- From: Bob MacGregor <bmacgregor@siderean.com>
- Date: Sun, 20 Mar 2005 10:12:38 -0800
- To: public-rdf-dawg-comments@w3.org
SPARQL has either failed to be a declarative language, or may as well be. The spec contains the following statement: "A filter constraint must have the variables it uses bound to values first, if possible ..." One order of clauses matters, you have lost the battle. Language like this makes it pretty clear that the SPARQL designers don't really understand what a declarative semantics is, and are trying to shore up that deficiency with bizarre syntax. SQL has no such restrictions, and query languages for declarative logics (e.g., for KIF) do not either. In other words, there is an established precedent for how so-called "computed" or "built-in" operators interact with data access operators, and SPARQL is completely missing it. If a FILTER clause cannot be placed interchangeably with a triple pattern, then you have lost orthogonality, and basically blown it. A decent query optimizer knows how to order clauses to achieve both efficiency and correctness; people don't. Proposal: Forbid compound expressions as arguments to FILTER, and allow it to appear anywhere that a 'triples' clause can appear. Also, search for a language expert that is willing to do the work of working out a formal declarative semantics for SPARQL. The mistakes being made here, plus with disjunction and/or optional, make it clear that such an expert is badly needed. There are relatively few folks that have the proper background for such a task (note: I'm not claiming to be one of them). Ignorance of how to design a declarative semantics is not a sin; designing around that ignorance, rather than admitting you are in over your head, is a sin. Regards, Bob
Received on Sunday, 20 March 2005 18:26:18 UTC