RE: another update test added (was: RE: Questions on grammar restrictions on Blank Node reuse across...)

Greg, Andy,

We can further discuss this shortly anyways...

Short summary on top:

The reason why I am insisting on that is that I am afraid, if 05 fails,
then we have a potential problem with the current definitions in Update. :-|
Do you think that our current definitions work, or no? If not, I would be
unsure how to fix them, honestly. Maybe we should get back to the definitions
instead of arguing about the test case...


More detailed:

Re: Greg
> Implementations *should* be failing
> test 05, which is the reason I suggested 05a (which I believe
> they should be passing).

Does that still apply to the midified test case where I use anonymous bnodes ('[]')
in http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/insert-05-g1-pre.ttl
?

Re: Andy
> You have not replied to my point that 05 is wrong and is only
> passable because of the specific definition in the test
> description, nothing to do with SPARQL itself. 05 is wrong
> because, by definition of RDF parsing, the test results must
> be different bNodes.

I don't understand the definition of "wrong" here, sorry.
Particularly, I don't understand in what sense insert-05
(with the fix that I have proposed) tests something *different*
from insert-05a, i.e. why 05a would be "less wrong" accordingly.

Again,
1) insert-05 tests equivalence of the result graphs.
2) insert-05a tests whether the result graphs have the same number of triples

> We could write a stronger 05b but at least 05a will work for
> dataset bnode isomorphism and 05 will fail at that point.

Why would 05 - with the anonymous bnode in g1 - fail?

Thanks for all your time & talk to you shortly,
Axel


> -----Original Message-----
> From: Gregory Williams [mailto:greg@evilfunhouse.com]
> Sent: Tuesday, 10 July 2012 3:44 PM
> To: Andy Seaborne
> Cc: Polleres, Axel; public-rdf-dawg@w3.org
> Subject: Re: another update test added (was: RE: Questions on
> grammar restrictions on Blank Node reuse across...)
>
> To avoid responding to all the messages along the way, I'll
> just summarize by saying that I agree with everything Andy
> has said in this thread. Implementations *should* be failing
> test 05, which is the reason I suggested 05a (which I believe
> they should be passing). It sounds like we should update the
> text in the test read me, because if that text indicates that
> implementations should be passing 05, I think it's not doing
> the job its intended for.
>
> .greg
>
> On Jul 10, 2012, at 9:37 AM, Andy Seaborne wrote:
>
> >
> >
> > On 10/07/12 14:19, Polleres, Axel wrote:
> >>
> >> Hia again,
> >>
> >>> Does not change anything.  It does not create a shared bNode.
> >>
> >> I don't want to test shared bnodes
> >
> > The reason the test was put in was to capture the fact that
> it is the same bnode and not a renaming apart of nodes from
> the graph on an INSERT.
> >
> > It matters for stores that can have one graph as a subgraph
> of another.
> >
> >> , because - as I think you agree -  this is not
> expressible. I want
> >> to approximate this (just as 05a tries to approximate this).
> >> I think that insert-05 is a closer approximation than insert-05a,
> >> that's why I prefer to have 05 in.
> >
> > I do not agree - 05 is not a close approximate because in
> the test tests there are two bnodes, one in g1 and one in g2
> and they are different.
> >
> > You have not replied to my point that 05 is wrong and is
> only passable because of the specific definition in the test
> description, nothing to do with SPARQL itself. 05 is wrong
> because, by definition of RDF parsing, the test results must
> be different bNodes.
> >
> > A better definition in the test description based on
> dataset bnode isomorphism, would *require* a fail of test 05.
> >
> > We could write a stronger 05b but at least 05a will work
> for dataset bnode isomorphism and 05 will fail at that point.
> >
> >     Andy
> >
> >>
> >> Hope that clarifies matters,
> > >
> >> Axel
> >
>
>

Received on Tuesday, 10 July 2012 13:52:58 UTC