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-owl] Inconsistent classification due to datatype restriction

Thomas Russ tar at ISI.EDU
Thu Feb 26 09:05:48 PST 2009


On Feb 26, 2009, at 12:58 AM, Ricardo Silva Cruz Gomes wrote:

> Hello,
>
> thanks for the answer Timothy.
>
> In the Types class, i want it to have those restrictions in order to
> define it's dimensions. At the same time i want to show in the
> CarryDimensions the dimensions that it is able to carry, so what can i
> do to achieve that? Take the disjoint between CarryDimensions and  
> Types?

You have to always be aware of the inferential consequences of what  
you are saying.  Unlike a programming language, what you say in OWL  
has effects that depend on the reasoner.  So it is important to be  
aware of exactly what it is you are saying.  In particular, you have  
to pay attention to the difference between "necessary conditions" (a  
one-way implication) and "necessary and sufficient conditions" (a two- 
way implication, also sometimes called the equivalent class).

So, to take some abstract examples.
Assume classes A, B, C; properties p1, p2, p3
=> to show necessary conditions
<=> to show necessary and sufficient conditions

If you say:

A
   B <=>  exactly 1 p1 & exactly 1 p2
   C <=>  exactly 1 p1 & exactly 1 p2

then you have said that ANYTHING which has exactly 1 p1 and 1 p2 is a  
B.  It is, by the second definition also a C.  In fact, these  
definitions imply that B and C are the same class.  If you then add  
that B and C are disjoint, then you get an inconsistent ontology once  
you include individuals.*  This type of assertion is, in fact, the  
source of the problem that you encountered in your ontology.  You had  
an overly general set of necessary and sufficient conditions and they  
resulted in an implication that you didn't really intend to have  
happen.  So you have to be careful.

There are two ways you can get around this.
One way is to make the conditions just be necessary:

A
   B =>  exactly 1 p1 & exactly 1 p2
   C =>  exactly 1 p1 & exactly 1 p2

B /= C

This says that anything that is a B has those properties.  But it  
doesn't say anything about the class that you are in if all we know is  
that you have those properties.  And you can have B and C disjoint  
without problems.

The other approach depends on there being some other intermediate  
classes that are disjoint.
A
  A1
   B <=>  A1 & exactly 1 p1 & exactly 1 p2
  A2
   C <=>  A2 & exactly 1 p1 & exactly 1 p2

A1 /= A2

Here you can use a fully equivalent definition because you include the  
additional class A1 or A2 in the right hand side of the definition.   
So just having the properties alone is not sufficient for class  
membership.

As a general rule, it is often incorrect to have necessary and  
sufficient conditions that consist solely of property restrictions.   
This tends to result in overly broad definitions that include many  
more individuals than you really intend.

----------
* The reason individuals are needed for inconsistency is that it is  
perfectly valid for a model to have classes that are contradictory --  
as long as there are no individuals.  Such classes must have no  
extension in the model theoretic sense. So as long as no individuals  
exist for such classes, there is no inconsistency.  In other words,  
one can define a class of "childless parents", and the ontology is  
fully consistent as long as there aren't any individuals of that class.


> About the imports, I have to refer them to a local file in order for
> the reasoner to load the file.
>
> Thanks in advance,
> regards,
> Ricardo
>
>> Quoting "Timothy Redmond" <tredmond at stanford.edu>:
>>
>> Your ontology is inconsistent.  This is a standard mistake.
>> CarryDimensions should have been defined as
>>
>> Properties and (hasHeighT exactly 1 float
>> and hasLengthT exactly 1 float
>> and hasWidthT exactly 1 float)
>>
>> First of all I will argue that the Types  class is inconsistent.
>> Types are disjoint from Properties and therefore also disjoint from
>> CarryDimensions.
>>
>> On the other hand, the ontology defines CarryDimensions as anything
>> that has exactly one height, length and width.  Unfortunately, the
>> ontology also states that Types have exactly one height, length and
>> width.  So any Types object is also a CarryDimensions object.
>>
>> Since Types is both a subclass of and disjoint from CarryDimensions,
>> the Types class is inconsistent.  But the ontology also claims that
>> there is a ConveyorBelt_1 individual which is a Types.  This is
>> impossible so pellet gets very stuck.
>>
>> A more confusing issue is that your import statements are bad for
>> based on the OWL 1.0 specification.  The reason that this explanation
>> is going to be confusing is that this issue is in flux at the moment.
>> So here is the situation.  In OWL 1.0 your imports statements are
>> broken (see [1]).  This means that when you send your ontology to
>> anyone they need to fix the owl files before they can read your
>> ontologies.  In OWL 2.0 your imports statements are fine (though  
>> maybe
>> not best practice).   However, Protege 4 has not yet caught up to the
>> OWL 2.0 specification so it still favors import by name.
>>
>> -Timothy
>>
>>
>> [1] http://protegewiki.stanford.edu/index.php/How_Owl_Imports_Work
>>
>>
>>
>> On Feb 19, 2009, at 8:42 AM, Ricardo Silva Cruz Gomes wrote:
>>
>>> hello community,
>>>
>>> maybe my last e-mail was not clear, i have an inconsistent ontology
>>> due to the use of datatype restrictions and i would like to remove
>>> that inconsistency. What can i do since i want to keep those
>>> restrictions.
>>>
>>> Can anyone help me?
>>>
>>> The owl files are in the attach.
>>>
>>> Thank you for your answer Thomas Russ.
>>>
>>> thanks in advance,
>>> regards,
>>> Ricardo
>>>
>>>
>>>>>>> Wed, 18 Feb 2009 : Ricardo wrote<<<<
>>> hello community,
>>>
>>> can you have a look at the owl files and tell me what do I have done
>>> wrong because when
>>> there is no individuals in the types class there is no
>>> inconsistency, but once there is
>>> one individual it becomes inconsistent. To make it consistent is
>>> just necessary to take
>>> one of the "dim:hasHeighT", "dim:hasLenghT" or "dim:hasWidthT"
>>> restrictions from the
>>> subclass Types of Conveyor class.
>>> To check the consistency I'm using pellet through the command line
>>> because it's not
>>> possible to use the dig interface for this datatype restriction.
>>>
>>> All the imported ontologies are local, if there is any problem in
>>> opening them is just a
>>> matter of changing the path of each import.
>>>
>>> thanks in advance,
>>> regards,
>>> Ricardo
>>> <
>>> ConveyorOntology
>>> .owl
>>>>
>>> <
>>> DimensionsOntology
>>> .owl><unit.owl>_______________________________________________
>>> protege-owl mailing list
>>> protege-owl at lists.stanford.edu
>>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>
>> _______________________________________________
>> protege-owl mailing list
>> protege-owl at lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03
>>
>
>
> _______________________________________________
> protege-owl mailing list
> protege-owl at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03




More information about the protege-owl mailing list