The definition of a domain ontology is a complex activity that requires two kinds of expertise: a deep knowledge of the domain to be modeled and a good level of familiarity with the ontology representation language to be used in order to formalize the built model. Existing ontology languages (such as SHOE, DAML+OIL, OWL) are inherently general purpose, allowing different domains to be tackled and modeled. We believe it is possible to enrich an ontology language with domain specific features to ease the ontology building process. Such a goal can be achieved along two lines. One is to provide a core domain ontology, containing the most general concepts in the domain of interest; another is to introduce specific modeling constructs in the ontology language. The latter option, referred to as domain adequacy, is addressed in this paper. We will show that adding a few domain specific concept categories in the language allows better ontologies to be built.
Domain ontology building is one of the most critical activities required in
ontologybased applications. The task is generally performed by domain experts, who do not
(generally) have the background nor the experience of a knowledge engineer. To ease
this task, ontology management systems (such as Protégé[
Existing ontology languages (such as SHOE[
In this paper we will focus on the latter, illustrating a proposal for augmenting ontology languages, to be used in the business domain. In this perspective, we introduce the notion of “domain adequacy” that represents, for an ontology language, the degree of domain specificity.
In this paper we address the business domain, without reference to a specific production sector (such as automotive, tourism or banking), to introduce a number of categories aimed at supporting the construction of business ontologies. The main proposed categories (referred to as concept kinds) are: Business Actor, Business Process, Business Object, Business Event, Business Message, Business Goal (we will drop the term “business” in the rest of the paper).
In the paper, we present an ontology model, OPAL (Object, Process, Actor modelling Language) where the mentioned concept kinds are used for the definition (and maintenance) of a consistent ontology.
The main goal of the proposed solution is to provide techniques able to ease the work of domain experts when building and maintaining an ontology. In this direction, such techniques should: − provide guidelines for domain experts in analyzing the problem domain and organizing its conceptualization − reduce cost and time required for domain ontology building − enhance the quality of the built ontology, with a support for consistency checking This goal is pursued by introducing elements (concepts) of the application domain in the ontology building environment. In particular, the ontology language is augmented with new constructs, that represent a bias imposed by the domain (meta) knowledge to the language.
Domain adequacy is not aimed at improving the expressive power; conversely, a language that exhibit a higher adequacy in a specific domain is less usable in a different domain: domain adequacy reduces the generality (i.e., applicability) of an ontology language, but allows more synthetic, concise, precise sentences to be formulated in the specific domain (intuitively, we may say that the same content can be represented by a shorter string, assuming an ontology representation in a linear form).
Here we introduce a first set of meta-concepts that represent a few categories in the
business domain. Referring to the traditional Frame-Slot-Facet modeling
paradigm[
All templates are characterized by three sections: (i) identification section, that contains the concept label, description, XML tag, and other meta-data (such as creation date, author) with an administrative flavor; (ii) structural section, that contains the slots corresponding to the attributes (simple or complex) that will be instantiated in the corresponding object; (iii) specific section, that contains information and references to other entities that play a specific role (predefined) in the correct definition of the concept. The first two sections are the same for all the kinds, while the third is differently tailored for each category. Below we briefly describe the specific section for each kind.
A business Actor (Ar) is an operating element of a business domain. The domain expert, in analyzing the reality, is asked to identify relevant actors that operate producing, updating or consuming information. An actor can be an enterprise, a computer system, an employee, a business unit. The corresponding concept is modeled in the ontology, it is categorized as an Actor, when having the following specific section: - Goals: objectives that must be accomplished by the Actor - Skills: indicating the actions it is able to perform - Responsibilities: the actions performed or monitored in achieving Goals - Managed Objects: the information objects required, generated, updated or deleted by the Actor in achieving the Goals.
A business Object (O) is a category that gathers passive entities involved in one or more business processes (subject to the so called CRUD lifecycle: create, read, update, delete). It can be either a material or an immaterial entity. An Object has a specific section that describes: - the Processes that create, manipulate, delete it - the Actors that insist on it - States, defined as boolean expressions over its attributes or those of related concepts.
A business Process (P) is a category that gathers business activities. A Process is aims at accomplish one or more business goals, modifying a set of objects. It can be 1 We experimented already some of them in EU Projects: Fetish and Harmonise, where an interoperability platform, based on a tourism ontology, has been built. The proposed approach has been further elaborated within IDEAS and is currently at the base of the ontology research in the INTEROP Noe and the Athena IP. rather simple, with a limited duration in time, or complex, with parallel branches and phases that last for a long time span.
Processes, as Objects and Actors, can be organized according to a specialisation and decomposition hierarchy, in order to obtain a more structured view of the enterprise activities. Process are decomposed into Actions (An), that can be recursively decomposed till we get to the Elementary Actions (EA), that are not further decomposable.
In modeling the information of an entity or a process, we distinguish between structured information, such as “address”, and elementary information, such as “street name”. Essentially, a (structured) Complex Attribute (CA) is defined as an aggregation of lower level CA and/or Simple Attributes (AA).
In OPAL we identified other conceptual categories, in particular: Business State, Event, Message, Goal, Rule (restrictive or prescriptive) and Decision. Their formal definition is currently in a preliminary stage therefore, also for sake of conciseness, we are not going to further elaborate on them, but we believe that these additional OPAL kinds will contribute in enhancing the domain adequacy of the ontology languages.
4.
As anticipated in the Section 2, the introduction of concepts kinds, besides representing a guideline for the ontology developer, has the purpose of improving the verifiable quality of an ontology. In fact, OPAL defines a rich set of constraints inherent to the ontology representation model. Consistency, a key formal property automatically verifiable, is valuable if a sufficient number of constraints is introduced in the ontology. We distinguish three sorts of constraints: Inherent constraints – imposed by the modeling approach and, therefore, transparent to the user. E.g., the acyclicity of a specialisation hierarchy.
Built-in constraints – specific language constructs, having a precise semantics. E.g., disjoint(A,B) asserts that the concepts A and B do not have common instances. Explicit constraints –defined by the user by means of a constraint language (such as OCL, the UML constraint language). The semantics of an explicit constraint is computed by the system on the bases of the supplied constraint expression.
In OPAL we aim at enriching the inherent constraints, reducing the amount of code (and therefore, of effort, time, and errors) that an ontology engineer has to write when building a domain ontology.
In the next section we present a first set of constraints inherent to the OPAL model. Such constraints are assumed when an OPAL ontology is constructed and automatically enforced by SymOntoX, the ontology management system developed at the LEKS, IASI-CNR.
Besides the concept categories presented in Section 3, the OPAL model includes meta-relations defined among categories. The OPAL meta-relations represent well known modeling notions common to (the knowledge model of) the most Knowledge Representation Languages: (i) inheritance hierarchies among concepts (ii) concept structure, defined by its attributes (iii) domain specific relationships with other concepts.
In the following they are described and, for each of them, the inherent constraints of the OPAL model are presented. Examples illustrating the constraints are taken from the business domain.
Specialisation (inverse: Generalisation) expresses the relation among a broader concept and a narrower concept. For example the concept Person can be specialized into Manager. This relation must be defined among concepts belonging to the same conceptual category (e.g Objects, Actors, Processes). Formally, let ci (i=1,…,n) be concepts, let kind(ci) be the OPAL category of the concept ci. The following constraint must be verified:
1) (c1,c2) ∈ ISA ⇒ kind(c1) = kind(c2) Furthermore the Specialisation relation is transitive and must be acyclic. 2) (ci,cj), (cj,ck) ∈ ISA ⇒ (ci,ck) ∈ ISA (transitivity) 3) there are no sequences c1..cn such that (c1,c2), …(cn-1,cn) ∈ ISA and c1=cn (acyclicity)
Predication expresses the relation among a concept and its attributes. For example a concept Person can have as attributes the concepts Name and Address.
Since this relation typically connects a primary concept with Complex Attributes and Simple Attributes, it must be defined between concepts whose kinds are defined as follows:
4) (ci,cj) ∈ Pr ⇒ kind(ci) = O | Ar, kind(cj) = CA | AA)
PartOf expresses the relation among a concept and a concept representing one of its components. For example an Enterprise can be decomposed in FunctionalUnits or an Address can be decomposed in City, Street, Number and ZipCode.
The involved concepts must satisfy one of the following constraints, depending on their kind: 5) (ci,cj) ∈ Po and kind(ci) = Ar | O ⇒ kind(ci) = kind(cj) 6) (ci,cj) ∈ Po and kind(ci) = CA ⇒ kind(cj) = AA | CA 7) (ci,cj) ∈ Po and kind(ci) = P ⇒ kind(cj) = P | An | EA 8) (ci,cj) ∈ Po and kind(ci) = An ⇒ kind(cj) = An | E
Relatedness expresses the fact that, between two concepts, a domain relation exists. Such domain relation can be labelled. For example an Enterprise can be related to a Manager with a relation named direction. Relatedness is symmetric.
9) (ci,cj) ∈ R ⇒ (cj,ci) ∈ R (symmetry)
The Domain Adequacy of an ontology language indicates the domain specificity of the language. It aims at providing a better guidance to domain experts, supplying a predefined categorization of the concepts introduced in the ontology. Such predefined characterization enhances the quality of the ontology, supplying a number of built-in constraints that can be automatically verified by the OMS supporting the language.
In this paper we briefly presented an ontology modeling language, OPAL, aimed at modeling the business domains. The OPAL concept kinds, and the meta-relations defined among them, have been described. Furthermore, for each meta-relation, inherent constraints of the OPAL model have been identified and their impact on the building (and maintenance) of a consistent ontology has been shown.
The inherent constraints of the OPAL model are automatically enforced by SymOntoX, the ontology management system developed at the LEKS, IASI-CNR.