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]
Dave
[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 <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 <[email protected]> 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
