On 9/19/07, Chimezie Ogbuji <[EMAIL PROTECTED]> wrote:
> On 9/19/07, whit <[EMAIL PROTECTED]> wrote:
> >
> >
> > > This should only be used against a CG since it will cause it to load
> > > the default graph ( "context" ). If you are dispatching SPARQL, you
> > > should either do it against a CG or use a GRAPH name / variable in the
> > > expression (perhaps with a topLevel binding of the graphs identifier:
> > > g.query(..query..,initBindings={Variable('graphName') :
> > g.identifier
> > > }).
>
> > I think saying graph.query(somequery) explicitly says "I want to query this
> > graph", and no ids should be necessary
>
> True. In retrospect, I guess it would simply be an API shortcut for
> "construct a RDF dataset consisting of an empty set of URI labeled
> graphs and a default graph composed of the source graph and evaluate
> the query".
>
> That accommodates both SPARQL and the RDFLib API
>
> > (note... this is what seems to be
> > going on) so though I accept that passing in the initBinding would work, why
> > are you making me do that?
>
> It was only a first attempt to reconcile the expected behavior for
> matching RDF datasets with the RDFLib API. This is not a trivial
> consideration. See: "No way to specify an RDF dataset of all the
> known named graphs", for instance:
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007Apr/0001.html
>
> > And why should CG and Graph act differently here
> > (and why should I have to care?)
>
> See above. I can add the above behavior.
>
> > > SPARQL queries are dispatched against RDF datasets, which are
> > > composed of 'multiple' RDF graphs.
> > hmmm... I picked that up from the crazy conditional blocks in
> > rdflib.sparql.Algebra.TopEvaluate (speaking of which,
> > shouldn't we be following
> > http://www.python.org/dev/peps/pep-0008/?)
>
> Sure. I've been a little more preoccupied with implementing full
> SPARQL behavior than formatting printable code =).
well... readable code is at least kind to those might help you debug...
would you mind if one of us cleaned it up a bit?
> > would the determination of dataset be something that should happen outside
> > of the graph API?
>
> In the absence of a dataset identified in the protocol request or in
> the query itself, the dataset used to match against a SPARQL query is
> application-specific. So, other than the graph API there isn't any
> other immediately obvious place to identify the dataset.
> > the fact that a query can call in other resources beyond the graph makes me
> > sort of feel like a more explicit api would be something like this:
>
> This is built into the SPARQL language. Any use of FROM <..>
> *requires* that the 'default graph' is loaded with the RDF resolved
> from the URI.
oh. bummer.
> > from rdflib import sparql
> >
> > ... set up a list of graph and resource, etc
> >
> > sparql.query(myquery, data=list_of_graphs_or_resources,
> > default_graphs='someid')
>
> The data argument wouldn't make sense there since the dataset is
> either determined already (if specified at the protocol), specified in
> the SPARQL query itself, or it is application-specific (in which case
> if it is evaluated against a CG, this is the RDF dataset, otherwise
> it's a bit wonky and the compromise seems to be to assume an RDF
> dataset with no named graphs and a single default graph consisting of
> the object of the 'query' method).
>
> The default_graph keyword would really only apply if the query is
> called against a CG and you wanted to explicitly identify the BNode to
> use as the identifier of the default graph (instead of using the
> 'first' one). i.e:
right... if sparql doesn't allow for the definition of "the universe"
outside of the query, the default keyword doesn't make much sense.
> class ConjunctiveGraph(..)
> def query(self,query,default_graph=self.default_context,....):
> pass
>
> > Otherwhise, it feels like we are conflating graphs and datasets or at least
> > hiding the actual relationship (and leading to nasty surprises).
>
> There is no conflation happening with graphs and datasets. The
> confusion is between the RDFLib API, the 'formal' definition of an RDF
> dataset, and the way for RDFLib to setup an 'application-specific'
> RDF dataset (in the abcense of any indication of one).
ok, this is making a bit more sense.
> > If my graph is ided as "http://myns/dataname";, I expect FROM to use that if
> > my graph is ided "http://myns/dataname"; as it, not attempt to download some
> > web resource (what currently happens).
>
> The FROM operation is supposed to behave that way by definition:
>
> "The FROM and FROM NAMED keywords allow a query to specify an RDF
> dataset by reference; they indicate that the dataset should include
> graphs that are obtained from representations of the resources
> identified by the given IRIs"
>
> By "representations of the resources .." they mean a HTTP dereference
> - at least with FROM <...>. FROM NAMED Is different.
>
> > Sparql seems to default sensibly the
> > graph the query dispatched from, but not recognize the id of that default
> > graph.
> Here is the chain:
>
> 1. No FROM / FROM NAMED in SPARQL query
> 2. Does the protocol specify a URI which resolves to an RDF
> representation to use as the default graph? No...
> 3. Use the application-specific default graph. Either:
> 3a. The default_context of the CG the query was dispatched against
> 3b. The Graph in CG with the given BNode as its identifier
> 3c. The *first* Graph in CG with a BNode identifier (or en empty graph
> if there is none)
> 3d. Use the graph the query was dispatched against
ok... thanks for explaining this.
what is happening makes a bit more sense than just being a startling
surprise when my query tries to load up a http resource. ;)
-w
--
| david "whit" morriss
|
| contact :: http://public.xdi.org/=whit
"If you don't know where you are,
you don't know anything at all"
Dr. Edgar Spencer, Ph.D., 1995
"I like to write code like
other ppl like to tune their
cars or 10kW hifi equipment..."
Christian Heimes, 2004
_______________________________________________
Dev mailing list
[email protected]
http://rdflib.net/mailman/listinfo/dev
