[protege-discussion] Bug in "java load packages" feature with inverse-slots

[Stanley Knutson]

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:

System-class

     Meta-class

           Class

                 Standard-class   ->  Generated class is MelStandardClass

                       Entity     - Entity has a slot called "list-of-comparisons"   -> Generated class is MelEntity  

     Config

           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.

 

Stanley Knutson

Director of Engineering

Purisma Inc.

 

                

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-discussion/attachments/20070209/0cf12133/attachment.html>