W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

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

From: Axel Polleres <axel.polleres@deri.org>
Date: Mon, 2 May 2011 17:16:40 +0100
Cc: public-rdf-dawg@w3.org
Message-Id: <92533DD7-6798-429F-8896-7163C548D135@deri.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT