W3C home > Mailing lists > Public > public-sparql-dev@w3.org > October to December 2010

Re: still not understanding FROM NAMED

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 17 Nov 2010 21:42:44 +0000
Message-ID: <4CE44C54.1060602@epimorphics.com>
To: Bob DuCharme <bob@snee.com>
CC: Lee Feigenbaum <lee@thefigtrees.net>, Rob Vesse <rav08r@ecs.soton.ac.uk>, public-sparql-dev@w3.org


On 17/11/10 20:48, Bob DuCharme wrote:
> Hi Lee,
>
> When I ran the query below with Sesame, although there were { ?s
> <http://example.com/ns/sample#classTitle> ?classTitle } triples in the
> default graph, it only returned the ones in the
> <http://example.com/classes/new/201106> named graph, so I assumed that
> the GRAPH keyword was telling it to look in that specific named graph
> and nowhere else. Is this wrong the wrong behavior by Sesame, and should
> it have needed a FROM NAMED <http://example.com/ns/sample#classTitle>
> first to only return the triples matching that pattern from that graph?
>
> thanks,
>
> Bob

If the query does not itself specify the dataset, you get whatever the 
dataset is for that service endpoint.

GRAPH is about the access to the data; FROM NAMED is about setting up 
the dataset to be queried.

The Sesame behaviour is to be expected if that's the RDF dataset behind 
the endpoint - the query does not specify it.

	Andy

>
>
> On 11/17/2010 11:22 AM, Lee Feigenbaum wrote:
>> On 11/17/2010 7:50 AM, Bob DuCharme wrote:
>>> That makes sense, but if I can do this
>>>
>>> SELECT ?classTitle
>>> WHERE {
>>> GRAPH <http://example.com/classes/new/201106>
>>> { ?s <http://example.com/ns/sample#classTitle> ?classTitle } .
>>> }
>>
>> Hi Bob,
>>
>> This query does not specify an RDF dataset, which means it executes
>> against whatever your SPARQL endpoint treats as its default data set.
>> Some deployments treat this as including all graphs; some treat it as
>> none; still others treat it as configurable.
>>
>>> does FROM NAMED add anything besides the ability to list a few graphs
>>> and then says GRAPH ?varName so that the graph pattern is applied to
>>> several graphs?
>>
>> Right. FROM NAMED explicitly defines the scope of the named graphs for
>> the query - the universe of graphs over which a GRAPH ... clause can
>> range.
>>
>> Slide 13 of http://www.slideshare.net/LeeFeigenbaum/sparql-cheat-sheet
>> has a visual explanation of RDF datasets and SPARQL that might (or
>> might not!) help.
>>
>> best,
>> Lee
>>
>>>
>>> thanks,
>>>
>>> Bob
>>>
>>>
>>> On 11/17/2010 4:24 AM, Rob Vesse wrote:
>>>> FROM NAMED specifies Graphs that are used in GRAPH clauses
>>>>
>>>> e.g.
>>>>
>>>> SELECT * FROM NAMED<http://example.org/myGraph> WHERE { ?s ?p ?o .
>>>> GRAPH
>>>> ?g { ?s ?x ?y }}
>>>>
>>>> Would first find all triples from the default graph (which may in
>>>> fact be
>>>> the union of several graphs) and then the GRAPH part would use Graphs
>>>> specified in FROM NAMED clauses to match additional triples. At least
>>>> broadly speaking that is how it should work. Actual implementations
>>>> tend
>>>> to vary somewhat.
>>>>
>>>> The difference should be that a FROM clause specifies a graph that
>>>> forms
>>>> part of the default graph over which the query operates while the FROM
>>>> NAMED specifies Graphs used only in Graph clauses
>>>>
>>>> Rob
>>>>
>>>> On Tue, 16 Nov 2010 19:29:23 -0500, Bob DuCharme<bob@snee.com> wrote:
>>>>> I understand the various examples in the SPARQL spec that use FROM
>>>>> NAMED, but I still don't completely understand what the FROM NAMED
>>>>> part
>>>>> does, especially compared with FROM<http://some/uri>.
>>>>>
>>>>> http://www.w3.org/TR/2010/WD-sparql11-query-20101014/#namedGraphs says
>>>>> "A query can supply IRIs for the named graphs in the RDF Dataset using
>>>>> the FROM NAMED clause." If they're named graphs, don't they already
>>>>> have
>>>>> IRIs as names? What is FROM NAMED adding here?
>>>>>
>>>>> thanks,
>>>>>
>>>>> Bob
>>>
>>>
>
Received on Wednesday, 17 November 2010 21:43:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 17 November 2010 21:43:26 GMT