On 10/28/07, Sidney <[EMAIL PROTECTED]> wrote:
> Before I continue, I wanted to clarify some things concerning graphs.
>
> What's the difference from "default" graphs and "named" graphs as defined by
> the FROM and FROM NAMED clause respectively?  Because it seems that the
> rdflib SPARQL code treats both kinds of graphs virtually the same and adds
> them both to the default graph (ie. base data set).

In SPARQL-proper, the default graph is a graph without an associated
URI identifier (so it cannot be matched by graph IRI).  It is not
necessarily disjoint from the named graphs in the dataset.  Any query
expression which isn't part of a GRAPH clause is supposed to match the
default graph.  The FROM / NAMED clauses are how a user can specify
where to find content to create the dataset (both default graphs and
'named graphs')

WRT rdflib's current SPARQL implementation, the default graph is
considered to be the first Graph with a BNode for an identifier.  See
[1]

> From my understanding of the specs, the default graph is to consist of the
> graphs defined by the FROM clause.

If specified, yes.

> The graphs defined by the FROM NAMED clause are ADDITIONAL graphs that might
> be called upon by the GRAPH clause. So, they should not be included in the
> base data set. Is this correct?

No they are part of the dataset by *definition*, but are only matched
(i.e., only become an 'active' graph during evaluation) via GRAPH
clauses.

> On top of that, you also have the "default-graph-uri" and "named-graph-uri"
> parameters defined by the SPARQL HTTP protocol.

Yes, this is where the service or a top-level protocol request can
specify overridding parameters for the dataset.

> As well, what happens in the case of when the GRAPH clause gets a variable
> and the value for that variable is a uri that that has not been listed by
> any of the above?  For example:

>    ?s foaf:homepage ?g
>    GRAPH ?g { ... }
> A custom graph resolving mechanism will need to take all of these into
> careful considerations.

Yes, but the LoadGraph is only for constructing the dataset
declaratively.  <dialect type='AWWW'> I.e. it must faithfully
construct a dataset from the representations associated with the RDF
information resources identified by the IRIs in the FROM / FROM NAMED
clause</dialect>.

In your example above, the GRAPH must force the group pattern to
'range' (or to be evaluated with-respect-to) all named graphs in the
dataset (each of which must have a IRI associated with it, by
*definition*)

So, at best such a resolver would really only be a URI/URL resolver,
but it might be able to trigger off certain URI schemes, perhaps
(LSID, etc..)

[1] http://rdflib.net/pipermail/dev/2007-September/000271.html

-- Chimezie
_______________________________________________
Dev mailing list
Dev@rdflib.net
http://rdflib.net/mailman/listinfo/dev

Reply via email to