jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: of isomorphism and AdhocDatatypes
Date Tue, 25 Sep 2018 13:34:41 GMT


On 25/09/18 12:35, Claude Warren wrote:
> Adding the equals() and hashCode() overrides does not work as the code
> calls Object.equals().

"the code" - where?

See LiteralLabelImpl.equals.

it calls Objects.equals (line ~375) so overrides work.

Objects.equals is the code:

public static boolean equals(Object a, Object b) {
         return (a == b) || (a != null && a.equals(b));
     }

Are you sure the lexical parts are "equals"?

If you can test just the literals at (8), its easier than the whole of 
GraphMatcher.

> 
> My base question is should the two literal nodes be considered "equal" for
> isomorphic purposes?
> 
> In my test case I do the following:
> 
> 
>     1. register the datatype
>     2. create a model
>     3. add a the triple <http://example.com/subj> <http://example.com/pred>
>     typedLiteral
>     4. serialize the model to a byte array.
>     5. register a different instance of the same datatype
>     6. create a new model
>     7. deserliaze the byte array into the new model.
>     8. test for isomorphism
>     9. test for present of triple using original typedLiteral.
> 
> The isomorphism test fails (as does the presence of the triple) even when
> equals and hashCode are overridden on the Datatype.
> 
> I can provide code if required.


> 
> On Tue, Sep 25, 2018 at 10:08 AM Andy Seaborne <andy@apache.org> wrote:
> 
>>
>>
>> On 25/09/18 09:48, Claude Warren wrote:
>>> I have a case that I know falls under Don't Do That (DDT), but it got me
>>> wondering.
>>>
>>> Background:
>>>
>>> We have created a custom data type that extends AdhocDatatype and
>> provides
>>> a data type for an enum.  The parse() and unparse() methods work as
>>> expected.
>>>
>>> I have a test case that managed to create 2 instances of the datatype
>> (this
>>> is the DDT part).  I will be spending this morning figuring out why we do
>>> this and what the proper solution is.  But it got me thinking.
>>>
>>> The isomorphic test fails on the enum data type based literals.  Looking
>> at
>>> the code, in BaseDatatype.java, it perfors Object.equals( datatype1,
>>> datatype2 ) in the various equality checks.
>>>
>>> Question:
>>>
>>> Since the two datatype instances return the same enum, and the lexical
>> form
>>> of the two is the same, and there is no language specified, should they
>> not
>>> be considered equal?  Should the two graphs not be considered isomorphic?
>>>
>>> If not can someone explain why?
>>
>> Because you haven't implemented .hashCode() and .equals()?
>> (AdhocDatatype doesn't and can't).
>>
>> BaseDatatype does not implement .hashCode() and .equals() - the inner
>> TypeValue does ... but that's the value, not the term.  See
>> LiteralLabel.equals.
>>
>>          Andy
>>
>>>
>>> Claude
>>>
>>
> 
> 

Mime
View raw message