[seek-kr-sms] Modeling large scale ontologies in OWL: Unmet needs (fwd)

[Shawn Bowers]

This is a good explanation of a current problem in OWL, and relevant to
SEEK KR/SMS. This problem haso been addressed in OWL 1.1 via qualified
cardinality restrictions.  Interestingly, I believe OBOE was recently
criticized for using the same property name with two distinct domains (the
"hasSubject" property), however, this email argues that this is often a
useful approach.


-shawn


---------- Forwarded message ----------
Date: Wed, 20 Sep 2006 16:25:33 +0200
From: David Decraene <David at landcglobal.com>
To: public-semweb-lifesci at w3.org
Subject: Modeling large scale ontologies in OWL: Unmet needs
Resent-Date: Thu, 21 Sep 2006 04:57:52 +0000
Resent-From: public-semweb-lifesci at w3.org


I would like to bring to discussion/debate what I believe is a flaw in the
design of the OWL web ontology language, at least if OWL will also serve a
purpose in representing large scale ontologies. I'll start the discussion
by listing some general examples of OWL 'properties' from the OWL
tutorials: HasFinger, HasSpouse, HasTopping, HasVintageYear, HasBrother,
HasParent, HasUncle, HasMaker, HasSugar, etc ... We have a problem with
this, seeing that these are not properties, but concatenated Property -
Target combinations. For a large scale (formal) ontology, imagine the
amount of duplication would occur if we would treat every parthood
relation as such; HasFinger, HasToe, HasNail, HasHair, HasSkin, HasVein,
HasCell, HasBone, HasMuscle, etc... In large scale ontologies, one link
should suffice, HasPart, and whether the part is a finger, toe, nail,
muscle or anything else is not a task for the property to describe, but
for the target, e.g. the ISA hierarchy where the respective parts are
situated in. Now this might seem trivial, and it might seem that OWL
allows the second approach as well, but the fact is that OWL propagates
this line of thought in how properties should be constructed and
restricted: Some of the existing expressivity of OWL (mainly: assigning
cardinalities) can not be applied if we decide to generalize property
types (formal modeling) to represent the nature of the relation, e.g.
without a description of what the target is (which is a task for the
target hierarchy).

Lost expressivity: cardinality. In OWL optional properties can be used by
setting mincardinality to 0: <Hand> Has6thFinger mincardinality 0 See how
in the above example we do NOT state a target. As a matter of fact the
above named property only has a meaning when the range is specified, in
this case the range might be <6th finger>. So we can use optional
properties, but only if we create a unique property for every property -
target combination. In formal ontology you could express this relation on
a general level of parthood: <Hand> HasPart <6thfinger>, cardinality 0.
This is not possible in OWL.

In OWL absence of properties can be modeled by setting cardinality to 0:
<Undiagnosed hyperbilirubinemia> IsDiagnosisParticipant cardinality 0
<Untreated hyperbilirubinemia> IsTreatmentParticipant cardinality 0 Again
in these examples we do NOT state the target, and again these above stated
examples might be referring to anything, the only way we (and a reasoner)
are able to figure that the properties are about <Diagnosis> and
<Treatment> is if we set the range of those properties as such. In formal
ontology you would express this relation on a general level of
participation: <Undiagnosed hyperbilirubinemia> IsParticipantOf
<Diagnosis> Cardinality 0 <Untreated hyperbilirubinemia> IsParticipantOf
<Treatment> Cardinality 0

Conclusion: OWL offers great expressivity, but only IF we use the above
mentioned approach of proliferating redundant properties at a large scale.
This is not a luxury we have in (formal) modeling of large scale
ontologies. As an example, the core domain of LinkBase (our inhouse
formal, medicine-oriented ontology) exists of about 700.000 concepts
(classes) which are related to each other with more than 700.000 relation
instantiations. The OWL approach would lead to hundred thousands of
properties, which in many ways would duplicate the classhierarchy.

It would be great to receive some feedback on this matter.

David Decraene
PH.D. BioMedical sciences/Ontology modeller.
Language and Computing