Applications of ontologies exist that go beyond standard deductive reasoning and rather have the character of empirical discovery in knowledge/data. We analyse the inventory of OWL with respect to two such applications, namely to pattern-based ontology matching and to ontology-aware knowledge discovery from databases.
Most design decisions about the OWL standard are motivated by its DL
semantics, reflecting deductive (in the general sense) scenarios of ontology exploitation.
We however assume that OWL ontologies will be frequently used and
sometimes even built by people primarily interested in computerised processing of
information beyond the scenarios foreseen by logicians. The inventory of OWL
could possibly be revisited with such applications in mind. We elaborate on two
such scenarios we exploited in our research: pattern-based ontology matching and
ontology-based knowledge discovery from databases (KDD). Other areas worth
similar analysis could be e.g. ontology retrieval over the web [
Problem A.1 A reviewer can submit a review of a paper. There is inherently
a ternary relationship between the reviewer, review and paper. The
modeller of ontology A may use the SWBPD n-ary relation pattern:5 creating
a concept such as ReviewSubmission, with properties reviewSubmitted,
submittedBy and reviewForPaper. The modeller of ontology B may
however prefer a simpler (though lossy) solution: creating multiple properties
expressing alternative variants of review, e.g. submittedPositiveReview
and submittedNegativeReview. If the ReviewSubmission concept were
annotated as ‘reiefid relation’ in ontology A, the task for a (pattern-aware)
mapping system, aligning A with B via a heterogeneous mapping [
In the context of KDD, formal ontologies allow, among other, to form the data
mining task more easily and accurately and to constrain the search space [
Problem B.1 For the human blood pressure, values that separate normal blood pressure from hypertension and hypotension could be used to create categories of the respective attributes; such categories could have solid chance for yielding strong associations and also make these hypotheses more easily interpretable by experts. Cutting values can be implicitly derived from restrictions on data properties. For example, if class Hypertension Observation is defined as having the value of data property hasSystolicBPValue higher than 140 and the value of data property hasDiastolicBPValue higher than 90 then these values can be suggested as cutting values in the data preparation phase of KDD. The designer of the ontology should however also be able to specify cut values of a data property directly.
6 We do not see the this information specifically relevant to association mining; it can probably be used in numerous other KDD tasks.
Problem B.2 Attributes such as Angina Pectoris, Myocardial Ischemia and Hypertension should be grouped together, as they all correspond to cardiovascular diseases. The same holds for attributes such as Height, Weight or Girth (biometric measures). While the former are likely to appear as classes in an OWL ontology, the latter could sensibly be data properties. 4
It seems that (entities or axioms in) OWL ontologies could be enriched with
the required information (expressing e.g. relation reicfiation, partition criteria,
property cut values and property groupings) in at least four ways:
Solution S0 Enriching the specicfiation of the OWL language itself
Solution S1 Using taxonomic inheritance
Solution S2 Using meta-modelling
Solution S3 Using the forthcoming annotation system of OWL [
The rfist option is clearly hard to put through due to language parsimony concerns. We will thus not consider it for the moment.
The second option is essentially harmless: additional information is attached to the given entity by subordinating it to an entity from a specicfi ‘structural’ ontology. This however only allows to assign binary features (and not e.g. numerical values) and only to atomic entities (not to axioms).
The third option consists in introducing new properties that have as their
domain either OWL meta-classes such as rdfs:Class or owl:DataProperty or
their purposefully defined subclasses. This allows to enrich all entities that are
instances of the given meta-class; it however immediately lifts the ontology to
OWL Full and also contaminates the domain model with information irrelevant
to deduction. A prototype of such practice is the way of modelling so-called
meta-properties in OntoClean [
The fourth option looks most universal; it however depends on the final structure of the OWL 2 annotation system. An advantage might be the possibility to store additional information in a separate file (information space).
Let us now relate the four problems above to the solutions S1-S3: A.1 Mere concepts have to be annotated. It is thus possible to use S1, namely, to create a special ontology with class such as ReifiedRelation, to import this ontology, and to subordinate the ReviewSubmission class to it. A disadvantage of this solution is the fact that an ontological concept was introduced for a notion that is merely anchored in the language (here, OWL as language lacking n-ary relation constructs) and has no real-world semantics.
Alternatively, S3 could presumably be used.
A.2 Disjoint partition axioms have to be annotated. The only applicable solution seems to be S3.
B.1 In our implemented prototype [
B.2 As OWL allows to specify a taxonomy for both classes and properties (including data properties), no information external to the actual domain ontology is presumably needed in most cases, as attribute grouping can reeflct the taxonomic closeness of the respective ontology entities. If necessary, an ontology specifically expressing ‘groupings relevant to data mining’ could be imported, with artificial classes such as Group Concept, i.e. realizing S1. If such ‘hard-coding’ were undesirable, S2 could alternatively be used, via introducing an object property such as sameAttributeGroup having metaclasses in its domain and range. Finally, S3 could be applied in a similar manner as S1.
In general, it seems that exploiting a rich annotation system would help avoid possible negative impact on formal complexity and/or domain accuracy. This work was partially supported by the IGA VSE grant no.20/08 “Evaluation and matching ontologies via patterns” and by the CSF project no.201/08/0802, “Application of Knowledge Engineering Methods in Knowledge Discovery from Databases”. 7 This was influenced by the concept-centric nature of UMLS; for a more DB-schemalike ontology, owl:dataProperty or its new subclass would fit well, in turn.