inheritance of allowed classes from multiple superclasses

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

inheritance of allowed classes from multiple superclasses

Mike Bada

Hello Team Protege,


I've been taking advantage of the overriding of allowed classes at
specific class levels extensively for my project and have noticed
behavior of inherited allowed classes that seems odd to me.
Specifically, when the slot of a class has the possibility of inheriting
different sets of allowed classes (because multiple superclasses of the
class also have this slot but with different sets of allowed classes),
the slot arbitrarily inherits one set of allowed classes, rather than an
intersection, as I would think. A simple example: Say you have classes
A, B, X, and Y, all of which are direct subclasses of :THING, and a slot
s; furthermore, there is a class C which is a subclass of A and B. s is
given a domain of A or B and the allowed classes X or Y at its top
level. At the level of A, s is overridden to have only X as an allowed
class, and at the level of B, s is overridden to have only Y as an
allowed class. Now, to me, C should ideally have X and Y (i.e., the
intersection of X and Y) as its set of allowed classes: If the value of
s of an instance of A must be an X, and if the value of s of an instance
of B must be a Y, then the value of s of an instance of C (which is also
instance of A and of B) must be an instance of X and of Y. However, in
Protege, at the level of C, s arbitrarily inherits either X or Y.
(Actually, in the GUI, it seems that it inherits the corresponding
allowed class of the class of which C was first made a subclass.) In
addition to being unintuitive, this behavior also seems to violate
Protege's rule that the set of allowed classes of a slot at a class
level should always be a subset of the sets of allowed classes of the
slot at superclass levels: In the case that s inherits X at the level of
C, X is not a subset of Y, which is the set of allowed classes at the
level of B (the superclass of C).


Has there ever been any discussion of this behavior, or has there been
any effort toward this representation? I understand that intersection of
classes is not part of frame-based Protege's knowledge model, and that
introduction of intersection probably wouldn't be trivial, as it'd have
to be able to specify complex expressions (e.g., (D or E) and (F or G)).
Protege's reasoning capabilities would probably have to be expanded (or
an external reasoner used). If there's no effort to such a capability,
we plan on writing external code that would try to resolve such
expressions to specific classes in the ontology (essentially, a simple
reasoner), but we wanted to know if anything's already in the pipeline...


Cheers,

Mike

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: inheritance of allowed classes from multiple superclasses

Thomas Russ


On Jun 6, 2006, at 3:41 PM, Mike Bada wrote:

>
> Hello Team Protege,
>
>
> I've been taking advantage of the overriding of allowed classes at
> specific class levels extensively for my project and have noticed
> behavior of inherited allowed classes that seems odd to me.
> Specifically, when the slot of a class has the possibility of  
> inheriting
> different sets of allowed classes (because multiple superclasses of  
> the
> class also have this slot but with different sets of allowed classes),
> the slot arbitrarily inherits one set of allowed classes, rather  
> than an
> intersection, as I would think. A simple example: Say you have classes
> A, B, X, and Y, all of which are direct subclasses of :THING, and a  
> slot
> s; furthermore, there is a class C which is a subclass of A and B.  
> s is
> given a domain of A or B and the allowed classes X or Y at its top
> level. At the level of A, s is overridden to have only X as an allowed
> class, and at the level of B, s is overridden to have only Y as an
> allowed class. Now, to me, C should ideally have X and Y (i.e., the
> intersection of X and Y) as its set of allowed classes: If the  
> value of
> s of an instance of A must be an X, and if the value of s of an  
> instance
> of B must be a Y, then the value of s of an instance of C (which is  
> also
> instance of A and of B) must be an instance of X and of Y. However, in
> Protege, at the level of C, s arbitrarily inherits either X or Y.
> (Actually, in the GUI, it seems that it inherits the corresponding
> allowed class of the class of which C was first made a subclass.) In
> addition to being unintuitive, this behavior also seems to violate
> Protege's rule that the set of allowed classes of a slot at a class
> level should always be a subset of the sets of allowed classes of the
> slot at superclass levels: In the case that s inherits X at the  
> level of
> C, X is not a subset of Y, which is the set of allowed classes at the
> level of B (the superclass of C).

Well, I would actually expect different (and easier to implement  
semantics).

I was with you up to the point where you expected the intersection of
the set of allowed classes.  I would agree that is what should happen.
But instead of taking the O-W-L notion of class intersection, I would
take the simpler notion of set intersection.  In that case, I would  
expect
that Protege frames would have the empty set for slot s on C, and thus
also expect the max cardinality of s to be zero.

This preserves the subset of sets rule, since the empty set is trivially
a subset of all sets.  And it is easy to implement, since it doesn't  
require
anything more than performing a set intersection on the sets of allowed
classes.  There is no need to do taxonomic reasoning and no need to  
create
and new classes.

This makes some sense for follow-on effects, since unless a multiple-
inheritance
class is specified in the class hierarchy, you can't actually create  
an instance
of more than one class in Protege frames.


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: inheritance of allowed classes from multiple superclasses

Mike Bada

But you can create an instance of more than one class in frame-based
Protege!  So I think an explicit representation of intersection would be
best since, referring back to my example, you could create an instance
xy that is an instance of X and of Y.  Then, for an instance of C, you
could fill in s with xy, even though there's no mutual subclass of X and
of Y.  This seems consistent with the semantics, yes?

Thomas Russ wrote:

>On Jun 6, 2006, at 3:41 PM, Mike Bada wrote:
>
>  
>
>>Hello Team Protege,
>>
>>
>>I've been taking advantage of the overriding of allowed classes at
>>specific class levels extensively for my project and have noticed
>>behavior of inherited allowed classes that seems odd to me.
>>Specifically, when the slot of a class has the possibility of  
>>inheriting
>>different sets of allowed classes (because multiple superclasses of  
>>the
>>class also have this slot but with different sets of allowed classes),
>>the slot arbitrarily inherits one set of allowed classes, rather  
>>than an
>>intersection, as I would think. A simple example: Say you have classes
>>A, B, X, and Y, all of which are direct subclasses of :THING, and a  
>>slot
>>s; furthermore, there is a class C which is a subclass of A and B.  
>>s is
>>given a domain of A or B and the allowed classes X or Y at its top
>>level. At the level of A, s is overridden to have only X as an allowed
>>class, and at the level of B, s is overridden to have only Y as an
>>allowed class. Now, to me, C should ideally have X and Y (i.e., the
>>intersection of X and Y) as its set of allowed classes: If the  
>>value of
>>s of an instance of A must be an X, and if the value of s of an  
>>instance
>>of B must be a Y, then the value of s of an instance of C (which is  
>>also
>>instance of A and of B) must be an instance of X and of Y. However, in
>>Protege, at the level of C, s arbitrarily inherits either X or Y.
>>(Actually, in the GUI, it seems that it inherits the corresponding
>>allowed class of the class of which C was first made a subclass.) In
>>addition to being unintuitive, this behavior also seems to violate
>>Protege's rule that the set of allowed classes of a slot at a class
>>level should always be a subset of the sets of allowed classes of the
>>slot at superclass levels: In the case that s inherits X at the  
>>level of
>>C, X is not a subset of Y, which is the set of allowed classes at the
>>level of B (the superclass of C).
>>    
>>
>
>Well, I would actually expect different (and easier to implement  
>semantics).
>
>I was with you up to the point where you expected the intersection of
>the set of allowed classes.  I would agree that is what should happen.
>But instead of taking the O-W-L notion of class intersection, I would
>take the simpler notion of set intersection.  In that case, I would  
>expect
>that Protege frames would have the empty set for slot s on C, and thus
>also expect the max cardinality of s to be zero.
>
>This preserves the subset of sets rule, since the empty set is trivially
>a subset of all sets.  And it is easy to implement, since it doesn't  
>require
>anything more than performing a set intersection on the sets of allowed
>classes.  There is no need to do taxonomic reasoning and no need to  
>create
>and new classes.
>
>This makes some sense for follow-on effects, since unless a multiple-
>inheritance
>class is specified in the class hierarchy, you can't actually create  
>an instance
>of more than one class in Protege frames.
>
>
>-------------------------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>  
>

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html