ok, now I understand. I will look into it.
best
Rupert
On Fri, Jun 28, 2013 at 4:27 PM, Reto Bachmann-Gmür <r...@wymiwyg.com> wrote:
> Hi Rupert,
>
> I do not understand your example. The "bNode" and "bNodeClone" are not
>> the same. Even that your force them to return the same hashCode, they
>> are in fact different BNode instances and therefore MUST NOT be
>> treated as the same Resource in a Graph.
>>
>
> No, Two BNode are equals if the equals method returns true. This is
> trivially the case when they are same instance but this doesn't need to be
> the case. They can well internally have an ID mapping to an id of the
> backend.
>
>
>>
>> AFAIK Clerezza does not support "ids" for BNodes, but relies on
>> "identity" (instance equality - bnode1 == bnode2). So based on that
>> "bode" and "bNodeClone" created by the provided test case are NOT
>> equals, but in fact different resources.
>>
>
> No clerezza is defined by it's api, so any bnode subclass qualifies as
> bnode. The above would be the case if and only is the bnode api would
> specify that equals has to return true if and only if it's the same object
> instance.
>
>
>>
>> What this means for the assertions in the provided test case is
>> described in detail in the following statements.
>>
>> mGraph.add(new TripleImpl(bNode, uriRef1, uriRef2));
>> mGraph.add(new TripleImpl(bNodeClone, uriRef2, uriRef3));
>>
>> bNode and bNodeClone are different resources
>>
>> NonLiteral bNodeBack = mGraph.filter(null, uriRef1,
>> uriRef2).next().getSubject();
>> Assert.assertEquals("The bnode we get back is not equals to
>> the one we added", bNode, bNodeBack);
>>
>> "bNodeBack" is equals to "bNode"
>>
>> NonLiteral bNodeBack2 = mGraph.filter(null, uriRef2,
>> uriRef3).next().getSubject();
>>
>> "bNodeBack2" is equals to "bNodeClone"
>>
>> Assert.assertEquals("The returnned bnodes are no longer
>> equals", bNodeBack, bNodeBack2);
>>
>> but "bNodeBack" and "bNodeBack2" are not equals as "bNode" and
>> "bNodeClone" are not.
>>
>> Assert.assertTrue("Not finding a triple when searching with
>> equal bNode", mGraph.filter(bNodeBack, uriRef2, null).hasNext());
>>
>> also this is expected to be empty, because there is no triple such as
>> "bNode", "uriRef2", "*"
>>
>>
>> BTW: if you you change bNodeClone to "bNodeClone = bnode" the test
>> runs fine (as expected)
>>
>> This does not mean that there is no issues related to bNodes. It just
>> means that the provided example does not show the problem.
>>
>
> It does show the problem. And it's a very real problem because a clerezza
> wrapper from some backend will not create inmenory mapping from orignal
> bnodes to clerezza bnodes but simply wrap the bnodes and implement hashcode
> and equals in a constistent fashion. So the test I added must pass for
> conformant implementation.
>
> Cheers,
> Reto
>
>
>
>
>>
>> best
>> Rupert
>>
>>
>>
>> On Fri, Jun 28, 2013 at 12:37 PM, Reto Bachmann-Gmür <r...@wymiwyg.com>
>> wrote:
>> > Hi Rupert,
>> >
>> > I've added a commented out failing test for
>> > STANBOL-1130<https://issues.apache.org/jira/browse/STANBOL-1130>
>> > .
>> >
>> > Cheers,
>> > Reto
>> >
>> >
>> > On Fri, Jun 28, 2013 at 12:23 PM, Rupert Westenthaler <
>> > rupert.westentha...@gmail.com> wrote:
>> >
>> >> Hi Reto,
>> >>
>> >> I changed the comparator implementation of the IndexMGraph some weeks
>> >> ago, because the old code was not working when different Resource
>> >> implementations where mixed within the same graph. So this indicates
>> >> indeed a bug.
>> >>
>> >> Can you add a failing unit test for this issue?
>> >>
>> >> best
>> >> Rupert
>> >>
>> >>
>> >> On Fri, Jun 28, 2013 at 12:07 PM, Reto Bachmann-Gmür <r...@apache.org>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > Investigating why recipe-exmpansion in no longer working I found that
>> it
>> >> > seems to be an issue with the IndexedMGarph as things work when using
>> >> > SimleMGraph instead. It used to work till a couple of week ago.
>> >> >
>> >> > Now it seems that a bnode is no longer identical to itself when
>> occuring
>> >> in
>> >> > different triples. While I'm investigating further I though I ask if
>> >> > someone else noticed problems like that.
>> >> >
>> >> > Cheers,
>> >> > Reto
>> >>
>> >>
>> >>
>> >> --
>> >> | Rupert Westenthaler rupert.westentha...@gmail.com
>> >> | Bodenlehenstraße 11 ++43-699-11108907
>> >> | A-5500 Bischofshofen
>> >>
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westentha...@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>>
--
| Rupert Westenthaler rupert.westentha...@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
