FILTER is non-orthogonal and non-declarative

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