Proceedings of the 12th European Conference on Knowledge ...

A Pattern-Based Ontology Engineering Platform
Thomas Janke
SAP Research, Dresden, Germany
thomas.janke@sap.com
Abstract: Building knowledge management systems based on semantic technologies can pr<strong>of</strong>it from <strong>the</strong> use <strong>of</strong>
ontologies. The latter provide a shared vocabulary, which helps to shape common understanding, fosters reuse
and data integration as well as facilitates reasoning. The problem companies are facing, though, is that, despite
all advantages, ontology engineering is very hard to master. First <strong>of</strong> all, domain engineers need to select <strong>the</strong>
most suitable ontology language from <strong>the</strong> pool <strong>of</strong> available languages ensuring that <strong>the</strong> chosen language reflects
<strong>the</strong> requirements <strong>of</strong> <strong>the</strong> given domain by means <strong>of</strong> expressivity, reasoning performance and tool support.
Moreover, in order to model high-quality ontologies, a good knowledge about <strong>the</strong> various logical formalisms, <strong>the</strong>
<strong>of</strong>fered ontology languages are based on, <strong>the</strong>ir characteristics and <strong>the</strong>ir differences is required. Published best
practices for ontology engineering, so called Ontology Design Patterns (ODPs) (Gangemi and Presutti, 2009) can
help here. They describe how to solve common modeling problems. The problem, though, is that in order to apply
such a pattern, ontology engineers not only have to find a suitable pattern but also need to understand its
semantics. The platform presented in this paper tackles those problems from two directions. First <strong>of</strong> all, domain
engineers are enabled to model <strong>the</strong>ir domain utilizing domain-specific languages reflecting <strong>the</strong> specific
requirements <strong>of</strong> <strong>the</strong> particular domain. As a result, <strong>the</strong> modeling task will be significantly simplified. Moreover,
based on <strong>the</strong> introduced level <strong>of</strong> abstraction, <strong>the</strong> platform will enable <strong>the</strong> generation <strong>of</strong> concrete ontologies in
various target languages and in doing so, mitigates <strong>the</strong> problem <strong>of</strong> language selection. Fur<strong>the</strong>rmore, <strong>the</strong> ontology
generation component introduces room for <strong>the</strong> second main principle which is <strong>the</strong> automatic and transparent
application <strong>of</strong> ODPs. This means that every transformation <strong>of</strong> domain-specific models into ontologies is based on
executable ontology patterns which can be contributed and registered to <strong>the</strong> platform by ontology experts.
Keywords: Ontology engineering, Model driven development, Ontology design patterns, Domain-specific
languages
1. Background
Knowledge management can be facilitated by utilizing semantic technologies. The reasons for that
are manifold. First <strong>of</strong> all, ontologies provide a vocabulary <strong>of</strong> domain relevant terms which helps to
build a common understanding. Moreover, <strong>the</strong>y can be designed in a modular way which fosters
reuse, helps to build standard vocabularies for certain domains (e.g. Friend <strong>of</strong> a Friend, Dublin Core)
and provides a basis for data integration. In addition, ontologies allow for inferring implicit knowledge
by means <strong>of</strong> reasoning. As a result, relevant parts <strong>of</strong> <strong>the</strong> knowledge in a specific domain can be
explicitly modelled in <strong>the</strong> ontology, in contrast to implementing <strong>the</strong> required logic in <strong>the</strong> business logic
layer <strong>of</strong> a target application.
The problem, however, is that ontology engineering is challenging, especially for non-experts. This
problem has many dimensions. First <strong>of</strong> all, <strong>the</strong>re is <strong>the</strong> aspect <strong>of</strong> language selection. In order to
choose <strong>the</strong> ontology language best suited for a given domain, available languages such as RDF(S),
OWL 2 with all its flavours and pr<strong>of</strong>iles, Topic Maps, F-Logic, etc., need to be compared with respect
to <strong>the</strong>ir expressivity, <strong>the</strong>ir reasoning performance, available frameworks, editing support and so on.
Moreover, if <strong>the</strong> requirements for <strong>the</strong> domain model change, <strong>the</strong> process <strong>of</strong> evaluating all <strong>the</strong>
languages needs to be repeated. This is not only time consuming but requires deep knowledge about
all <strong>the</strong> languages. After selecting a language, <strong>the</strong> next problem emerges and this is <strong>the</strong> lack <strong>of</strong>
modeling expertise. The various languages are based on different logical formalisms, starting from
description logics and semantic networks to rule based languages. Each formalism has its specific
characteristics, for example <strong>the</strong> existence <strong>of</strong> <strong>the</strong> unique name assumption or <strong>the</strong> open world
assumption. Knowing about those differences and <strong>the</strong>ir impact is a key requirement to model good
ontologies. It addition to that, it is favourable to follow published and widely accepted modeling best
practices, in order to guarantee high modeling quality. Referring to <strong>the</strong> related work in this area, those
best practices are called ontology design patterns. They describe how to solve common modeling
problems and cover experiences gained by ontology engineering experts. The problem, though, is
that in order to apply those pattern, domain engineers have to be aware <strong>of</strong> <strong>the</strong>ir existence, <strong>the</strong>y need
to find a matching pattern for <strong>the</strong>ir problem, need to understand <strong>the</strong> provided solution and finally have
to adopt <strong>the</strong> solution to <strong>the</strong>ir own domain models. As a non-ontology export, each <strong>of</strong> those steps
represents a tough challenge. At <strong>the</strong> moment, <strong>the</strong> gap between domain engineers, knowing about <strong>the</strong>
particular domain, and ontology engineers, knowing how to transfer <strong>the</strong> modeling requirements into
concrete ontologies, can only be filled by an intense collaboration between both roles. This introduces
461