Re: USING/USING NAMED test cases...

On 28 Apr 2011, at 14:16, Andy Seaborne wrote:

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

fine, that means we are on the same page, and this is IMO what the current spec text in Update leaves -deliberatyely- open to implementations and why I wanted to suggest this test cases with the two possible outcomes, to illustrate this.

best,
Axel

> 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 Friday, 29 April 2011 05:22:34 UTC