On 10/28/07, Sidney <[EMAIL PROTECTED]> wrote:
> 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".
Now you put it that way, I see what you mean. Essentially it is the
same mechanism in both query languages and it would be pretty useful
enough to abstract.
> It also makes me wonder why defining named-graphs (FROM
> NAMED) is even required - just resolve graphs dynamically as you need them!
Most of the queries I use in practice have this form: i.e., no dataset
clauses and no GRAPH expressions. Intuitively it should match
whatever RDF data the application has in mind (which is basically a
user-defined resolving function).
> 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.
Yes.
> 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.
Well, in SPARQL there is the notion of a query service which may
override the dataset that the queries are evaluated against. A
resolving function (which has a default behavior if the user doesn't
specify one) passed to the Graph.query method could be considered such
an override.
However, the query method is quickly becoming crowded, so it might be
a good time to reconsider some separation of the moving parts: query
parsing, evaluation, extension hooks, etc..
> You and the RDFLIB team have a done a tremendous job on the SPARQL
> implementation.
Thanks :)
> 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.
Yes. It is a case for reconsidering the query APIs.
-- Chimezie
_______________________________________________
Dev mailing list
Dev@rdflib.net
http://rdflib.net/mailman/listinfo/dev
