Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Class equality discussion on code generation feature

Tania Tudorache tudorache at
Wed Apr 8 17:07:14 PDT 2009

Hi Simon,

Paradies, Simon wrote:
> Hi,
> I really like the code generation feature for wrapping Protégé instances into Java objects.
> However, I wonder why two Java Objects obtained by the factory and associated with the same individual are not the same in the sense of the java '==' operator. Example (PersonFactory and Person are generated by Protégé; its OWL but would apply to Frames as well):
> JenaOWLModel owlModel = ProtegeOWL.createJenaOWLModelFromURI("file:///C:/temp/person.owl");
> 		PersonFactory pf = new PersonFactory(owlModel);
> 		Person jd = pf.createPerson("JonDoe");
> 		Person jd1 = pf.getPerson("JonDoe");
> 		Person jd2 = pf.getPerson("JonDoe");
> 		RDFIndividual jdI1 = owlModel.getRDFIndividual("JonDoe");
> 		RDFIndividual jdI2 = owlModel.getRDFIndividual("JonDoe");
> 		System.out.println(jd1 == jd2);
> 		System.out.println(jd1.toString().equals(jd2.toString()));
> 		System.out.println(jdI1 == jdI2);
> 		System.out.println(jdI1.toString().equals(jdI2.toString()));
> I get the following output:
> false
> true
> true
> true
> The generated pf.getPerson() every time creates a new wrapping object.

> I presume that to let the first comparison to be true would require a bit of effort (holding pointers to the already generated objects).
Right. The unused wrapped instances will also be garbage collected when 
they are not reference anymore, while keeping everything in a hashmap 
would prevent that (yes, there are solutions around that).

> Why this works for RDFIndividuals but not for generated classes? Any thoughts or design decisions?

The  RDFIndividuals are the same because you are using a in memory model 
(a file-based model). In this case, the entire content of the ontology 
is read into memory and kept in some structures. Whenever you call 
getRDFIndividual, you get the same Java object. That's why "==" works, 
However, this is not true if you would use a database backend or a 
Protege client (in multi user mode). In that case, we have a Java 
factory that creates the Java objects on demand, and there is no 
guarantee (quite the contrary) that the generated Java objects will not 
be ==. However, they will always be "equal".

So, the right way of testing the equality of the Protege Java objects, 
including the wrapped instances is to use "equals". That will always 
return the right result for any backend.


> Thanks
> Simon
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at
> Instructions for unsubscribing: 

More information about the protege-discussion mailing list