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] Metaclass mismatch resulting from drag and drop

Richard Dunlap rdunlap at
Wed Jan 31 06:37:51 PST 2007

Thomas Russ wrote:
> On Jan 30, 2007, at 2:16 PM, Richard Dunlap wrote:
>> Build two sibling subclasses of :STANDARD-CLASS, call them :CLASS-1  
>> and
>> :CLASS-2.  Build an instance of each metaclass, Class 1-1 and Class  
>> 2-1,
>> and build a subclass of each of those classes, Class 1-2 and Class  
>> 2-2.
>> Now, drag and drop Class 1-2 as a subclass of Class 2-1 and Class  
>> 2-2 as
>> a subclass of Class 1-1.  Note that we now have an instance  
>> of :CLASS-1
>> with a subclass that is an instance of :CLASS-2, and vice versa.   
>> Mayhem
>> is likely to ensue; even more mayhem may occur if I drag and drop  
>> Class
>> 2-1 under Class 2-2.  If I do this mischeviously, I deserve what I  
>> get;
>> but this can also happen when a user inadvertently drags a class on  
>> the
>> Classes view, and might sensibly happen intentionally while editing  
>> the
>> class structure in an ontology.
>> A suggestion: if a drag and drop would result in an inconsistency
>> between a child's metaclass and a parent's metaclass, ask the user if
>> he/she really wants to do this and, if so, change the child's  
>> metaclass
>> (and the metaclass of all its children, if it was the root of a tree).
> It isn't at all clear to me why this would need to lead to mayhem.
> There doesn't seem to be any reason why subclasses need to share
> the metaclass of their parent.  The meta-class is specific to the
> actual class object itself and isn't one of the things that is
> inherited by subclasses, so having such differences isn't necessarily
> a mistake.

Except that it is "inherited", in the sense that, when I create a 
subclass of a class, it is by default given the metaclass of the parent. 
  One might argue that's a convenience to keep from having to set a 
metaclass everytime... but the fact that that's generally considered to 
be the right choice means there is a certain elegance (or QWAN, if you 
prefer) to that solution.

> For example, suppose one wanted to use metaclasses to track the
> whether a particular class was supposed to be abstract or concrete.
> Changing the superclass link shouldn't necessarily affect whether
> one wants the class in question to change its metaclass.  So, it
> doesn't really appear that inconsistency is a result of just having
> a different metaclass than a parent class.  That would make any
> sort of warning a bit questionable.
> -Tom.
> (Yes, such an Abstract/Concrete distinction could be done with some  
> other
>   meta-annotation, but it seemed like a simple example).

And, in my opinion, it's a contrived example -- especially because 
Protege already deals with that problem in a different way by adding the 
abstract/concrete distinction as a slot to a metaclass definition.  More 
generally, it's using the metaclasses system to track a non-structural 
difference between two classes; simply looking at the existing 
metaclasses, I would argue that the metaclass system is best used to 
enforce structural distinctions.

Here's a more concrete example where this causes problems.  In the 
application that I'm working with, there is a need to represent 
different types of pattern nodes for a set of graph-based knowledge 
structures.  Specific instances of a pattern node type can themselves be 
instantiated into instance nodes, which quickly leads to the forced 
conclusion that pattern nodes are classes. Different pattern node types 
are themselves structurally different for engineering convenience; think 
of it as a set of templates for organizing the slots in a frame into 
various sublists (you'll note this all ties in with issues I've raised 
in the past regarding the handling of subslots of 
:DIRECT-TEMPLATE-SLOTS.) Thus, each pattern node type was found to be 
best represented as a metaclass.  Decide for yourself if this is also a 
contrived use of metaclasses, and then move on.

Now, the drag and drop scenario I originally described is setting up a 
superclass-subclass relationship where the superclass and subclass are 
nodes of different types with different structures. In particular, the 
child is no longer substitutable for the parent, and that violates my 
expectations for a superclass-subclass relationship.  I would tend to 
argue that the metaclass of a subclass should be equal to or a subclass 
of the metaclass of a superclass.  I am aware that the "change 
metaclass" option does not enforce this... and, well, maybe that's a 
problem too.

Enough from me for now -- someone else's turn to talk. :-)

-- Richard Dunlap
    Applied Systems Intelligence, Inc.

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

More information about the protege-discussion mailing list