Re: USING/USING NAMED test cases...

Dear Andy,

I totally see your point, that for your use case

    <g1>
       _:a :p :o, :o2 .

is a valid result.

However, IMO, also the other view could make sense in a different scenario...
I can imagine that actually implementations treat USING/USING NAMED (just like some implementations treat FROM/FROM NAMED as retrieving a graph from the Web by dereferencing the IRI (similar to load)

Now under that assumption, let's say we have 

<http://g1>
  _:a :p :o .

in the graph store, and

<http://g1>
  _:blabla :p :o .

on the Web... (both graphs are equivalent, but when g1 was first loaded to the store, it has assigned distinct bnode to the bnode _:blabla)

Then, IMO in that scenario, the result
     <g1>
       _:a :p :o.
       _:b :p :o2.

would totally make sense.

The way I see it, in the current spec text, we do *not* impose either in the current spec, 
by leaving that behavior up to the implementation. I don't think that we can/shall prescribe either way at this stage.
A test case with two possible outcomes should just illustrate that this feature is implementation dependent.
Does that make sense?

Axel


On 28 Apr 2011, at 08:53, Andy Seaborne wrote:

> 
> 
> On 27/04/11 23:36, Axel Polleres wrote:
> > Should we add the following example as test cases the test suite, making explicit that the behavior is not dictated by the spec?
> > Can someone remind me how/whether we have dealt with test cases that allow - implementation dependent -  alternative outcomes?
> > I think I vaguely remember that we had that case already...
> >
> > Axel
> >
> > Graph store:
> >     <g1>
> >       _:a :p :o .
> >
> > Do we want Q1
> >
> >     INSERT {GRAPH<g1>  ?s :p :o2 } WHERE  {GRAPH<g1>  ?s :p :o }
> >
> > and Q2
> >
> >     INSERT {GRAPH<g1>  ?s  :p :o2 } USING<g1>  WHERE  {?s :p :o }
> >
> > and Q3
> >
> >     INSERT {GRAPH<g1>  ?s  :p :o2 } USING NAMED<g1>  WHERE  {GRAPH<g1>  ?s  :p :o }
> >
> > behave the same or different? That is, does the new dataset defined by USING/USING NAMED change bnodes or not?
> 
> I want them to be the same.
> 
> I want it to be legal within-graph-store operations to treat bNodes as
> entities in the store, like IRIs or literals.  graphs/sub-graphs use
> case matter to me.
> 
> I don't care if we also make it legal to rename bNodes apart regardless,
> but I do not want to force that behaviour.
> 
> It's very hard to do the renaming consistently across operations, and
> across requests and across queries+requests.
> 
> > Essentially, for Q1, we'd expect as resulting graph store:
> >
> >     <g1>
> >       _:a :p :o; :o2.
> 
> Yes.
> 
> (it's potentially different _:a but the point is there is one)
> 
> > whereas for Q2/Q3 we probably may rather expect:
> >
> >     <g1>
> >       _:a :p :o.
> >       _:b :p :o2.
> >
> 
> I don't expect that.
> 
> Explaining why
> 
> WHERE  {GRAPH<g1>  ?s :p :o }
> USING<g1>  WHERE  {?s :p :o }
> 
> must be different is a "challenge".
> 
> > but that might be implementation depenent also
> >
> >     <g1>
> >       _:a :p :o; :o2.
> 
> which is what ARQ does.
> 
>         Andy
> 
>