jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <cla...@xenei.com>
Subject Re: of isomorphism and AdhocDatatypes
Date Tue, 25 Sep 2018 13:25:24 GMT
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 <dave.e.reynolds@gmail.com>
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 <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
> >>>
> >>
> >
> >
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message