Ordering in WHERE clause when generating SPARQL

[yfaria]

The resulting SPARQL query is not easy to interpret considering the original WQL query; one of the reasons is the renaming of hte variables and the other is the order in which the triple patterns are added to the WHERE clause. The first one is a bit out of reach because we delegate this task the the library hsparql, the second problem is a consequence of our code to generate SPARQL. Most things in queries look as they are being outputted backwards; the reason is the laziness of Haskell and is solvable by reversing the order of execution of the code.

This is mostly for making the resulting query more interpretable and for embellishment, but before 228605bd59dbfd610ad170d97797168461a1fb94, the filtering of a negation would appear before the pattern of the type of MRS node; as a result the results of the query were distorted. For example, the query !_dog_n_1 would have been

PREFIX mrs: <http://www.delph-in.net/schema/mrs#> 
PREFIX delph: <http://www.delph-in.net/schema/> 
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> 
SELECT ?x2 ?x0 WHERE { 
  FILTER NOT EXISTS { 
    ?x3 delph:predText "_dog_n_1" . 
    ?x1 delph:hasPredicate ?x3 . 
    ?x1 rdfs:label ?x2 . 
    ?x0 mrs:hasEP ?x1 . 
  } 
  ?x0 rdf:type mrs:MRS . 
} 

This would take every MRS in the profile. If we put the triple pattern ?x0 rdf:type mrs:MRS . before the FILTER NOT EXISTS clause we effectively take the MRSs where there isn't a predicate _dog_n_1.