W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2012

Re: Testcase - values7

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 03 Oct 2012 10:55:54 +0100
Message-ID: <506C0BAA.4020705@epimorphics.com>
To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
This is not an official working group response - I'm taking it as a 
question rather than a comment on the spec.

The query values07 has a VALUES clause after the graph pattern - this 
creates a data table to be joined with the outcome of matching the graph 
pattern.

The algrebra for is:

       (join
         (leftjoin
           (bgp (triple ?s ?p1 ?o1))
           (bgp (triple ?s foaf:knows ?o2)))
         (table (vars ?o2)
           (row [?o2 :b])
         ))

where the outermost operation is the join of pattern results and data table.

The graph pattern without VALUES part results in an intermediate result:

SELECT ?s ?o1 ?o2
{
    ?s ?p1 ?o1
    OPTIONAL { ?s foaf:knows ?o2 }
}

which evaluates to:

---------------------------------
| s  | o1                  | o2 |
=================================
| :a | :b                  | :b |
| :a | "alan@example.org"  | :b |
| :a | "Alan"              | :b |
| :c | "alice@example.org" |    |
| :c | "Alice"             |    |
| :b | :c                  | :c |
| :b | "bob@example.org"   | :c |
| :b | "Bob"               | :c |
---------------------------------

The rules for evaluating OPTIONAL have now been applied.

(NB : the :c in ?o2 which seem to be missing in your expected results)

This intermediate results is joined with the one row data table: (?o2=:b).

The first 3 rows match by join equality.

SPARQL join compatibility rules mean no occurrence of a variable on one 
side is considered to be a join match so rows 4 and 5 become:


| :c | "alice@example.org" | :b |
| :c | "Alice"             | :b |

rows 6, 7 and 8 do not match the join compatibity rule because ?o2 is :c.

> By this I was hoping the variable "o2" will not be bound for the
> records related to "Alice". But from the expected result, "o2" is
> bound and says "Alice" knows "Bob" (rows 4 & 5), though the data does
> not say that.

This is a test example.  The query forces ?o2 bindings into the results 
by using the VALUES which is without reference (i.e. pattern matching) 
to the structure of the data.  Hence the results may be odd compared to 
the input data.

Your expected output might arise from a query such as:

PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s ?o1 ?o2
{
   ?s ?p1 ?o1
   OPTIONAL { ?s foaf:knows ?o2
                VALUES ?o2 { :b }
            }
}

where the VALUES clause is places inside the OPTIONAL part of the query 
matching.  It's a very different query where the leftjoin is the outer 
most operation:

       (leftjoin
         (bgp (triple ?s ?p1 ?o1))
         (join
           (bgp (triple ?s foaf:knows ?o2))
           (table (vars ?o2)
             (row [?o2 :b])
           )))

Hope that helps,

	Andy


On 01/10/12 05:10, Rajendran Appavu wrote:
> While running the conformance tests for SPARQL 1.1 on our implementation, I
> came across this test case for VALUES whose expected result is different
> from what I was expecting and wanted to clarify it with you.
>
> data07.ttl
>
> @prefix : <http://example.org/> .
> @prefix foaf:       <http://xmlns.com/foaf/0.1/> .
>
> :a foaf:name "Alan" .
> :a foaf:mbox "alan@example.org" .
> :b foaf:name "Bob" .
> :b foaf:mbox "bob@example.org" .
> :c foaf:name "Alice" .
> :c foaf:mbox "alice@example.org" .
> :a foaf:knows :b .
> :b foaf:knows :c .
>
> values07.rq
>
> SELECT ?s ?o1 ?o2
> {
>    ?s ?p1 ?o1
>    OPTIONAL { ?s foaf:knows ?o2 }
> }
> VALUES (?o2) {
>   (:b)
> }
>
> The expected result by the test is:
>
> ----------------------------------------------------------------------------
> | s                      | o1                     | o2
> |
> ============================================================================
> | <http://example.org/a> | <http://example.org/b> | <http://example.org/b>
> |  -> 1
> | <http://example.org/a> | "alan@example.org"     | <http://example.org/b>
> |  -> 2
> | <http://example.org/a> | "Alan"                 | <http://example.org/b>
> |  -> 3
> | <http://example.org/c> | "alice@example.org"    | <http://example.org/b>
> |  -> 4
> | <http://example.org/c> | "Alice"                | <http://example.org/b>
> |  -> 5
> ----------------------------------------------------------------------------
>
> By the definitions for OPTIONAL in section 6 of the spec (
> http://www.w3.org/TR/sparql11-query/#optionals) I was expecting:
>
> ----------------------------------------------------------------------------
> | s                      | o1                     | o2
> |
> ============================================================================
> | <http://example.org/a> | "Alan"                 | <http://example.org/b>
> |
> | <http://example.org/a> | "alan@example.org"     | <http://example.org/b>
> |
> | <http://example.org/a> | <http://example.org/b> | <http://example.org/b>
> |
> | <http://example.org/c> | "Alice"                |
> |
> | <http://example.org/c> | "alice@example.org"    |
> |
> | <http://example.org/b> | "Bob"                  |
> |
> | <http://example.org/b> | <http://example.org/c> |
> |
> | <http://example.org/b> | "bob@example.org"      |
> |
> ----------------------------------------------------------------------------
>
> In section 6 we have :
>
> [...  if the optional part does not match, it creates no bindings but does
> not eliminate the solution. ...]
>
> By this I was hoping we will not filter any matching records and records
> related to "Bob" will also appear. But the expected result by the test case
> seem to vary with this.
>
> In section 6.2 on Constraints in Optional Pattern Matching, for the example
> we have:
>
> [ .. No price appears for the book with title "SPARQL Tutorial" because the
> optional graph pattern did not lead to a solution involving the variable "
> price". ]
>
> By this I was hoping the variable "o2" will not be bound for the records
> related to "Alice". But from the expected result, "o2" is bound and says
> "Alice" knows "Bob" (rows 4 & 5), though the data does not say that.
>
> Could you please clarify?
>
> Thanks,
> Rajendran.
>
>
>
>
Received on Wednesday, 3 October 2012 09:56:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2012 09:56:24 GMT