Formalizing the OPAL eBusiness ontology design
patterns with OWL
1
Fulvio D'Antonio, Michele Missikoff, Francesco Taglino
LEKS - Laboratory for Enterprise Knowledge and Systems
IASI - CNR, Rome, Italy
{missikoff, dantonio, taglino}@iasi.cnr.it
Abstract. Domain ontology building is one of the most critical activities required in
Semantic Web applications. The task must be performed by domain experts, who do not
(generally) have the background of a knowledge engineer. To ease this task, Ontology
Management Systems (such as Kaon, Protégé, OntoEdit, Athos) are developing user friendly
interfaces. However the problem is mainly of a cognitive nature. Difficulties comes from the
fact that the existing ontology languages: (i) are hard to be used by unskilled people, (ii)
have very basic constructs (e.g., class, property), (iii) are not domain specific, i.e., they are
conceived for very diverse contexts (e.g., from medical sector to high energy physics).
OPAL (Object, Process, Actor modelling Language) aims at supporting business experts
who need to build an ontology by providing a limited number of high level conceptual
templates.
Keywords: Ontology, Ontology representation languages, Axiomatic Semantics,
Formal Languages, Design Patterns
1
This work has been partially supported by the European FP6-IST Project
Athena, contract number: 507849
2 A. Contributor, B. Author and C. Epistoler
1. Introduction
Ontology building is one of the most critical activities required in Semantic Web
applications. The task must be performed by domain experts, who do not
(generally) have the knowledge engineer expertise required to build an ontology.
To ease this task, ontology management systems (such as Kaon, Protégé, OntoEdit,
Athos) propose user friendly interfaces. However the problem is mainly of a
cognitive nature and a GUI can only solve part of it. Difficulties come from the
fact that the existing ontology languages: (i) are hard to be used by unskilled
people, (ii) have very basic constructs (e.g., class, property), (iii) are not domain
specific, i.e., they are conceived for very diverse contexts (e.g., from medical
sector to high energy physics), showing hence little eBusiness specificity.
OPAL (Object, Process, Actor modelling Language) is an ontology
modelling framework aimed at supporting business experts in building an
ontology. To this end, OPAL provides a limited number of high level conceptual
templates, conceived along the lines of software design patterns having in mind the
business world. OPAL design patterns are formally defined by using OWL,
allowing for a compatibility with this popular ontology language. OPAL is at the
basis of the Athos OMS developed within the Athena Integrated Project
2
. It has
been tested and validated in several national and international projects and
applications, showing its effectiveness and high acceptance among business
experts.
1.1 Learning from software design patterns
Software development is a challenging discipline that has significantly evolved in
the last decades. To reduce cost and time of software development, the Software
Engineering (SE) research has proposed several methods and techniques that cover
the whole software lifecycle, from analysis and design to coding and testing.
Ontology development is a hard discipline as well, showing a complexity that is
comparable with software design. Therefore, we explored various SE solutions, to
check their adaptability to the ontology domain.
In a previous paper [2] we addressed the adoption of a systematic
methodology for ontology building, derived from the RUP, referred to as UPON
(Unified Process for Ontology building). UPON includes the possibility of reusing
existing resources (from lexicons and glossaries to thesauri and pre-existing
ontologies) and a step-wise refinement of the developed ontology. In this paper we
intend to address another important approach, based on design patterns.
In this paper we address the design patterns. Design patterns in software
design have been proposed more than a decade ago by a group also known as the
Gang of Four (GOF) [3] with the aim of supporting the design phase of object-
oriented software development. A design pattern is a named, repeatable conceptual
structure that can be used by a software designer to solve an algorithmic problem.
2
http://www.athena-ip.org
Chapter Title 3
It is independent from a specific programming language, since it addresses the
conceptual intricacy of a problem rather than the coding difficulties, but assumes
an object-oriented programming context. In this paper we propose a set of ontology
design patterns, referred to as OPAL (Object, Process, Actor modelling
Language.), to be used in modelling a business ontology.
1.2 Ontology Modelling and Domain Adequacy
In proposing a set of ontology design patterns, we introduce also the notion of
Domain Adequacy. A language (a representation paradigm) is adequate for a given
domain if it adopts specific jargon, constructs, and locutions that characterise the
communication of experts in that domain. From physicians to computer engineers,
but also in very different areas such as sailors or golf players, the members or such
communities have developed their own specific language. The idea of having
domain specific languages to develop software applications is an emerging
research area.
Today, OWL [4] appears to be the most popular language for ontology
modelling. OWL is an ontology language rooted in specific Description Logics [5]
that exhibits a compromise between expressive power and tractability of the
associated reasoning procedures. OWL is a general purpose language that can be
adopted for building ontologies in very different domains; however its generality
does not match friendliness and usability. Therefore, when building an ontology,
domain experts require a substantial help from ontology engineers. Our objective,
in proposing the OPAL representation framework and design patterns, is to lay the
basis for a methodology that can be directly used (when supported by a suitable
tool) by business people when building an ontology.
In defining the OPAL design patterns, we analysed the emerging standards
and methods in enterprise and business modelling identifying a few primary
modelling notions, particularly suited to model a business scenario: Business
Object, Business Process, and Business Actor. Then, we added a number of
complementary modelling notions, such as Business Event, Business Message, and
Business Goal, to enrich and complete a business ontology (please note that in the
sequel, for sake of conciseness, we will drop the term “Business”.). In our
approach, we propose ontology design patterns (ODP) that correspond to the above
modelling notions. Then an ODP is implemented by a template and ontology
building essentially consists in filling a number of OPAL templates. Athos is the
OMS, developed within the Athena European Integrated Project, that supports
ontology building based on OPAL ontology design patterns. Athos has been
already experimented in several business applications with encouraging results.
The rest of the paper is organised as follows. In the next section we briefly
present some of the main ontology design pattern approaches proposed in the
literature aimed at supporting ontology building. In Section 3 the OPAL templates
are illustrated, with the help of a running example in the eProcurement area.
Section 4 provides a formal account of OPAL, by presenting its axiomatic
semantics based on OWL. Finally, in Section 5, conclusions and future research
lines are reported.
4 A. Contributor, B. Author and C. Epistoler
2. Related work
Ontology design patterns represent a promising research line with a number of
interesting proposals. Here we also consider, more in general, ontology
representation framework, that propose modeling notions that can be used for
defining ODP. However none of the illustrated proposals are specifically aimed at
business ontologies.
The Semantic Web Best Practices and Deployment Working Group
(SWBPDWD) has addressed the issue of ontology building by providing
engineering guidelines, ontology/vocabulary repositories and patterns to solve
specific problems (such as representing n-ary relationships or “part of”
representation). Such patterns are of a general nature and are not specifically
conceived for the eBusiness sector.
The General Use Cases (GUC) proposed in [6] have a formal counterpart
called Conceptual Ontology Design Patterns CODeP. A CODeP is considered as a
fragment of either a “foundational” or a “core” ontology (that is called its reference
ontology); in [6] are also presented some design patterns drawn from the DOLCE
foundational ontology.
The Resource Event Agent ontology framework (REA) can be considered a
set of ontology design patterns derived from McCarthy’s work [7] with strong
roots in accounting and economics.
In [8] is addressed the problem of creating (or extracting) ontology design
patterns from corpora of ontologies in the business domain. This work has different
objectives with respect to OPAL. As the author states, enterprise ontologies are so
far quite scarce and often sparsely documented, and therefore most of the work in
the paper is devoted to the extraction of design patterns from enterprise databases.
Concerning different application domains, the Gene Ontology Next
Generation (GONG)
3
project aims to make use of ODP for easing the migration of
biological ontologies to formal languages, like OWL, and for the maintenance of
large biological ontologies. They propose Ontology Design Patterns (ODPs) that,
as Software Design Patterns (SDPs), are formalized, documented, efficient
solutions to frequent modeling problems.
3. The OPAL ontology design patterns
In this section, we present the OPAL templates conceived to implement the ODP
corresponding to the business concept categories.
An ODP is structured following the traditional Frame-Slot-Facet modeling
paradigm. In particular, there is a design pattern (template) for each concept
category (referred to as kind, in OPAL.)
OPAL templates are divided into: primary and complementary. The former
represent the core of a business ontology, the latter are used to refine the former.
3
http://www.gong.manchester.ac.uk/htlatex/design.html
Chapter Title 5
3.1 The OPAL templates
The primary templates: Object, Process and Actor, that have their initials included
in the acronym, are at the basis of the OPAL modeling framework and provide the
backbone of an OPAL ontology.
BusinessActor
It is aimed at modelling any relevant entity of the domain that is able to activate
or perform a process (e.g. Buyer, Supplier). An Actor can be a human being like
an Employee, but also any other kind of entity like an Enterprise or a Computer
System.
BusinessObject
It is aimed at modelling a passive entity, on which a process operates, typically to
modify its state. It is seen as an information object, representative of a material or
an immaterial entity in the real world (e.g. Product)
BusinessProcess
It is aimed at modeling an activity that is performed by an Actor to achieve one or
more given goals. (e.g. Issuing Purchase Order, Sending Request for Quotation)
Table 1: OPAL Primary templates
OPAL includes other conceptual categories typical of the eBusiness domain, such
as, Message, Business Object Document, Business State, Goal, Event, Rule and
Decision. These categories have been identified having considered several
languages and methodologies for business modeling. For instance, messages are
defined along the line of FIPA
4
and the speech act theory. For sake of space, we
are not going to elaborate on complementary templates, except attributes.
In OPAL, attributes are distinguished as:
•
Complex Attribute (CA) structured attributes, such as Address
•
Atomic Attribute (AA), such as Street Name.
Essentially, a Complex Attribute is defined as an aggregation of lower level
CAs and/or AAs.
3.2 OPAL templates organization
An OPAL templates is characterized by three sections, as summarized in the
following table.
Identification Section
contains traditional metadata, such as the concept label,
description, and other information (such as creation date,
author) with an administrative flavor;
Structural Section
that contains the slots corresponding to the attributes (simple
or complex) to be instantiated in the corresponding object; it
contains also the semantic relations (such as ISA,
decomposition, etc.) with other concepts;
Specific Section
that contains information and references to other entities that
play a specific role (domain specific) in the correct
definition of the concept (e.g,, executed processes in the
Actor template).
Table 2: OPAL templates’ sections
4
www.fipa.org
