soooooo... if I add a FROM <my-graph-uri> my problem should be solved?
maybe this thread goes in the launchpad answers section... A broader consideration: it occurs to me that a configuration system might be good for problems like this (really I should chose whether to deal with dawg compliance in my code not rdflibs). It also would provide a way to better leverage the plugin system rather than the more static state of affairs we have now. Not sure what it would look like exactly but the idea is somewhat inspire by Niklas's use of paste's config system in oort. -w On 8/9/07, Chimezie Ogbuji <[EMAIL PROTECTED]> wrote: > > On 8/6/07, Niklas Lindström <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I did some digging and discovered that the test will work (using > > latest trunk, 1236 right now) if you change DAWG_DATASET_COMPLIANCE in > > "rdflib/sparql/Algebra.py" to False. Not sure wether or not this > > signifies a much bigger problem, my example code below does it by > > "monkey patch" (and I will not change this in the file for now, I feel > > it may be a more deep problem). > > Some explanation of this switch (DAWG_DATASET_COMPLIANCE) might shed > some light. If you follow SPARQL specification verbatim, the > 'default' graph is always the first one that is matched. The > 'default' graph is a graph without an identifier - or at least, its > identifier cannot be matched. This breaks with RDFLib where *all* > Graphs have an identifier which can be matched (note the Graph.quads > method). In the absence of a default graph specified explicitely as > the dataset for the query (via FROM <..>), the default graph is an > empty graph, so any pattern without a GRAPH directive will always > match nothing! In order to comply with SPARQL, the assumption had to > be made (when the compliance flag is set to True) that the default > context for a ConjunctiveGraph is *the* default graph (as defined by > SPARQL). > > Take a look at the graph tests for an example of what is the > 'expected' verbatim behavior here - and how it might be problematic > for RDFLib without these caveats: > > http://www.w3.org/2001/sw/DataAccess/tests/data-r2/graph/ > > This switch was a first attempt to allow a break from this verbatim > interpretation which is problematic for practical use where you have > an RDF dataset all with well defined identifiers and you wish to have > SPARQL patterns without GRAPH operators search within all the named > graphs (which is the expected behavior of ConjunctiveGraph.quads(.)). > The default is True, currently. Perhaps it should be false by default > instead? > > This is not the only area where RDFLib's SPARQL capabilities break > from the verbatim spec interpretation. SPARQL does not allow direct > matching of BNodes in persistence, RDFLib does. So SPARQL patterns > with BNode identifiers evaluated within RDFLib will match those BNodes > in persistence with the same name. It is a well known frustration to > not be able to carry BNode identifiers from one query session to > another (especially against RDF graphs which make heavy use of > BNodes). > > > > This is the "test" code I used. (Please notice my use of FILTER - I'm > > not sure wether that is needed in SPARQL or if the spec says that > > SPARQL does no such "no uniqueness assumption" for bindings by > > default.) > > It doesn't, the filter is neccessary. At least, the sparql-p > evaluation algorithm will unify variables regardless of the names of > the variables. > -- | 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 Dev@rdflib.net http://rdflib.net/mailman/listinfo/dev
