Re: Refining Optionals

Geoff Chappell wrote:
 >
 >>-----Original Message-----
 >>From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
 >>Sent: Friday, July 01, 2005 11:27 AM
 >>To: Geoff Chappell
 >>Cc: 'RDF Data Access Working Group'
 >>Subject: Re: Refining Optionals
 >>
 >>
 >>
 >
 > [...]
 >
 >>>>?x = unbound
 >>>>If ?x occurs in some Pi and BP.Pi has a solution, then a solution with
 >>
 >>?x
 >>
 >>>>unbound is not considered a solution of the group.
 >>>>
 >
 >
 > Hi Andy,

Hi Geoff,

 >
 > I've been playing with this trying to find test cases that result in
 > different answers between this method and the one I've advocated in past
 > emails. I found I couldn't really do that because I don't understand yours
 > in enough detail. For example, the definition you've given above would seem
 > to say that for data:
 >
 > 	:s0 :p1 :s0
 > 	:s1 :p1 :s1
 > 	:s1 :p2 :s1
 >
 > and query:
 >
 > 	optional{?a :p1 ?b} optional{?b :p2 ?c}
 >
 > that:
 >
 > 	?a=:s1, ?b=:s1, ?c=:s1
 >
 > would be a result, but:
 >
 > 	?a=:s0, ?b=:s0
 >
 > would not be (since P2 has a solution for ?c, then there can't be a solution
 > with ?c unbound). But you don't mean that, do you? Surely a user would
 > expect to see the second result, wouldn't he/she? Or am I misunderstanding
 > what you're suggesting?

No - you're right.  I'd expect that answer.

 >
 > The way I look at it, each optional has a positive and negative path through
 > it. So for a group of n optionals, you have 2^n possible paths (e.g. OPT(P1)
 > OPT(P2) has paths P1P2, P1!P2, !P1P2, !P1!P2). I think your rule above is
 > valid only for each possible path separately (not all at once).

I see that now - I had only unwrapped the DNF partially and your example shows 
it has to be done completely.

 >
 > Of course that's just another way of saying what I've suggested before -
 > rewrite the query to an equivalent query in dnf and for each disjunct
 > determine the range of a variable by whether it's mentioned in a positive
 > basic pattern (if it's not mentioned positively, it's unbound). The only
 > difficulty I've run into with that approach is with FILTERs inside
 > optionals. When they are treated as first-class patterns (as they are
 > today), you run into problems when you have a negated FILTER and the vars in
 > the filter are not bound by a basic pattern (you end up with valid but often
 > unwanted results as I illustrated in my earlier email with the
 > optional-filter test case). You could solve that problem by requiring that a
 > filter is always paired with a basic pattern, but that might have even more
 > undesirable results.
 >
 > Can you comment on why you don't think the dnf approach is suitable? It's
 > pretty much in line with the genral direction you're going.

I am taking that approach as I see it.  The main difference, aside from 
incompletely following it, is that I'm not using it to define the right answers 
but instead using it to limit the space of answers that don't add useful 
information for the application.

This way, FILTERs don't matter because they don't contribute positive bindings.

FILTERs could be made to attach to a graph pattern but that doesn't really 
chnage anything because that pattern could be group.  FILTERs could be attached 
to basic patterns but that would be a chnage in the possible answers (e.g. 
FILTER on a UNION where all branches define the variable tested).


 >  As far as I can
 > see, the only downside is that it highlights the oddity of being able to
 > express negation in the language without being able to do it explicitly.
 >
 > Hope that makes some sense.
 >
 > -Geoff

Yes - makes a lot of sense,

	Thanks
	Andy

Received on Tuesday, 5 July 2005 09:03:07 UTC