Search Mailing List Archives
[protege-discussion] Bug in "java load packages" feature with inverse-slots
sknutson at purisma.com
Fri Feb 9 15:22:31 PST 2007
We have been using the "java load packages" feature (KnowledgeBase.addJavaLoadPackages) with code generated from our model using a modified JSave module.
It has worked very well.
We have encountered a problem with deleting instances that contain a slot that is an inverse-slot to a slot contained in a metaclass.
A similar problem occurs with undo of deletion of objects that are part of an inverse-slot pair.
In both cases, it appears the cls-specific object (the generated java class) is replaced by the generic object within the processing of the delete-simplification framestore.
We are on Protégé 3.1, but there does not appear any change in the relevant code in 3.2.1
We'd like some help if possible in determining the problem and coming up with a fix.
The model looks like this:
Standard-class -> Generated class is MelStandardClass
Entity - Entity has a slot called "list-of-comparisons" -> Generated class is MelEntity
Comparison - Comparison has a slot called "containing-entity", with inverse-slot as "list-of-comparisons", Generated class is MelComparison
With this model we create some objects:
MelEntity my-entity (creating a Cls using metaclass entity)
MelComparison cmp1 (created as instance using Cls comparison)
MelComparison cmp2 (created as instance using Cls comparison)
Set cmp1's "containing-entity" to my-entity -> the list of comparisons contains cmp1
Set cmp2's "containing-entity" to my-entity -> the list of comparisons contains cmp1 and cmp2
Delete cmp2 -> the list of comparisons changes to just cmp1
The problem is the "containing-entity" in cmp1 is replaced during the delete process by a different object (of type MelStandardClass) instead of the proper MelEntity class type. The two objects have the same FrameID, so this would not be a problem for any application not using java packages. What I think is happing is the ReferenceImpl objects internal to DeleteSimplificationFrameStore are storing the original (non-specifc) objects and these objects are getting inserted into the slot somehow.
This mismatch of the exact frame object type breaks our application quite a bit: we have a lot of places where we expect the generated class type to be used (as is promised by the JavaLoadPackages feature), so we get class cast exceptions after the delete has occurred.
Director of Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the protege-discussion