Managing ontology versions with a distributed blackboard architecture

Managing ontology versions with a

distributed blackboard architecture

Ernesto Compatangelo Wamberto VasconcelosBruce Scharlau

Department of Computing Science, University of Aberdeen

Abstract

Ontology versioning deals with the management of ontology changes,including the evaluation of the consequences arising from these changes.We describe a distributed, “pluggable” blackboard architecture for man-aging different ontology versions. This allows existing environments forontology design to be naturally extended with versioning capabilities withlittle or no overhead. We also outline how some core components of ourarchitecture can be linked together, showing how this can be used tomanage ontology versions, reasoning with and about them.

1 Introduction

Ontological engineering was born with the aim of reusing of knowledge-basedsystems by building and sharing domain ontologies, which are semanticallysound specifications of domain conceptualisations [10]. Focus in this researcharea rapidly shifted from the editing and the application of single ontologiesto the different aspects of managing multiple ontologies in a distributed en-vironment [5]. Most of these aspects involve the querying, the maintenance,and the reuse of multiple ontologies in a semantic web context. Such know-ledge management tasks are accomplished by sharing, mapping, combining,and versioning a number of distributed ontologies [11].

Versioning, i.e. the ability to manage ontology changes and their con-sequences, is a critical functionality in those frameworks that deal with themanagement of multiple ontologies. In fact, versioning entails a thorough ana-lysis of the available ontologies, which is based on the changes introduced totransform one ontology version into a different one. Such analysis leads to thespecification of the evolution history of an ontology as an oriented graph ofversions. This history can be used to assess whether any two ontology versionsare based on different conceptualisations or whether they represent the sameconceptualisation, rendered using a different descriptive structure and/or lex-icon. In turn, such an assessment allows the evaluation of the effects of eachontology change on the results provided by those systems that use the ontology.

To date, ontology versioning research has given rise to different, somehowcomplementary frameworks for ontology versioning and evolution within thecontext of multi-ontology management. The ontology versioning approach forthe semantic web [5] is part of the WonderWeb 1 ontology infrastructure frame-work. It mainly focuses on ontology versions for which a history of changes isavailable. The approach also includes the OntoView versioning system [6],which can highlight changes in concepts belonging to differentiated ontologies.The ontology evolution management approach [9] is part of the Karlsruhe On-tology and Semantic Web (KAON) 2 framework. It mainly focuses on ontologyversions in which articulations between concepts can be introduced such thatthe retrieval of ontology instances is not affected once a new ontology versionreplaces an old one. The approach also includes the Ontologging system [8],which establishes semantic bridges between concepts in different ontology ver-sions. The component-based approach to ontology evolution [7] is part of theProtege 3 ontology development framework. It mainly focuses on ontology ver-sions for which a history of version is not available. The approach also includesthe Prompt system [11], which establishes alignment mappings between con-cepts in different ontology versions based on their degree of similarity. All theseframeworks at least partially focus on one or more of the following aspects:

1. Representing details of changes between ontology versions [7, 4].

2. Specifying ontology change operations and analysing the different implic-ations of these operations in diverse contexts [12, 7, 5, 14].

Although each of the different ontology versioning approaches currently un-der development separately addresses one or more of the above aspects (1) and(2), to the best of our knowledge none of them jointly addresses all of them.Therefore, we propose an architecture to jointly address the above issues. Ourproposal is built around a blackboard system where information on the designactivity is recorded. The blackboard system allows for the simultaneous accessof the versioning space by different users and tools. An important feature inour proposal concerns the ability to reason with and about the versioning space– for instance, showing when in the design of an ontology a concept appearsand what implications it has in the current version. Our declarative approachallows for alternative reasoning capabilities to be deployed. We envisage ourarchitecture being added with little or no overhead to existing ontology man-agement environments. As an immediate advantage, this allows single-userenvironments to be naturally extended to distributed, multi-user scenarios.

This paper is structured as follows. Section 2 introduces our architecture.Section 3 outlines our framework for ontology versioning. Section 4 describesour representation of changes in actual or virtual ontology versions. Section 5provides some relevant versioning scenarios. Finally, Section 6 draws somepreliminary conclusions and describes future research in this area.

1http://wonderweb.semanticweb.org/2http://kaon.semanticweb.org/3http://protege.stanford.edu/

2 A blackboard architecture for versioning

An ontology generally changes with time as part of its evolutionary lifecycle,thus giving rise to a whole range of (sometimes incompatible) actual variants 4.Handling these variants is the remit of that part of ontology management oftendenoted as ontology evolution management [9]. However, independently de-veloped ontologies can be also considered as virtual variants 5 of a hypotheticalcommon ancestor. In the broader context of multiple ontology management,these virtual variants should also fall within the scope and the remit of ontologyversioning. In fact, algorithms for establishing mappings (i) between similarelements in two independently developed ontologies and (ii) between differen-tiated elements in two versions of the same ontology are themselves variants ofa common approach to ontology comparison [11].

In theory, the creation and the modification of (each knowledge elementin) an ontology should always be formally recorded and documented as a logof changes. This would allow the reconstruction of the actual versioning his-tory. In practice, the documentation of ontology changes is often unavailable.However, it should still be possible to infer and thus to reconstruct a virtualversioning history, i.e. a series of possible sequences of changes. Unfortunately,this requires the combination of a wide range of logical deductions and heuristicinferences that detect similarities and differences in ontology variants [5, 11].A similar combination should be also used to assess the effects of changes inreplacing an ontology variant with a different one.

A way to enable the interaction between the various representation and reas-oning components needed to manage different ontology versions is that of devis-ing a versioning architecture thataccommodates the different com-ponents around a shared ontologyversioning space. The architec-ture proposed in this paper is thusbuilt around a blackboard system,which consists of a memory spaceshared by different processes orthreads. We present a diagramwith our proposed architecture inFigure 1. The shared blackboard,

Ω ΩΩ

ΩΩ Ω

1 2

4

6 7

Ontology 3

ΩΩ

ΩΩ

Ω ΩΩ Ω

1 2

3 4 5

6 7

Ontology 1

Ω4 Ω5

Ω21ΩΩ3

Ω Ω6 7

ΩOntology 2

Blackboard

ConcepTool

Agent3

Agent2

Agent1

ToolsVisualisationWeb Browser

ToolsReasoning

Figure 1: Blackboard architecture

represented as a larger central box, stores the versioning spaces of different on-tologies. Distinct users, represented by smaller boxes around the blackboard,access and update the shared memory space. Our versioning architecture im-plements the infrastructure required for the blackboard system functionalities(e.g., concurrent access, queues, priority of access, and so on) as well as forknowledge representation and reasoning.

4The term “actual variant”, (“variant” for short), is used to denote any ontology which iseither proven or reliably acknowledged to be a modification of another accessible ontology.

5The term “virtual variant”, (or “version” for short), is used to denote an ontology thatrepresents any of the (independently developed) conceptualisations of the same domain.

2.1 Architectural components

The bottom left box shows the ConcepTool intelligent management envir-onment [2] interacting with the blackboard, performing changes directly ontothe versioning space and annotating the space with extra knowledge aboutthe operations carried out. Alternatively, a Web browser (second box, bottomrow) interacts via forms with the shared space, sending requests in a particularformat – this allows users to remotely access the shared space and confers open-ness on our proposal. Reasoning tools (third box, bottom row) make use ofthe knowledge stored in the blackboard space to perform inferences. Anotheruseful class of users concern the visualisation services that allow the inspectionof the shared space along different dimensions and in alternative formats.

The “pluggability” of our architecture is realised in the following way. Ex-isting environments for ontology engineering can be augmented with a function-ality where, on saving the latest changes on a local non-shared file, a separateevent takes place. As a result of such event, a new ontology version is addedto the space with the appropriate connections forged between the new versionand an existing version. Ultimately, the file exclusively owned by users wouldbecome obsolete as the blackboard will store all of them, possibly includingadditions and changes that will benefit people other than its originators. Weaim at an implementation of our architecture in which we can offer this feature.

We also show on the right-hand side of the diagram a vertical row of boxeswith agents, i.e. autonomous and proactive pieces of software able to commu-nicate with other (software or human) agents [16]. Our architecture will bepopulated with a team of agents that continuously roam the versioning spacestored in the blackboard, carrying out checks of desirable properties (or lack ofundesirable ones) on the latest versions and preparing reports on the activitiesof teams and team members. Agents will also be used to search for particularcomponents in the versioning space, monitoring it until when they appear.

We want to investigate adequate data structures for storing the ontologyconstructs as well as means for representing knowledge on finer- and coarsegrained operations and annotations on the changes (authorship, date/time,justification, and so on). The data structures and knowledge representationformalisms should be accompanied with, respectively, algorithms for the man-agement of the data and reasoning mechanisms. The shared memory requiresmechanisms and policies for the disciplined access and update by the users.

The policies regulating the access and update of the shared memory shouldincorporate some of the practices adopted in real-life scenarios. For instance,changes introduced by junior engineers could be vetoed by a senior engineer.This would lead to provisional versions with changes subject to approval.

A Linda tuple space [1] is a realisation of a blackboard system that hasbeen incorporated into various programming languages, including Prolog andJava [3]. Our versioning system will deploy existing tuple space managementfacilities based on blackboard systems for multi-agent systems [15].

It is worth noting that our architecture is an open one: other function-alities can be added without affecting existing components. The blackboard

can be accessed simultaneously by different threads that implement arbitrarycomputational behaviours. We envisage auxiliary management services beinggradually added to our architecture, for instance, preparing summaries of teammembers’ performance (using their output stored in the blackboard), monit-oring particular versions (due to their confidentiality or complexity), creatingvisual representations of (portions of) the blackboard, and so on.

The different functionalities can be realised in many ways, using differenttechnologies and programming languages; this also confers heterogeneity to ourarchitecture. The architecture is also scalable as the blackboard can be dividedup and kept in different machines – as many as necessary – and be managed asone single knowledge repository. We also note that our proposal is lightweight inthat there is only a thin interface layer between those accessing the blackboardand the blackboard itself. The bulk of the management will be carried outbehind-the-scenes and those developing new tools and functionalities will beprovided with high-level means to access and update the blackboard.

2.2 Case Study: ConcepTool and JavaSpace

We want our architecture to enable “plug-and-play” capabilities with existingeditors and tools. We demonstrate the ease of this by allowing the ConcepToolsystem [2] to use a JavaSpace [3] to share ontology versions. We found thatwe only needed a trivial amount of code to write a project, the larger unitsof concepts organised by ConcepTool, onto the space. While this could bewritten into the core code of ConcepTool (or any other tool, for that matter)we find that the extra functionalities of a shared JavaSpace should be addedas a plug-in for other ontology editors and tools.

Saving a project onto a JavaSpace can be transparent to the user, whoworks on her project as normal. When their work is saved, then a copy of itcan be placed in the JavaSpace to be shared and monitored by the servicesrunning there. Saving onto the JavaSpace is done in addition to the standardfunctionalities of saving the work locally. We illustrate our approach with thediagram in Figure 2. In the diagram we show ConcepTool and its local file

Ontology 1

Ω4 Ω5

Ω21ΩΩ 3

Ω Ω6 7

Ω

Ontology 2

Ω ΩΩ

ΩΩ Ω

1 2

4

6

Ontology 3

ΩΩ

ΩΩ

Ω ΩΩ Ω

1 2

3 4 5

6 77

ConcepTool

Local File

Remote/local JavaSpace

Figure 2: ConcepTool and a JavaSpace Blackboard

as well as its connection to the JavaSpace. For the purposes of testing ourimplementation, we added a monitor to the JavaSpace, shown in the bottomright of the diagram. The monitor shows the interaction with the JavaSpaceas ConcepTool connects to it and sends out a project for saving.

We added an item to the menu of ConcepTool labelled “Save to JavaS-pace”. When selected the menu item makes a simple method call, shown inFigure 3. The method first writes the file to the local file system, and then

...void memProjectSaveToJavaSpace actionPerformed(ActionEvent e)

pf.saveToJavaSpace();

...public boolean saveToJavaSpace() // first make sure that a ’normal’ save has been performed to set the file name// for the project

save();try

JavaSpace space = SpaceAccessor.getSpace("JavaSpace");if (space == null) throw new Exception("=== no JavaSpace !! ===");String projectString = null;this.saveXML(JAVA SPACE PATH);projectString = new String();BufferedReader in = new BufferedReader(new FileReader(JAVA SPACE PATH));while (in.ready())

projectString = projectString + in.readLine() + "/n";

// create new ProjectInfoProjectInfo pi = new ProjectInfo(projectString, this.project.getName(), "version1");

// write to JavaSpaceSystem.out.println("Write to Space: " + pi.projectIdentifier);space.write(pi, null, Lease.FOREVER);return true; catch (Exception e) e.printStackTrace();

return saveAs();

Figure 3: Fragment of code to save ConcepTool projects onto a JavaSpace

acquires the JavaSpace and writes out a ‘ProjectInfo’ object onto the space,which can then be read and used by anyone with access to the JavaSpace.

Used this way JavaSpaces enable any standalone editor to be networked toother colleagues by adding our plug-in. There is no latency as with HTMLbased tools, or Java plug-in problems as occur with applets. Developers canstill use their preferred environment and only need to add our plug-in to takeadvantage of JavaSpace persistence and collaboration. The only requirementbeyond our plug-in is access to a JavaSpace, which can be anywhere on theInternet. Another part of our envisaged plug-in is the JavaSpace browser,which will enable developers to select an item from the JavaSpace, downloadit to their local filesystem where they can work on it, and then to save it backto the JavaSpace as a new version.

3 Versioning for ontology management

Our framework for ontology versioning encompasses a formal knowledge model,a software engineering method, and tools to support both real and virtualversioning. The adopted knowledge model should provide means to exploreand organise the space of possible ontologies, allowing engineers to annotatetheir design activities and to reason about these annotations. The softwareengineering methodology and the accompanying tool(s) should support theconstruction, the evolution and the maintenance of ontologies, creating vir-tual versioning histories whenever necessary. We thus envisage an InferentialOntology Management System (IOMS) equipped with an Ontology VersioningEnvironment (OVEN), such that:

• The OVEN should explicitly document the evolutionary history of (eachconcept in) an ontology across different ontology versions. Versioninginformation about (each concept in) an ontology (including the rationalefor its current structure and content) could be encoded using a numberof specialised “own slots” in the representation of ontological knowledge.

• The OVEN should be able to reconstruct and show the evolutionary his-tory of (each concept in) an ontology across different ontology versionsusing the available (versioning) information.

• The OVEN should be able to create a virtual versioning hierarchy outof a set of partially overlapping ontologies. In the most general case,these ontologies, for which no versioning information is available, areindependently developed from a single original ontology, their engineershaving had no contact to share or reuse design principles.

Therefore, we envisage a set of specific ontology versioning services to beprovided by the OVEN environment whereby any changes are formally re-corded, justified, and explained by their authors. In our vision, these changesshould be recorded as ontology annotations; they would thus represent a layerof knowledge about the ontology design, development and maintenance history.

For practical reasons, we will focus on domain ontologies represented usingframes (possibly in conjunction with first order logic axioms), as most applic-ation ontologies are currently expressed in this way. However, we will exploredifferent logic-based annotations to represent both concept creation or modi-fication operations and their justification or rationale. We will also investigatehow formal reasoning can be exploited to manage different ontology versions,e.g. comparing selected properties and computing the implications of the dif-ferences between these versions.

We envisage a formal framework supported by software tools where en-gineers and domain experts share their knowledge, either independently orjointly building and maintaining ontologies. For instance, starting from anexisting ontology Ω0, users can perform operations ϕ1, ϕ2, . . . , ϕn, independ-ently developing ontologies Ω1, Ω2, . . . , Ωn which are thus partially overlapping.Alternatively, starting from an existing ontology Ωi, users can perform op-

erations f1, f2, . . . , fn, jointly de-veloping distinct ontology versionsΩ[i,1], . . . , Ω[i,j]. Each operation,its associated parameters and res-ult are recorded and made avail-able for inspection by other usersand/or by other reasoning services.These parameters provide a know-ledge layer that can be used to ex-plore the design space of an onto-

Ω0

ϕ1

xxxxxxxxxϕ2

²² !!DDDD

DDDD

D

Ω1

f1

||xxxx

xxxx

xf2

²²

Ω2

f3

²²

· · ·

Ω[1,1] Ω[1,2] Ω[2,1]

Figure 4: Ontology design space

logy. This is depicted in Figure 4, where each labelled arrow represents one ofthe above kinds of transformation operations. In our formal framework, special-ised operations are defined to insert, delete, and modify ontology components,to merge ontology clusters, and so on.

The usage of a frame-based model to represent ontological knowledge providesa natural and cost-effective way of enabling annotation-based ontology version-ing services in addition to structural or lexical reasoning services. More pre-cisely, while ontological knowledge as such can be recorded in the template slotsof frames, versioning information can be recorded in the own slots of frames.As ontology reasoning only takes template slots into account, own slots can bethus used to record all sort of annotations for versioning and other purposes.In particular, each versioning-relevant operation (e.g. creation, modification)involving any concept in the ontology should be recorded in terms of:

• The structure and the content of the new concept in the ontology versiongenerated at the end of the editing session as a result of the modificationoperation.

• A pointer to the ontology version opened during the editing session inwhich that concept has been created or modified.

• A pointer to the starting concept on which the modified concept is based.This starting concept is contained in the ontology version opened duringthe editing session in which that concept has been created or modified.

In our vision, an OVEN working session is an editing session during whicheither a new ontology is created or an existing ontology is opened, altered andsaved. A new ontology version is generated as a result of an editing sessionif there is any difference between the ontology immediately after opening andimmediately before closing.

In our approach, any operation f(C,C?) : CΩi → C?Ω[i,n]

, where a concept C

in the ontology Ωi is transformed into a concept C? in the ontology Ω[i,n], can beentirely reconstructed and described by comparing the versioning information inthe specifications of C and C?. If such versioning information is not available,then a possible reconstruction must be inferred by the OVEN on the basis ofthe available non-annotated ontologies.

Our goal is akin to that of software versioning systems, that are now com-mercially or freely available for a number of languages like Java and C++ (e.g.,

the open source project [13]). However, we want to exploit the declarativenature and semantic richness of formally represented ontological knowledge,which can be manipulated in a number of different ways. For instance, wewould like to extract either those portions of the ontology that were affectedby a particular change or those portions that remained completely unaffected6.

4 Representing changes in ontologies

Given an ontology Ωi expressed using a suitable formalism and notation, wewant to represent the changes at the end of an editing session that gives riseto a variant ontology version Ω[i,1]

7. The description of such changes shouldinclude the element of Ω[i,1] resulting from each operation, the nature andthe author of the operation, the time stamp, and the rationale for such achange. These operations (generically denoted as f1, f2, . . . , fn) are functionswhose features (i.e. types and number of parameters) may vary depending ontheir nature. Parameters, however, should include reference to Ωi; moreover,the result of each fk must be a variant ontology Ω[i,1] of Ωi. For instance,an operation to create a new subclass of a class in an ontology Ωi needs asparameters the superclass to which the new subclass will be added plus anyspecific values for attributes which give rise to the subclass. It is worth notingthat some of parameters of an operation, such as the originating superclass ina new subclass are already specified by default in the concept created duringthe editing session.

The different annotated versions fully characterise the development historyof an ontology, as the sequence of modification operations can be reconstructedby comparing the available ontology variants. The same ontology can be editeddifferently by different users; as a result, the design space is explored via a treerooted on the starting ontology Ωi, whose nodes are new variant versions of Ωi.The edges connecting a node Ωi to its offspring nodes Ω[i,1],Ω[i,2], . . . , Ω[i,n] arethe editing operations fk applied to Ωi and resulting in Ω[i,1], Ω[i,2], . . . , Ω[i,n].The topology of the design space is shown Figure 4.

4.1 Granularity of changes

The granularity of the f operations is an important issue to consider. At oneend of the spectrum, there are coarsely-grained operations F that represent anediting session in its entirety, where any number of simpler editing operationsfk ∈ F have been performed. In this case, no annotations about the singleoperations fk on the individual concepts in Ωi are recorded. Conversely, an-notations on the whole ontology are recorded. These could simply be the authorof the editing operations and the date/time the new ontology version was gen-erated. Alternatively, operations can be finer-grained, in this case describingindividual editing operations performed on the ontology.

6The notion of “being affected” by a change can be given different alternative definitions.7A variant ontology version is one for which all the required versioning annotations exist.

Given an original ontology and a new version, we envisage a frameworkwhere it is possible to automatically compare them, figuring out their mutualdifferences and thus reconstructing the operations that have caused these dif-ferences. Hence, in principle we can infer the operations carried out on anontology. However, if an ontology is sufficiently complex and large this processcan be costly. Therefore, we could save the effort of inferring the changes if werequire that new ontology versions are explicitly annotated with the operationsthat generated them.

4.2 A declarative representation of the version space

A declarative representation of the version space should allow us to ex-plicitly manipulate nodes, edgesand branches. Ideally one shouldprovide the same information indifferent ways: for instance, wemight need to represent the frag-

root(∅).edge(∅, f1, Ω1). edge(∅, f2, Ω2). · · ·edge(Ω1, f3, Ω[1,1]). edge(Ω1, f4, Ω[1,2]).edge(Ω2, f1, Ω[2,1]).

Figure 5: Representation of the versioning space

ments of the explored version space in which a particular operation fk has notbeen performed. We show in Figure 5 an initial declarative presentation forthe version space depicted in Figure 4. In this case, we use Prolog constructsto define relationships between the components. We have used fact root/1 todefine the root of the version space: in our case, the Ω0 ontology. Facts edge/3state that the application of a second parameter (i.e., a function) to the firstparameter (i.e., an ontology) generates the second parameter (i.e., the newontology).

Using the above representation, we can develop tools and functionalities thatsupport users in navigating and infurther exploring the design space.For instance, we can devise a way ofreconstructing the design history ofany ontology from the design space.Figure 6 shows a fragment of Prologcode that implements such function-

history(Onto,H):-root(Root),path(Root,Onto,[],H).

path(A,A,Path,Path).path(A,B,PathSoFar,Path):-

edge(A,F,C),path(C,B,[C/F|PathSoFar],Path):-

Figure 6: Ontology design history

ality. In this fragment, predicate history/2 reconstructs, given an ontologyOnto (first argument) the design history H of this ontology (second argument),i.e., the sequence of intermediate versions and operations leading from the rootontology to Onto. Predicate history/2 builds on the usual definition of a pre-dicate path/4 which finds a path between its first argument and its secondargument, using an intermediary path (path built so far) in its third argumentand returning the final path in its fourth argument.We want to investigate alternative formalisms suitable to represent operationsfi. Although these can be safely regarded as ordinary functions, the previ-ously discussed granularity issues affect how they should be represented. Therange of allowed operations to be performed on the ontologies also influencethe formalism adopted and its representation. Time issues (when the versionbecomes available), authorship (who performs the operations, their reputation,

authority within the team, and so on), and justification (why was the operationperformed – this issue is further exploited below) may all influence our decision.

5 Versioning scenarios

Scenarios characterised either by surreptitious ontology changes or by untrace-able changes can lead to ambiguous or incomplete interpretations and unac-ceptable or inconsistent implications. Hence, they are not considered in theversioning approach proposed in this paper.

In the following, we will introduce and discuss a specific example. Wewill use simple mathematical constructs to present our example in order notto overload the discussion with technical details, avoiding early commitmentsto particular formalisms (Description logics, RDF, UML, etc.) and notations(XML, UML diagrams).

We define an ontology as the pair Ω = 〈C,R〉, where C = C1, . . . , Cn is aset of concepts Ci and R = ρ1, . . . , ρm is a set of relationships. Each conceptdefinition is of the form 〈c, 〈a0, v0〉, . . . , 〈an, vn〉〉, where c is the concept nameand 〈ai, vi〉 are pairs of attribute names ai and values vi. Each ρj ⊆ C ×C, 1 ≤j ≤ m, is a relationship among the concepts Ci. The elements of each ρj areof the form 〈C, C ′〉, where C, C ′ ∈ C are concepts in C, and the pair representsthat C is related to C ′ via ρj .

Some typical operations performed on ontologies can be formally represen-ted as rewriting rules as follows:

• Creation of a concept – a concept definition is introduced in the set Cwith an added entry in one of the relationships ρj .

〈C,R〉 c−→ 〈C ∪ C, (R− ρj) ∪ ρj ∪ 〈C, C ′〉〉

Additional constraints may be required to precisely represent the condi-tions under which the operation can be performed. For instance, C ′ ∈ C,that is, the concept with which C is newly related must already be aconcept in Ω (possibly subsuming all concepts).

• Renaming of a concept – the name of a concept may be changed and thischange must be propagated throughout the ontology.

〈C ∪ 〈c,A〉,R〉 r−→ 〈C ∪ 〈c′,A〉,R · c/c′〉

Concept C = 〈c,A〉 is renamed to C ′ = 〈c′,A〉, A being the set of attrib-ute/value pairs. The operation must replace every occurrence of c withc′ in the sets of R, denoted by R · c/c′.

• Addition of attribute/value pair to a concept – an existing concept maybe altered to accommodate an extra attribute/value pair 〈a, v〉.

〈C ∪ 〈c,A〉,R〉 a−→ 〈C ∪ 〈c,A ∪ 〈a, v〉〉,R〉

The above list is not exhaustive: it is meant to illustrate the kind of op-erations we aim to provide to annotate the versioning space. The operationsrequire user intervention, to provide the details of a concept definition, to choosethe concept to be renamed (and its new name), to choose the concept to bechanged and so on. The rewriting rules above should accommodate means foruser-interaction, allowing engineers to experiment with distinct combinations.

A more appropriate data structure to represent the exploration of the ver-sion space is a graph, as different sequences of operations may result in the sameontology. We illustrate this scenario inFigure 7 where different ontologies mayconverge depending on the operationsperformed on them. Graphs can, how-ever, be broken into trees by replicatingnodes that cause two (or more) branchesto converge.In the figure we show the operationsdefined above being used to obtain newontologies. The operations are recordedand the specific parameters provided by

Ω1

czzuuuuuuuuuu

c

²²Ω[1,1]

rvvvvvvvvv

a

²²

a

::uuuuuuuuuuΩ[1,2]

avvvvvvvvv

c

²²Ω[1,1,1]

r

;;vvvvvvvvvc // Ω[1,1,2] Ω[1,2,1]

Figure 7: Sample ontology space

the users are also incorporated to the versioning space. Convergence in a ver-sion space may suggest that although users went along different design paths,they eventually reached an agreed ontology. In our example, version Ω[1,1,2]

has been reached via three alternative design paths. Although we have shownindividual rewriting rules on our diagram, these can be gathered as a sequenceof operations performed during an editing session and only the final resultingontology is stored in the versioning space.

Our formalisation of alterations in terms of rewriting rules allows us to studyimportant versioning issues from solid theoretical underpinnings. For instance,during an editing session many operations can be later undone. In such cases,we should be able to analyse the sequence of rewrite rules applied and select theshortest subsequence that maps the original ontology onto the resulting one.

Furthermore, given two subsequences of rewrite rules applied to the sameoriginal ontology, we should be able to infer properties among different resultingontologies based on the operations carried out. For example, given two versionsΩ′ and Ω′′ stemming from the same original version and obtained via differentsequences of operations, we may want to check if Ω′ ∩ Ω′′ 6= ∅, if Ω′ ` Ω′′,or conversely, Ω′′ ` Ω′. We want to answer these questions by analysing thesequence of operations, rather then the ontologies themselves.

6 Conclusions

Ontology building is a team effort: domain experts and engineers jointly devisepartial and/or overlapping constructs that together give rise to ontologies andtaxonomies. Tools to support the engineering of ontologies must take intoaccount the inherently collaborative and distributed nature of the task.

Software engineers have long detected the evolutionary nature of softwaredevelopment, whereby bugs or limitations of initial versions once detected giverise to improved, more robust versions. The evolutionary nature of this pro-cess calls for means for recording and managing different versions of softwarecomponents. Indeed, more recent proposals of environments for ontology en-gineering have included versioning in their functionalities.

We propose an architecture for ontology versioning. Our approach, however,differs from those adopted in conventional versioning of software and ontolo-gies in that it is knowledge-rich. This would allow reasoning with and aboutthe changes performed to components of ontologies. We also want to form-ally address the issue of justification of choices and decisions of early designsand their changes, proposing mechanisms whereby engineers can interactivelydocument their activities. The justifications of design and changes allows forformal reasoning about the design activity, taking into account authorship andreputation, refutation of justification, lifespan of a version, and so on.

Our distributed architecture is built around a shared blackboard systemallowing different access policies to reflect real-life practices. Independent on-tologies can be simultaneously developed, and design histories can be trans-ferred across from one ontology to another. A set of support services such asvisualisation tools and summaries will help coping with the potential growth ofversion spaces. Our architecture is pluggable, open, lightweight and scalable.

Our approach to ontology versioning should naturally lead to an OntologyConfiguration Management (OCM) system, the equivalent of Software Config-uration Management (SCM) systems. We are investigating the adaptability ofthe functionalities of SCMs to OCMs, such as deltas (whereby only the changesare recorded and the unchanged part is reused, thus saving space), specifica-tions of ontological components and their individual versioning, and so on.

References

[1] N. Carriero and D. Gelernter. Linda in Context. Comm. of the ACM, 32(4):444–458, April 1989.

[2] E. Compatangelo and H. Meisel. ConcepTool: intelligent support tothe management of expressive knowledge. In Proc. of the 7th Int’l conf. onKnowledge-Based Intell. Information & Engineering Systems (KES’2003),volume 2773 of Lect. Notes in Artif. Intell., pages 81–88. Springer-Verlag,2003.

[3] E. Freeman, S. Hupfer, and K. Arnold. JavaSpaces: Principles, Patternsand Practice. Addison-Wesley, 1999.

[4] J. Heflin and J. Hendler. Dynamic Ontologies on the Web. In Proc. of theAmerican Association for Art’l Intell. Conf. (AAAI-2000). AAAI Press,2000.

[5] M. Klein et al. Ontology versioning and change detection on the web. InProc. of the 13th Int’l Conf. on Knowledge Engineering and KnowledgeManagement (EKAW’2002), pages 197–212. Springer-Verlag, 2002.

[6] M. Klein et al. OntoView: Comparing and versioning Ontologies. CollectedPosters of the 1st Int’l Semantic Web Conf. (ISWC’2002), 2002.

[7] M. Klein and N. F. Noy. A component-based framework for ontologyevolution. In Proc. of the IJCAI ’03 W’shop on Ontologies and DistributedSystems, 2003.

[8] A. Maedche et al. Managing Multiple Ontologies and Ontology Evolutionin Ontologging. In Proc. of the Conf. on Intelligent Information Pro-cessing, World Computer Congress 2002, pages 51–63. Kluwer AcademicPublishers, 2002.

[9] A. Maedche et al. Ontologies for enterprise knowledge management. In-telligent Systems, 18(2):26–33, 2003.

[10] R. Neches et al. Enabling technology for knowledge sharing. AI Magazine,12(3):36–56, 1991.

[11] N. F. Noy and M. A. Musen. Ontology Versioning as an Element ofan Ontology-Management Framework. Technical Report SMI-2003-0961,School of Medical Informatics, Stanford University, USA, 2003. To appearin IEEE Intelligent Systems.

[12] N. Noy and M. Klein. Ontology Evolution: Not the Same as SchemaEvolution. Knowledge and Information Systems, 6(4):428–440, 2004.

[13] D. Price. Concurrent version system, last accessed April 2004. URL http://ccvs.cvshome.org/.

[14] L. Stojanovic et al. User-driven ontology evolution management. In Proc.of the 13th Int’l Conf. on Knowledge Engineering and Knowledge Man-agement (EKAW’2002), volume 2473 of Lect. Notes in Comp. Sci., pages285–300. Springer-Verlag, 2002.

[15] W. W. Vasconcelos et al. Rapid Prototyping of Large Multi-Agent Sys-tems through Logic Programming. Annals of Mathematics and ArtificialIntelligence, 41(2–4), 2004. Special Issue on Logic-Based Agent Imple-mentation.

[16] M. Wooldridge. An Introduction to Multiagent Systems. John Wiley &Sons, 2002.