Ok. Can you clarify what you said here:
GRAPH ?g { ... }
> 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*)
To me, it just seems that "GRAPH ?g" should be easily resolvable dynamically
at evaluation time, regardless of whether the value ?g evaluates to is
included in the *data set* as defined by the named graphs (FROM NAMED). To
me "GRAPH ?g" is kind of like or should be like 4Suite's VERSA function
"scope-evaluate". It also makes me wonder why defining named-graphs (FROM
NAMED) is even required - just resolve graphs dynamically as you need them!
This is why I thought a more sophisticated graph resolution solution was
required: a graph resolver that can take an IRI and return the corresponding
graph. This gives the client the power to define whatever rules they want
for mapping IRIs to graphs.
But if every graph is required to be instantiated at query initialization
(via FROM, FROM NAMED), then overriding the LoadGraph function would
suffice. But of course, passing a graph resolving function or object to the
evaluation process would still be more elegant.
You and the RDFLIB team have a done a tremendous job on the SPARQL
implementation. What I like is that I can use a non-RDFLIB backend (like
4Suite RDF) and wrap it up so it can be used with RDFLIB. The biggest
problem I'm having right now is in how graph resolving works. In terms of
SQL language, I have a set of RDF graphs, each contained in their own
separate tables, that I need to map IRIs to based on whatever rules as
defined by my requirements. So, clearly, the default behavior of the
LoadGraph function is not what I want.
Thanks!
-----Original Message-----
From: Chimezie Ogbuji [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 28, 2007 8:41 AM
To: Sidney
Cc: dev@rdflib.net; [EMAIL PROTECTED]
Subject: Re: [rdflib-dev] Major updates to SPARQL implementation
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
