Re: draft response MK-1 (Fwd: Proposal for simplifying FILTER semantics)

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 Tuesday, 3 May 2011 12:51:51 UTC