A holistic approach to collaborative ontology development based on change management

A Holistic Approach to Collaborative Ontology Development Based on ChangeManagement

Raul Palmaa,1,∗, Oscar Corchoa, Asuncion Gomez-Pereza, Peter Haaseb,2

aOntology Engineering Group, Departamento de Inteligencia Artificial, Facultad de Informatica, Universidad Politecnica de Madrid, Campus deMontegancedo sn, Boadilla del Monte, 28660, SpainbInstitute AIFB, KIT, D-76128 Karlsruhe, Germany

Abstract

This paper describes our methodological and technological approach for collaborative ontology development in inter-organizational settings. It is based on the formalization of the collaborative ontology development process by means ofan explicit editorial workflow, which coordinates proposals for changes among ontology editors in a flexible manner.This approach is supported by new models, methods and strategies for ontology change management in distributedenvironments: we propose a new form of ontology change representation, organised in layers so as to provide as muchindependence as possible from the underlying ontology languages, together with methods and strategies for theirmanipulation, version management, capture, storage and maintenance, some of which are based on existing proposalsin the state of the art. Moreover, we propose a set of change propagation strategies that allow keeping distributedcopies of the same ontology synchronized. Finally, we illustrate and evaluate our approach with a test case in thefishery domain from the United Nations Food and Agriculture Organisation (FAO). The preliminary results obtainedfrom our evaluation suggest positive indication on the practical value and usability of the work here presented.

Keywords: Collaborative Ontology Development, Ontology Changes, Ontology Metadata

1. Introduction

Ontology development is transforming from a pro-cess traditionally performed by isolated ontology engi-neers or domain experts into a process performed col-laboratively by mixed teams, who may be geographi-cally distributed and play different roles in the process.For example, some domain experts acting as editorsmay propose changes in specific parts of the ontologies,while other domain experts acting as authoritative usersmay approve or reject them following a well-defined ed-itorial process. Similarly, ontology engineers acting asknowledge architects may propose remodelling parts ofthe ontologies to follow specific ontology design pat-terns, which have to be approved by authoritative users.

∗Corresponding author. Tel: +48 61 858 21 60Email addresses: [email protected] (Raul Palma),

[email protected] (Oscar Corcho), [email protected] (AsuncionGomez-Perez), [email protected] (Peter Haase)

1Present address: Poznan Supercomputing and Networking Cen-ter, ul. Dabrowskiego 79a, 60-529, Poznan, Poland

2Present address: fluid Operations AG, Altrottstr. 31 69190, Wall-dorf, Germany

Classical ontology engineering methodologies (e.g.,METHONTOLOGY [1], On-To-Knowledge [2]) do notconsider this distributed setting and propose most oftheir ontology development activities and tasks for iso-lated ontology engineers or domain experts workinglocally with their ontologies. This is also the casefor most of the existing ontology development tools(e.g., Protege3, TopBraid Composer4, SWOOP5), whichmainly support the single-developer scenario, whereonly one user is involved in the development and latermodification of the ontologies. Only in some cases theyprovide additions or plugins to support groups of ontol-ogy developers working in collaboration (e.g., Collabo-rative Protege6 and Hozo7).

Other more recent methodologies or approaches,such as DILIGENT [3] and DOGMA-MESS [4], con-sider that ontologies can be developed collaboratively in

3http://protege.stanford.edu/4www.topbraidcomposer.com/5http://code.google.com/p/swoop/6http://protegewiki.stanford.edu/wiki/

Collaborative_Protege7http://www.hozo.jp/

Preprint submitted to Special Issue: Semantic Web Dynamics May 31, 2011

distributed settings. However, they normally focus oncentralized approaches for ontology and change man-agement, where a main copy of the ontology is main-tained and updated by groups of ontology developersthat may work with local adaptations. More impor-tantly, even though they consider some methodologicalaspects involved in collaborative ontology development,in general they focus less on the varied approaches fol-lowed by different organizations to coordinate this pro-cess. For example, they only propose simple conceptualmodels describing how ontology developers may use ashared (aka. main) copy of ontology, create local adap-tations, and then, somehow, other authoritative userswill collect, select and merge the proposed changes tocreate a new version of the main copy.

Different organizations may follow different ap-proaches for collaborative ontology development. Ex-amples of such collaborative development processes canbe found in international institutions like the United Na-tions Food and Agriculture Organization (FAO)8, whichis developing and maintaining large ontologies in thefishery domain [5], or the World Health Organization(WHO), which is developing and maintaining large on-tologies and classifications in the medical domain, suchas ICD9 (International Classification of Diseases) orICPS10 (International Classification for Patient Safety).Another similar example is the Gene Ontology (GO)project11, which addresses the need for consistent de-scriptions of gene products in different databases.

Figure 1 identifies a number of representative scenar-ios for the management of ontologies and their changesduring collaborative ontology development. The con-tinuous lines represent a permanent (tight) connectionbetween the editors and the centralized copy of theontology, whereas the dotted lines represent a tempo-rary (loose) connection between the editors and the dis-tributed copies of the ontology. At one end (ScenarioA), in a permanent online environment, ontology devel-opers may work collaboratively using a centralized copyof the ontology. This model is supported, for example,by WebProtege12 and the more recent iCAT platform13.At the other end (Scenario B), in a mostly offline en-vironment, they may collaborate using distributed lo-cal copies of the ontology that are sporadically syn-chronized, allowing ontology developers to collaborate

8http://www.fao.org/9http://www.who.int/classifications/icd/en/

10http://www.who.int/patientsafety/taxonomy/en/11http://www.geneontology.org/12http://protegewiki.stanford.edu/wiki/WebProtege13http://sites.google.com/site/icd11revision/home/

icat

Editor

Validator

Editor

Metadata

(a) Scenario A: Centralized Ontology Management.

Editor

Validator

Metadata

MetadataEditor

Metadata

(b) Scenario B: Distributed Ontology Management.

Editor

Validator

Editor

Metadata

Editor

Validator

Editor

Metadata

(c) Scenario C: Hybrid Ontology Management.

Figure 1: Typical Scenarios for the Management of On-tologies and Their Changes During Collaborative On-tology Development

2

even without a permanent and reliable connection, or ifnot enough centralized resources are available. This issupported, for example, by our collaborative ontologydevelopment extensions in NeOn Toolkit, implementedwith a set of plugins14 (described in detail in Section 6).Hybrid approaches (Scenario C), partly centralized andpartly distributed, are also possible.

In all these collaborative ontology development sce-narios, there is a need to coordinate the actions of allthe developers (for example, when do editors want theirchanges to be reviewed, what kind of actions can theyperform according to their roles, etc.). Therefore, weneed appropriate models, strategies and infrastructureto support those coordination tasks. This is one of thetwo major contributions of our work. Moreover, sincethe whole collaborative ontology development scenariois driven by the ontology changes, there is a need tosupport the management of those changes in distributedsettings, including their formal representation, manipu-lation and propagation. This is the second major contri-bution of our work.

The remainder of this document is organized as fol-lows: after a summary of the state of the art (Section 2),we provide a high level overview of our solution (Sec-tion 3). Then, we describe our contributions for collab-orative ontology development (Section 4) and for on-tology change management in distributed environments(Section 5). Then, in Section 6 we present the techno-logical support for the work here presented. In Section7 we present the evaluation experiments, in Section 8we summarize and discuss the results. We conclude inSection 9 and discuss directions for future research inSection 10.

2. Overview of the State of the Art

In this section we briefly discuss the main limitationsand challenges encountered for the core topics of thiswork, namely, collaborative ontology development andontology change management. A more comprehensivestate of the art of all these activities can be found in [6].

Previous efforts to support collaborative ontologydevelopment produced relevant methodological andtechnological results (e.g., [7], [4], [8], [9], [10], [11],[12], [13], [14], [15] and [16]). However, existing solu-tions support only a centralized management of the on-tology and its related changes. In some cases (e.g., [7]

14http://neon-toolkit.org/wiki/1.x/Workflow_

Support, http://neon-toolkit.org/wiki/1.x/Change_

Capturing and http://neon-toolkit.org/wiki/1.x/

Oyster-menu

and [4]), a shared (aka. main) copy of the ontology canbe adapted or specialized by distributed users; in othercases (e.g., [9] and [10]), a main copy of the ontologyis divided into sub-ontologies each of them modified bydistributed users; and in other cases (e.g., [8], [11], [12],[13] and [15]) there is only a central copy of the ontol-ogy that all distributed users can modify. In every case,changes are applied and managed in the central copy ofthe ontology.

Moreover, in general they do not support the pro-cesses typically followed by organizations for the coor-dination of change proposals, which specifies the typeof actions or operations ontology editors can performdepending on their role and the state of the ontology.Some early conceptual efforts were presented in [7] and[4]. Besides, a notable exception is the work from [14]—and derivative works— which provided recently aproposal, although without any technological support.

Furthermore, in many of them (e.g., [7], [4], [10] and[11]) there is not even a formal management of ontol-ogy changes (e.g., explicit representation and propaga-tion). And in summary, there is no integrated approach(and technological support) that addresses all the previ-ous issues.

In contrast to existing approaches, first, our solutionis based on a formalization of the collaborative devel-opment process followed by organizations for the coor-dination of change proposals. Second, while there is apoor management of ontology changes in many existingsolutions, our solution is supported by models, methodsand strategies for change management in distributed en-vironments.Third, unlike existing approaches that sup-port only a centralized management of the ontology andits related changes, our solution supports both a central-ized and a distributed management. Finally, we providean integrated approach (and technological support), cur-rently not available, which addresses all the previous is-sues.

Regarding the management of changes, we limit ourdiscussion to the main activities that we address: changerepresentation, change propagation and tool support.

For the representation of ontology changes two mainworks can be identified: Stojanovic’s [17] and Klein’s[18]. They classify changes in a similar manner (atomicor elementary, composite and complex), where atomicchanges refer to operations at the entity level. Someother works in the literature resemble (e.g., [19] and[20]) or extend (e.g., [21] and [12]) the previous modelsor provide partial solutions (e.g., [22], [23] and [24]).All of these, however, are dependent on the underlyingontology model, which makes them difficult to integrateor reuse. Besides, even when they classify changes at

3

different granularity levels, their lower level considerschanges at the entity level (e.g., classes, properties andindividuals), instead of considering the real low leveloperations that can be performed in an ontology, whichmakes them less flexible, less detailed and more difficultto process. In our work, we propose a change represen-tation model that is independent of the underlying on-tology language, and that includes a more fine-grainedtaxonomy of ontology changes in comparison to exist-ing models, which identifies the real low-level opera-tions that can be performed in an ontology.

With respect to the propagation of changes, it hasonly been considered in the past to related ontologies(e.g., [17], [25] and [9]), to ontology individuals (e.g.,[26] and [27]), and to some extent to related applications([28]). For the propagation of changes to related ontolo-gies, existing approaches consider only a central (main)copy of the ontology that is either replicated (e.g., [17])or divided into several component ontologies (e.g., [9])and where in general, changes are propagated only inone direction: from the main copy to its replicas. Theonly exception is when the ontology is divided into sev-eral component ontologies, but in this case the manage-ment of changes is centralized. As a consequence, thepropagation of changes to distributed (editable) copiesof the same ontology with a distributed control, are notsupported yet. Our work addresses exactly that issue,enabling a distributed management of the ontology andits changes.

Finally, existing tools (that do not tackle additionalcollaborative aspects) support different aspects of thechange management. Many of them are focused on themanagement of ontology versions (e.g., [29], [30] and[31]). Nevertheless, some tools address evolution as-pects, such as the effect of changes on dependent appli-cations (e.g., [28]), the tracking of changes along withtheir formal representation, and the propagation task(e.g., [17], [32] and [31]). However, in those cases,the management of ontologies and their changes is ei-ther centralized or the changes are propagated from amain copy of the ontology to its distributed non-editablereplicas. The technological support that we provide, in-tegrates our solutions for the management of changes indistributed environments, including the tracking, repre-sentation and propagation of changes from any copy ofthe ontology to other copies.

3. Our Approach in a Nutshell

This paper presents a holistic approach to support col-laborative ontology development in inter-organizationalsettings. Our work is based on models, methods and

strategies for the management of ontology changes indistributed environments.

The diagram in Figure 2 depicts a general overviewof the paper contributions and the relationship betweenthem. In the diagram, the two boxed areas representthe two research areas that we address; the componentsin the outer box rely on the components of the innerbox. The way the components are related to each otheris illustrated by the arrows.

Collaborative Ontology Development (Section 4)

Ontology Change Management in Distributed Environments

(Section 5)

Change

Representation

Model

(Section 5.1)

Change

Propagation

Strategies

(Section 5.3)

Process

Formalization

(Section 4.3, 4.4)

Change

Manipulation

Activities

(Section 5.2)

Workflow

Management

and Enactment

(Section 4.5)

Infrastructure for

Collaborative

Ontology

Development

(Section 6)

Supports

Figure 2: Overview of Our Contributions and the Rela-tionship Between Them.

As presented in the figure, the first major contribu-tions of this work (described in Section 4) starts with theformalisation of the collaborative development pro-cess as an editorial workflow (Sections 4.3 and 4.4),which can be described as a special case of epistemicworkflow15 characterized by the ultimate goal of de-signing networked ontologies and by specific relationsamong designers, ontology elements, and collaborativetasks [33]. The need for such workflows has also beenacknowledged in the past in other related works (e.g.,[13]). Then we focus on the management and enact-ment of such editorial workflows (Section 4.5), whichinclude the execution of several tasks that have to be car-ried out to provide a complete solution that supports col-laborative ontology development, such as the enforce-ment of process constraints. Finally, our contributionincludes an integrated infrastructure for collaborativeontology development (described in Section 6) that im-plements all the models, methods and strategies hereproposed.

Our second major contribution is the management ofontology changes in distributed settings (described inSection 5), which is central to our approach since the

15Epistemic workflows describe the flow of knowledge from onerational agent to another [16].

4

whole collaborative ontology development scenario isdriven by them. The contributions here can be dividedinto: (i) those related to the representation of changes(Section 5.1), including how they can be identified, andat which level of granularity, from high level changesthat identify the basic parameters in which an ontol-ogy has changed, including its metadata, to low levelchanges that identify the changes that were producedat the axiom level and which are highly dependent onthe ontology implementation language; (ii) those re-lated to their manipulation (Section 5.2), includinghow changes can be captured or how the consistency ofthe ontology is ensured after those changes; and finally,(iii) those related to change propagation (Section 5.3)in distributed settings. As a fundamental characteris-tic of our approach, all these contributions on ontologychange management build on OMV16 [34], a metadatavocabulary that captures relevant information about on-tologies such as provenance, availability, statistics, etc.

4. Collaborative Ontology Development Supportedby Change Management

This section presents our solution to support collab-orative ontology development in distributed settings. Itaddresses the main limitations in existing approaches asdiscussed in Section 2.

In order to achieve our goal, we first identified themost relevant requirements to support collaborative on-tology development in distributed settings, based on theanalysis of the processes typically followed by organi-zations in the development and maintenance of ontolo-gies (Section 4.1). For this analysis, we considered dif-ferent processes and scenarios for collaborative ontol-ogy development and previous efforts in the state of theart. We will illustrate the outcome of this analysis, aswell as the models and strategies proposed, with a con-crete example (described in Section 4.2) based on thefisheries ontologies lifecycle from FAO [5]. In particu-lar, Section 4.3 describes how the collaborative processcan be formalized by means of a collaborative workflowmodel and illustrate it with the particular collaborativeprocess in our running example. Similarly, in Section4.4 we discuss how the workflow model can be repre-sented and implemented in a workflow ontology and il-lustrate it with our running example. Finally, in Sec-tion 4.5 we describe the strategies for the managementand enactment of the workflow during ontology devel-opment.

16http://omv.ontoware.org

4.1. Analysis of Collaborative Ontology Development

As mentioned before, the collaborative developmentof ontologies usually follows a pre-defined process thatspecifies who (depending on the user role), when (de-pending on the ontology state) and how (which ac-tions or operations users can perform) an ontology canchange. However, the details of this process, as well asthe configuration of the collaborative scenario, can varyfrom one organization or context to another.

Figure 1 already presented three representative sce-narios for collaborative ontology development. In eachcase, the management of the ontology and its associ-ated changes is performed in a different way, supportingdifferent setups and characteristics of the collaborativeenvironment:

i) In Scenario A (c.f. Figure 1(a)), ontology andchange management is centralized. There is onlyone copy of the ontology, stored in a central server,which can be edited by all (distributed) membersof the team from their (remote) node. The changeinformation about the ontology is also stored in acentral registry.

ii) In Scenario B (c.f. Figure 1(b)), ontology andchange management is distributed. There are ”n”copies of the ontology, where ”n” is the number ofontology editors working on their own local copyof the ontology. Change information is also storedin a distributed manner (e.g., in a local registry ofeach member). The local nodes exchange informa-tion about ontology metadata and synchronize on-tology changes. Changes received from other nodesare applied locally in the ontology copy to keep thedistributed copies synchronized.

iii) Scenario C (c.f. Figure 1(c)) is a hybrid betweenscenarios ”A” and ”B”. The team of ontology edi-tors can be divided in at least two different groups.Each group works in an environment with the char-acteristics of scenario A. Additionally, the groupshave between them an environment with the charac-teristics of scenario B. That is, each group has a cen-tralized ontology server (and metadata provider),which in turn is treated as the ontology editor’snodes in configuration B.

Since scenarios B and C are not supported yet by ex-isting methods and tools as they rely on a distributedmanagement of the ontology and its related changes (seeSection 2), part of our work was targeted for supportingthem.

5

From this analysis, as well as from previous effortsin the state of the art (e.g., [12]), we derived a set ofrequirements [35]. Briefly, lifecycle requirements ad-dress the coordination of the change proposals enablingontology editors to consult, modify, validate or pub-lish ontologies depending on their role and the stateof the ontology. Activity requirements deal with theactivities required to be supported, such as edit ontol-ogy elements, change state of elements, etc. Visual-ization requirements are those concerned with enablingusers to consult the corresponding information gener-ated by those actions, such as view the change history.Change management requirements are related to therepresentation, capturing, propagation and notificationof changes. Versioning requirement deals with the iden-tification and tracking of different ontology versions.Finally, we identified requirements related to concur-rency control, such as the coordination of changes ap-plied in distributed ontology copies, necessary to sup-port the collaboration among editors during ontologydevelopment.

In the remainder of this section we provide solutionsto support the lifecycle and activity requirements. InSection 5 we address the management of changes, themanagement of different ontology versions and the con-currency control by the synchronization of local ontol-ogy copies. Finally, in Section 6, we address the visual-ization requirements with our technological support.

4.2. Running Example

Ontology developers at FAO are developing anontology-based information system to facilitate the as-sessment of fisheries stock depletion by integrating thevariety of information sources available. In this context,one of the goals is the development of an application forthe management of fishery ontologies and their lifecy-cle.

Several actors are involved in the ontology devel-opment process, such as, experts in ontology model-ing who, are in charge of defining the original skele-ton of the ontology, and ontology editors, who are incharge of the everyday editing and maintenance of theontologies. Ontology editors include subject expertswho know about the domain to be modeled and val-idators who, besides being domain experts, can movea change to production state for external availability.Ontology development follows a well-defined process,which needs to be supported in the engineering environ-ment. This process allows ontology editors to consult,validate and modify the ontology collaboratively, keep-ing track of all changes in a controlled manner. Finally,

Draft

To Be Deleted

Approved To Be Approved

Send to be approved Send to approved

Send to be deleted

Reject to approved

Reject to draft Reject to be approved

Update Insert

Delete

Delete

Update

Update

(SE)

(SE)

(SE)

(SE)

(V)

(V)

(V)

(V)

(SE)

(SE, V) (V)

(V)

Figure 3: Collaborative editorial workflow at the ele-ment level for the running example.

once editors in charge of validation consider the ontol-ogy as final, they are authorized to release it and makeit available to end users and systems.

4.3. Workflow Model

In our approach, we consider the collaborative devel-opment process at two different levels of abstraction:the (ontology) element level and the ontology level. Ineach level, we must model the way in which the differ-ent elements involved in this process (roles of designers,states of ontologies and elements, available collabora-tive actions) are related to each other.

Hence, we propose the use of collaborative editorialworkflows to formalize the collaborative ontology de-velopment process. In our solution, we consider that anontology consists of a set of axioms and facts, whichcan relate to entities such as classes, properties or in-dividuals. These entities constitute the basic ontologyelements that we consider.

The details of the collaborative ontology develop-ment process (the specific roles, actions, etc.) dependon the organization setting. Therefore, to illustrate ourapproach, in the rest of this section we discuss our solu-tion for the particular scenario of our running example.

Illustration with running example. Figures 3 and 4show the two different workflow levels (element and on-tology level) for our running example. States are de-noted by rectangles and actions by arrows. The infor-mation in parentheses specifies the actions that an editorcan perform depending on its role, where ”SE” denotesSubject Expert, ”V” denotes Validator and ”-” denotesthat the action is performed automatically by the sys-tem.

The possible states that can be assigned to ontologyelements (see Figure 3) are the following:

6

PublishedPublish

Approved

Move to be approved

DraftApproval

To Be Approved

Move to draft

(V)(-)(-)(-)

Move to draft (-)

Figure 4: Collaborative editorial workflow at the ontol-ogy level for the running example.

• Draft: This is the state assigned to any elementwhen it passes first into the workflow, or when itwas approved and then updated by a Subject Ex-pert.

• To be approved: Once a Subject Expert is confi-dent with a change in Draft state, the element ispassed to the To Be Approved state and remainsthere until a Validator approves or rejects it.

• Approved: If a Validator approves a change in anelement in the To Be Approved state, it passes tothe Approved state. Additionally, this is the defaultstate for every element of the initial version of astable ontology.

• To be deleted: If a Subject Expert considers thatan element needs to be deleted, the item will beflagged with the To Be Deleted state and removedfrom the ontology although only a Validator willbe able to definitively delete it.

• Deleted: This is the state assigned to any elementwhen a Validator definitely deletes it after its statewas To Be Deleted. Additionally, this is the stateassigned to any element when a Subject Expertdeletes it after its state was Draft. Note that thisstate is represented by the doubled circle in the fig-ure.

The ontology state (see Figure 4) is automatically as-signed by the system (denoted with ”-” in the figure),except from the Published state. The ontology state isbased on the state of its elements, i.e., the state of anontology is given by the ”lower” (less stable) state ofany of its elements. For instance, it can happen that inthe same ontology there are elements in the Draft stateand elements in the To Be Approved state, then the stateof the ontology is going to be Draft. Hence, ontologystates are defined as follows:

• Draft: Any change to an ontology in any state au-tomatically sends it to Draft state.

• To be approved: When all ontology elements in anontology version are in the To Be Approved state(or Deleted), the ontology is automatically sent tothe To Be Approved state.

• Approved: When all ontology elements in an ontol-ogy version are in the Approved state (or Deleted),the ontology is automatically sent to the Approvedstate. Additionally, this is the default state of theinitial version of a stable ontology.

• Published: Only when the ontology is in the Ap-proved state, it can be sent by a Validator to thePublished state.

In our running example, the workflow starts after get-ting a stable populated ontology that satisfies all the or-ganizational requirements. Hence, we assume that theinitial state of this stable ontology (and all its elements)is Approved17.

Note that during the workflow, actions are performedeither:

• Implicitly: For instance, when a user updates anelement, he does not explicitly perform an Updateaction. In this case it has to be captured from theuser interface. The action is recorded after the op-eration is successfully executed.

• Explicitly: For example, validators explicitly ap-prove or reject proposed changes. The action isrecorded immediately when the user explicitly per-forms the action.

As we can see from the previous discussion, thecollaborative ontology development process highly de-pends upon the operations performed to the ontol-ogy itself (the changes performed by ontology editors).Hence, similarly to our change representation model,we decided to model the workflow elements (roles,states, actions) using a workflow ontology. Having bothmodels (ontology changes and workflow) formalized asontologies facilitates the representation of the tight re-lationship that exists between them. For instance, con-sider a user with role Subject Expert that inserts a newontology class to the ontology. That class will receiveautomatically the draft state. All the information re-lated to the process of inserting a new ontology elementwill be captured by the workflow ontology, while theinformation related to the particular element inserted

17In a different scenario, the workflow could start with an emptyontology (without elements), which we could assume that will be bydefault in the Approved state.

7

along with the information about the ontology beforeand after the change is captured by the change ontol-ogy. Additionally, the workflow process also relies onOMV to refer to ontologies and users.

4.4. Workflow Ontology

The main classes and properties of the workflowontology along with the relationships with the otherontologies in our approach (e.g., OMV and GenericChange Ontology) are illustrated in Figure 5. In the fig-ure, the elements above the horizontal line are genericelements of the workflow ontology that are independentof the collaborative development process details, whilethe elements below the line are specific for our runningexample (see below).

Ontology

Person

hasCreatorhasContributor

hasRole

Role

Subject Expert

Validator

Viewer

ChangeSpecification Change

EntityChange hasChange

...

OMV Core Generic Change Ontology

Action

OntologyAction EntityAction

State

EntityState OntologyState

Publish Delete

Send to bedeleted

Insert

Reject toApproved

Reject to beApproved

Reject toDraft

Send to beApproved

Send toApproved

Update

Draft

To BeApproved

Approved

To BeDeleted

Deleted

DraftOnto

To Be App-rovedOnto

Approved

PublishedOnto

Onto

relatedChange

hasState

hasOntologyState

performedBy

hasAuthor

From/To PublicVersion

Class Name

ObjectProperty

Range

Domain

Class

subClassOf

InstanceOf

nameIndividual

Generic Elements of Workow Ontology

Specic Elements for Running Example

Figure 5: Overview of the Workflow Ontology.

The different roles that ontology editors can have aremodeled as individuals of the Role class that is relatedto the Person class of the OMV core ontology (a personhas a role).

To explicitly model the separation between the possi-ble states of ontology elements (classes, properties and

individuals) and the possible states of the ontology it-self, the State class is specialized in two subclasses(EntityState and OntologyState). Similarly to theroles, the possible values of the states are modeled as in-dividuals of their respective subclass. Furthermore, thetwo subclasses of State allow representing the appro-priate relationships at the element and ontology level: tospecify that an ontology element has a particular state,we rely on the class EntityChange from the changeontology (described in Section 5.1) which is associ-ated to a particular ontology element and associate itwith subclass EntityState; to specify that an ontologyhas a particular state, we rely on the class Ontology

from the OMV core and associate it with the subclassOntologyState. Note that at this point we are not con-sidering composite changes in our workflow; they aretreated as a sequence of changes at the entity level. Ad-ditionally, observe that the state is not assigned to theactual object (e.g., ontology element or ontology) but tothe referring metadata entity (entity change or the on-tology metadata) for two reasons: first, it is the actualreferring entity that modifies the state of the object; sec-ond, all this information is managed by the ontologyregistry that stores all ontology related metadata but notthe ontologies themselves.

Finally, for the actions there is also a separation be-tween the possible actions at the element level and ac-tions at the ontology level. Hence, the Action classis specialized in two subclasses (EntityAction andOntologyAction). To track the whole process (andkeep the history) of the workflow, the possible actionsare modeled as subclasses of the appropriate Action

subclass. Similar to the states, the two subclasses ofAction also allow representing the appropriate rela-tionships at the element and ontology level. To spec-ify that an action was performed over a particular on-tology element, the subclass EntityAction is associ-ated with class EntityChange. However, as illustratedabove with our running example, actions at the ontol-ogy level are usually performed automatically by thesystem. The explicit actions at the ontology level aredependent on the specific workflow details. Therefore,we do not specify any association between the genericsubclass OntologyAction and class Ontology; asso-ciations are only specified, if necessary, between the ex-plicit actions (at the ontology level) of the specific work-flow and the class Ontology (see below).

Illustration with running example. As we can see inFigure 5, the three different roles of our running exam-ple (Subject Expert, Validator, Viewer) are modeledas individuals of the class Role.

8

Similarly, the five possible states that can be assignedto ontology elements (Draft, To Be Approved, Ap-proved, To Be Deleted and Deleted) are modeled asindividuals of the class EntityState and the four pos-sible states for an ontology (Draft, To Be Approved,Approved and Published), as individuals of the classOntologyState.

Finally, the nine actions that ontology editors can per-form over ontology elements (Insert, Update, Delete,Send To Be Approved, Send To Approved, Send To BeDeleted, Reject To Draft, Reject To Be Approved,Reject To Approved) are modeled as subclasses of theclass EntityAction. Additionally, the only explicit ac-tion that can be performed to the ontology (Publish) ismodeled as subclass of the class OntologyAction. No-tice that, as described in the previous section, the actionPublish may change the version of the ontology. There-fore, it is associated to the class Ontology to specifythe previous and next public version of the ontology.

Note that in the current implementation of our work-flow ontology, the constraints of the collaborative devel-opment process in our running example are not explic-itly declared as part of the ontology. Those constraintsare handled by the strategies for workflow managementand enactment discussed in next section. The reasonsfor taking a procedural approach instead of a declara-tive one were mainly of pragmatic nature, as in our casethe benefits of a declarative approach did not outweighthe additional development effort. Still, future work inthis area should evaluate the practicability of a declara-tive approach.

4.5. Workflow Management and Enactment

The management and enactment of the workflow con-sists on the execution of several tasks to support the col-laborative ontology development.

• It requests users to identify themselves with theirusername and corresponding role.

• It enforces the constraints imposed by the collab-orative workflow. That is, every time an ontologyeditor performs a workflow action (e.g., insert newelement or submit a change to be approved), thefollowing tasks are carried out:

i) To verify that the ontology editor has the ap-propriate permissions. This can be performedby verifying the role of the user. For instance,the collaborative workflow may constrain thatonly subject experts can insert new ontologyelements (as in our running example).

ii) To verify the state of the corresponding ontol-ogy element (if any) for the proposed action.For this task, we need to evaluate the currentstate of the element before applying the re-quested action. For instance, a change in anontology element may not be approved if it isin draft state.

iii) To verify the provenance of the action. For in-stance a subject expert may not be allowed tosubmit changes from another subject expert tobe approved. For this task, the author of thechange has to be compared with the currentuser.

• It supports transaction management capabilities.This means that if the performed action is rejected,all of its effects have to be undone.

• It creates and stores the appropriate individuals ofthe workflow ontology, if an action is successfullyexecuted.

• It performs all consequences of an action if it issuccessfully executed. For instance, if a subject ex-pert submits one change to be approved, the stateof the change has to be updated to To Be Approved.This task also involves storing the correspondingstate of the related element along with the work-flow ontology individual.

Additionally, the workflow enactment includes theprovision of appropriate interfaces for the users to vi-sualize and perform all the required actions. For in-stance, ontology editors (e.g., subject experts and val-idators) need to have different views of the ontologiesdeveloped collaboratively, depending on their role.

5. Change Management in Distributed Environ-ments

Our collaborative ontology development approach isbased on the management of ontology changes in dis-tributed environments. Our solution provides contribu-tions to the representation of ontology changes (Section5.1), their manipulation (Section 5.2) and propagationto distributed copies of the same ontology (Section 5.3).

5.1. Ontology Change Representation

A core element in our solution is the representationof changes. Although we found several approaches forthe representation of changes (e.g., [17], [18], [19], [21]and [22]), they have still some limitations (see Section

9

2). In particular, they are dependent on the underly-ing ontology model, and they only consider changesat the entity level (classes, properties, individuals). In[36] we presented our proposal for the representation ofchanges. In this paper we highlight only the most rel-evant parts: We propose a layered model for the rep-resentation of ontology changes that integrates manyof the features of existing change ontologies (e.g., [17]and [18]). The core of this model consists of a genericchange ontology, independent of the underlying ontol-ogy language that models generic operations in a taxon-omy of changes that are expected to be supported by anyontology language (based on the ontology componentsidentified by Gruber [37]). The generic change ontol-ogy can be reused and specialized for specific ontologylanguages18 (Figure 6 illustrates the layered model spe-cialized for OWL 2 - elements of the generic changeontology are in white whereas elements of the OWL 2specialization are in grey). The generic change ontologycomprises three levels for the classification of changes:

• Atomic - the smallest and indivisible operation thatcan be performed in a specific ontology model.

• Entity - basic operations that can be performedover ontology elements.

• Composite - group of changes applied together thatconstitute a logical entity.

Besides the taxonomy of ontology changes, thegeneric change ontology models the provenance ofchanges, that is, when the change was made, who madeit, and how it was made. Furthermore, the genericchange ontology provides the means to support not onlythe tracking of changes but also the information thatidentifies the original and the current version of the on-tology after applying the changes.

The generic change ontology has been implementedas an extension of the OMV ontology metadata model,since we consider ontology changes as a special kind ofontology metadata.

5.2. Ontology Change Manipulation

The manipulation of changes includes supplementarymethods and strategies that support the management ofchanges in distributed environments.

18The generic change ontology and two specializations (for OWL2 and RDFS) are available at http://omv.ontoware.org/.

0:n hasChange

ChangeSpecification•

lexOMV v.0.1

[prefix:] Class Name

ObjectPropertyChange

owl2:Class

owl2:Datatype

owl2:NamedIndividual

owl2:ObjectProperty

owl2:DataProperty

0:n fromVersion0:n toVersion

owl2:Entity

EntityChange

AtomicChange

0:n relatedEntity

CompositeChange

lexOMV v.0.1

owl2:ClassAxiom

owl2:Assertion

owl2:Declaration

owl2:ObjectPro- pertyAxiom

owl2:DataPro- pertyAxiom

owl2:Axiom

0:n appliedAxiom

omv:OntologyGeneric Class

subClassOf

DatatypeProperty

[prefix:] Class Name

DatatypeProperty

OWL2Specialised Class

prefix: Imported Ontology Namespace Reference

Range

Domain

MIN:MAX Cardinality

1:n hasAuthor

1:1 hasPreviousChange

Log 1:1 hasLastChange• uri• date• priority•••

•initialTimestamplastTimestamp

Removal

Addition

AnnotationPropertyChange

CommentChange

ClassChange

SubClassOfChange

DisjointnessChange

ClassEquivalenceChange

IndividualChange

IndividualEquivalenceChange

InverseObjectPropertyChange

AddSubtree

MergeSiblings

MoveSubtree

SplitClass

ObjectPropertyChange

Agent

omv:Person

Figure 6: Overview of the OWL 2 Change Ontology.

5.2.1. Ontology Change CapturingChanges in ontologies need to be captured and stored

in a certain format. The definition of the change on-tology presented in the previous section, allows stor-ing changes about a certain ontology in a machine-understandable format. However, there should be ap-propriate methods to capture the changes in the evolvingontology, such as information gathering and data encod-ing, and to store them for future references.

In a controlled scenario where several ontology engi-neers are working collaboratively on a set of ontologies,the editing activities are performed directly using theontology editor interface. Thus, the process of capturingchanges can be described in the following steps: first, achange in an ontology from the ontology editor (Step1), fires an ontology change monitor (Step 2). Then, inStep 3, the monitor calls an ontology change process-ing component, responsible to collect all the informa-tion about the change (e.g., author of the change, timeof the change and type of change). Next, in Step 4, thecollected information is passed to the ontology changeencoder where the change is represented according tothe change ontology by creating the corresponding in-dividual(s). Finally, this change individual(s) is stored

10

in an ontology registry for future processing and propa-gation (Step 5).

Note that the task of storing a change individual in-volves additional subtasks, such as updating the infor-mation of the chronological order of changes and thepropagation of changes to related entities. In our solu-tion, such tasks are carried out by the ontology registrysystem.

5.2.2. Ontology Version ManagementThere are different definitions and understandings of

what ontology versioning is (see [6]). For this work, weconsider ontology versioning as a mechanism to keeptrack of ontology changes and to identify and maintaindifferent variants of ontologies and their dependencies,with support to undo and redo operations (e.g., rollbackto a previous variant).

To keep track of ontology changes we generate alog that maintains the history (and order) of appliedchanges as a sequence of individuals of our proposedchange ontology. The management of that ontologymeta-information (applied changes) is the responsibil-ity of the ontology registry, which is in charge of the ad-ministration of all the ontology related metadata (as de-scribed below). Furthermore, the information about theprecise changes performed can be used to easily com-pute the difference between variants or to implement amultiple undo and redo mechanism.

Nevertheless, as it has been noted in the past (e.g.,[38]), the issue of identifying the different variants (ver-sions) of an ontology is not a trivial one. For instance,even the OWL ontology language itself did not providethe means to identify and manage multiple versions andphysical representations of one ontology until the latestrelease of OWL 2, where this is partially addressed. So,even though ontologies are supposed to be identified bya URI (as OWL 2 has just been released), in practicedifferent versions of an ontology carry the same logicalURI. Also as we noted before, typically ontologies ei-ther do not provide any version information at all or theontology editors explicitly do not want to change theversion of the ontology after making some changes.

However, since we are considering a controlled envi-ronment (typical within an organizational setting) wherewe are logging changes on the ontologies as they occur,we can assume that we will always have the version in-formation. Hence, our solution is based on the identi-fication of ontologies that we proposed in the specifi-cation of OMV (see [39]) which consists of a tripartiteidentifier: the ontology URI, the ontology version (ifpresent), and the ontology location. We also rely on

OMV for representing the relationship between the dif-ferent ontology versions (e.g., prior version and com-patible with). Furthermore, the specific set of changesfrom one ontology version to the next one is capturedby the change representation model (described in 5.1)and maintained by the distributed registry with the restof the ontology related metadata.

Therefore, in our scenario, after a first version ofan ontology is obtained, this will normally enter intoa maintenance phase in which it could be modified forseveral reasons. This phase normally follows a well-defined process for the coordination of changes (e.g.,who can propose or approve changes, and when, de-pending on the state of the ontology) and the approvalof a new ontology release (e.g., a whole new version oran update of the current version). Particularly, in our so-lution, the first stable version (version 1) of an ontology(the ontology that satisfies all requirements) is consid-ered the first approved ontology (which in some cases isalso published in the Internet). The first change to thatversion will automatically create a new version, with adifferent version information (N+1), unless the editorexplicitly specifies that the modified version will not be-come a new version; in this case, the modified versionwill keep the same version information (N). In any case,this (unapproved) version can receive many changes (bymany ontology editors) without changing the version in-formation until it becomes approved. Then, an autho-rized editor may want to publish this approved ontologyversion, and decide to either keep the version informa-tion or to specify a new one.

Note that in a distributed scenario, where ontologyeditors can work with local copies of the same ontology,the same new version can be created offline by two ormore editors after applying some changes to the samebase ontology. These copies will be synchronized oncechanges are propagated when they eventually go online,as described in Section 5.3.

5.2.3. Ontology Change Storage and MaintenanceAs we already mentioned before, the storage and

maintenance of the change information is the respon-sibility of an ontology registry. The registry stores andmanages ontology metadata information which includesinformation about changes. Hence, in our solution, theregistry implements the following features for the man-agement of changes (based on the models, methods andstrategies described through this section):

• Stores the change history (log) for different ontolo-gies, i.e., set of individuals of our change ontolo-gies.

11

• Maintains the chronological order of changes. Theset of individuals is maintained in a linked list,where each change individual is linked to the pre-vious one.

• Supports different versions of ontologies at differ-ent locations.

• Provides access and advanced search capabilitiesto retrieve changes (based on the change represen-tation model.

• Propagates changes to support, for instance, thesynchronization of distributed copies of ontolo-gies or the update of ontology related entities, e.g.,metadata.

5.3. Ontology Change Propagation

Ontology change propagation is another task identi-fied by most of the ontology evolution approaches andrefers to the activity of updating all of the ontology de-pendent artifacts ([17]). As we discussed in Section 2,there are several limitations in this area. In general, ex-isting approaches (e.g., [17], [25]), [9], [26] and [27])consider only the propagation to related ontologies andindividuals. Besides, for the propagation of changesto related ontologies, these approaches consider only acentral (main) copy of the ontology that is either repli-cated or divided into several component ontologies and,in general, changes are propagated only in one direc-tion: from the main copy to its replicas. The only ex-ception occurs when the ontology is divided into severalcomponent ontologies, but in this case the managementof changes is centralized.

Hence, in this section we consider the propagation ofchanges to distributed ontology copies, which supportsa distributed management of changes and the propaga-tion of changes from any copy of the ontology to othercopies.

Change Propagation to Distributed Copies of anOntology

One of the goals of propagating ontology changesin a distributed setting is to keep distributed copies ofthe same ontology synchronized. In order to propagatechanges, first we need to have those changes stored inan appropriate system. In the previous section, we pre-sented our solution for capturing ontology changes.

Once the required changes are represented in amachine-understandable format, the system can prop-agate them to the distributed copies of the ontology.There are two possible approaches for the propagation:

push or pull. The benefits and disadvantages of both ap-proaches have already been analyzed (e.g., [17]). Sincewe are considering a distributed environment where wecannot guarantee the availability of nodes, we propose acombination of a pull and push mechanisms that we callsynchronization. The synchronization is based on thetime when the changes were originally applied (times-tamp). Consequently, it is important that the distributednodes have their system times synchronized (e.g., witha time server) and that the timestamps have a high pre-cision (to avoid many changes occurring at the sametime).

For the pull mechanism, we propose that, periodi-cally, nodes will contact other nodes in the network toexchange updated information. For this task, in ad-dition to the changes themselves, i.e., individuals ofthe change ontology in chronological order, each nodemaintains in its local log explicit information about(i) which ontologies the node is tracking, (ii) the lastchange it knows for each of the tracked ontologies and(iii) the set of URIs of the changes applied to each on-tology (version). Note that, if the local node does nothave yet any change information about a tracked ontol-ogy, the last change known by the local node for thatontology is equivalent to null, and the set of URIs of thechanges applied to that ontology is an empty set.

During the pull mechanism, the following rules ap-ply: (i) nodes can only update their local registry (log),and (ii) nodes can pull changes applied to ontologiesfrom any remote node. The reason for (i) is that eachnode can only update the information it owns. Besides,as each node performs the same pull mechanism peri-odically, if the contacted remote node has an outdatedinformation, eventually it will contact a node with up-dated information and modify its own information ac-cordingly.

So, the process that takes place when node x contactsnode z is as follows:

For each ontology that is tracked in both nodes x andz, the first step is to compute the difference between theset of URIs of the changes applied to the ontology (e.g.,Oi) in the remote node z and the corresponding set inthe local node x. If the difference is the empty set, theset in x is either (i) equal or (ii) a superset of the cor-responding group in z. If the difference is not the emptyset, at least one of the changes in z is not in x, i.e., (iii)x is not synchronized with z19.

Case (i) indicates that nodes are synchronized witheach other and, therefore, the local node x does not have

19 x ∩ z = ∅ or x ∩ z = x (x is a subset of z) or x ∩ z = subset of xand subset of z

12

to do anything.In case (ii), the local node x knows about all the

changes that the remote node z knows, but additionallyit also knows about other changes. Hence, following therules described above, x does not have to do anything.

In case (iii), the remote node z knows about one ormore changes that the local node x does not know about.Hence, the local node x retrieves from z all the un-known changes (pull propagation), i.e., the changes cor-responding to the URIs of the computed difference be-tween z and x. Then, a local conflict detection mecha-nism should determine whether there is any change thatis conflicting with the current changes. Conflicts maybe detected on a syntactic level (when the same entity isaffected by changes from different users), or on a se-mantic level (when the combination of changes fromdifferent users results in a logical inconsistency) [40].In case there are conflicting changes, a conflict resolu-tion mechanism will be responsible for resolving them.In the simplest case, this mechanism removes the con-flicting changes from the set and notifies the presence ofthe conflict (see below). Note that entity and compositechanges must be treated as atomic operations. For in-stance, in an OWL 2 ontology, the entity change ”AddIndividual” will be in conflict if any of its two corre-sponding atomic changes (”Add Declaration” and ”AddClassMember”) is in conflict.

Next, for each change Ci, x registers it in its local log.However, unlike the normal logging operation describedin Sections 5.2.1 and 5.2.3, Ci is not necessarily ap-pended at the end of the local log. Instead, Ci is placedat the corresponding position in the chronological or-der. That is, Ci is placed after the last change whosetimestamp is equal-to or older than Ci timestamp, be-fore the first change whose timestamp is newer than Ci

timestamp. Besides, the pointer to the last change in thelocal log is not updated unless Ci is actually added at theend of the local log. Note that Ci is registered with itsoriginal information (e.g., author, timestamp and state)except from the link to its previous change, which mayneed to be modified after merging changes from differ-ent nodes. You can further observe that the unknownchanges can be processed in any order. However, itwould be advisable to process them in chronologicalorder, starting with the first (oldest) unknown change,in order to minimize the modifications of the previouschange information.

Hence, for each change, x performs the followingtasks: first, it determines the corresponding previouschange of Ci (PCCi ) in the local log (the last changewhose timestamp is equal-to or older than Ci times-tamp). Thus, the following situations can occur:

• PCCi = null.

• PCCi = LCOi , where LCOi is last change registeredin the local log for Oi, i.e., the change applied toOi with the newest timestamp.

• PCCi , null and PCCi , LCOi .

Second, x identifies the current next change of PCCi

(NCPCCi) in the local log (the first change whose times-

tamp is newer than Ci timestamp). Thus, the followingspecial situations can occur:

• If PCCi = null, NCPCCi= null if local log for Oi

is empty or NCPCCi= first change in the local log

(FCOi ).

• If PCCi = LCOi , NCPCCi= null.

Finally, x adds Ci in the local log between PCCi andNCPCCi

. As a result, Ci will be registered as follows:

• At the beginning of the local log if PCCi = null.

• At the end of local log if PCCi = LCOi .

• Somewhere in the middle of the local log if PCCi ,null and PCCi , LCOi .

Note that the last change in the local log is not up-dated after registering the change except when PCCi =

LCOi (the change was registered at the end of the log),or when the local log for Oi was empty.

Figure 7 illustrates the process described above. Itdepicts the logs for ontology O1 in nodes x and z beforeand after the synchronization. In the figure, the timewhen the change was originally applied is denoted by t-i; a change with timestamp t-i was applied after a changewith timestamp t-j if j < i. As we can see in Figure 7(a),before the synchronization, node x has five changes,while node z has seven changes. When x contacts z,the synchronization process calculates the difference be-tween the remote log and the local log. In this example,five changes in z are unknown by x and, consequently, xretrieves them from z. Assuming none of these changesis conflicting, then, each of them is registered in the lo-cal log at the corresponding position in the chronologi-cal order. In Figure 7(b), after the synchronization, thelog in x has ten changes. This example illustrates thethree possible scenarios described above, i.e., changesplaced at the beginning, at the end, or somewhere in themiddle of the local log. Finally, note that before the syn-chronization, both x and z knew about changes C-e andC-f. For instance, these two changes were originally ap-plied in a third node, and both x and z have previouslysynchronized with this node.

13

Node x Node z O1

LogO1Log

C-i: Change it-j: Time Stamp j; t-j<t-k if j<k

LC

LC

LC: Last Change

C-a t-1C-b t-2C-e t-5C-f t-6C-m t-10C-n t-11C-w t-20

C-k t-8C-r t-15C-s t-16

C-e t-5C-f t-6

(a) Before synchronization.

Node x Node z O1

LogO1Log

LC

LC

C-a t-1C-b t-2

C-a t-1C-b t-2C-e t-5C-f t-6

C-e t-5C-f t-6

C-k t-8C-m t-10C-n t-11

C-m t-10C-n t-11

C-r t-15C-s t-16C-w t-20

C-w t-20

C-i: Change it-j: Time Stamp j; t-j<t-k if j<kLC: Last Change

(b) After synchronization.

Figure 7: Illustration of the Synchronization Process.Logs for ontology O1 in nodes x and z before and aftersynchronization, if changes are not conflicting.

The mechanisms for the identification and resolutionof conflicts are out of the scope of this paper. How-ever, our strategy allows minimizing conflicts by run-ning the synchronization process periodically in an au-tomatic manner. Besides, the complete description ofchanges kept in the logs can be used in conflict resolu-tion mechanisms to detect conflicts or to propose res-olution strategies (e.g., based on the timestamp of theconflicting changes). We refer the reader to [41] for adiscussion on how to deal with some potential conflicts.

The following observations can be drawn: first, notethat for this process it is essential to have the appropriatesupport to retrieve only the required changes instead ofthe complete list in order to make the process as efficientas possible.

Second, the registration of each change must be pro-cessed in a serialized manner. For instance, if a localnode applies a new change while registering a changefrom a remote node, the new change will be queued forlater processing.

Third, the periodicity of the synchronization processmust be configurable. Imagine, for instance, a situa-tion where an ontology editor does not want to update(for some reason) his local copy of the ontology with

changes from other nodes. Having the possibility toconfigure the periodicity of the process and even to stopit, if necessary, would solve this problem.

Fourth, if for some reason the timestamps of thechanges are not available, the following additionalconsiderations are needed: the local node has to processthe unknown changes in order, starting with the first(oldest) unknown change. Additionally, each changehas to be placed in the same location as in the remotelog. That is, after the addition of Ci, the previouschange of Ci will be the same in the local log as inthe remote log (PCCi = the original value of the objectproperty hasPreviousChange of Ci). The reason isthat, due to the distributed nature of the environmentconsidered, nodes can synchronize with other nodesin a totally unpredictable manner, i.e., nodes contactother nodes in different order and nodes can leave orenter the network. As a consequence, when a localnode contacts a remote node, its local log could havesome information not available in the remote log, someinformation also available in the remote log, and somemissing information from the remote log. Hence, afterthe synchronization, the local log can have changes ina different order, but it will have all the changes of theremote node.

Finally, we propose an optional push mechanismduring the synchronization process in which nodespush (periodically) their changes to a specific node inthe network so that if the node goes offline before othernodes pull the new changes, the node changes are notlost or unavailable during the node down time. Notethat the longer changes from one node are unavailable,the higher the probability of conflicts with changes inother nodes. Hence, pushing changes to a particularnode will minimize those problems. The process forpushing changes is the same as the one described forthe pull mechanism, except that the roles of the nodesare inverted: the push (remote) node is treated as thelocal node, and the local node is treated as the remotenode in the process described.

Notice that the strategies described above deal onlywith the propagation of changes in the domain ontol-ogy, that is, for individuals of the change ontology. Thepropagation of workflow ontology individuals is doneby retrieving and processing the list of workflow actionsin chronological order from the remote node, applyinglocally those actions that are not present in the localnode. Applying those actions involves creating and stor-ing the appropriate individuals of the workflow ontol-ogy and performing all the consequences of an action,

14

such as changing the state of the associated changes, asdescribed in Section 4.5.

6. Technological Support for Collaborative Ontol-ogy Development in Distributed Environments

The models, methods and strategies proposed inthis work for collaborative ontology development andchange management in distributed environments havebeen implemented within the NeOn Toolkit20 by meansof a set of plugins and extensions. A high level concep-tual architectural diagram of the components involvedis shown in Figure 8.

niamoDygolotnO

egnahCygolotnO

wolfkroWygolotnO

Change Capturing

Individuals Metadata Individuals

Workflow Managment

Oyster Distributed Registry

Ontology Editor

Figure 8: Conceptual architecture for the collaborativeontology development support.

Distributed Registry. Ontologies are stored within arepository and their metadata is managed by the dis-tributed registry Oyster21 [42]. As an ontology registry,it provides services for storage, cataloguing, discovery,management, and retrieval of ontology (and related enti-ties) metadata definitions. To achieve these goals, Oys-ter implements OMV as a way to describe ontologiesand related entities, supporting the exchange and re-useof ontologies and related entities (e.g., advanced seman-tic searches of the registered objects ) and providing ser-vices to support the management and evolution of on-tologies in distributed environments.

The metadata includes information about ontologiesand users (represented using OMV core), the changes to

20http://www.neon-toolkit.org/21http://ontoware.org/projects/oyster2/

the ontology (represented using the generic change on-tology and its specializations) and about the actions per-formed (represented using the workflow ontology). Foreach change, the state is also kept to support the collabo-rative editorial workflow. Oyster implements the strate-gies described in Section 5.2. So, when a new changeis registered into an Oyster node, Oyster automaticallyupdates the log history, keeping track of the chronolog-ical order of changes. In particular, it (i) gets the lastregistered change (using the ”Log” class); (ii) adds it asthe previous change of the current one; (iii) updates the”Log” class to point to the current change.

Additionally, Oyster implements the strategies for thepropagation of changes to distributed copies of the on-tology described in Section 5.3, thus allowing the no-tification of new changes to ontology editors. Oys-ter implements the synchronization process as follows:nodes periodically contact other nodes in the network toexchange updated information (pull changes) and, op-tionally, they can push their changes to a specific node(called the push node) so that if a node goes offlinebefore all other nodes pull the new changes, the nodechanges are not lost.

Change Capturing Components. Once the ontology ed-itor specifies that he wants to monitor an ontology,changes are automatically captured from the ontologyeditor by a change capturing plugin. This plugin imple-ments the methods and strategies presented in Section5.2 for the capturing of ontology changes and the main-tenance of different ontology versions.

This plugin is also in charge of applying changes re-ceived from other clients to the same ontology afterOyster synchronizes the changes in the distributed en-vironment (see previous subsection). Finally, this plu-gin extends the NeOn Toolkit with a view to display thehistory of ontology changes.

Workflow Management and Enactment Component. Inour implementation, this component implements thestrategies described in Section 4.5. It (i) takes care ofenforcing the constraints imposed by the collaborativeeditorial workflow, (ii) creates the appropriate action in-dividuals of the workflow ontology and (iii) registersthem into the distributed registry ensuring a transac-tional support.

Ontology Editing and Visualization Components. Tosupport the workflow activities we rely on the NeOnToolkit, which comes with an ontology editor that al-lows the editing of ontology elements. Additionally, theNeOn Toolkit is extended with a set of views that allow

15

editors (i) to visualize the appropriate information ofontologies developed following a collaborative editorialworkflow and (ii) to perform (as described in 4.3) theapplicable workflow actions (approve, reject, etc.),depending on their role. There are four views22: Draftview, Approved view, To Be Approved view and To Bedeleted View. Each view is organized in two verticalpanes. The top pane displays the list of changes in thelog along with their most relevant information, suchas the URI of the modified ontology, type of change,related entity, author, date and time, the status and lastaction (according to the workflow) associated to thechange. The bottom pane shows all the details of thechanges selected in the top pane, that is, a serializationof the change ontology individuals. Additionally, eachview provides different buttons that allow ontologyeditors to perform the applicable workflow actions(e.g., send to be approved and reject to draft). Figure 9illustrates the draft view.

For a detailed description on how our framework canbe configured to support the scenarios identified in Sec-tion 4.1, we refer the reader to [6].

7. Evaluation Experiment

We have conducted an experiment in a real life sce-nario at the Food and Agricultural Organization (FAO)for evaluating the usability and performance of our con-tributions. Besides, our conceptual models have beenevaluated using specific criteria such as applicability,completeness or adequacy. Because of space constraintswe present here only an overview of the experiment con-ducted, and in Section 8 we discuss some of the rele-vant results of the performed evaluation. For a com-plete description of the evaluations conducted we referthe reader to [6].

Following the phases considered in most softwareexperimentation approaches ([43], [44], [45]), the ex-periment was performed in three consecutive phases.First, during the plan phase, the definition and designof the experiment was described, including the motiva-tion, constraints, goals, beneficiaries and the experimentsubject as well as the relevant characteristics, metricsand criteria, the data collection and analysis processes.Then, during the experiment phase, the execution ofthe experiment was described, including the particularconfiguration of the collaborative infrastructure and the

22Subject experts can see the first two views while validators cansee the last three.

software used as well as the description of the users in-volved, the activities they had to carry out and the timeneeded for the overall experiment. Finally, during theanalysis phase, the experiment results were analyzed.

Table 1 summarizes the characteristics evaluated dur-ing the experiment along with the applied metrics andcriteria. Note that for measuring the user satisfaction,we used as basis the Software Usability MeasurementInventory23 (SUMI) which is a rigorously tested andproven method of measuring software quality from theend users point of view [46].

Table 1: Metrics and criteria for characteristics evalu-ated in experiment

Metric CriteriaAdequacy ofthe changerepresenta-tion model

From a set of typical changes performed byontology editors, to verify that each changecould be represented by our model and thatit captured all the information required bythe ontology editors.

Adequacyof the work-flow model

To analyze if ontology editors were able toperform all of the required workflow ac-tions and that each action could be repre-sented with our model capturing all the in-formation required by the ontology editors.

Effectivenessof the sys-tem

From a set of tasks performed by ontologyeditors, to analyze the percentage of taskscompleted, the ratio of successes to failuresand the number of features or commandsused.

Efficiency ofthe system

From a set of tasks performed by ontologyeditors, to analyze the time to complete atask, the time to learn how to use the sys-tem, the percentage or number of errorsand the frequency of help or documentationuse.

User satis-faction

Measure software quality from the endusers point of view, including the fiveSUMI dimensions (efficiency, affect, help-fulness, control and learnability) and thecollaborative ontology development pro-cess perception.

In summary, a team of three representative ontologyeditors, each playing one of two roles (subject expert,validator), worked collaboratively on the maintenanceof the species ontology schema, one of the most fre-quently used fishery ontologies at FAO24. FollowingFAO priorities and time constraints, the infrastructure

23http://sumi.ucc.ie/index.html24http://aims.fao.org/website/Ontologies-/sub2#

species

16

Figure 9: Draft View in the NeOn Toolkit. The view (right pane of the window) illustrates the collaboration of threeontology editors (2 subject experts and 1 validator). The top pane of the view shows the list of changes in the log,whereas the bottom pane shows the details of the selected changes.

was configured as the scenario A described in Section4.1. In particular, the configuration consisted of threeclients, each running the NeOn Toolkit extended withthe registry (Oyster), change management and collabo-ration plugins, and one server running Oyster (in servermode) and the NeOn collaboration server. The latter issoftware component that allows distributed users (run-ning the NeOn toolkit) to remotely access, browse andedit concurrently a centralized copy of an ontology.

After a brief introduction to the system (30 min), ed-itors followed a detailed and personalized guide of thetasks they had to perform. In a nutshell, each subjectexpert (SE) had to perform 6 main tasks while the val-idator (V) had to perform 3 main tasks, as follows:

• Every ontology editor was requested to configureand start the collaboration support within his NeOntoolkit (T1).

• Next, each subject expert was requested to make

several changes to the ontology concurrently(SE’s-T2). The chosen changes were 34 (17changes for each SE) realistic modifications to theontology including real information that were de-fined in collaboration with FAO experts. Examplesof those changes are:

– To add Individual 31005-10001 (Species).– To add Individual 31005-10000 DataProperty

hasCodeAlpha3 value: DCR. Type: string.– To add Individual 31005-10001 DataProperty

hasNameScientific value: Pterodroma wrongmacroptera. Type: string.

– To add Root Class Speciation.– To add ObjectProperty hasScientific-

NameAuthor.

• Then, subject experts had to visualize the results oftheir changes and analyze the information providedby the system (SE’s-T3).

17

• Next, subject experts were requested to submittheir changes to be approved (SE’s-T4).

• Then, the validator was requested to analyze thechanges performed and to approve some of themand reject the rest (V-T2).

• The subject experts were then requested to performsome additional actions according to the workflowto test the possible subject expert actions (e.g.,delete a rejected change and modify an approvedchange) (SE’s-T5 and T6).

• Finally, the validator was also requested to performsome additional actions in order to test the possi-ble validator actions (e.g., reject to be approved achange and delete an approved change) (V-T3).

During the experiment the tester was taking note ofthe behavior of the editors, their questions and prob-lems, and at the end of the experiment, each editor ful-filled an online survey consisting of 60 questions (50 ofthe standard SUMI questionnaire and 10 specific for thecollaborative ontology development)25.

8. Evaluation Summary and Discussion

As a general conclusion we can say that the results ofthe experiment were positive. In particular, they showedthat:

• Our models (change representation, workflowmodel) are adequate with respect to the ontologyeditors needs. That is, representative changes andworkflow operations from our use case could becaptured and represented correctly by our modelsalong with their required information.

• The overall system effectiveness was positive. On-tology editors completed 64 out of the 68 specifictasks (94%) that were grouped in the 15 main tasksintroduced in Section 7. However, the log showedthat some editors performed other additional tasks(i.e., they added 13 additional changes) that werenot in the guide. Additionally, there was a 90%rate of changes logged correctly (3 out of the 30changes created from the guide were logged twicedue to a limitation in the NeOn collaboration server

25Online survey at http://www.oeg-upm.net/files/

UsabilitySurvey/survey.htm. Guides, setup files and re-sults of the experiment available at http://www.oeg-upm.net/

files/material/experimentData.zip

- see [6]). Moreover, we obtained a 100% rateof success of the workflow management and en-actment functionality, that is, for each of the 73actions completed from the guide (SE1 performed17 implicit actions and 20 explicit ones, SE2 per-formed 13 implicit actions and 16 explicit ones andV1 performed 7 explicit actions), the workflow ac-tion was correctly created, represented and regis-tered and it had the expected consequences. Fi-nally, 90% (18 out of 20) of the features of the in-frastructure were tested during the experiment (asa result of the scenario setup). These numbers pro-vide positive evidence with respect to the effective-ness of the infrastructure.

• The efficiency of the system was in general satis-factory. A positive point is that the time users re-quired to complete their tasks was better than withtheir previous approach (see results of question 1of the part of the survey specific to collaborativeontology development in [6]), providing positiveevidence with respect to the efficiency of the in-frastructure. Regarding the frequency of help use,users asked regularly for assistance during the ex-periment. This is reasonable taking into accountthat they had only a brief introduction to the col-laborative infrastructure (and the experiment) (30min), in addition to the fact that they did not usethe NeOn toolkit frequently. Moreover, after usingthe system for some minutes, users learned how touse most of the system features.

Moreover, the results of the survey to measure usersatisfaction showed that users were in general satisfiedwith the infrastructure and generally agreed on its use-fulness and correctness. However, even though the re-sults of the experiment provide an indication of the realvalue and practical usability of the models, methods andstrategies proposed in this work, additional experimentswith more users will be needed to draw full conclusions.

Ontology editors liked the main features of the sys-tem (e.g., the integrated view of the workflow and themanagement of changes in a collaborative environment)as we can see from the feedback received in the textualanswers. For example, some textual answers regardingthe best features are: ”Seeing changes of others”, ”Aunified view of everything happening in the workflow”,”Great capability and real time update”.

The overall results for each of the five SUMI dimen-sions have a similar pattern. In each case, only aroundone fourth (7 out of 30) of the total answers were neg-ative, another fourth (approximately 8 out 30) were un-

18

decided and at least half of the answers (15 out of 30)were always positive.

Nevertheless, during the experiment and as part ofthe analysis of the results, we also learned importantlessons. For instance, we found out that sometimesusers were interested to see only specific changes (e.g.,from specific users and from a specific type), in specificorder, or grouped by some criteria, instead of havingthe complete history of changes in chronological order(as it is at this moment). Related to this issue is that ofthe granularity of changes: The change log captures thechanges as performed in the ontology editor, where a setof multiple changes may reflect a change that – on thelevel of the user intent – should be a single compositechange. Such aggregation or grouping into compositechanges is currently not possible in our implementation.Another interesting observation is that users wanted tohave a quick view of the changes related to a specificontology element instead of having again a complete listof changes. From these (and other) observations we gotsome recommendations on how to improve our infras-tructure, specifically at the GUI level. First we shouldimprove our views with additional features such as sort-ing, grouping, filtering, and aggregating. Second, weshould also add new user-friendly features to our inter-faces, such as the ability to select several changes inone click or refreshing automatically the views whenopening them. Finally, we should provide a tighter linkbetween the ontology navigator and the information dis-played in our views.

9. Conclusions

In this work we have presented our solution to sup-port collaborative ontology development based on themanagement of ontology changes in distributed envi-ronments.

For our contribution to collaborative ontology de-velopment, first, we address different collaborative sce-narios, typical in an organizational setting, where themanagement of the ontology and its related changes canbe centralized, distributed or a hybrid between both ofthem. So, unlike existing approaches that support only acentralized management, we provide novel strategies toaddress scenarios in which distributed ontology editorscan work with a local copy of the ontology, while oursolution takes care of synchronizing the different copiesby means of the change propagation strategies we de-veloped.

The benefit is that we provide a more flexible solu-tion, compared to existing approaches, which can ad-dress different organizational needs and limitations. For

example, in many cases, ontology editors may not beable to have a permanent or reliable connection to acentral server to work with an ontology. Similarly,other well known problems of centralized approaches(e.g., performance, maintenance and resources) can beavoided by using a distributed control.

Second, unlike most existing approaches, we focuson the process followed by organizations for the coordi-nation of the change proposals. We propose to formal-ize this process by means of a collaborative editorialworkflow model. Further, this model was implementedin a workflow ontology by reusing knowledge modeledby OMV and our change ontology.

The benefits of having a workflow ontology is thatit allows the formal and explicit representation of theworkflow knowledge in a machine-understandable for-mat, that can be easily integrated with other models(e.g., our change representation model). In particular, itallows to represent the tight relationship that exists be-tween the workflow elements and the ontology changes.Besides, having the history of the workflow as individ-uals of an ontology allows reusing existing ontology-driven technologies for the processing of the workflowinformation (e.g., propagation mechanisms and reason-ing).

Additionally, we propose strategies for the manage-ment of the collaborative ontology development pro-cess. We identify the set of tasks that have to be carriedout, including those to enforce the constraints specifiedby the collaborative development process, and proposestrategies to deal with them.

Our contributions also include an integrated in-frastructure implemented within the NeOn Toolkit bymeans of a set of plugins and extensions that supportcollaborative ontology development. It relies on thedistributed ontology registry Oyster for the manage-ment of ontology changes in distributed environments.In contrast to existing solutions, it supports a formalcollaborative development process that coordinatesthe proposal of ontology changes and a completelydistributed control for the management of changes.

With respect to the management of changes, wehave focused on two main activities: representation andpropagation.

First, for the representation of ontology changes,we provide a layered model that consists of a genericchange ontology independent of the underlying on-tology language, which can be reused and specializedfor different ontology languages. Our model consid-ers ontology changes at the lowest level of granular-ity (the real atomic operations) instead of at the entity

19

level like other existing approaches. Since informa-tion about changes in ontologies is a type of ontologymetadata, we implemented our change ontology as anextension of OMV. Additionally, our model integratesmany of the relevant features of existing approachesfor describing ontology changes, but its novelty lies inits language-independent approach and finer granularitylevel of changes. Our contribution also includes the de-velopment of two extensions for two different ontologylanguages (OWL 2 and RDFS).

A language-independent model that can be eas-ily extended fosters its reusability and interoperabil-ity between different applications and scenarios, and afiner granularity level for the classification of ontologychanges supports a more efficient processing of changes(e.g., to implement undo and redo operations, or com-parison between ontology versions) and provides a moredetailed information of how an ontology changed aswell as the specific consequences of operations at ahigher level.

Second, we address the propagation of changes todistributed copies of the same ontology. The ben-efit of our solution is that it addresses previously un-supported scenarios for collaborative ontology develop-ment where distributed editors can work with a localcopy of the same ontology version, having a distributedcontrol of the ontology and its related changes.

Our solution also addresses complementary activi-ties required for the management of ontology changes.We propose methods and strategies for the identi-fication of ontology versions and the manipulationof changes, including their capturing (e.g., monitoring,processing and logging), storage and maintenance in adistributed ontology registry.

Our contributions also include the implementation ofthe distributed ontology registry Oyster for the manage-ment of ontology changes in distributed environments.

10. Future Work

The most important topics in the context of collabora-tive ontology development in distributed environmentsthat can extend our work are:

Configurable editorial workflows. An important fea-ture to elaborate in the future is to extend our approachfor the formalization of the collaborative developmentprocess to support any kind of collaborative editorialworkflow (configurable at run-time, making sure at ev-ery moment that the workflow constraints are not vio-lated).

Conflict Resolution. In our current work, the propaga-tion of changes to distributed ontology copies can onlyminimize conflicts by running periodically a synchro-nization process in an automatic manner. However, wedo not provide explicit mechanisms for the identifica-tion and resolution of conflicts.

Argumentation support. Another interesting aspect thatcan complement our current work is to support argu-mentation lines during the collaborative ontology devel-opment. In particular, this would be useful for the pro-posal of changes. However, instead of being just com-ments annotations to the proposed changes, it would bemore interesting to support discussions that can be rep-resented in a machine-understandable format.

Algebra of changes. Another interesting future work isto define an algebra of changes that would be usefulto represent the semantics of changes on ontologies ex-pressed in different ontology languages.

Acknowledgments Research reported in this paper was par-tially supported by the EU in the IST project NeOn (IST-2006-027595, http://www.neon-project.org/. We areindebted to FAO for their help with the evaluation and for theirinsightful feedback on the tool.

References

[1] M. Fernandez-Lopez, A. Gomez-Perez, J. Pazos-Sierra,A. Pazos-Sierra, Building a Chemical Ontology Using Methon-tology and the Ontology Design Environment, IEEE IntelligentSystems 14 (1) (1999) 37–46.

[2] S. Staab, R. Studer, H.-P. Schnurr, Y. Sure, Knowledge Pro-cesses and Ontologies, IEEE Intelligent Systems 16 (1) (2001)26–34.

[3] S. Pinto, S. Staab, Y. Sure, C. Tempich, OntoEdit Empower-ing SWAP: A Case Study in Supporting DIstributed, Loosely-controlled and evolvInG Engineering of oNTologies (DILI-GENT), in: Proceedings of the First European Semantic WebSymposium, ESWS 2004, Heraklion, Crete, Greece, 2004, pp.16–30.

[4] A. de Moor, P. D. Leenheer, R. Meersman, DOGMA-MESS: AMeaning Evolution Support System for Interorganizational On-tology Engineering, in: Proceedings of the International Con-ference on Conceptual Structures, (ICCS 2006), Aalborg, Den-mark, Springer, 2006.

[5] O. Munoz-Garcıa, A. Gomez-Perez, M. Iglesias-Sucasas,S. Kim, A Workflow for the Networked Ontologies Lifecycle. ACase Study in FAO of the UN, in: Proceedings of the CAEPIA-TTIA 2007, Springer, Spain, 2007.

[6] R. Palma, Ontology Metadata Management in DistributedEnvironments, Ph.D. thesis, Universidad Politecnica de Madrid,Spain (December 2009).URL http://www.oeg-upm.net/files/material/

dissertation-RAP-Digital.pdf

[7] C. Tempich, Ontology Engineering and Routing in DistributedKnowledge Management Applications, Ph.D. thesis, Universityof Karlsruhe (TH), Germany (2006).

20

[8] V. Komulainen, A. Valo, E. Hyvonen, A Tool for CollaborativeOntology Development for the Semantic Web, in: Proceedingsof International Conference on Dublin Core and Metadata Ap-plications (DC 2005), 2005.

[9] E. Sunagawa, K. Kozaki, Y. Kitamura, R. Mizoguchi, An En-vironment for Distributed Ontology Development Based on De-pendency Management, in: D. Fensel, K. P. Sycara, J. Mylopou-los (Eds.), International Semantic Web Conference, Vol. 2870 ofLecture Notes in Computer Science, Springer, 2003, pp. 453–468.

[10] J. Bao, V. Honavar, Collaborative Ontology Building withWiki@nt - A Multi-agent based Ontology Building Environ-ment, in: Proceedings of 3rd International Workshop on Eval-uation of Ontology-based Tools, located at the 3rd InternationalSemantic Web Conference ISWC 2004, Hiroshima, Japan,2004.

[11] S. Auer, S. Dietzold, T. Riechert, OntoWiki - A Tool for So-cial, Semantic Collaboration, in: The Semantic Web - ISWC2006, 5th International Semantic Web Conference, ISWC 2006,Springer, 2006, pp. 736–749.

[12] N. F. Noy, A. Chugh, W. Liu, M. A. Musen, A Frameworkfor Ontology Evolution in Collaborative Environments, in: I. F.Cruz, S. Decker, D. Allemang, C. Preist, D. Schwabe, P. Mika,M. Uschold, L. Aroyo (Eds.), International Semantic Web Con-ference, Vol. 4273 of Lecture Notes in Computer Science,Springer, 2006, pp. 544–558.

[13] T. Tudorache, N. Noy, Collaborative Protege, in: Workshop onSocial and Collaborative Construction of Structured Knowledge(CKC 2007) at WWW 2007, Banff, Canada, 2007.

[14] A. Sebastian, N. F. Noy, T. Tudorache, M. A. Musen, A GenericOntology for Collaborative Ontology-Development Workflows,in: A. Gangemi, J. Euzenat (Eds.), Proceedings of the 16th In-ternational Conference on Knowledge Engineering and Knowl-edge Management (EKAW 2008), Vol. 5268 of Lecture Notesin Computer Science, Springer, 2008, pp. 318–328.

[15] T. Tudorache, N. Noy, S. Tu, M. Musen, Supporting Collabora-tive Ontology Development in Protege, in: International Seman-tic Web Conference, 2008.

[16] A. Sebastian, T. Tudorache, N. F. Noy, M. A. Musen, Customiz-able Workflow Support for Collaborative Ontology Develop-ment, in: 4th International Workshop on Semantic Web EnabledSoftware Engineering (SWESE) at ISWC 2008, 2008.

[17] L. Stojanovic, Methods and Tools for Ontology Evolution, Ph.D.thesis, University of Karlsruhe (TH), Germany (August 2004).

[18] M. Klein, Change Management for Distributed Ontologies,Ph.D. thesis, Vrije Universiteit, Amsterdam) (2004).

[19] M. Klein, D. Fensel, A. Kiryakov, N. F. Noy, H. Stucken-schmidt, Versioning of Distributed Ontologies, Tech. rep., VrijeUniversiteit Amsterdam (December 2002).

[20] Y. Liang, Mini-Thesis: Enabling Active Ontology Change Man-agement within Semantic Web-based Applications, Ph.D. thesis,University of Southampton (2006).

[21] M. Klein, N. Noy, A Component-based Framework for Ontol-ogy Evolution, in: Proceedings of the IJCAI’03 Workshop: On-tologies and Distributed Systems, Acapulco, Mexico, 2003.

[22] N. F. Noy, M. C. A. Klein, Tracking Complex Changes DuringOntology Evolution, in: ISWC-2003 Poster Proceedings, Sani-bel Island, Florida, 2003.

[23] P. Haase, Y. Sure, D. Vrandecic, D3.1.1 Ontol-ogy Management and Evolution: Survey, Meth-ods and Prototypes, Tech. Rep. D3.1.1, AIFB, Uni-versity of Karlsruhe; Sekt Deliverable, available athttp://www.sekt-project.com/rd/deliverables/

wp03/sekt-d-3-1-1-IncrementalOntologyEvolution.

V1.pdf (December 2004).

[24] G. Flouris, D. Plexousakis, Handling Ontology Change:Survey and Proposal for a Future Research Direction, Tech.Rep. FORTH-ICS/TR-362, Institute of Computer Science,FORTH, available at http://www.ics.forth.gr/isl/

publications/paperlink/fgeo_TR362.pdf (September2005).

[25] D. Oliver, Change Management and Synchronization of Localand Shared Versions of a Controlled Vocabulary, Ph.D. thesis,Stanford University (2000).URL citeseer.ist.psu.edu/oliver00change.html

[26] L. Stojanovic, N. Stojanovic, S. Handschuh, Evolution of theMetadata in the Ontology-based Knowledge Management Sys-tems, in: Proceedings of the 1st German Workshop on on Expe-rience Management, GI, 2002, pp. 65–77.

[27] D. Maynard, W. Peters, M. Sabou, M. d’Aquin, Change Man-agement for Metadata Evolution, in: International Workshop onOntology Dynamics (IWOD) ESWC 2007 Workshop - 7 June -Innsbruck, 2007-06.

[28] Y. Liang, H. Alani, D. Dupplaw, N. Shadbolt, An Approach toCope with Ontology Changes for Ontology-based Applications,in: Second Advanced Knowledge Technologies DTA Sympo-sium, Aberdeen, 2006.

[29] M. Klein, Ontology Versioning and Change Detection onthe Web, in: Proceedings of the 13th International Confer-ence on Knowledge Engineering and Knowledge Management(EKAW02), Siguenza, Spain, 2002.

[30] N. Noy, S. Kunnatur, M. Klein, M. Musen, Tracking ChangesDuring Ontology Evolution, in: International Semantic WebConference, 2004.

[31] D. Rogozan, G. Paquette, Managing Ontology Changes onthe Semantic Web, in: WI ’05: Proceedings of the 2005IEEE/WIC/ACM International Conference on Web Intelligence,IEEE Computer Society, Washington, DC, USA, 2005, pp. 430–433.

[32] D. Ognyanov, A. Kiryakov, Tracking Changes in RDF(S)Repositories, in: EKAW ’02: Proceedings of the 13th Inter-national Conference on Knowledge Engineering and Knowl-edge Management. Ontologies and the Semantic Web, Springer-Verlag, London, UK, 2002, pp. 373–378.

[33] A. Gangemi, J. Lehmann, V. Presutti, M. Nissim, C. Catenacci,C-ODO: An OWL Meta-model for Collaborative Ontology De-sign, in: Workshop on Social and Collaborative Constructionof Structured Knowledge (CKC 2007) at WWW 2007, Banff,Canada, 2007.

[34] J. Hartmann, R. Palma, Y. Sure, P. Haase, M. del CarmenSuarez-Figueroa, OMV – Ontology Metadata Vocabulary, in:C. Welty (Ed.), ISWC 2005 - In Ontology Patterns for the Se-mantic Web, 2005.

[35] R. Palma, P. Haase, O. Corcho, A. Gomez-Perez, Q. Ji, AnEditorial Workflow Approach For Collaborative Ontology De-velopment, in: ASWC ’08: Proceedings of the 3rd Asian Se-mantic Web Conference on The Semantic Web, Springer-Verlag,Berlin, Heidelberg, 2008, pp. 227–241.

[36] R. Palma, P. Haase, O. Corcho, A. Gomez-Perez, Change Rep-resentation for OWL 2 Ontologies, in: Fifth International Work-shop OWL: Experiences and Directions (OWLED 2009), 2009.

[37] T. R. Gruber, A Translation Approach to Portable OntologySpecifications, Knowledge Acquisition 5 (2) (1993) 199–220.

[38] M. Klein, D. Fensel, Ontology Versioning for the Semantic Web,in: Proceedings of the International Semantic Web WorkingSymposium (SWWS’01), Stanford University, California, USA,2001.

[39] R. Palma, J. Hartmann, P. Haase, OMV - Ontology Meta-data Vocabulary for the Semantic Web, Tech. rep., Universi-dad Politecnica de Madrid, University of Karlsruhe, version 2.4.

21

Available at http://omv.ontoware.org/ (2008).[40] P. Haase, L. Stojanovic, Consistent Evolution of OWL Ontolo-

gies, in: A. Gomez-Perez, J. Euzenat (Eds.), ESWC, Vol. 3532of Lecture Notes in Computer Science, Springer, 2005, pp. 182–197.

[41] R. Palma, P. Haase, Y. Wang, M. d’Aquin, D1.3.1 Propaga-tion Models and Strategies, Tech. Rep. D1.3.1, UPM; NeOnDeliverable, available at http://www.neon-project.org/(November 2007).

[42] R. Palma, P. Haase, Oyster - Sharing and Re-using Ontologiesin a Peer-to-Peer Community, in: International Semantic WebConference, 2005, pp. 1059–1062.

[43] V. R. Basili, R. W. Selby, D. H. Hutchens, Experimentation inSoftware Engineering, IEEE Trans. Software Eng. 12 (7) (1986)733–743.

[44] S. L. Pfleeger, Experimental Design and Analysis in SoftwareEngineering - Part 2: How to Set Up and Experiment, SIGSOFTSoftw. Eng. Notes 20 (1) (1995) 22–26.

[45] B. A. Kitchenham, S. L. Pfleeger, L. M. Pickard, P. W. Jones,D. C. Hoaglin, El, J. Rosenberg, Preliminary Guidelines for Em-pirical Research in Software Engineering, Software Engineer-ing, IEEE Transactions on 28 (8) (2002) 721–734.

[46] E. P. van Veenendaal, Questionnaire Based Usability Testing, in:Proceedings of the European Software Quality Week, Brussels,1998.

22

Collaborative Ontology Development (Section 4)

Ontology Change Management in Distributed Environments

(Section 5)

Change

Representation

Model

(Section 5.1)

Change

Propagation

Strategies

(Section 5.3)

Process

Formalization

(Section 4.3, 4.4)

Change

Manipulation

Activities

(Section 5.2)

Workflow

Management

and Enactment

(Section 4.5)

Infrastructure for

Collaborative

Ontology

Development

(Section 6)

Supports