Search Mailing List Archives
[protege-discussion] Metaclass mismatch resulting from drag and drop
rdunlap at asinc.com
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
>> :CLASS-2. Build an instance of each metaclass, Class 1-1 and Class
>> and build a subclass of each of those classes, Class 1-2 and Class
>> 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.
>> is likely to ensue; even more mayhem may occur if I drag and drop
>> 2-1 under Class 2-2. If I do this mischeviously, I deserve what I
>> but this can also happen when a user inadvertently drags a class on
>> Classes view, and might sensibly happen intentionally while editing
>> 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
>> (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.
> (Yes, such an Abstract/Concrete distinction could be done with some
> 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
Enough from me for now -- someone else's turn to talk. :-)
-- Richard Dunlap
Applied Systems Intelligence, Inc.
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
More information about the protege-discussion