Re: Refining Optionals

Geoff Chappell wrote:
> 
>>-----Original Message-----
>>From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
>>Sent: Thursday, July 07, 2005 11:27 AM
>>To: Geoff Chappell
>>Cc: 'RDF Data Access Working Group'; Pat Hayes
>>Subject: Re: Refining Optionals
>>
>>
>>
>>Geoff Chappell wrote:
>>
>>>>-----Original Message-----
>>>>From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
>>>>Sent: Tuesday, July 05, 2005 5:00 AM
>>>>To: Geoff Chappell
>>>>Cc: 'RDF Data Access Working Group'
>>>>Subject: Re: Refining Optionals
>>>>
>>>
> [...]
> 
>>The more I think about it, the more I'm unsure we can sort this out in
>>time.
>>
>>We have a way of talking about the "Junk" case - although as ?v may appear
>>in a
>>different position, creating a set of spurious terms from the model, I am
>>a
>>little nervous of this still.
>>
>>It's the unbound case that I still can't get straight.  We are talking
>>about
>>whether a negated pattern involving unbound variables does or does not
>>match a
>>graph.  As match is defined as subgraph, anything involving variables
>>never
>>matches.  The negation always is true - the !P case always admits a
>>solution.
>>
>>As I read your expansion rules above:
>>optional { :x :p ?v }
>>{ :x :p ?v } UNION NOT { :x :p ?v }
>>
>>but ?v = unbound is not a solution to  { :x :p ?v } so NOT { :x :p ?v } is
>>true
>>and hence that is a solution.  I must be missing something.
> 
> 
> An unbound var in a solution can be substituted with any RDF-T and the
> solution will still be valid. Do you agree with that?

I agree for the style of solution that your approach is taking.  The alternative
is something more prescriptive that only has substitutions in the solution that
are needed to make the pattern match.  This is the contrast between the
narrowing down approach and the constructional one.

If we compare the two approaches, are there any queries that given different
solutions?

> I agree the current
> definitions don't support the unbound case (however they do seemingly
> support the replace-the-unbound-with-all-RDF-T case which means that a query
> with an optional could have an infinite number of solutions) -- that
> suggests to me a problem with the definition of matching or the definition
> of solution, not a problem with the use of unbounds in solutions.
> 
> 

<snip jump="filters"/>

>>It leaves it open to provide an alternative set of definitions that are
>>based on
>>the framework you outline.  It will take time to get consensus around such
>>an
>>approach (especially with negation and unbound variables being very
>>significant
>>in how they work).
> 
> 
> Won't it take some time for any real solution? It seems like you either have
> to take that time or punt on what are valid solutions when optionals are
> involved.

I hope the approach I outlined is simpler as there is no DNFG rewriting to consider.

For FILTERs, everything seems OK even in the any order version of group (if the 
filter is too early, it will just fail a solution with a type evaluation failure 
  and another order will find the solution).

That is, except unbound(), which masks such evaluation failures and interacts in 
an order dependent way.   I'll need to work on that - unfortunaltely, unbound() 
does have legitimate uses (e.g. find all ?x where ?x > 18 or ?x is unknown). 
These can often be written in other ways but it may not be a natural query to 
write and so lead to application writer confusion.

> 
> 
>>	Andy
> 
> 
> Rgds,
> 
> Geoff
> 
> 

	Many thanks,
	Andy

Received on Monday, 11 July 2005 17:14:50 UTC