- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Mon, 02 May 2011 10:28:57 -0400
- To: Axel Polleres <axel.polleres@deri.org>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
I agree with this response. Lee On 5/2/2011 9:02 AM, Axel Polleres wrote: > I drafted a response for this > > http://www.w3.org/2009/sparql/wiki/CommentResponse:MK-1 > > Axel > > > Begin forwarded message: > >> *From: *Markus Krötzsch <markus.kroetzsch@comlab.ox.ac.uk >> <mailto:markus.kroetzsch@comlab.ox.ac.uk>> >> *Date: *2 May 2011 14:00:12 GMT+01:00 >> *To: *"Polleres, Axel" <axel.polleres@deri.org >> <mailto:axel.polleres@deri.org>> >> *Subject: **Re: Proposal for simplifying FILTER semantics* >> >> On 02/05/11 13:39, Axel Polleres wrote: >> > >> > On 2 May 2011, at 10:53, Markus Krötzsch wrote: >> > >> >> On 01/05/11 20:40, Polleres, Axel wrote: >> >>> OfflIist: warum funkt BIND fuer deinen use case nicht? >> >> >> >> Fuer FILTER "=" koennte das eventuell funktionieren (fuer andere >> >> Funktionen natuerlich nicht, aber da ist auch die praktische Motivation >> >> nicht so stark). Was mir da nicht so klar waere ist allerdings wie man >> >> BINDINGS disjunktiv mit (Sub-)Queries kombinieren wuerde. So wie >> ich die >> >> Semantik verstehe werden sie immer konjunktiv mit dem GroupGraphPattern >> >> verbunden. Man haette dann also wieder das gleich Problem, eine >> >> Disjunktion zwischen der Gleichheit mit den Bindings (FILTER) und >> >> etwaigen anderen Patterns (BGP) im WHERE-Teil auszudruecken. >> > >> > ja, aber das geht doch mit EXISTS im FILTER (auch ein neues feature >> in SPARQL1.1, dass genau deinen use case abzudecken scheint... nicht?) >> >> Das habe ich noch nicht gefunden -- wo ist denn die Semantik von EXISTS >> definiert? >> >> Markus >> >> >>> >> >>> ----- Original Message ----- >> >>> From: >> public-rdf-dawg-comments-request@w3.org<public-rdf-dawg-comments-request@w3.org >> <mailto:public-rdf-dawg-comments-request@w3.org>> >> >>> To: >> public-rdf-dawg-comments@w3.org<public-rdf-dawg-comments@w3.org >> <mailto:public-rdf-dawg-comments@w3.org>> >> >>> Sent: Sun May 01 20:29:37 2011 >> >>> Subject: Proposal for simplifying FILTER semantics >> >>> >> >>> Dear WG, >> >>> >> >>> when working with SPARQL recently, I noticed that certain disjunctive >> >>> queries are most cumbersome/inefficient to formulate due to the >> special >> >>> post-processing semantics of FILTER expressions. I have written up a >> >>> detailed explanation [1]. In a nutshell: it is *really* hard to >> combine >> >>> FILTERs and BGPs in disjunctions. >> >>> >> >>> But the problem has a simple fix: >> >>> >> >>> * Define FILTER in such a way that it can *create* new solution >> >>> mappings, just like BGP. A FILTER would create all variable >> bindings (to >> >>> terms from the active graph) that make the filter condition true. >> >>> * Instead of applying filters after matching, the generated solution >> >>> mappings of a FILTER would directly be joined with other parts of >> the query. >> >>> >> >>> Putting it like this simplifies the whole algebra, both formally and >> >>> conceptually. Moreover, I think that practical implementation are >> >>> already working like that anyway (using FILTER conditions such as >> "=" to >> >>> pre-generate results instead of waiting until the very end before >> >>> "checking" them). >> >>> >> >>> The only negative effect that I see is that this would change the >> >>> meaning of variables that occur in filters but in no BGP. Currently, >> >>> such variables are considered "unbound". With the change, they >> would be >> >>> instantiated to all terms that match. Experimenting with FILTER-only >> >>> variables in some RDF stores, I merely got error messages (and rightly >> >>> so, since a variable that can never be bound is of little use in a >> >>> filter). So I assume that this is a corner case of little practical >> >>> relevance. >> >>> >> >>> AFAICT, all other queries would give exactly the same results (joining >> >>> having the same effect as filtering). So it seems that I am >> suggesting a >> >>> largely formal algebra change, but one that would make hitherto >> useless >> >>> queries very helpful (e.g. to solve the problem in [1]). >> >>> >> >>> I am aware that this proposal comes at a very late stage, but I >> think it >> >>> is still feasible to do it. I could help with updating the formal >> parts >> >>> of the algebra. In any case, I would like to hear the opinion of >> >>> implementers/practitioners, also re [1]. Note that I am writing this >> >>> largely as a user (and teacher) of SPARQL, so when I am investing my >> >>> time here it is merely because I am convinced that it would greatly >> >>> benefit the language. >> >>> >> >>> Cheers, >> >>> >> >>> Markus >> >>> >> >>> >> >>> [1] http://korrekt.org/page/The_State_of_the_UNION >> >>> >> >> >> > >> > >> >
Received on Monday, 2 May 2011 14:29:29 UTC