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

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 12:11:52 UTC