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] Problem with removal of an included project

Richard Dunlap rdunlap at
Fri Feb 2 10:34:14 PST 2007

We've found a problem that occurs when removing an included project from 
another project where the included project provided base classes from 
which the master classes build derived classes.  I'll say up front that 
I'm in general happy with the way Protege handles this situation... 
except in this case. :-)

Open up a new project.  Build a subclass of :STANDARD-SLOT called 
:CUSTOM-SLOT, and add to :CUSTOM-SLOT a new slot called 
:SLOT-CUSTOM-VALUE.  Give it single cardinality and make it of type String.

Build a new subclass of :THING called Class.  Add a slot to it called 
classSlot, move to the Slots Tab, and change the slot metaclass to 
:CUSTOM-SLOT. (In the actual case from which this bug report is derived, 
this happens without the Slots Tab via a custom widget on a 
:DIRECT-TEMPLATE-SLOTS subslot.) Go back to Class, open up the top-level 
slot view of the slot, and enter a value of "baseValue" for 

Save this project as baseProject.

Open up a new project.  Save it as derivedProject, and then add 
baseProject as an included project.  Class will now be available; add a 
subclass called DerivedClass.  If at this point, baseProject is removed 
from the list of included projects, Protege will reload derivedProject 
with readily understandable errors related to the non-existence of Class 
and place both Class and DerivedClass under an :UNDEFINED superclass. 
Hard to see a better solution.

Here's the problem.  Open up the "at class" view of classSlot in 
DerivedClass, and change the value of :SLOT-CUSTOM-VALUE to 
"derivedValue".  Save the project and remove baseProject.  This time, 
the errors are parse errors from the .pont file; even more disturbingly, 
while DerivedClass is loaded, it does not show up on the Classes Tab (it 
and Class both show up as instances of :STANDARD-CLASS on the Instances 
Tab.)  What I'd expect is the same resolution as in the previous 
paragraph, except that the slot override of the custom value in the 
custom slot would be irretrievably lost (unfortunate, but forced).

As one would expect, the situation does not change if the :CUSTOM-SLOT 
definition is placed in its own project included by both baseProject and 

Thanks for any help possible in advance!

-- Richard Dunlap
    Applied Systems Intelligence, Inc.

More information about the protege-discussion mailing list