- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 2 May 2011 17:16:40 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg@w3.org
thanks andy, fair points, let me know if you want to edit any of those into the draft reply, otherwise, I'd send tomorrow whatever I find on the wiki then. best, Axel On 2 May 2011, at 16:34, Andy Seaborne wrote: > Fine although I'd note: > > [[Comment: > I am aware that this proposal comes at a very late stage, but I think it is still feasible to do it. > ]] > > 1/ Worth pointing out that this is outside the charter of the WG - the web page notes it but trivialises it. > > 2/ He raised this on the 4store list where it was pointed out that > > :locatedIn+ > > would work. That only addresses the specific example, but then much of argument seems to be that messy data leads to messy queries. > > 3/ Inference can address "locatedIn" as a transitive relationship. > > 4/ DAWG did consider binding filters. The style in the spec was preferred. > > Andy > > PS The proposal, as I understand it, returns junk answers if it can bind to anything in the graph that might solve the filter. It confuses a common optimization technique with language design. > > On 02/05/11 15:28, Lee Feigenbaum wrote: >> 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 16:17:09 UTC