Re: USING/USING NAMED test cases...

On 28/04/11 13:57, Axel Polleres wrote:
> 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)


Yes - I acknowledged that:

 >> I don't care if we also make it legal to rename bNodes apart regardless,
 >> but I do not want to force that behaviour.


>
> 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.

If by "totally" you mean "in every system", then I don't support that. 
If you mean it's one possible implementation of the specification, then 
that is what I am suggesting.  Both "within store, no renaming" (because 
the system knows the bnodes are the same) and "load from web, renaming" 
should be possible.  I would point out that "laod from web" always 
creates fresh bnodes because its an RDF syntax - that's independent of 
the SPARQL 1.1 update specification.  BNode labels in documents are 
scoped to the GET request.


I am arguing that a system can legitimately do " _:xyz :p :o, :o2" *as 
well*.

You had:
"""
whereas for Q2/Q3 we probably may rather expect:

    <g1>
      _:a :p :o.
      _:b :p :o2.
"""
and I don't expect that (probably or not :-)

Q2 is:
INSERT {GRAPH <g1> ?s  :p :o2 } USING <g1> WHERE  {?s :p :o }
Q3 is:
INSERT {GRAPH <g1> ?s  :p :o2 } USING NAMED <g1> WHERE  {GRAPH <g1> ?s 
:p :o }

> 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?

I have proposed wording that I think is better:

"describes a datasets in a manner similar to FROM"

"""
my concerns about the intention to prescribe still stand - "identical" 
is a bad choice of word, "similar to" or "describes a datasets in a 
manner similar to FROM" - the point being one implementation can meet 
the dataset description using "FROM" etc definition in one way and meet 
it for USING in another.
"""


	Andy

>
> 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
>>
>>
>

Received on Thursday, 28 April 2011 13:17:31 UTC