Managing ontology versions with a distributed blackboard architecture

1
Managing ontology versions with a distributed
blackboard architecture

• Ernesto Compatangelo, Wamberto Vasconcelos and
  Bruce Scharlau

2
Overview

• Versioning Context
• Architecture
• Framework
• Representation
• Scenarios
• Conclusions and future work

3
Software versioning

• Concurrent versioning system (CVS) and Subversion
  used for software engineering compare versions
  line-by-line
• Doesnt work in ontologies where there are
  multiple ways to write the ontology
• Need something else

4
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

5
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

6
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

7
Architecture
JavaSpace
Blackboard
Notification
Agent 1
Other functions
Agent 2
.
Agent n
Reports
Visualisation Tools
Ontology Editors
Web Browsers
Reasoning Tools
Distill changes
Alternative views
Form interaction
Changes
8
ConcepTool Example
Local Filespace
9
Framework I-MOMS and OVM

• Inferential 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

10
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

11
Versioning Scenarios

• Rewriting 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.

12
Example - Various paths
13
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

14
Thanks for your time.Any questions?
15
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
  versions
• Tools to do each (and some) of these, but nothing
  to do all of these
• None of the others address the reasoning with
  and about the versioning space issue

16
Architecture Features

• 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

• Agents
• 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

17
JavaSpaces what are they?

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

18
JavaSpaces what are they?

• 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

19
JavaSpaces what are they?

• 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

20
JavaSpaces what are they?

• 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.

21
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

22
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.

23
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 affair
• Spaces 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

24
Architecture
JavaSpace
Notification
Other functions
Reports
Changes
Distill changes
Alternative views
Form interaction