Dave, I figured this might be the case. Thus my "Don't Do That" note at the beginning. Thx for the note.
I am beginning to suspect that they should be isomorphic but are not due to historical development decisions. Claude On Tue, Sep 25, 2018 at 1:26 PM Dave Reynolds <[email protected]> wrote: > 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 > >>> > >> > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
