Search Mailing List Archives
[protege-owl] Inconsistent classification due to datatype restriction
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:
> 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
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:
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:
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
The other approach depends on there being some other intermediate
classes that are disjoint.
B <=> A1 & exactly 1 p1 & exactly 1 p2
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
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,
>> 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
>> 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 ). 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
>> not best practice). However, Protege 4 has not yet caught up to the
>> OWL 2.0 specification so it still favors import by name.
>>  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
>>> Can anyone help me?
>>> The owl files are in the attach.
>>> Thank you for your answer Thomas Russ.
>>> thanks in advance,
>>>>>>> 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,
>>> protege-owl mailing list
>>> protege-owl at lists.stanford.edu
>>> Instructions for unsubscribing:
>> protege-owl mailing list
>> protege-owl at lists.stanford.edu
>> Instructions for unsubscribing:
> protege-owl mailing list
> protege-owl at lists.stanford.edu
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
More information about the protege-owl