Change and Version Management in Variability Models for Modular

Ontologies

Melanie Langermeier

, Thomas Driessen

, Heiner Oberkampf

1, 2

, Peter Rosina

and Bernhard Bauer

Software Methodologies for Distributed Systems, University of Augsburg, Augsburg, Germany

Siemens AG, Corporate Technology, Munich, Germany

Keywords:

Variability Model, Modular Ontologies, Version Management, Change Management, Enterprise Architecture

Management.

Abstract:

Modular ontology management tries to overcome the disadvantages of large ontologies regarding reuse and

performance. A possibility for the formalization of the various combinations are variability models, which

originate from the software product line domain. Similar to that domain, knowledge models can then be

individualized for a speciﬁc application through selection and exclusion of modules. However, the ontology

repository as well as the requirements of the domain are not stable over time. A process is needed, that

enables knowledge engineers and domain experts to adapt the principles of version and change management

to the domain of modular ontology management. In this paper, we deﬁne the existing change scenarios and

provide support for keeping the repository, the variability model and also the conﬁgurations consistent using

Semantic Web technologies. The approach is presented with a use case from the enterprise architecture domain

as running example.

1 INTRODUCTION

Knowledge management is an important aspect in or-

ganizations. Typically, different models are used to

capture all relevant aspects of the organization. These

models can extend each other, but can also overlay

in some parts. Furthermore, the semantics of two

models can exclude the use of both in one applica-

tion. The composition of modular knowledge mod-

els to one application ontology is dealt with in the

research area of modular ontology management. A

speciﬁc domain ontology is created through selection

of different modules from an ontology repository. To

manage the complexity of the different variants that

exist for the composition of an application ontology,

we proposed in (Langermeier et al., 2013) the use of

variability management (MOVO). This is a technique

from product line engineering, that focuses on a con-

sequent and explicit documentation of the variability

on software artifacts. Such a documentation enables

an individualization of software products while keep-

ing control of the rising complexity of the variants.

Variability models (VM) can also be used for modu-

lar ontologies to formalize the dependencies, that are

annotated in them (e.g. owl:import). Furthermore,

these models also formalize domain independent re-

quirements, for instance, that the domain Ontology A

and Ontology B should not be used together. For the

creation of a conﬁguration, this variability knowledge

can be automatically processed, and therewith sup-

ports the domain expert in creating a consistent con-

ﬁguration. The existing MOVO approach, however,

merely presents a methodology to attain an initial

setup, but does not describe how to handle changes in

the VMs, their conﬁgurations and the respective on-

tologies. One major challenge is to keep the overall

system consistent when changes occur. Our aim is to

extend MOVO with concepts and techniques to sup-

port change and version management for modular on-

tology management. This includes concepts, to relate

different versions and conﬁgurations to each other,

but also technical support to fulﬁll consistent version

updates or deletions. In section 2 we summarize the

MOVO approach we want to extend. The foundations

of versioning in ontology management are presented

in section 3. The required change events, to support

in the MOVO extension, are described in section 4

using an enterprise architecture (EA) use case as run-

ning example. The technical realization of the change

management approach is described in section 5) using

OWL 2 and SPARQL. We conclude with an evalua-

tion and discussion of related work.

383

Langermeier M., Driessen T., Oberkampf H., Rosina P. and Bauer B..

Change and Version Management in Variability Models for Modular Ontologies.

DOI: 10.5220/0004953603830390

In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 383-390

ISBN: 978-989-758-028-4

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 2: A variability model for modeling an enterprise architecture with a possible conﬁguration (Langermeier et al., 2013).

2 VARIABILITY MODELS FOR

MODULAR ONTOLOGY

MANAGEMENT

In software product line engineering, the different

variants of the product are managed through VMs.

Those models allow the explicit and consequent doc-

umentation of the software artifacts’ variability in or-

der to enable reuse in the development process (Chen

et al., 2009). An overview of techniques for variabil-

ity management can be found in (Chen et al., 2009)

and (Sinnema and Deelstra, 2007). One well-known

technique is feature modeling. Features capsule be-

havior, visible to the end user, on a logical layer

(Beuche et al., 2004). Examples for feature model-

ing approaches are (Kang et al., 1990), (Kang et al.,

1998) or (Czarnecki et al., 2004). Modular ontology

management tries to overcome the issues of difﬁcult

reuse and performance challenges in large ontologies.

Therefore, the idea is to develop small ontological

models, called modules, that can be composed to a

bigger application ontology. These small modules en-

able (partial) re-use, more efﬁcient reasoning, easier

maintenance and collaborative development (Spac-

capietra et al., 2005; Stuckenschmidt et al., 2009).

Using OWL 2 provides a standardized set of vocab-

ulary to describe the modules as well as the depen-

dencies between the single modules. These are for

example the relations owl:ontologyIRI, owl:imports

or version information (see section 3) (Motik et al.,

2012). In (Langermeier et al., 2013) we introduced an

approach for the management of the dependencies be-

tween such ontological modules as well as their com-

position to one application ontology. We decided to

use VMs to formalize and reason about the depen-

dencies between modular ontologies. For the cre-

ation of such a variability model, ﬁrst, an ontology

repository (OntRepo), including all used modular on-

tologies, has to be established. Then the dependen-

cies between these modules are analyzed and formal-

ized in the ontological variability model V M

. Using

this model as a basis a knowledge engineer (KE) can

create an integrated variability model V M

through

strengthening or extending V M

. Finally, the domain

expert (DE) can select the features of V M

, that shall

be included. Additional modules, that are necessary

to get a consistent application ontology, will be added

automatically. An overview of this concept with the

used models and their dependencies is given in Fig-

ure 1. Figure 2 is an example of V M

for the EA do-

Figure 1: Overview of the models and their dependencies

(Langermeier et al., 2013).

main in order to enable a combined meta model from

two different frameworks. It is modeled using the fea-

ture modeling approach from (Kang et al., 1990). The

model captures not only the ontological restrictions in

the single modules, but also restrictions from the do-

main, modeled by a KE. Each rectangle represents a

feature. The shaded ones indicate a possible conﬁgu-

ration for an application ontology.

3 STATE OF THE ART

Versioning in Modular Ontology Management.

One of the main problems using modular ontolo-

gies is to manage changes systematically and being

aware of their impacts. Ontology development is a

continuous process, since ontologies evolve and have

to be adapted to a changing environment and addi-

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

384

tional knowledge. A high modularity intensiﬁes the

problem, since a change in one ontology can affect

various other dependent ontologies (Stuckenschmidt

and Klein, 2007; Flouris et al., 2008). (Stucken-

schmidt and Klein, 2007) characterize different kind

of changes in their work: (1) Changes that do affect

the logical theory and therewith affect the compiled

subsumption relationships and (2) changes that affect

only the syntactic representation or the names of con-

cepts and relations. Furthermore, they state that in

real-word scenarios changes mostly are of the second

type and therefore are harmless changes. Neverthe-

less, also the smaller kind of harmful changes require

methods to deal with since they can have an impact

on other modules. Therewith, we do not focus on the

effects of changes within an ontology or the effects on

other ones in this paper. Merely, we address the prob-

lem to ﬁnd that places in an organization where an on-

tology, that has or should be changed, is in use. When

doing changes to an ontology, this will always result

in a new version. A versioning method is required,

which will deal with the different versions of an ontol-

ogy and the effects of changes to them (Klein, 2001).

A method supporting ontology versions has to keep

track of dependencies between them and provide ac-

cess to ontologies, (prior) versions of ontologies and

their respective usages (Flouris et al., 2008).

Version Information for Ontologies. To repre-

sent version information, OWL 2 provides different

annotation properties (Motik et al., 2012). First,

owl:ontologyIRI can be used to identify an ontol-

ogy. If an ontology IRI is speciﬁed, one can addi-

tionally declare an owl:versionIRI. Ontologies with

the same ontology IRI but different version IRIs be-

long to one ontology series. In a series there is ex-

actly one current ontology which should be accessible

through the ontology IRI. Using the owl:priorVersion

property one can relate an ontology to its previ-

ous versions. Information about compatibility be-

tween versions of an ontology can be represented by

owl:backwardCompatible or owl:incompatibleWith.

There is no clear deﬁnition of owl:incompatibleWith

within the speciﬁcation. Obviously two ontology ver-

sions are incompatible, if they contain contradicting

statements

, but one could also regard two versions as

incompatible, if not all concepts of the prior version

have the same semantics in the new version. General

version information, like a version number, a date or

other information can be added using the annotation

property owl:versionInfo.

http://www.w3.org/TR/owl-guide/.

4 EXTENDING MOVO FOR

VERSION AND CHANGE

MANAGEMENT

The four basic functions of persistent storage, create,

read, update and delete, are called CRUD in the do-

main of computer science. (Langermeier et al., 2013)

shows how to read from the OntRepo and VMs, in

the following the create, update and delete (CUD)

functions are shown. In the MOVO approach intro-

duced in section 2 four results are established: (1) an

ontology repository (OntRepo), containing the rele-

vant ontological modules for the organization, (2) an

ontological variability model V M

, formalizing the

dependencies between the modules, (3) an integrated

variability model V M

, formalizing additional depen-

dencies according to a speciﬁc domain under consid-

eration of V M

and (4) a speciﬁc conﬁguration of

modules, which is conform to V M

and serves as ap-

plication ontology. For each function, the existing de-

pendencies between the OntRepo, the different VMs

and their conﬁgurations are shown, as well as how

these dependencies can be utilized to end up with a

consistent overall system, after performing one of the

CUD functions. Typically, such a repository stays not

stable over time, it changes. To be able to manage

these changes and ensure the correctness of the exist-

ing application ontologies, we enhance MOVO with

concepts for the classiﬁcation and connection of dif-

ferent V M

s as well as the conﬁgurations based on

those V M

s. Figure 3 shows MOVO extended with

concepts for versioning and tracing. To be able to

Figure 3: Extend concept of MOVO with versioning.

trace conﬁgurations to the V M

they are built on, a

conﬁguration of/has conﬁguration relationship is re-

quired. To connect different V MI

s, a successor/pre-

decessor relationship is introduced. As proposed for

ontologies by the OMG, we also use backward com-

patible and incompatible relationships between V M

ChangeandVersionManagementinVariabilityModelsforModularOntologies

385

To mark obsolete V M

s, the label deprecated is in-

troduced. The technical details about the new rela-

tionships are explained in section 5. In the following

the different possible change events are illustrated and

their effects are shown using the Enterprise Architec-

ture use case of (Langermeier et al., 2013) as running

example (see ﬁgure 2).

4.1 Changes in the Ontology Repository

Create Ontology. In order to model the distribution

and communication path of the software applications

in an organization, the KE wants to add an ontology

module about communication and distribution. This

new module has two important dependencies to

existing modules in the repository. The new ontology

is added to the OntRepo in order to be further pro-

cessed. The V M

data set is updated automatically

using the set-up steps described in section 5.2. This

ensures that the OntRepo and V M

are always

consistent to each other. In the use case, the new

ontology will not be included in V M

at that time. It

is the responsibility of the KE to decide, whether the

new ontology should be included in an existing V M

In that case, the changes to V M

have to be published

as a new version (for more details see Update V M

Update Ontology. When updating an ontology,

only the ontology’s version information is consid-

ered and internal ones, i.e., semantic or syntactic

changes are not interpreted. That means, when

an updated version of an ontology is added to

the OntRepo, the V M

is updated differently,

according to the ontology’s comprising OWL

annotations (owl:backwardCompatibleWith and

owl:incompatibleWith). If only an owl:priorVersion

annotation is made, without further information

about compatibility, this is treated as an incompatible

update. The ﬁrst and simple case is the annotation

of owl:backwardCompatibleWith: the ontology can

be simply included in the OntRepo. The V M

must not be changed, since an ontology’s IRI always

represents its newest version. If applicable, additional

entailed dependencies of this newer version are also

checked, adapted and added to V M

. The second

case implies, that the ontology is annotated with

owl:incompatibleWith. In this case, the representing

features of the old and new version get translated

to an XOR group in the feature model and both are

kept in V M

. For example The TOGAF Business

module is updated to version 2.0, while keeping it

backward compatible with the prior version 1.0. The

Iteraplan Business module is also updated to version

2.0, but will then be incompatible with the prior

version. Figure 4 visualizes the changes in the EA

V M

through the update of Iteraplan Business. To

Figure 4: Visualization of the publication of a new version,

incompatible to the old one in V M

keep the Iteraplan Business feature mandatory, an

empty feature is created which is then decomposed

using the XOR group. Afterwards, the KE has to

determine if the changes made to the newer version

have an impact on the already existent mappings.

When necessary, they have to be adapted manually,

according to the changes made to the ontology. If the

KE wants to use the new versions in the V M

, this has

to be done manually via an update (see Update V M

Delete Ontology. Although deletion of an existent

and used ontology is very unlikely to happen, the fol-

lowing paragraph describes how to keep the overall

system consistent after such an event. This change

event is illustrated through deletion of the TOGAF

Motivation module as well as the old versions of TO-

GAF Business and Iteraplan Business. In contrast to

the former two operations the OntRepo is unaffected

for the moment. The to be deleted ontology is marked

as deprecated. This implies, that the V M

s containing

that ontology are marked as deprecated too. Since the

TOGAF Motivation module is not used in any V M

we are able to safely remove this module from the On-

tRepo and V M

. Whereas the modules TOGAF Busi-

ness and TOGAF Iteraplan are included in an V M

we cannot remove these modules. To be able to exe-

cute the deletion, the KE has to delete the respective

V M

s (see Delete V M

4.2 Changes in the Set of V M

Create V M

. The creation of a new V M

does not

have any impact, neither on the OntRepo nor on

existing conﬁgurations.

Update V M

. A V M

can only be updated via the

creation of a new version. This new version has

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

386

to be linked via the successor-relationship to its

prior one. Using the labels incompatible with and

backward compatible more semantic information

about the update can be made. In the new version

of V M

for EA (V2) only the newer version of the

Iteraplan Business module should be included. Due

to the incompatibility of the module versions also the

two V M

versions are incompatible. Whenever an

V M

is updated, all DEs of affected conﬁgurations

are determined via the link between the V M

and its

conﬁgurations. If the DE updates the conﬁguration

to the new version of the V M

, the link between the

conﬁguration has to be updated accordingly.

Delete V M

. A V M

can only be deleted, if there is

no conﬁguration using it. Following, before deleting,

the V M

has to be marked as deprecated. If the DE

decides to switch his application to V M

V2, there is

no conﬁguration using V M

V1 and it can thus be re-

moved. Every time a V M

is removed by a KE, this

V M

has to be checked for a deprecated ontology. If

such an ontology was found, and no other VM

is us-

ing this ontology, it can be removed safely from the

OntRepo and V M

. When deleting V M

V1, we get

informed, that now the deprecated modules TOGAF

Business V1 und Iterplan Business V1 are no longer

in use in any conﬁguration or V M

, and can be re-

moved safely.

4.3 Events Concerning the

Conﬁgurations

Create/Update Conﬁguration. Every time a DE

creates or updates a conﬁguration, the link to the

respective V M

(movo:conﬁgurationOf ) will be

created/updated.

Delete Conﬁguration. A conﬁguration can be

deleted by a DE at any time. If the corresponding

V M

is marked as deprecated and has no more pend-

ing conﬁgurations left, this V M

can be deleted too.

In our use case, after the deletion of the old conﬁgu-

ration, we get informed that now the deprecated VM

V1 is no longer used by any conﬁguration. We are

now able to remove V M

V1.

5 REALIZATION

In the following the extended version of the Variabil-

ity Model Ontology (VMO), the storage of ontology

versions in the OntRepo, the representation of them as

features in the ontological variability model and the

change management are described.

5.1 Variability Model Ontology

The initial version of the VMO is described in

(Langermeier et al., 2013). The main classes

of the V M

are vmo:Feature

, owl:Ontology,

vmo:Composition, vmo:Alternative_Composition and

vmo:Or_Composition. We added several new object

properties to the V M

(see ﬁgure 5). For instance,

Figure 5: Object properties of the Variability Model Ontol-

ogy (VMO). New properties are in bold.

we deﬁned an object property vmo:isRealizedIn to re-

late features with ontology IRIs of the OntRepo (see

Figure 8). Domain and Range of this property is

vmo:Feature and owl:Ontology respectively. Further,

we added a class vmo:VMI for the integrated Variabil-

ity Models (V M

s). A V M

is an instance of vmo:VMI

and is represented through a named graph, contain-

ing features and relations between them. Named

graphs are a good way to group triples in a triple

store and further the graph URI (i.e. the URI of

the V M

instance) can be used to relate the V M

in-

stance to its dependent conﬁgurations: A conﬁgura-

tion is a valid selection of features from one V M

Since each feature represents an ontology, a con-

ﬁguration represents indirectly also a set of ontolo-

gies. The two properties vmo:conﬁgurationOf and

vmo:hasConﬁguration are used to connect a con-

ﬁguration with the corresponding V M

. Selected

features are related to the conﬁguration with the

property vmo:selectedFeature. The object prop-

erty vmo:isRealizedIn is used to relate vmo:Features

with the respective ontology the feature is represent-

ing. Additionally a transitive property vmo:successor

(with inverse vmo:predecessor) is used to intercon-

nect different versions of V M

s in the right order. Do-

main and range of both properties is vmo:VMI. Differ-

ent versions of V M

s are backward compatible (and

linked with vmo:backwardCompatibleWith property),

We write vmo:Feature instead of <http://www.ds-

lab.org/ontologies/movo-ontology.owl#Feature>.

ChangeandVersionManagementinVariabilityModelsforModularOntologies

387

if all conﬁgurations created by the older version can

still be created using the newer version. Otherwise

they are linked with vmo:incompatibleWith. The

property owl:deprecated is generally used for mark-

ing IRIs as deprecated. We use this annotation prop-

erty to ﬂag outdated and thereby obsolete ontolo-

gies, which comes into play when ontologies shall be

deleted. A similar property (vmo:deprecated) is used

to ﬂag V M

s, conﬁgurations or features as as depre-

cated.

5.2 Set-up of OntRepo and VMO

For the technical realization of our approach we set

up an Apache Jena Fuseki triple store with two data

sets (see ﬁgure 6). The ﬁrst data set (ontrepo) is

Figure 6: The triple store contains two data sets. One for the

ontology repository and another for the variability models.

A SPARQL Query Repository is used to access and modify

data.

the ontology repository, the second (vmo) is used

to store the Variability Model Ontology, the features

with their dependencies and the V M

s. Since the on-

tology repository contains several versions of one on-

tology we separate them using named graphs. This is

necessary since concepts of different versions share

the same namespace. The named graphs reuse the

version IRIs of the ontology versions or the ontology

IRI if no version IRI is deﬁned. Ontology annotation

properties such as version IRIs or import statements

are additionally stored in the default graph. These

relations are shown in Figure 7. In the next step,

we automatically create features in the vmo dataset

for all ontology IRIs in the default graph of the On-

tRepo data set. This is done using SPARQL UP-

DATE queries from the query repository. If there

are incompatible versions of one ontology, we ad-

ditionally create one vmo:Alternative_Composition

Figure 7: Relations between ontology IRIs in the OntRepo

default graph.

and relate it to the version IRIs and the ontology

IRI through vmo:consistsofFeatures property. Since

vmo:consistsOfFeatures has range vmo:Feature these

versions become also vmo:Feature in the vmo data

set. An example of an alternative composition with

relations to the IRIs is shown in ﬁgure 8. Within

Figure 8: An alternative composition in V M

and relations

to ontology IRIs from the OntRepo.

the creation process of V M

the KE can then decide

whether to use the feature for the ontology (which

will result in the use of the most current version) or

the composition rule in order to allow the use of one

of the different versions.

5.3 Changes in the Ontology Repository

If a new ontology is added to the ontology repository,

the initial set-up steps for integration into OntRepo

and V M

as described in section 5.2 are repeated.

If a new version of an existing ontology is added to

the repository, we distinguish two cases: If the new

version is backward compatible, we simply repeat the

set-up steps. Since the corresponding feature points to

the ontology IRI and not to the version IRI, we do not

have to change the V M

. However conﬁgurations us-

ing the respective features have to be recreated. If the

new version is incompatible with the prior version we

need to create a new alternative composition in V M

or adapt an existing one in adding a new feature for

the new version. If one ontology should be deleted

from the ontology repository,ﬁrst the IRI of the ver-

sion or ontology has to be ﬂagged as deprecated us-

ing the owl:deprecated property as mentioned above.

Features in the V M

dataset, which are related to a

deprecated ontology via the vmo:isRealizedIn prop-

erty, as well as corresponding V M

s are set as depre-

cated using vmo:deprecated property too. The feature

and corresponding ontology are deleted after the last

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

388

V M

graph referencing the feature is dropped from the

V M

dataset.

5.4 Changes in V M

A backward compatible new version of a V M

simply

obtains all references from conﬁgurations to the old

version. The named graph of the old VM

is dropped

afterwards. Both operations are automatically per-

formed using SPARQL UPDATE queries. Conﬁgu-

rations are not linked to the new V M

, if it is incom-

patible to the former version. In the case of ontology

updates in the OntRepo all V M

s containing features

with references to the respective ontology need to be

updated.

6 EVALUATION

Comparing our versioning method with the issues

stated in section 3, we support most of them. We are

able to manage different versions of the same ontol-

ogy in one data set and also manage the dependencies

between those versions. We consider the dependen-

cies between different ontologies as well as their us-

age in speciﬁc applications. Therewith, our method

ensures, that the information about which ontology

version is used in which application is always correct

and hinders an automatic update to newer ontology

versions that may cause inconsistencies. Older ver-

sions of an ontology are kept in the data set while

marking them as deprecated. If no other ontology or

application is using them, they can be automatically

removed. Additionally, we evaluated the method in a

use case (see running example in section 4). There-

fore, we reused the established V M

(Figure 2) from

(Langermeier et al., 2013) and executed change oper-

ations. This VM is created for the Enterprise Archi-

tecture (EA) domain in order to be able to combine

different meta models and mix and match them ac-

cording to the requirements of a speciﬁc organization.

The different versions of the models (current, depre-

cated, deleted) with their dependencies, that exist af-

ter executing all the change operations, are illustrated

in ﬁgure 9

The test set for the evaluation with the data sets,

queries, scripts and a documentation is published in

http://megastore.uni-augsburg.de/get/HAth0VS7qw/. The

test set was built upon the results from (Langermeier et al.,

2013).

Figure 9: Concept applied to EA use case after executing

the change operations.

7 RELATED WORK

Ontology Evolution. As stated in (Stojanovic et al.,

2002), most of the research in the ontology engineer-

ing ﬁeld is done on construction issues. However,

evolution of ontologies requires different approaches.

Our work was focused on the evolution of multiple,

modular ontologies on an abstract feature level,

whereas most of the related work copes with single

ontologies and their evolution over time. Examples

can be found manifold, like in (Stojanovic et al.,

2002). In this work, the authors present a 6-phase

methodology in order to keep an ontology consistent

over time. The key step of this methodology is to

differentiate between syntactic and semantic changes.

Another approach is presented by (Plessers et al.,

2007), where the authors created an own framework

for detecting changes, made to OWL DL ontologies.

Using a predeﬁned set of change deﬁnitions, they are

able to provide different overviews of changes made

to an ontology, depending on the user’s role.

Ontology Repositories. Ontology repositories store

either domain speciﬁc or independent ontologies, pro-

vide users with browse and search interfaces, and

can offer other functionality like reviewing, annotat-

ing or editing and mapping ontologies. The ontolo-

gies’ metadata, for instance, author, version, date or

scope, is a valuable instrument for these functionali-

ties. The mapping metadata can even be used to relate

concepts from different ontologies (Noy et al., 2008).

Generally, there are two different types of ontology

repositories: the ones that are automatically crawled

(Swoogle, Watson etc.) and the ones where the on-

tologies are submitted manually by users (Noy et al.,

2008). The initialization and extension of our pro-

posed repository is a manual effort. It is still rudimen-

tary and does not provide a user interface. Nonethe-

ChangeandVersionManagementinVariabilityModelsforModularOntologies

389

less, we use the meta data provided with the ontolo-

gies in order to ﬁnd mapping and version information.

8 CONCLUSION

In this paper we proposed a method for change and

version management for MOVO. By reusing the well

known CRUD functions, we strongly reduced the

complexity for change management. We show the

impact of those events for the OntRepo, its VM

, the

different V M

s and their conﬁgurations. Using tech-

nologies from the Semantic Web technology stack,

we implemented the method to calculate the impacts

automatically. Some parts still require the decision

of a KE or a DE. Applying this method we enable

MOVO to be used by long-term systems without los-

ing manageability due to increasing complexity. Fu-

ture work has to be done to enable our approach han-

dling the changes made within an ontology and es-

pecially consider the semantic impacts these mod-

iﬁcations have on other ontologies. We also want

to research more expressive approaches for deﬁn-

ing relations between ontologies, e.g., E -Connections

(Cuenca Grau et al., 2009), Package Based Descrip-

tion Logics (P-DL) (Bao et al., 2006), Distributed De-

scription Logics (DLL) (Borgida and Seraﬁni, 2003)

or the Interface-based modular ontology Formalism

(IBF) (Ensan, 2010). Finally a prototype tool imple-

mentation has to be done with a ﬁrst user interface.

REFERENCES

Bao, J., Caragea, D., and Honavar, V. G. (2006). Modular

ontologies – a formal investigation of semantics and

expressivity. In Proceedings of the First Asian con-

ference on The Semantic Web, ASWC’06, pages 616–

631, Berlin, Heidelberg. Springer-Verlag.

Beuche, D., Papajewski, H., and Schröder-Preikschat, W.

(2004). Variability management with feature models.

Science of Computer Programming, 53(3).

Borgida, A. and Seraﬁni, L. (2003). Distributed Description

Logics: Assimilating Information from Peer Sources.

Journal on Data Semantics, 1:153–184.

Chen, L., Babar, M. A., and Ali, N. (2009). Variability

management in software product lines: a systematic

review. In Proceedings of the 13th International Soft-

ware Product Line Conference, SPLC’09, pages 81–

90.

Cuenca Grau, B., Parsia, B., and Sirin, E. (2009). Modu-

lar ontologies. chapter Ontology Integration Using E-

Connections, pages 293–320. Springer-Verlag, Berlin,

Heidelberg.

Czarnecki, K., Helsen, S., and Eisenecker, U. (2004).

Staged Conﬁguration Using Feature Models. In Nord,

R. L., editor, Software Product Lines, volume 3154 of

Lecture Notes in Computer Science, pages 266–283.

Springer Berlin Heidelberg.

Ensan, F. (2010). Semantic Interface-Based Modular On-

tology Framework. PhD thesis, University of New

Brunswick.

Flouris, G., Manakanatas, D., Kondylakis, H., Plexousakis,

D., and Antoniou, G. (2008). Ontology change: clas-

siﬁcation and survey. The Knowledge Engineering Re-

view, 23(2).

Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., and Huh,

M. (1998). FORM: A feature-oriented reuse method

with domain-speciﬁc reference architectures. Annals

of Software Engineering, 5(1):143–168.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E.,

and Peterson, A. S. (1990). Feature-Oriented Domain

Analysis (FODA) Feasibility Study. Technical report,

Carnegie-Mellon University Software Engineering In-

stitute.

Klein, M. (2001). Combining and relating ontolgies: an

analysis of problems and solutions. In IJCAI 2001

Workshop on ontologies and information sharing,

pages 53–62.

Langermeier, M., Rosina, P., Oberkampf, H., Driessen, T.,

and Bauer, B. (2013). Management of Variability

in Modular Ontology Development. In International

Workshop on Semantic Web Enabled Software Engi-

neering, Berlin.

Motik, B., Patel-Schneider, P. F., and Parsia, B. (2012).

OWL 2 Web Ontology Language, Structural Speciﬁ-

cation and Functional-Style Syntax (Second Edition).

W3C Recommendation.

Noy, N. F., Grifﬁth, N., and Musen, M. A. (2008). Collect-

ing community-based mappings in an ontology repos-

itory. The Semantic Web-ISWC 2008, pages 371–386.

Plessers, P., De Troyer, O., and Casteleyn, S. (2007). Under-

standing ontology evolution: A change detection ap-

proach. Web Semantics: Science, Services and Agents

on the World Wide Web, 5(1):39–49.

Sinnema, M. and Deelstra, S. (2007). Classifying variabil-

ity modeling techniques. Journal of Information and

Software Technology, 49(7).

Spaccapietra, S., Menken, M., Stuckenschmidt, H., Wache,

H., Seraﬁni, L., and Tamilin, A. (2005). Report on

Modularization of Ontologies. Knowledge Web Con-

sortium, (D2.1.3.1).

Stojanovic, L., Maedche, A., Motik, B., and Stojanovic, N.

(2002). User-driven ontology evolution management.

In Knowledge engineering and knowledge manage-

ment: ontologies and the semantic web, pages 285–

300. Springer.

Stuckenschmidt, H. and Klein, M. (2007). Reasoning and

change management in modular ontologies. Data &

Knowledge Engineering, (63):200–233.

Stuckenschmidt, H., Parent, C., and Spaccapietra, S., ed-

itors (2009). Modular Ontologies: Concepts, Theo-

ries and Techniques for Knowledge Modularization,

volume 5445 of Lecture Notes in Computer Science.

Springer, Berlin.

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

390