Re: Test cases

Geoff Chappell wrote:
> 
>>-----Original Message-----
>>From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
>>Sent: Wednesday, June 15, 2005 11:32 AM
>>To: Geoff Chappell
>>Cc: public-rdf-dawg-comments@w3.org
>>Subject: Re: Test cases
>>
>>Geoff,
>>
>>Let me reduce this to a simple test case to see if we are have the same
>>understanding of the problem:
>>
>>Data:
>>:book :title "Title" .
>>
>>Query:
>>SELECT ?x
>>WHERE
>>     {
>>       OPTIONAL { :book :title ?x }
>>     }
>>
>>in other words, a single optional.
>>
>>Solutions: (desired)
>>?x = "Title"
>>
>>The issue as I see it is why isn't
>>?x = "Junk"
>>
>>a solution as well because ?x="Junk" is a solution to OPTIONAL(P).
> 
> 
> Yes, I'd agree that's the issue (or at least is at the center of several
> related issues). 
> 
> Even assuming that the range of substitution was restricted to the terms in
> the dataset, you'd still have ?x=:book and ?x=:title as seemingly valid
> solutions.

Geoff,

This does seem to suggest an approach though.

The definitions could require that any binding is tracable to a basic pattern 
match from some part of the overall query pattern.  This restricts the graph 
terms to those that can arise anywhere in the query from a basic pattern - and 
it's only basic patterns that connect the query pattern to the target RDF graph.

	Andy


>  
> 
>>[[Related, but different, is that any solution can be extended with other,
>>unrelated bindings of variables without afecting the matching.  This is a
>>result
>>of the pattern composition - subpatterns may not involve all variables.]]
> 
> 
> You might be able to duck composition issues by saying that any solution to
> a pattern (even a sub pattern) must include all variables mentioned in the
> query. That doesn't really resolve the question of what values those
> variables can range over, however. For that, the only approach that I've
> been able to make work is to say that any variable not mentioned in
> non-negated basic pattern in a particular disjunctive branch of the query,
> is treated as unbound/null (and no resultset compaction is performed - i.e.
> no treating a result as an instance of another and removing it)
> 
> 
>>	Andy
> 
> 
> Geoff
>  
>

Received on Friday, 17 June 2005 08:19:24 UTC