This wiki has been archived and is now read-only.


From SPARQL Working Group
Jump to: navigation, search


This is in respons of your comments




I was looking at your page http://korrekt.org/page/The_State_of_the_UNION

First of all, it seems you disregard the power of BIND and EXISTS, new constructs in SPARQL1.1 which seems to solve your use cases.

E.g., BIND does the job for your first example:

 { ?x :population ?number FILTER( ?number>1000000 ) }
 { BIND (:Luxemburg AS ?x ) ?x :population  ?number }

and seems to cover your stated requirement that

"* Define FILTER in such a way that it can *create* new solution mappings, just like BGP. "

The difference between FILTER and BIND - by design - is that BIND creates bindings while FILTER only filters solutions.

As for your second requirement: "* Instead of applying filters after matching, the generated solution mappings of a FILTER would directly be joined with other parts of the query." let's turn to your second example

"Find all ?x locatedIn ?y, where ?y is the USA or a state of the USA."

Here, similar to above

 { BIND (:USA AS ?y) ?x locatedIn ?y }
 { ?y :stateOf :USA . ?x locatedIn ?y }

seems to do the job. Similarly, a FILTERs only version is possible, however, within FILTERs you can't use UNION, but you can use || in combination with EXISTS here to express the desired filter conditions over patterns:

  ?x locatedIn ?y 
  FILTER  ( ?y = :USA || EXISTS( ?y :stateOf :USA ) )

the additional condition

"?y has at least 10 million inhabitants or is in the pacific"

can be added likewise.

Summarising, I think your request

"Concretely, one would need to make the following modifications:
   change the formal semantics to treat FILTERs like patterns, not
   like post-processing features, 

is already addressed by the EXISTS feature of SPARQL 1.1 which readily provides this feature, and seems to address your use case. Additionally, the new BIND feature allows you to create bindings.

Finally, as for your proposal in you second mail


Please note that your suggested change of the semantics would affect backwards compatibility with SPARQL1.0, which our charter explicitly discourages [1].

We'd appreciate if you could indicate whether this response adequately addresses your comment.


Axel (on behalf of the SPARQL WG)

1. http://www.w3.org/2009/05/sparql-phase-II-charter.html#scope