"Then I am clearly not a smart person." your words. I am only pointing out that the interpretation of unionDefaultGraph and mixed FROM/FROM NAMED clauses is not as obvious as you seem to imply.
"FROM and also including the union is a no-op anyway. " that is your statement and it seems that this is how TDB/Jena is implemented. However, that does not mean it is obvious or intuitive "What is relevant in the spec is that the dataset description is supposed to be "complete". So no FROM should mean empty graph regardless. That seemed unhelpful so ARQ deviates." yes, I think that was an interpretation going around here (based on the spec) as well and agreed, that is not helpful. I know that standards are sometimes intentionally vague to satisfy different communities. However, that does not make it helpful. "But one FROM definitely does mean one graph." if unionDefaultGraph=false, yes. The spec is inclear what happens when unionDefaultGraph=true and I would not be surprised if there are stores out there implementing this differently "There are bugs anyway - try asking for an explicitly named union with the union flag on - it'll stackoverflow." can you be more specific? As for 304, you can close it, but perhaps with a reference to this e-mail thread for future reference thanks SImon From: Andy Seaborne <[email protected]> To: [email protected] Date: 08/24/2012 11:45 AM Subject: Re: mixing FROM and FROM NAMED with unionDefaultGraph=true On 24/08/12 16:24, Simon Helsen wrote: > 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> Then I am clearly not a smart person. Did you ask those people how to specify exactly FROM <graphUri1> FROM NAMED <graphUri2> when the global unionDefaultGraph is set? FROM and also including the union is a no-op anyway. It adds nothing as the graph triples are already there > 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. I think it is consistent - if you say what the default graph is in the query, then it is that. > 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 The editor of this part of the SPARQL 1.0 spec created a careful balance between different viewpoints. Having the default graph as the (fixed) union was common but in many engines FROM* means nothing anyway. Other people wanted web semantics (always read from the web). A third community wanted "contexts". A fourth group wanted independent graphs. All this switchable, namable union business is non-standard that's why the URI of the union graph is <urn:x-arq:UnionGraph>. What is relevant in the spec is that the dataset description is supposed to be "complete". So no FROM should mean empty graph regardless. That seemed unhelpful so ARQ deviates. But one FROM definitely does mean one graph. Andy There are bugs anyway - try asking for an explicitly named union with the union flag on - it'll stackoverflow. > > 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. Presumably because that's the way you send the email. "reply list" is picking up cc's you included.
