- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 06 May 2011 15:17:38 +0100
- To: public-rdf-dawg@w3.org
Looks fine to me. Andy On 06/05/11 13:11, Axel Polleres wrote: > Any support for sending out the modified > http://www.w3.org/2009/sparql/wiki/index.php?title=CommentResponse:MK-1 > which should address both > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0000.html > and > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0003.html > ? > > thanks, > Axel > > On 3 May 2011, at 13:51, Axel Polleres wrote: > >> I didn't send that yet, since Markus sent another comment in between. >> I edited the answer to a combined answer for both comments. >> >> the main thing I changed was pointing out that his propose to change the semantics affects backwards compatibility, which our charter forbids. >> This also addresses Andy's point 1/ below. As for points 2/ - 5/, though I do appreciate >> the additional thoughts, I think they don't need to be mentioned explicitly in the reply. >> >> Please let me know whether ok with the modified reply >> http://www.w3.org/2009/sparql/wiki/index.php?title=CommentResponse:MK-1 >> >> best, >> Axel >> >> On 2 May 2011, at 20:29, Andy Seaborne wrote: >> >> 5/ >>> And fairly obviously, it changes queries using bound(). >>> >>> Andy >>> >>> On 02/05/11 17:16, Axel Polleres wrote: >>>> 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 Friday, 6 May 2011 14:18:10 UTC