I agree with your statements below, but where it becomes incomprehensible for end-users is the following:
case 1): FROM <graphUri1> FROM <graphUri2> everyone agrees that the default graph is the merge of graphUri1 and graphUri2 (unionDefaultGraph plays no role since no named graphs are defined) FROM <graphUri1> FROM NAMED <graphUri2> in this case, I woudl expect the default graph to be just graphUri1, unless unionDefaultGraph=true, in which case the explicitly named graphUri2 has to be merged into it. Don't you agree that any other behavior becomes really difficult to follow for end-users? Simon From: Andy Seaborne <[email protected]> To: Simon Helsen/Toronto/IBM@IBMCA Cc: [email protected], Andy Seaborne <[email protected]> Date: 08/24/2012 10:57 AM Subject: Re: mixing FROM and FROM NAMED with unionDefaultGraph=true On 24/08/12 14:29, Simon Helsen wrote: > Andy, > > ok, thanks for the clarification. No, I really meant > > FROM <graphUri1> > FROM NAMED <graphUri2> > > because we thought that unionDefaultGraph=true would still affect the > explicit (dynamic) dataset. There is always a default graph. If it is not specified, and unionDefaultGraph is false/undef, it is an empty graph. If it is not specified, and unionDefaultGraph is true, it is the union of supplied named graphs. If it is specified, it is the merge of all FROM clauses. Here, you specified it. Andy > > Simon > > > From: Andy Seaborne <[email protected]> > To: [email protected] > Date: 08/24/2012 06:26 AM > Subject: Re: mixing FROM and FROM NAMED with unionDefaultGraph=true > > > ------------------------------------------------------------------------ > > > > On 23/08/12 22:51, Simon Helsen wrote: > > Hi guys, > > > > I have a question which may or may not be a defect, but I need some input > > first. > > > > If you run with unionDefaultGraph==true and you have the following > type of > > query: > > > > SELECT ?o > > FROM <graphUri1> > > FROM NAMED <graphUri2> > > WHERE { ?s <somePredicate> ?o } > > > > I would expect the pattern to match triples in both graphUri1 and > > graphUri2. > > The dataset description is: > FROM <graphUri1> > FROM NAMED <graphUri2> > > so the default graph is contents of <graphUri1> > > unionDefaultGraph is irrelevant - you've overridden it by providing a > dataset description. > > Did you mean: > FROM <graphUri1> > FROM <graphUri2> > > which makes the default the (calculated) merge of 1 and 2. > > > Currently, TDB/ARQ does not do this, but only picks matches > > from graphUri1. Given that unionDefaultGraph=true should merge all named > > graphs into the default graph, this is surprising. To elaborate a bit, we > > found that the following query > > > > SELECT ?o > > FROM NAMED <graphUri2> > > WHERE { ?s <somePredicate> ?o } > > Bug. > > If you specify the dataset description, you are giving a complete > description. There is an empty default graph in that description. > > > does pick results from graphUri2 (when run with unionDefaultGraph==true). > > Also, when we execute the following query: > > > > SELECT ?o > > FROM <graphUri1> > > FROM NAMED <graphUri2> > > WHERE { graph ?g { ?s <somePredicate> ?o } } > > > > then tdb seems to pick results from graphUri2 which is as expected. > > > > We were thinking that explicit FROM/FROM NAMED clauses simply ignores the > > unionDefaultGraph=true switch which could then explain the behavior > of the > > first query above, but it doesn't explain the one of the second query. > > > > Feedback on this is welcome. > > > > thanks, > > > > Simon > > > > >
