Re: FROM and FROM NAMED

Richard Newman wrote:
> 
> Hello again folks, DAWG,

Hi Richard,

> 
>   I'm finding the current published SPARQL spec to be a little ambiguous 
> with regards to named graphs. (As a documentation comment, this is 
> primarily because the examples are insufficient; they are each both 
> small and 'positive', in that there are no triples or graphs to 
> distinguish between interpretations by causing spurious or missing 
> results. This makes it hard to divine a correct interpretation by example.)
> 
>   So, an out-and-out question:
> 
> - Can GRAPH clauses be nested? If yes, how is this to be interpreted? 
> The spec does not say that they cannot, and the grammar does not 
> restrict it, but no examples are provided, and it is hard to imagine a 
> reasonable interpretation.

GRAPH clauses can be nested.

The dataset is global set of names, so it is just setting the appropriate
graph for the contained pattern.  An outer GRAPH pattern has no effect on
the choice of graph made by an inner GRAPH clause.

>   ... and two points of clarification:
> 
> - It should be made absolutely explicit that a query is really composed 
> of two interleaved parts:
> 
>   - a collection of patterns that run on the default graph, which is 
> selected by the merge of the FROM clauses
>   - a collection of patterns, each with a GRAPH context, which are run 
> against the collection of named graphs selected by FROM NAMED.
> 
>   Without a careful reading of the spec, it is hard to tell that GRAPH 
> patterns don't also run on the default graph (where the graph variable 
> would be unbound)*. In fact, these two collections of patterns intersect 
> only in their variable bindings; otherwise, they are essentially 
> completely separate.
> 
> 
> - The spec suggests that a default graph is chosen by the implementation 
> only if no dataset specification is provided;

Correct.

> otherwise, the default 
> graph is "a default graph consisting of the merge of the graphs referred 
> to in the FROM clauses". The query:
> 
>   SELECT *
>   FROM NAMED <http://example.com>
>   {
>     ?x ?y ?z .
>   }
> 
> has a dataset specification, but it contains no FROM clauses.

I have added:

"""
If there is no FROM clause, but there is one or more FROM NAMED clauses, then 
the dataset includes an empty graph for the default graph.
"""

to the "Specifying RDF Datasets" section.

http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#specifyingDataset

(numbering is different in the current editors' draft to the last published 
version)


> A strict 
> reading of the spec, then, implies that the default graph is the RDF 
> Merge of 0 graphs, which is the empty graph: the query can have no 
> results. Is this as intended,

Correct

  > or should the implementation provide its
> chosen default graph if there are no FROM clauses? If so, the spec needs 
> to be altered.

Current text includes:

"""
If a query provides such a dataset description, then it is used in place of
any dataset that the query service would use if no dataset description is
provided in a query. The RDF dataset may also be specified in a SPARQL
protocol request, in which case the protocol description overrides any
description in the query itself. A query service may refuse a query request
if the dataset description is not acceptable to the service.
"""

that is, if there is any FROM/FROM NAMED, or protocol request specifying
graphs, it will be used as the dataset description.  The processor is not
free to use some dataset description and some graphs of its choosing.  I hope 
that makes it clear.

	Thanks for the comments
	Andy

> 
>   Regards,
> -Richard
> 
> 
> * Indeed, 9.1 suggests that this is a good idea: "The definition of RDF 
> Dataset does not restrict the relationships of named and default graphs. 
> Information can be repeated in different graphs; relationships between 
> graph can exposed. Two useful arrangements are:
> to have information in the default graph that includes provenance 
> information about the named graphs
> to include the information in the named graphs in the default graph as 
> well.".

Received on Tuesday, 30 January 2007 16:06:50 UTC