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

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 15:34:32 UTC