managing ontology versions with a distributed blackboard architecture ernesto compatangelo, wamberto...

Managing ontology versions with a distributed blackboard architecture

Ernesto Compatangelo, Wamberto Vasconcelos and Bruce Scharlau

AI 2004 Compatangelo, Vasconcelos and Scharlau

Overview

Versioning ContextArchitectureFrameworkRepresentationScenariosConclusions and future work


Software versioning

Concurrent versioning system (CVS) and Subversion used for software engineering compare versions line-by-line

Doesn’t work in ontologies where there are multiple ways to write the ontology

Need something else…


Context of ontology versioning

Ontology versioning supports the evolution of a

conceptualisation formally represents this evolution as a

set of transformations between ontology versions

involves recording, analysing, deriving, classifying, and combining changes between ontology versions

often occurs in a distributed environment


Why ontology versioning?

Keeping track of ontology versions is useful to evaluate the different context-

dependent consequences of changes on the knowledge repositories and

query the knowledge-based applications that use the evolving ontology

ensure that the applications using the ontology are not broken by changes


What else?

Need to keep track of more than ontology versioning information

Also need… Profiling team members

How often and how much each member contributes

Quality of contributions

Recording responsibilities – who did what

Recording justification for changes


Architecture

JavaSpaceJavaSpace

ReportsReports

NotificationNotification

Other functions

Other functions

Change

s Change

s Form

interaction Form

interaction D

istillchanges Distill

changes A

lternativeview

s

Alternativ

eviews

OntologyEditors

OntologyEditors

WebBrowsers

WebBrowsers

ReasoningTools

ReasoningTools

VisualisationTools

VisualisationTools

Agent 1Agent 1

Agent 2Agent 2

Agent nAgent n

….

Blackboard


ConcepTool Example

Local Filespace

Local Filespace


Framework: I-MOMS and OVMInferential Multiple Ontology Management

System (I-MOMS) encompasses ontology elicitation, modelling,

validation, interoperability, integration, and versioning in the semantic grid

Ontology Versioning Manifold (OVM) Evolutionary history documentation of each

concept across different ontology versions Reconstruction of each concept in the ontology

using the versioning information Enable virtual versioning hierarchy with set of

overlapping ontologies


Representation of changes

Given an ontology we want to represent the changes at the end of the editing session that end in the variant ontology version [i,1]

Result of each operation fk must be a variant ontology [i,1] of [i]

Allow for the reconstruction of development history of the ontology from course-grain to fine-grain


Versioning ScenariosRewriting rules

Creation of a concept Renaming of a concept Addition of attribute/value pair to a concept

The rewriting rules should accommodate means for user-interaction, allowing engineers to experiment with distinct combinations.

A graph may be better represention as different sequences of operations may result in the same ontology.


Example - Various paths


Conclusions and the road ahead

Ontology building demands tools that support distributed team work

Ours is a knowledge-rich approach to versioning deployed in an open, pluggable, lightweight and scalable architecture

The justifications of design and changes allows for formal reasoning about the design activity


Thanks for your time.

Any questions?


Related versioning work

There are Frameworks for versioning evolution Modelling and representing change details Specifying change operations and their

implications Developing algorithms and tools for

comparing versionsTools to do each (and some) of these, but

nothing to do all of theseNone of the others address the ‘reasoning

with and about the versioning space’ issue


Architecture FeaturesAgents

monitor the space prepare reports search for components

Ontology editors perform changes in the

versioning space and add extra knowledge

on the operations carried out

Web browsers interact with the

shared space via forms

Reasoners distill complex ontology

changes from a log of editing changes,

including structural, and lexical

differences between ontology versions

Visualisation tools allow the inspection

and retrieval of the shared space along different dimensions and in alternative formats


JavaSpaces: what are they?

JavaSpaces applications: collections of processes cooperating by exchanging objects using one or more spaces



Java implementation of space-based distributed computing

Implementation consists of: Spaces Primitive operations to allow processes to use

spaces

What is a “space”? Shared, network-accessible repository for objects

What are the operations? Means to store & exchange objects in spaces

No direct (point-to-point) communication



Processes perform simple operations to: Write objects onto space Take (remove) objects from space Read (copy) objects from space

When taking/reading objects, processes Use a simple lookup to find objects May be blocked if no such object exists (if we

want…)

In order to modify an object, processes must Remove object from space, Alter it and then Reinsert it onto space



Space-based applications require Distributed data structures and Distributed protocols

Distributed data structures: Multiple objects stored in different spaces Data structures held in a space can be

concurrently accessed and modified by different processes

Distributed protocols: Define the way processes share and modify

data structures in a coordinated way.


JavaSpaces: what are they?Distributed protocols are loosely coupled:

Senders and receivers do not need to know each other

Senders and receivers do not need to be active simultaneously

Using a shared space, we write an object with the expectation that Someone, Sometime, Somewhere

Will take the object and use it according to the distributed protocol

Designers/Programmers Define distribute protocol AND Ensure that processes follow it


JavaSpaces: key features

Spaces are shared: Network-accessible shared memories Many remote processes can interact

concurrently Space itself handles concurrent accesses

Spaces are persistent: Reliable storage for objects. Once stored in a space, an object will stay

there until a process removes it. Processes may specify a time after which the

object will be destroyed.


JavaSpaces: key features Spaces are associative:

Objects are located via associative lookups We use a template to match against objects. A template is an object with some/all of its fields set to

specific values or null (wildcard).Spaces are transactionally secure:

An operation on a space is an atomic affairSpaces allow us to exchange executable content:

When a process gets an object from a space a local copy is created;

As a local object, we can modify its public fields and invoke its methods;

We can extend the behaviour of our applications


Architecture

JavaSpaceJavaSpace

ReportsReports

NotificationNotification

Other functions

Other functions

Change

s Change

s Form

interaction Form

interaction D

istillchanges Distill

changes A

lternativeview

s

Alternativ

eviews

managing ontology versions with a distributed blackboard architecture ernesto compatangelo, wamberto...

Documents

changes slide

ontology zneed

track of ontology versions

bruce scharlau slide

scharlau versioning

evolving ontology y

variant ontology i

versioning space issue