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

RE: Test cases

From: Geoff Chappell <geoff@sover.net>
Date: Wed, 15 Jun 2005 12:12:53 -0400
To: <andy.seaborne@hp.com>
Cc: <public-rdf-dawg-comments@w3.org>
Message-ID: <007001c571c5$1601cd40$6501a8c0@gsclaptop>

> -----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:
>      {
>        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
> [[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

Received on Wednesday, 15 June 2005 16:13:19 UTC

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