W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2005

Re: Test cases

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 17 Jun 2005 09:19:12 +0100
Message-ID: <42B28780.8020602@hp.com>
To: Geoff Chappell <geoff@sover.net>
CC: public-rdf-dawg-comments@w3.org

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
>>Let me reduce this to a simple test case to see if we are have the same
>>understanding of the problem:
>>:book :title "Title" .
>>     {
>>       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.


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.


>>[[Related, but different, is that any solution can be extended with other,
>>unrelated bindings of variables without afecting the matching.  This is a
>>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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC