jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Reynolds <>
Subject Re: of isomorphism and AdhocDatatypes
Date Tue, 25 Sep 2018 12:26:26 GMT
It has been a while since I had any involvement in this area of the code 
and it may have all changed in the interim but ...

There used to be an assumption that data types are always registered and 
that the same instance of a datatype object will be used by all literals 
with that datatype. So I suspect there are more places in the code than 
just the isomorphism checker where equality of datatype is checked by 
Object equality rather than by, say, URI equality or plain equals.

That does mean that if you change the registration entry for a datatype 
URI after having already read in some data then you'll be breaking that 
assumption. The before- and after- literal instances will test as having 
different datatypes.

Code that dynamically creates new datatypes generally avoids stomping on 
an existing registration of the datatype URI.

Not saying this is a *good* design, but if you want to drop this 
invariant then you may need to look further afield than just the 
isomorphism code.[1]


[1] Indeed I have seen external code that also uses this assumption.

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

View raw message