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

Re: Testcase - values7Re: Testcase - values7

From: Rajendran Appavu <apprajen@in.ibm.com>
Date: Wed, 10 Oct 2012 11:16:45 +0530
To: andy.seaborne@epimorphics.com
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <OFD397CF8F.2A00EDCA-ON65257A93.001F2CD3-65257A93.001FBF1D@in.ibm.com>
Andy,

Thank you for the clarification. It is very helpful.

Regards,
Rajendran.


-------------------------
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



From:	Rajendran Appavu/India/IBM
To:	public-rdf-dawg-comments@w3.org
Date:	10/01/2012 09:40 AM
Subject:	Testcase - values7


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, 10 October 2012 05:57:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 October 2012 05:57:23 GMT