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] Restricting Cardinality Restrictions in Subclasses

Thomas Russ tar at isi.edu
Tue Sep 7 10:40:32 PDT 2010


Probably better discussed on the protege-owl list.

On Sep 7, 2010, at 2:03 AM, Natschläger Christine wrote:

> Hello,
>
> I have a question regarding the inheritance of cardinality:
> Is it possible to restrict cardinality restrictions for subclasses  
> in Protégé 4.x?
>
> I want to define that a class has 1..n relationships (min 1).  
> However, one of the subclasses can only have exactly 1 relationship.  
> If I insert the first restriction for the superclass and the second  
> restriction for the subclass, I see both restrictions (the first  
> under inherited anonymous classes and the second under superclasses).
> Is this correct?
> Having two restrictions [1..n] and [1], is the second really  
> overwriting the first or

The restrictions are cumulative.  The second doesn't overwrite the  
first.  Instead, it is enforced in addition to the first.

One of the key concepts to grasp is that all of the restrictions in  
OWL are logical axioms.  In other words, they are inference rules that  
OWL reasoners can use to infer information.  They can also be used to  
detect inconsistencies, such as when the axioms are violated.

>  would it be possible for a user to create nevertheless several  
> relationships for the subclass?


It would still be possible for a user to create several  
relationships.  But that has nothing to do with the inheritance.  OWL  
does not prevent violation of the constraints.  OWL reasoners,  
instead, identify ontologies that are inconsistent when the  
restrictions are violated.

This is a bit different mode of operation that you are perhaps  
expecting.

In particular, the inference part of this often comes as a surprise to  
many users who are more used to programming language operation.

For example, if you had the restriction "A: exactly 1 P" and then  
added the following assertions:

  a-1 type A
  a-1 P p-1
  a-1 P p-2

This would be a fully consistent ontology, and an OWL reasoner would  
also be able to conclude the following inference:

   p-1 sameAs p-2

since that would be required in a consistent ontology.  This also  
shows the way the lack of a unique name requirement can surprise new  
users, since they might not be expecting that the two individuals  
"p-1" and "p-2" could be the same.  But unless there is some reason  
why they cannot be the same individual, they are allowed to be  
identical.

> I have found a thread on "inheriting quantifier restrictions" from  
> 2007 (http://thread.gmane.org/gmane.comp.misc.ontology.protege.owl/20964 
> ), with a discussion whether inherited and actual restrictions are  
> connected with AND or with OR. The answer to this thread was "AND",  
> so if I connect [1..n] and [1], the intersection would be 1.
> Can I, however, somehow adapt or remove the entry [1..n] under  
> inherited anonymous classes to not confuse the user?

 From the semantics point of view, you can't get rid of the inherited  
restriction, since it is actually present in the class hierarchy.

If you wanted to create your own interface, you could then choose to  
suppress the display of any subsumed restrictions.  But AFAIK there  
isn't any option for that in the Protege interface.  You would have to  
build that yourself.

> Regarding the question whether this should be possible at all, I  
> have only found one presentation:http://www.itee.uq.edu.au/~infs3101/_Lectures/09_OWL.pdf
> On slide 10, it is stated that the cardinality can be strengthened  
> on subclasses by increasing the min or decreasing the max value. I  
> would agree on this suggestion and would also allow “exactly” if the  
> value is lying between the min and max of the superclass.

Exactly is just shorthand for having min = max cardinality.  So it is  
implied as a consequence of the definition of exact cardinality.   
Strictly speaking, there isn't any need to actually have an exact  
cardinality operator, since it is redundant.  But it is often  
convenient.  You will find that there can be more than one way of  
expressing the same restriction using OWL.

> In addition, I have one further question: Is it possible, to  
> restrict properties based on the value of other properties? E.g. I  
> have a class with a boolean Data Property. If the value of the  
> property is true, then another property must select from a value  
> partition A, however, if the value is false, then the other property  
> must select from a value partition B. Or: If the data property is  
> true, then an object property to class C should be possible,  
> otherwise to class D.

In general this may not be possible, since arbitrary restrictions  
between the values of properties in OWL is not expressible.  But there  
are certain specific cases where you can do this.  The example you  
give is among those that can be expressed in OWL.

The way to think about this is to work on building a description of  
the logical restrictions that you want your class to fulfill.  If you  
can formulate that within the restriction language of OWL, then you  
can do it.  So, for example, one could write a restriction like the  
following.  In this I will use "<=>" to indicate "necessary and  
sufficient" conditions and "=>" to indicate "necessary" conditions.   
So based on what you write, you would need to create two subclasses.

So something like:

    Sub-1 <=> Base and hasValue P1 true
    Sub-1  => all P2 A

    Sub-2 <=> Base and hasValue P1 false
    Sub-2  => all P2 B

This adds some more subtlety to this by choosing between "necessary"  
conditions and "necessary and sufficient" conditions.  These will have  
some impact on the reasoning that is done and the particular  
inferences or consistency violations that will be detected.  By making  
the boolean value be "<=>" it forces any individual of "Base" with  
that boolean value to belong to the subclass (the sufficient part of  
the constraint).  That will, in turn, end up requiring the appropriate  
necessary restriction on the other property.




More information about the protege-discussion mailing list