Re: mixing FROM and FROM NAMED with unionDefaultGraph=true

[Simon Helsen]

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. 

Simon



From:
Andy Seaborne <a...@apache.org>
To:
dev@jena.apache.org
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
>