Generated SPARQL

generated SPARQL

Simple queries (that is, those that do not use @not or @or) generate SPARQL structured thus:

SELECT all-the-variables
WHERE {
    { ?item aspect-property-1 ?aspect-value-1 ...
      FILTER(expr-1)...
    } 
    OPTIONAL {?item aspect-property-10 ?aspect-value-10 } 
    ...
} outer-modifiers

(Note that this differs from the earlier query stucture, which did not {}-box the structures before the OPTIONALs, which improves performance in some cases.)

The outer-modifiers are defined from the @sort, @limit, and @offset of the originating query. If any of @itemSort, @itemLimit, @itemOffset are specified then the structure becomes:

SELECT all-the-variables
WHERE {
    { SELECT ?item all-inner-variables
      { ?item aspect-property-1 ?aspect-value-1 ...
      FILTER(expr-1)...
    } inner-modifiers } 
    OPTIONAL {?item aspect-property-10 ?aspect-value-10 } 
    ...
} outer-modifiers

The inner-variables are those bound within the body of the nested SELECT.

(Some notes on the generated SPARQL, there's probably a better way of structuring the pages to do this.)

Simple queries -- generally, those without @not and @or -- end up generating SPARQL that looks like

prefixes

?item aspectProperty1 ?aspectVariable1 
OR  ?item aspectProperty1 Value1 BIND(Value1 AS ?aspectVariable1)
...
OPTIONAL { ... optional item bindings likewise ...}
...
FILTER(?aspectVariableN Op Value)
...

The complete set of aspects appears in the generated query. All the optional aspects appear after all the non-optional aspects. Within each of those two groups, all the constrained aspects -- that is, those which will appear in a filter or equality binding -- appear before those that are not. And within those groups, the aspects are ordered by URI (picking something deterministic).

There are issues with multi-valued properties which have still to be addressed.