Andy, Although this is perhaps a matter of taste, I discussed this issue with a few smart people here who all intuitively assumed that unionDefaultGraph=true would automatically merge graphUri2 into the default graph even if explicitly defined as in the following query:
FROM <graphUri1> FROM NAMED <graphUri2> The unionDefaulGraph parameter should be treated as part of the query semantics and you are simply overruling it with your implementation. That there is a way to formulate the same semantics is irrelevant. It adds complexity when clients use FROM/FROM NAMED and defaultUnionGraph=true Btw, the exact behavior of these clauses in the context of defaultUnionGraph seems to be notably absent in the spec. That is too bad Simon PS: my mail clients adds the sender automatically in cc. I agree that it is annoying and will try to recall removing it, but at the same time, I have had countless cases were you cc-ed me in exactly the same way. From: Andy Seaborne <[email protected]> To: [email protected] Date: 08/24/2012 11:14 AM Subject: Re: mixing FROM and FROM NAMED with unionDefaultGraph=true On 24/08/12 16:06, Simon Helsen wrote: > 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? No. The query asked for default graph to be <graphUri1>. That is what it gets. Why should unionDefaultGraph have any influence on the dataset to query? If you want the alternative, ask for it: FROM <graphUri1> FROM <graphUri2> FROM NAMED <graphUri2> Andy (you don't need to cc me on emails to dev@) > > Simon
