an ontology for software - uni koblenz-landaustaab/research/...loose design: an ontology is...

An Ontology for Software

Daniel Oberle1, Stephan Grimm2, and Steffen Staab3

1 SAP Research, CEC Karlsruhe, 76131 Karlsruhe, Germany, [email protected] Research Center for Information Technology, FZI, 76131 Karlsruhe, Germany,

[email protected] University of Koblenz-Landau, ISWeb, 56016 Koblenz, Germany,

[email protected]

1 Introduction

The domain of software is a primary candidate for being formalized in anontology. On the one hand, the domain is sufficiently complex with differentparadigms (e.g., object orientation) and different aspects (e.g., security, le-gal information, interface descriptions, etc.). On the other hand, the domainis sufficiently stable, i.e., new paradigms and aspects occur rather seldom.Capturing this stable core in a reference ontology for software can be fruit-ful in order to prevent modeling from scratch. For example, the approachesdescribed in the Chapter “Ontologies and Software Engineering” introduceindividual formalizations of at least one paradigm or aspect although theyshare basic principles.

In this chapter, we present such a reference ontology for software, calledthe Core Software Ontology, which formalizes common concepts in the soft-ware engineering realm, such as data, software with its different shades ofmeaning, classes, methods, etc. As we cannot possibly formalize a completeand comprehensive view of software, the Core Software Ontology is designedfor extensibility in different directions. In order to demonstrate the extensi-bility, the chapter presents three examples of how to extend the core ontologywith the notions of libraries, policies, and software components.

The reference nature of such an ontology makes it important to clarifythe intended meanings of its concepts and associations. Otherwise, users of-ten have a hard time untangling the intended meanings. The prevailing typeof ontologies, namely ones which are lightweight and quite often reduced tosimple taxonomies, are not eligible for this purpose because they exhibit thefollowing shortcomings (as identified in [10]):

Conceptual Ambiguity: We will consider an ontology to be conceptually am-biguous if it is difficult for users to understand the intended meaning

S. Staab and R. Studer (eds.), Handbook on Ontologies, International Handbooks 383on Information Systems, DOI 10.1007/978-3-540-92673-3,c© Springer-Verlag Berlin Heidelberg 2009

384 D. Oberle et al.

of concepts, the associations between the concepts, and the relationshipsbetween concepts and modeled entities.

Poor Axiomatization: Even when an ontology is easy to understand by manyor most of its users, it may have only a poor axiomatization. Such a pooraxiomatization will lead to an unsatisfying restriction of possible logicalmodels (cf. Chapter “What is an Ontology?”).

Loose Design: An ontology is afflicted with loose design, if it contains mod-eling artifacts. Modeling artifacts are concepts and associations which donot bear ontological meaning.

Narrow Scope: An ontology exhibits narrow scope when it is unclear howa distinction could be made between the objects and events within aninformation system (regarding data and the manipulation of data) and thereal-world objects and events external to such a system. As an exampleconsider the distinction between a user account and its correspondingnatural person(s).

In order to remedy the shortcomings, we build the Core Software Ontologyon a foundational ontology (cf. Chapter “Foundational Choices in DOLCE”)and apply content ontology design patterns (cf. Chapter “Ontology DesignPatterns”). We demonstrate that the formalization of the software domaincan greatly benefit from the use of the DOLCE foundational ontology and thecontent ontology design patterns extracted from Descriptions & Situations,the Ontology of Plans, as well as the Ontology of Information Objects.

The chapter is structured as follows: we start by presenting the origin andmotivation of our ontology in Sect. 2 in order to understand which aspects havebeen taken into account and why. Subsequently, we sketch the formalizationof the Core Software Ontology in Sect. 3 and some of its extensions in Sect. 4.For the complete formalization we refer the reader to [11,12]. Section 5 showsexamples of how the four shortcomings are improved as a proof of concept.We give an overview of related work in Sect. 6 and conclude in Sect. 7.

2 Background

An initial ontology for software certainly cannot cover every single paradigmand aspect related to software. As an example, we limit ourselves to the con-cept of object orientation. In order to understand which aspects have beentaken into account and why, we present here the origin and motivation ofour ontology, viz., the work presented in [11]. The motivation for buildingthe ontology in this work is the missing conceptual coherence of applicationserver and Web service descriptors. We motivate that a careful and rigor-ous modeling of the computational domain is necessary to automate – or atleast facilitate – some development and management tasks related to softwarecomponents and Web services. Several use cases are identified that give usindications of what concepts a suitable ontology must contain.

An Ontology for Software 385

The use cases relevant for developing and managing software componentsin application servers are: libraries and their dependencies, conflicting licensesof libraries, capability descriptions, component classification and discovery, se-mantics of parameters, support in error handling, reasoning with transactionalsettings and reasoning with security settings.

The use cases relevant for developing and managing Web services are: an-alyzing message contexts, selecting service functionality, detecting loops in theinterorganisational workflow, incompatible inputs and outputs, relating com-munication parameters, monitoring of changes, aggregating service informa-tion and quality of service.

Altogether, the use cases let us derive a set of modeling requirementsfor deciding which aspects our ontology should formalize. The model-ing requirements are: (i) libraries, licenses, component profiles, componenttaxonomies, API descriptions, semantic API descriptions, access rights andworkflow information of software components and (ii) service profiles, ser-vice taxonomies, policies, workflow information, API descriptions, as well assemantic API descriptions of Web services.

We do not claim that the modeling requirements are exhaustive. However,they allow us to constrain the initial modeling horizon. As demonstrated inthe following, the ontology is designed in an extensible way such that furthermodeling requirements can be met easily.

3 Formalization of the Software Domain

Our contribution starts in this section with the Core Software Ontology (CSO)which introduces fundamental concepts of the software domain such as soft-ware itself, data, classes, or methods. The purpose of the ontology is to providea reference by specifying the intended meanings of software terms as preciselyas possible, and to prevent the shortcomings mentioned in the introduction.

The contribution continues in Sect. 4 where we extend the Core Soft-ware Ontology in different directions, e.g., in the direction of software com-ponents, resulting in a Core Ontology of Software Components. All of theontologies have been presented in detail in [11, 12] and are available athttp://cos.ontoware.org.

Figure 1 shows that we reuse the foundational ontology DOLCE [9] as amodeling basis. DOLCE and its extensions Descriptions & Situations (DnS)[5], the Ontology of Plans (OoP) [4], and the Ontology of Information Objects(OIO) [4] provide us with content ontology design patterns which we applyfor formalizing the software domain. For extensive running examples pleaserefer to [11,12].

3.1 Software vs. Data

We start our discussion of the Core Software Ontology with a detailed discus-sion of software and data. In order to clarify both concepts, which are heavily


DOLCE

Ontology

Core

Specificity

gene

ricco

re

reusedontologymodules

contribution

Descriptions

Fig. 1. Overview of the ontologies as UML package diagram. Packages representontologies; dotted lines represent dependencies between ontologies. An ontology O1

depends on O2 if it specializes concepts of O2, has associations with domains andranges to O2 or reuses its axioms

inflicted by polysemy, it is necessary to identify and formalize the entitiesof the computational domain. The computational domain has a reality of itsown, consisting of data manipulated by programs that implement algorithms.The programs that manipulate the data are usually referred to as software.Upon close inspection, it seems that the term software is overloaded and refersto at least three different concepts:

1. The encoding of an algorithm specification in some kind of representation.Encoding can be either in mind, on paper, or any other form. The Quick-sort algorithm can be represented as Java or pseudo code, for instance.This is SoftwareAsCode (which we abbreviate to Software) and is a kindof OIO:InformationObject.1

2. The realization of the code in a concrete hardware. These realizationsare the DOLCE:PhysicalEndurants that are stored on hard disc or resid-ing in memory. Henceforth, we call them ComputationalObjects (a specialkind of OIO:InformationRealization). This could be the appearance of the

1 Throughout the chapter, concepts and associations are written in sans serif andare labelled in a namespace-like manner. Namespace-prefixes indicate the on-tology where concepts and associations are defined. If no namespace is given,concepts and associations are assumed to be defined in the ontology currentlydiscussed. With respect to the formulae given in the following, the reader mightrefer to Chapters “Description Logics, Ontologies in F-Logic, Resource Descrip-tion Framework (RDF), Web Ontology Language: OWL, Ontologies and Rules”for the logic background.


Quicksort algorithm in main memory that can be interpreted and exe-cuted by the CPU. Hence, the difference between 1 and 2 is that 2 isphysically present in some hardware.

3. The running system, which is the result of an execution of a Computational-Object. This is the form of software which manifests itself in a sequence ofactivities in the computational domain, e.g., the increment of a variable,the comparison of data, the storage of data on the hard disc, etc. This formof software is a DOLCE:Perdurant which we call ComputationalActivity.

ComputationalObjects (item 2) are a specialization of OIO:Information-Realization (any entity that realizes an OIO:InformationObject) as introducedin the Ontology of Information Objects. ComputationalActivities (item 3)are a specialization of OoP:Activity as introduced in the Ontology of Plans.ComputationalObjects and ComputationalActivities are the entities that live inthe computational domain.

ComputationalObjects are characterized by the fact that they are neces-sarily dependent on Hardware which is a DOLCE:PhysicalObject. A suitabledependence association is axiomatized in DOLCE and is called specifically-ConstantlyDependsOn. A ComputationalObject is considered here as a spatio-temporally bounded entity, therefore it exists for the time a memory cell isrealizing a certain Software, for instance. Copies of ComputationalObjects inthe same or another Hardware are different, although related by some kind of“copy” association. For example, in the case of mobile agents, where peoplerefer to a mobile agent as a piece of software that can move from machineto machine executing the “same” process, it is useful to make agents distinctbecause the “same” agent can perform differently from machine to machine.The similarity has to be caught via a specialized association, such as copy(which we do not define here) rather than via logical identity.

The execution of a ComputationalObject leads to ComputationalActivities.ComputationalActivities require at least one ComputationalObject as a partici-pant. The definitions below formalize the described properties.

(D1) ComputationalObject(x) =def OIO:InformationRealization(x) ∧∀y(DOLCE:participantIn(x, y) → ComputationalActivity(y)) ∧∃d(DOLCE:specificallyConstantlyDependsOn(x, d) ∧ Hardware(d))

(D2) ComputationalActivity(x) =def OoP:Activity(x) ∧∀y(DOLCE:participantIn(y, x) → ComputationalObject(y)) ∧∃c(DOLCE:participantIn(c, x) ∧ ComputationalObject(c))

(D3) DOLCE:specificallyConstantlyDependsOn(x, y) =def

(∃t(DOLCE:presentAt(x, t)) ∧ ∀t(DOLCE:presentAt(x, t) →DOLCE:presentAt(y, t)))

(D4) DOLCE:presentAt(x, t) =def ∃t′(DOLCE:qlT (t′, x) ∧ DOLCE:part(t, t′))

Regarding item 1, we characterize Software as an OIO:InformationObject.Accordingly, we specialize the design pattern represented by the Ontology


OIO:InformationEncodingSystem

OIO:InformationObject

OIO:orderedBy

ComputationalObject ComputationalActivityDOLCE:

participantIn

OIO:realizes

DOLCE:Particular

identifies

computational domain

OoP:PlanOIO:expresses ComputationalTaskDnS:defines

DnS:sequences

Data

SoftwareAbstractData

OoP:ActivityOIO:Information

Realization

Fig. 2. The classification of software and data. Concepts and associations takenfrom DOLCE, Descriptions & Situations (DnS), the Ontology of Plans (OoP), theOntology of Information Objects (OIO) are labelled with a namespace

of Information Objects [4]. First, we constrain the OIO:realizedBy associa-tion to ComputationalObjects. Second, we say that Software OIO:expresses anOoP:Plan (cf. Fig. 2 for an overview). The OoP:Plan consists of an arbitrarynumber of ComputationalTasks, which DnS:sequence ComputationalActivities(cf. Definition (D6) below). As explained in the Ontology of Plans [4], Tasksare the descriptive counterparts of OoP:Activities which are actually carriedout. Definition (D5) below captures this intuition of software.

(D5) Software(x) =def OIO:InformationObject(x) ∧ ∀y(OIO:realizedBy(x, y) →ComputationalObject(y)) ∧ ∃p, t(OoP:Plan(p) ∧ OIO:expresses(x, p) ∧ComputationalTask(t) ∧ DnS:defines(p, t))

(D6) ComputationalTask(x) =def OoP:Task(x) ∧ ∀y(DnS:sequences(x, y) →ComputationalActivity(y))

We consider the data that is manipulated by the programs as Comput-ationalObjects as well. This reflects the fact that the appearances in the mainmemory or on the hard disc can be interpreted as instructions for the CPU(i.e., as software) or can be treated as data from the viewpoint of anotherprogram. For example, the operating system manipulates application software(loading and unloading it into memory, etc.) much like application softwaremanipulates application data.

Hence, Data can also be considered as a special kind of OIO:Information-Object. The difference to Software is that Data does not OIO:express an


OoP:Plan.2 Furthermore, we introduce AbstractData as a special kind of Datathat identifies something different from itself. An example for AbstractDatamight be a user account in a Unix operating system which has a physicalcounterpart in the real world. Thus, we say that AbstractData identifies aDOLCE:Particular (a natural person, a company, a physical object) [4]. Theidentifies association is a specialization of OIO:about. Definitions (D7), (D8),and (D9) capture these intuitions.

(D7) Data(x) =def OIO:InformationObject(x) ∧ ∀y(OIO:realizedBy(x, y) →ComputationalObject(y))

(D8) AbstractData(x) =def Data(x)∧∃y(DOLCE:Particular(y)∧identifies(x, y))(D9) identifies(x, y) =def

OIO:about(x, y) ∧ AbstractData(x) ∧ DOLCE:Particular(y) ∧ x �= y

The theorem (T1) below is an entailment of our axiomatization. (T1)states that Software must also be considered as Data. As discussed before,this is intuitively clear because an algorithm can be considered as Data fromthe viewpoint of a compiler, for example. Comparing (D5) and (D7), wefind that Software additionally OIO:expresses an OoP:Plan with at least oneComputationalTask. Thus, Software is strictly more specific than Data.

(T1) Software(x)→ Data(x)

3.2 Interfaces, Classes, and Methods

Building on the fundamental notions of software and data introduced in theprevious section, we now formalize the most important concepts of objectorientation. We begin with a Class in Definition (D10) as a special kind ofSoftware that encapsulates an arbitrary number of Data and an arbitrarynumber of Methods. Vice versa, a Method is defined as being a part of aClass, having input and output parameters and throwing exceptions.3 Theassociations between Methods and their parameters and exceptions are estab-lished via methodRequires, methodYields, and methodThrows (cf. (D11), (A1),(A2), and (A3)). Exceptions are special kinds of Classes as defined in (D12).dataType relates Data with specific kinds of DOLCE:Regions in the case ofsimple datatypes, such as strings or integers, or with other Data in the caseof complex datatypes, e.g., other classes (cf. Axiom (A4)).

(D10) Class(x) =def Software(x) ∧ ∀y(DOLCE:properPart(y, x) →(Data(y) ∨Method(y)))

(D11) Method(x) =def Software(x) ∧ ∀y(DOLCE:properPart(x, y) → Class(y))

2 The reader may note, that we occasionally use concept and association names(written in sans serif and preceded by a namespace to clarify their origin) assubjects, objects, and predicates of the sentences in the text.

3 The OoP:Plan of the Class contains all Plans of its Methods as alternatives.


(D12) Exception(x) =def Class(x) ∧ ∀y(methodThrows(y, x) → Method(y))(D13) DOLCE:properPart(x, y) =def DOLCE:part(x, y) ∧ ¬DOLCE:part(y, x)

(A1) methodRequires(x, y) → Method(x) ∧ Data(y)(A2) methodYields(x, y) → Method(x) ∧ Data(y)(A3) methodThrows(x, y) → methodYields(x, y) ∧ Exception(y)(A4) dataType(x, y) → Data(x) ∧ (Region(y) ∨ Data(y))

We here introduce the notion of an Interface in order to group methodsand parameters independently of the Classes they belong to (cf. (D14) and(A5) below). The Interface extends the notion of Java interfaces because itallows to grasp additional information as explained above. In our ontology,the Interface has to be classified as Data as it cannot be executed, i.e., itdoes not OIO:express an OoP:Plan. Different Classes may implement the sameInterface as stated in (A6). In doing so, we are able to model that differentClasses provide names for Methods with comparable functionality (e.g., get-Price() vs. getCost()).

(D14) Interface(x) =def Data(x) ∧ ∀m(inferfaceRequires(x,m) →(∃p(OIO:expresses(m, p) ∧ OoP:Plan(p)) ∧ ∀d(methodRequires(m, d) →∃e(DOLCE:Particular(e) ∧ OIO:about(d, e)))))

(A5) interfaceRequires(x, y) →DOLCE:properPart(y, x) ∧ Interface(x) ∧Method(y)

(A6) implements(x, y) → Class(x) ∧ Interface(y) ∧∀m1∃m2(interfaceRequires(y,m1) → DOLCE:properPart(x,m2))

3.3 Workflow Information

Workflow information, such as method invocations, also belong to the fun-damental notions of software. In order to model such information, we useand specialize the ontology design pattern of the Ontology of Plans which inturn builds on Descriptions & Situations. We do so because the design pat-tern allows abstracting from concrete, i.e., actually executed, workflows. Thatmeans, we use ComputationalTasks, which are OoP:Tasks, to represent invoca-tions, the addition of two integers, etc. rather than the actual executions ofsuch tasks (which would be ComputationalActivities). ComputationalTasks aregrouped and linked via the OoP:successor and OoP:predecessor associations inan OoP:Plan (a DnS:SituationDescription).4

The workflow information we need to model is twofold. First, we have tomodel invocations between software. Second, we also need to model the inputsand outputs of tasks because the Ontology of Plans does not provide suchcapabilities.4 The OoP:predecessor and OoP:successor associations hold between OoP:Tasks, and

are different from OoP:precondition and OoP:postcondition associations, whichhold between OoP:Plans and DnS:SituationDescriptions.


Invocations Between Software

We start with two associations, viz., executes and accesses, to formalize in-vocations between Software. Below, (D15) introduces executes as “shortcut”between Software, such as Class or Method, and a ComputationalTask. For ex-ample, the doGet() method of a servlet executes an invocation task.

(D16) introduces accesses as “shortcut” between the ComputationalTaskand the Software or Data that is being called or modified by the task. Thesequence of executes and accesses can be further abbreviated by invokes whichis declared as being transitive (cf. (D17) and (A7)). Axioms (A8) and (A9) areintroduced for convenience. Regarding (A8), we say that also a Class executesa ComputationalTask when one of its Methods executes this task. Regarding(A9), we state that invokes also holds when we have succeeding tasks.

(D15) executes(x, y) =def Software(x) ∧ ComputationalTask(y) ∧∃co, ca, p(ComputationalObject(co) ∧ ComputationalActivity(ca) ∧OoP:Plan(p) ∧ OIO:realizedBy(x, co) ∧ OIO:expresses(x, p) ∧DnS:defines(p, y) ∧ DnS:sequences(y, ca) ∧ DOLCE:participantIn(co, ca))

(D16) accesses(x, y) =def

ComputationalTask(x) ∧ Data(y) ∧ ∃ca, co(DnS:sequences(x, ca) ∧ComputationalActivity(ca) ∧ DOLCE:participantIn(co, ca) ∧ComputationalObject(co) ∧ OIO:realizes(co, y))

(D17) invokes(x, y) =def ∃z(executes(x, z) ∧ accesses(z, y))

(A7) invokes(x, z) ← invokes(x, y) ∧ invokes(y, z)(A8) executes(x, y) ←

(executes(z, y) ∧Method(z) ∧ DOLCE:properPart(z, x) ∧ Class(x))(A9) invokes(x, z) ← executes(x, y) ∧ OoP:successor(y, t) ∧ accesses(t, z)

Inputs and Outputs

Besides invocations, we also need to model the Inputs and Outputs of tasks. TheOntology of Plans does not provide such capabilities. Inputs and Outputs arerequired when we want to represent the information of a WS-BPEL workflow,for instance. Inputs and Outputs are DnS:Roles which are both DnS:playedByData and DnS:definedBy an OoP:Plan (cf. (D18), (D19) and (A12)). The re-lationships between Inputs (Outputs) and ComputationalTasks are modeled byinputFor / outputFor, as specified in (A10), and (A11).5 The difference be-tween Inputs and Outputs is that the former must be present before the latter(cf. (A13)).

(D18) Input(x) =def DnS:Role(x) ∧ ∀y(DnS:playedBy(x, y) → Data(y))(D19) Output(x) =def DnS:Role(x) ∧ ∀y(DnS:playedBy(x, y) → Data(y))

5 Both are specializations of DnS:modalTarget, viz., the generic association holdingbetween DnS:Roles and DnS:Courses.


(A10) inputFor(x, y) →DnS:modalTarget(x, y) ∧ Input(x) ∧ ComputationalTask(y)

(A11) outputFor(x, y) →DnS:modalTarget(x, y) ∧ Output(x) ∧ ComputationalTask(y)

(A12) Input(x) ∨ Output(x) → ∃p(OoP:Plan(p) ∧ DnS:defines(p, x))(A13) ComputationalTask(ct) → ∀d1, d2(∀i, o(inputFor(i, ct) ∧

DnS:playedBy(i, d1) ∧ outputFor(o, ct) ∧ DnS:playedBy(o, d2)) →∃t1, t2(presentAt(d1, t1) ∧ presentAt(d2, t2) ∧ t1 < t2))

4 Extensions to the Core Software Ontology

In this section, we continue our contribution of formalizing the software do-main by extending the Core Software Ontology in three different directions.First, we start with the minor extension of libraries and licenses which is put inthe Core Software Ontology itself. Second, our focus are access rights and poli-cies which were originally put in the Core Software Ontology as well. However,[7] continued to extend in this direction and emancipated their formalizationin a Core Policy Ontology. Third, an extra ontology module, i.e., the CoreOntology of Software Components (COSC), is devoted to the paradigm of soft-ware componentry. The reader may note, that other extensions are possible,e.g., the Core Ontology of Web Services as presented in [12].

4.1 Libraries and Licenses

We introduce the concepts of SoftwareLibrary and License in (D20) and (D21)below. Both occur in many programming languages and are a common meansin software engineering. A SoftwareLibrary consists of a number of CSO:Classesand is classified as CSO:Data because it cannot be executed as a whole. Theconcept License is a special kind of LegalContract as introduced in the CoreLegal Ontology [3].

(D20) SoftwareLibrary(x) =def CSO:Data(x) ∧ ∀c(DOLCE:properPart(x, c) →CSO:Class(c))

(D21) License(x) =def

LegalContract(x) ∧ ∃y(CSO:Software(y) ∧ DnS:involves(x, y))

Very often there are functional dependencies between libraries that arerevealed only during run time (e.g., by ClassNotFoundExceptions in Java).For example, a library lib1.jar might depend on lib2.jar which in turndepends on lib3.jar and so forth. It is a very tedious task to keep trackof such dependencies and, additionally, to check whether there are conflictsbetween libraries in this dependency graph. In order to reason with such infor-mation, we introduce further associations and axioms, such as the transitivelibraryDependsOn in (A14) and (A15) and the symmetric libraryConflictsWithin (A16) and (A17) below, while in (A18) we formalize indirect conflicts.


The existence of incompatible licenses further complicates the situation.Even if libraries in the dependency graph do not conflict, they might haveincompatible licenses. In order to reason with such information, we furtherintroduce the association releasedUnder between SoftwareLibraries and Licensesin (A19), as well as the symmetric licenseIncompatibleWith in (A20) and (A21).

(A14) libraryDependsOn(x, y) →DOLCE:specificallyConstantlyDependsOn(x, y) ∧ SoftwareLibrary(x) ∧SoftwareLibrary(y)

(A15) libraryDependsOn(x, z) ←libraryDependsOn(x, y) ∧ libraryDependsOn(y, z)

(A16) libraryConflictsWith(x, y) → SoftwareLibrary(x) ∧ SoftwareLibrary(y)(A17) libraryConflictsWith(x, y) ↔ libraryConflictsWith(y, x)(A18) libraryConflictsWith(x, z) ←

libraryDependsOn(x, y) ∧ libraryConflictsWith(y, z)(A19) releasedUnder(x, y) →

OIO:expresses(x, y) ∧ SoftwareLibrary(x) ∧ License(y)(A20) licenseIncompatibleWith(x, y) → License(x) ∧ License(y)(A21) licenseIncompatibleWith(x, y) ↔ licenseIncompatibleWith(y, x)

4.2 Access Rights and Policies

In general, access rights are required to state that access is granted for aspecific user on a specific resource. Policies can be regarded as a generalizationof access rights. They define high-level guidelines that constrain the behaviorof an information system.

We use and specialize Descriptions & Situations for modeling access rightsand policies. The design pattern represented by Descriptions & Situationsprovides us with the basic primitives of context modeling, such as the notionof roles, which allows us to talk about subjects and objects of a policy onthe abstract level, i.e., independent of the entities that play such roles. Asdescribed in [5], Descriptions & Situations therefore distinguishes betweendescriptive entities and ground entities.

In a first step, it is necessary to introduce further ground entities whichare required later on. (D22) below specifies a User as a special kind ofAbstractData which identifies a DnS:Agent. The intuition behind User is auser account in an operating system. Hence, Users identify DnS:Agents whichare either DOLCE:AgentivePhysicalObjects or DOLCE:AgentiveSocialObjects. Inmost cases, a natural person is associated with such an account. We aggregateUsers to a UserGroup by exploiting DnS:Collection in (D23).

(D22) User(x) =def AbstractData(x) ∧ ∀y(identifies(x, y) → DnS:Agent(y))(D23) UserGroup(x) =def DnS:Collection(x) ∧ ∀y(DnS:member(x, y) →

User(y))


In a second step, we specialize the descriptive entities of Descriptions &Situations, viz., DnS:Roles, DnS:Courses, DnS:Parameters, and DnS:Situation-Descriptions as follows. First, we introduce two DnS:Roles to represent thesubject and the object of a policy in (D24) and (D25). PolicySubjects areDnS:AgentiveRoles and can be DnS:playedBy Users or UserGroups. PolicyObjectsare DnS:NonAgentiveRoles and can be DnS:playedBy Data. Second, we need torepresent the predicate of a policy by a special kind of DnS:Course. (D6)already introduces ComputationalTask which meets this requirement. We fur-ther aggregate such tasks to TaskCollections in (D26). The intuition behindTaskCollections are the security “roles” in operating systems or database sys-tems. This means that a TaskCollection groups ComputationalTasks, such asread, write, or execute. Third, we introduce Constraints as special kinds ofDnS:Parameter. The ComputationalTask or TaskCollections can be constrainedin some way, e.g., a Web service policy might state that an invocation is onlypossible with Kerberos or X509 authentication (cf. (D27)). Finally, we con-struct a PolicyDescription, viz., a special kind of DnS:SituationDescription, fromthe aforementioned concepts.6 Axiom (A22) requires each PolicyDescription tohave a PolicySubject, ComputationalTask, and a PolicyObject. Figure 3 providesan overview.

(D24) PolicySubject(x) =def DnS:AgentiveRole(x) ∧ ∀y(DnS:playedBy(x, y) →(User(y) ∨ UserGroup(y))) ∧ ∀z(DnS:attitudeTowards(x, z) →(ComputationalTask(z) ∨ TaskCollection(z)))

(D25) PolicyObject(x) =def DnS:NonAgentiveRole(x) ∧∀y(DnS:playedBy(x, y) → Data(y)) ∧ ∀z(DnS:attitudeTowards(x, z) →(ComputationalTask(z) ∨ TaskCollection(z)))

PolicyDescriptionComputationalTask

DnS:attitudeTowards

UserGroup

PolicySubject

DnS:definesDnS:playedBy

Constraint

TaskCollection DnS:unifies

DOLCE:member

PolicyObject

DOLCE:member

User

DnS:attitudeTowards

Data

DnS:playedByDnS:requisiteFor

DnS:attitudeTowards

DnS:defines

DnS:defines

DnS:defines

DnS:attitudeTowards

Fig. 3. The Policy Description as UML class diagram. Grey classes representground entities, white classes the descriptive entities of Descriptions & Situationsor specializations

6 Note that DnS:unifies is the generic association between DnS:SituationDescriptionsand DnS:Collections.


(D26) TaskCollection(x) =def DnS:Collection(x) ∧ ∀y(DnS:member(x, y) →ComputationalTask(y))

(D27) Constraint(x) =def DnS:Parameter(x) ∧ ∀y(DnS:requisiteFor(x, y) →(ComputationalTask(y) ∨ TaskCollection(y))) ∧ ∀z(DnS:defines(z, x) →PolicyDescription(z))

(D28) PolicyDescription(x) =def DnS:SituationDescription(x)∧∀y(DnS:unifies(x, y) → TaskCollection(y)) ∧ ∀z(DnS:defines(x, z) →Constraint(z) ∨ ComputationalTask(z) ∨ PolicySubject(z) ∨PolicyObject(z))

(A22) PolicyDescription(x)→∃s, t, o(DnS:defines(x, s) ∧ PolicySubject(s) ∧ DnS:defines(x, t) ∧ComputationalTask(t) ∧ DnS:defines(x, o) ∧ PolicyObject(o))

It is worthwhile to spend some words on the DnS:attitudeTowards asso-ciation between DnS:Roles and DnS:Courses. The DnS:attitudeTowards asso-ciation is a special kind of DnS:modalTarget and can be considered thedescriptive counterpart of the DOLCE:participantIn association. It is used tostate attitudes, attention, or even subjection that an object can have withrespect to an action or process. In our case, DnS:attitudeTowards is used tostate the relationship between PolicySubjects, as well as PolicyObjects, andthe ComputationalTask or TaskCollection. Descriptions & Situations providesus with three initial specializations of DnS:attitudeTowards, viz., DnS:right-Towards, DnS:empoweredTo, and DnS:obligedTo. We further refine DnS:right-Towards in (A23) below.

(A23) computationalRightTowards(x, y) → DnS:rightTowards(x, y) ∧PolicySubject(x) ∧ (ComputationalTask(y) ∨ TaskCollection(y))

(A24) computationalRightTowards(x, z) ← computationalRightTowards(x, y) ∧TaskCollection(y) ∧ DnS:member(y, z) ∧ ComputationalTask(z)

(A25) (DnS:playedBy(x, z) ∧ PolicySubject(x) ∧ UserGroup(z)) →∃y(DnS:member(z, y) ∧ User(y) ∧ DnS:playedBy(x, y))

(A24) and (A25) infer the closure of all resulting rights considering User-Groups and TaskCollections. A PolicySubject is granted rights on all tasks whichare members of the TaskCollection. Similarly, a User is granted all access rightswhich are granted for his UserGroup.

4.3 Core Ontology of Software Components

Software componentry is a loosely defined term for a software technologyproposing that software should be developed by glueing prefabricated com-ponents together as in the field of electronics or mechanics. Software compo-nentry also proposes encapsulating software functionality for multiple use ina context-independent way, composable with other components, and as a unitof independent deployment and versioning.


Software components often take the form of object-oriented classes con-forming to a framework specification. However, software components differfrom classes. The basic idea in object-oriented programming is that soft-ware should be written according to a mental model of the actual or imag-ined objects it represents. Software componentry, by contrast, makes no suchassumptions.

The framework specifications prescribe (1) interfaces that must be im-plemented by components and (2) protocols that define how components in-teract with each other. Examples of framework specifications are EnterpriseJavaBeans (EJB) and the Component Object Model (COM) from Microsoft.

The definitions below formalize this intuition of software component asclosely as possible. Assuming the object-oriented paradigm, (D31) belowstates that a SoftwareComponent is a special kind of CSO:Class that conformsto a FrameworkSpecification. According to the definition above, a Framework-Specification is (1) a DOLCE:Collection of CSO:Interfaces and (2) a special kindof OoP:Plan which specifies the interaction of components (cf. (D29)). Con-formance means that at least one CSO:Interface prescribed by the Framework-Specification has to be implemented by the SoftwareComponent (cf. (D30)).

(D29) FrameworkSpecification(x) =def

OoP:Plan(x) ∧ ∃y(DOLCE:Collection(y) ∧ DnS:unifies(x, y) ∧∀z(DOLCE:member(y, z) → CSO:Interface(z)))

(D30) conforms(x, y) =def CSO:Class(x) ∧ FrameworkSpecification(y) ∧∃i, c(CSO:Interface(i) ∧ DOLCE:member(c, i) ∧ DOLCE:Collection(c) ∧DnS:unifies(y, c) → CSO:implements(x, i))

(D31) SoftwareComponent(x) =def

CSO:Class(x) ∧ ∃y(conforms(x, y) ∧ FrameworkSpecification(y))

The Core Ontology of Software Components also introduces componentprofiles that group relevant information of a software component such as itsinterfaces, policy descriptions, or plans. We expect that such an aggregationmakes browsing and querying for developers more convenient. The componentprofile is envisioned to act as the central information source for a specificsoftware component rather than having bits and pieces all over the place.

(D32) and (A26) define a Profile as follows: First, it aggregates CSO:Policy-Descriptions, an OoP:Plan, the required SoftwareLibraries, the implemented In-terfaces and additional Characteristics of a specific Software entity. Second, thelink to the described Software is specified via the describes association. (D33)specializes this definition to ComponentProfile.

Often, we need to express certain capabilities or features of components,such as the version, transactional or security settings. For this purpose, weintroduce Characteristics on a Profile in (D34). It is expected that Component-Profiles are specialized and put into a taxonomy. For example, we mightdefine a DatabaseConnectorProfile as a ComponentProfile that provides forspecific Characteristics describing whether the underlying database supports


transactions or SQL-99. A taxonomic structure further accommodates thedeveloper in browsing and querying for ComponentProfiles in his system.

Finally, (A27) specifies the profiles association as a “catch-all” for DnS:-defines, DnS:unifies, OIO:about, as well as OIO:expressedBy. This is done forconvenience in order to relieve the developer from modeling details, who willcertainly have to deal with such information.

(D32) Profile(x) =def OIO:InformationObject(x) ∧ ∀y(profiles(x, y) →(CSO:PolicyDescription(y) ∨ SoftwareLibrary(y) ∨ CSO:Interface(y) ∨OoP:Plan(y) ∨ Characteristic(y))) ∧ ∀z(describes(x, z) → Software(z))

(D33) ComponentProfile(x) =def Profile(x) ∧ ∀y(describes(x, y) →SoftwareComponent(y))

(D34) Characteristic(x) =def DnS:Parameter(x) ∧ ∀y(DnS:defines(y, x) →Profile(y)) ∧ ∀z(DnS:valuedBy(x, z) ∧ DOLCE:AbstractRegion(z))

(A26) describes(x, y) → OIO:about(x, y) ∧ Profile(x) ∧ CSO:Software(y)(A27) profiles(x, y) → DnS:defines(x, y) ∨ DnS:unifies(x, y) ∨

OIO:about(x, y) ∨ OIO:expressedBy(x, y)

5 Proof of Concept

In this section, we give some examples of how the Core Software Ontologyand its extensions circumvent the four shortcomings, viz., conceptual ambi-guity, poor axiomatization, loose design, and narrow scope, mentioned in theintroduction. We argue that the use of the DOLCE foundational ontology aswell as the use of content ontology design patterns help us here.

Conceptual Disambiguation

As mentioned in the introduction, lightweight ontologies typically suffer fromconceptual ambiguity. A prominent example is the notion of OWL-S:Servicein [8] which is defined twice and differently in the specification. In turn, bothdefinitions stand in conflict with the axiomatization of the concept in theontology. In [16], we have found a similar dilemma regarding the plethora ofmeanings and definitions of terms, such as component, software component, orsoftware module. Typically, lightweight ontologies fail to convey their intendedmeanings of such terms and leave the interpretation to the ontology user.

In contrast to such commonly built ontologies we have captured the in-tended meanings of concepts and associations as precisely as possible. For thispurpose, it proved to be rather helpful to capture the three different flavors ofthe term software via the information object content ontology design pattern,for instance.

While our definitions of the terms “software” and “software component”may not be the only ones, the fact that they are highly axiomatized allowscomparing them to alternative definitions and allows fostering discussions onalternative conceptualizations.


Increased Axiomatization

Ontologies are often reduced to a simple taxonomy with domain and rangerestrictions on associations. This does not suffice to clarify the intended mean-ing of terms which is of central importance when building ontologies for reuseand reference purpose. As an example, consider control constructs, such as,fork or join, to specify workflow information. Many ontologies, such as OWL-S[8], omit a concise formalization of their intended meaning.

In our ontology we have made use of the Ontology of Plans which providesextensive axiomatization of OoP:Tasks and subconcepts thereof. OoP:Tasksare directly comparable to control constructs, but provide a heavyweight ax-iomatization. An example is SynchroTask (an instance of OoP:ControlTask)which matches the concept of a “join.” A SynchroTask joins a set of tasks aftera branching and waits for the execution of all tasks (except the optional ones)that are direct successors to a ConcurrencyTask or AnyOrderTask. Below wegive the axiomatization of the SynchroTask as introduced in [4].

ControlTask(SynchroTask) → ∃t1, t2, t3(t1 = ConcurrencyTask ∨ t1 =AnyOrderTask) ∧ successor(t1, x) ∧ (ComplexTask(t2) ∨ ActionTask(t2)) ∧(ComplexTask(t3) ∨ ActionTask(t3)) ∧ directSuccessor(t2,SynchroTask) ∧directSuccessor(t3,SynchroTask)

Another example is the link between the control constructs and the pro-cess steps. Very often, the intended meaning of such links remains unclear. Isit a parthood association? And if yes, is it temporary, transitive, etc.? Ourontology is very specific with respect to such notions because it builds onthe Ontology of Plans. The latter exploits the DOLCE:temporaryComponentassociation which has a firm foundation as a special kind of the more ba-sic DOLCE:component mereological association and DOLCE:partlyCompresenttemporally indexing association. Both are characterized by formal restrictionson their application to other basic concepts.

Improved Design

In our ontology, we propose to use contextualization as a design pattern.Contextualization allows us to move from software descriptions to the repre-sentation of different, possibly conflicting views with various granularity. TheDescriptions & Situations ontology provides us with a corresponding contentontology design pattern with the basic primitives of context modeling such asthe notion of roles, for instance. Roles allow us to talk about inputs and out-puts on the abstract level, i.e., independent of the objects that play such roles.

This pattern applies clearly defined semantics and scoping provided byDescriptions & Situations where we want to express that the output of aprocess is the input to another process. In our ontology, inputs and outputscan be modeled as DnS:Roles which serve as variables. Thus, CSO:Data canplay multiple roles within the same or different descriptions. It is natural toexpress that the given CSO:Data is output with respect to one process, butinput to another (cf. Fig. 4).


DnS:Role

DnS:defines

CSO:Data

DnS:playedBy

CSO:Input CSO:Output

OoP:Plan

CSO:ComputationalTask

CSO:outputFor

DnS:playedBy

CSO:inputFor

DnS:defines

DnS:SituationDescription

Fig. 4. Data can play both the role of an Input and an Output at the same time.Inputs and Outputs can be linked to ComputationalTasks in a Plan. White classesrepresent descriptive entities, grey classes represent ground entities

Wider Scope

Software resides on the boundary of the world inside an information systemand the external world. Web services, in particular, may carry out operationsto support a real-world service. Functionality, which is an essential propertyof a service, then arises from the entire process that comprises computationalas well as real-world activities.

The distinction between information objects, events, and physical objectsis not explicitly made in most ontologies. In our ontology, this separationnaturally follows from the use of DOLCE and the Ontology of InformationObjects, where the distinction is an important part of the characterization ofconcepts. In particular, it becomes possible to be more precise about the kindsof relationships that can occur among objects or between objects and events.

For example, we can distinguish a physical object (such as a naturalperson) from an information object (such as user account in an informationsystem) and represent the link between the two. Figure 5 shows which capabil-ities our ontology provides to do so. It is worthwhile to make such differencesexplicit, e.g., when we want to infer the total of access rights granted for a nat-ural person who might have several user accounts in and across informationsystems.


OIO:InformationObject

CSO:ComputationalObject

CSO:identifies CSO:User

CSO:AbstractData

DnS:Agent

OIO:realizedBy

Fig. 5. Using the Ontology of Information Objects allows us to model the relation-ship between a user in an information system and its corresponding agent (e.g., anatural person)

6 Related Work

As already outlined in the introduction, the Chapter “Ontologies and Soft-ware Engineering” surveys a wealth of approaches that formalize at least oneparadigm or aspect of software in an ontology. Although the respective ontolo-gies share basic principles, they (1) rely on individual formalizations, and (2)are typically lightweight and not of a reference nature. Such approaches couldbenefit from our Core Software Ontology capturing the stable core and pre-venting modeling from scratch. The same proposition is valid for approacheslike [13,14] that embed ontology modeling into the transformation processes ofmodel-driven engineering in order to conjoin ontology modeling and softwareengineering.

Furthermore, there has been some work that overlaps with the ideas pre-sented here. For example, the COHSE Java ontology7 offers a formal schemafor expressing a Java software project by an ontology. The open source projectIntrospector8 is a back-end to the popular GNU compiler collection gcc,9

which generates an RDF-defined ontology out of gcc compiled source code,and thus works with all languages supported by gcc, for example, C, C++,Java, Fortran, and others. [17] offers a more profound and sound ontology-based foundation, analyzing the constructs available when programming. Allthese works provide support for using ontologies in the area of software de-velopment, but on a much finer grained level than the work presented here.Thus, such ontologies could be used complementary to ours.

7 http://cohse.semanticweb.org/software.html8 http://introspector.sourceforge.net9 http://gcc.gnu.org


An example of a higher level software component ontology in use is pro-vided by [1]. The work focusses on the social and project-level managementof Open Source software projects. Such aspects have not been considered bythe Core Software Ontology yet.

Finally, there are some ontologies which focus on specific aspects, whereasour ontology tries to relate the different aspects in a larger focus. Examplesare the Core Plan Representation (CPR) [15] and the Process SpecificationLanguage (PSL) [6] which are comparable to the Ontology of Plans. UPML,the Unified Problem-solving Method Development Language [2], has been de-veloped to describe and implement intelligent broker architectures and com-ponents to facilitate semi-automatic reuse and adaptation.

7 Conclusion

The chapter has shown how to proceed in building a Core Software Ontologyand extending it in different directions. The result is grounded in a founda-tional ontology and avoids the typical shortcomings of lightweight ontologies.Related, seminal approaches only weakly formalize the meaning of their termsand leave their disambiguation to the intuition of the reader, a situation thatwe here improve upon considerably.

The reader may note that what is presented here are the reference on-tologies in this domain. For actual work, these reference ontologies need tobe reduced to knowledge representation schemes that are more amenable tooperation.

So far, the Core Ontology of Software Components has been applied in [11]for developing and managing software components in an application server.The Core Ontology of Web Services has been used by the EU project FUSION(cf. http://www.fusionweb.org) for information integration. The Core Pol-icy Ontology has been emancipated, extended and used for service market-places by [7]. We expect many more fruitful applications and extensions ofour ontologies in the future.

References

1. Anupriya Ankolekar, James Herbsleb, and Katia Sycara. Addressing Challengesto Open Source Collaboration With the Semantic Web. In Joseph Feller, BrianFitzgerald, Scott Hissam, and Karim Lakhani, editors, Proceedings of TakingStock of the Bazaar: The 3rd Workshop on Open Source Software Engineering,the 25th International Conference on Software Engineering (ICSE), Washing-ton, D.C., 2003. IEEE Computer Society.

2. Dieter Fensel, Richard Benjamins, Enrico Motta, and Bob J. Wielinga. UPML:A Framework for Knowledge System Reuse. In Thomas Dean, editor, Proceed-ings of the 16th Int. Joint Conference on Artificial Intelligence, IJCAI 99, Stock-holm, Sweden, 1999. 2 Volumes, 1450 pages, pages 16–23. Morgan Kaufmann,1999.


3. Aldo Gangemi, Maria-Teresa Sagri, and Daniela Tiscornia. A ConstructiveFramework for Legal Ontologies. Internal project report, EU 6FP METOKISProject, Deliverable, 2004. http://metokis.salzburgresearch.at.

4. Aldo Gangemi, Stefano Borgo, Carola Catenacci, and Jos Lehmann. Task tax-onomies for knowledge content. Metokis Deliverable D07, Sep 2004.

5. Aldo Gangemi and Peter Mika. Understanding the Semantic Web throughDescriptions and Situations. In DOA/CoopIS/ODBASE 2003 ConfederatedInternational Conferences DOA, CoopIS and ODBASE, Proceedings, LNCS.Springer, 2003.

6. Michael Gruninger and Christopher Menzel. The Process Specification Language(PSL) Theory and Applications. AI Magazine, 24(3):63–74, 2003.

7. Steffen Lamparter, Anupriya Ankolekar, Daniel Oberle, Rudi Studer, andChristof Weinhardt. A Policy Framework for Trading Configurable Goods andServices in Open Electronic Markets. In Proceedings of the 8th Int. Conferenceon Electronic Commerce (ICEC’06), pages 162–173, AUG 2006.

8. David Martin, Mark Burstein, Jerry Hobbs, Ora Lassila, Drew McDermott,Sheila McIlraith, Srini Narayanan, Massimo Paolucci, Bijan Parsia, Terry Payne,Evren Sirin, Naveen Srinivasan, and Katia Sycara. OWL-S: Semantic Markupfor Web Services. http://www.daml.org/services/owl-s/1.1/, Nov 2004.

9. Claudio Masolo, Stefano Borgo, Aldo Gangemi, Nicola Guarino, and AlessandroOltramari. Ontology Library (final). WonderWeb Deliverable D18, Dec 2003.http://wonderweb.semanticweb.org.

10. Peter Mika, Daniel Oberle, Aldo Gangemi, and Marta Sabou. Foundations forService Ontologies: Aligning OWL-S to DOLCE. In The 13th InternationalWorld Wide Web Conference Proceedings, pages 563–572. ACM, May 2004.

11. Daniel Oberle. Semantic Management of Middleware, volume I of The SemanticWeb and Beyond. Springer, New York, Jan 2006.

12. Daniel Oberle, Steffen Lamparter, Stephan Grimm, Denny Vrandecic, SteffenStaab, and Aldo Gangemi. Towards Ontologies for Formalizing Modularizationand Communication in Large Software Systems. Journal of Applied Ontology,1(2):163–202, 2006.

13. F. Silva Parreiras, S. Staab, and A. Winter. On marrying ontological and meta-modeling technical spaces. In ESEC/ACM FSE-2007 — Proceedings of the 6thjoint meeting of the European software engineering conference and the 14th ACMSIGSOFT symposium on Foundations of software engineering, pages 439–448.ACM, September 2007.

14. F. Silva Parreiras, S. Staab, and A. Winter. Improving design patterns by de-scription logics: An use case with abstract factory and strategy. In T. Kuhne andF. Steimann, editors, Proc. of Modellierung 2008, LNI. GI e.V., March 2008.

15. Adam Pease. Core Plan Representation. Object Model Focus Group, Nov 1998.16. Marta Sabou, Daniel Oberle, and Debbie Richards. Enhancing Application

Servers with Semantics. In 1st Australian Workshop on Engineering Service-Oriented Systems (AWESOS 2004) Melbourne, Australia, pages 7–15, 2004.

17. Christopher Welty. An Integrated Representation for Software Developmentand Discovery. PhD thesis, Rensselaer Polytechnic Institute Computer ScienceDepartment, 1995.

an ontology for software - uni koblenz-landaustaab/research/...loose design: an ontology is...

Documents