PREFIX : <http://people.example/>
SELECT ?y ?name WHERE {
:alice :knows ?y .
{SELECT ?y ?name WHERE {
?y :name ?name
}ORDER BY ?name LIMIT 1
}}
if you looks at the inner SELECT, and evaluate it you get:
---------------------
| y | name |
=====================
| :alice | "A. Foo" |
---------------------
but
:alice :knows ?y .
is :carol and :bob.
No match, no join results.
try:
PREFIX : <http://people.example/>
SELECT ?y ?name
WHERE
{ :alice :knows ?y
{ SELECT ?y (MIN(?n) AS ?name)
WHERE
{ ?y :name ?n }
GROUP BY ?y
}
}
which creates one row per ?y and puts the MIN name paired with ?y, then
joins it to ":alice :knows ?y ."
Andy
On 08/03/11 12:25, baran_H wrote:
Andy, thank you very much for your quick and detailed reply, i think i
understand now logic of 'bottom-to-top' SPARQL evaluation for sub-selects,
i could also other tests get working with this logic.
But i see a test-case for 'SubSelect with LIMIT' in
http://www.w3.org/2009/sparql/wiki/Design:SubSelect
I guess the output there is the result of 'top to bottom' evaluation and
therefore with Joseki 3.4.3 i cannot get that result?? Or do i overlook
some other detail to get this test-case work?
---------------------------------------------
@prefix : <http://people.example/> .
:alice :name "Alice", "Alice Foo", "A. Foo" .
:alice :knows :bob, :carol .
:bob :name "Bob", "Bob Bar", "B. Bar" .
:carol :name "Carol", "Carol Baz", "C. Baz" .
---------------------------------------------
PREFIX : <http://people.example/>
SELECT ?y ?name WHERE {
:alice :knows ?y .
{SELECT ?y ?name WHERE {
?y :name ?name
}ORDER BY ?name LIMIT 1
}}
--------------------------------------------
result: ?y ?name
:bob "B. Bar"
:carol "C. Baz"
--------------------------------------------
thanks, baran.
On Mon, 07 Mar 2011 16:54:25 +0100, Andy Seaborne
<[email protected]> wrote:
> SPARQL evaluation is bottom-to-top (functional). Evaluate the arguments
> then combine them, just like a programming language:
>
> f(3+4, 5+6) => f(7, 11) => ....
>
> Evaluate the two parts:
>
> 1/ The inner select evaluates to one row:
>
> ?x = <http://dbpedia.org/resource/Dynamic_programming>
> ?y ="Dynamische Programmierung"@de
>
> 2/ The ?x dcterms:subject dbpc:Optimal_control evaluates to two rows:
>
> ?x = http://dbpedia.org/resource/Optimal_control
>
> and
>
> ?x = http://dbpedia.org/resource/Dynamic_programming
>
> Combine these with a join:
>
> When you join those there is one answer:
>
> ?x = <http://dbpedia.org/resource/Dynamic_programming>
>
> There will be no results with
>
> ?x = http://dbpedia.org/resource/Optimal_control
>
> It is common to read from top to bottom but it's not always right (and
> in the past, ARQ has got this wrong with sub-selects as well).
>
> Andy
>
>
--------------------------------------------------------------------------------------
>
> On 07/03/11 15:20, baran_H wrote:
>> Hello, i test with Joseki 3.4.3
>> ----------------------------------------------------------------
>> PREFIX dbpc: <http://dbpedia.org/resource/Category:>
>> PREFIX dbpo: <http://dbpedia.org/ontology/>
>> PREFIX dcterms: <http://purl.org/dc/terms/>
>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>> SELECT ?x ?y
>> FROM <http://dbpedia.org/resource/Dynamic_programming>
>> FROM <http://dbpedia.org/resource/Optimal_control>
>> WHERE {?x dcterms:subject dbpc:Optimal_control .
>> {SELECT ?x ?y WHERE
>> {?x rdfs:label ?y . FILTER (lang(?y) = 'en' || lang(?y) = 'de')
>> }ORDER BY (lang(?y)) LIMIT 1
>> }}
>> ----------------------------------------------------------------
>>
>> WITHOUT LIMIT 1 i get:
>> <../Optimal_control> "Optimal control"@en
>> <../Dynamic_programming> "Dynamische Programmierung"@de
>> <../Dynamic_programming> "Dynamic programming"@en
>>
>> WITH LIMIT 1 i get:
>> <../Dynamic_programming> "Dynamische Programmierung"@de
>>
>> I think now: This is coreect if LIMIT 1 is at the end of the query, but
>> LIMIT 1 for nested SELECT should effect, like ORDER BY (lang(?y)) does,
>> only results with identical ?x, because
>> ?x dcterms:subject dbpc:Optimal_control
>> is outer nested SELECT, in the results this is: <../Dynamic_programming>
>>
>> and therefore with LIMIT 1 i expect (??) :
>>
>> <../Optimal_control> "Optimal control"@en
>> <../Dynamic_programming> "Dynamische Programmierung"@de
>>
>> thanks, baran.
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
