=Paper=
{{Paper
|id=Vol-273/paper-14
|storemode=property
|title=Distributed and Collaborative Construction of Ontologies Using Hozo
|pdfUrl=https://ceur-ws.org/Vol-273/paper_19.pdf
|volume=Vol-273
|dblpUrl=https://dblp.org/rec/conf/www/KozakiSKM07
}}
==Distributed and Collaborative Construction of Ontologies Using Hozo==
https://ceur-ws.org/Vol-273/paper_19.pdf
Distributed Construction of Ontologies Using Hozo
Kouji Kozaki Eiichi Sunagawa Yoshinobu Kitamura Riichiro Mizoguchi
The Institute of Scientific and Industrial Research (ISIR), Osaka University
8-1 Mihogaoka, Ibaraki, Osaka, 567-0047 Japan
+81-6-6879-8416
{kozaki, sunagawa, kita, miz}@ei.sanken.osaka-u.ac.jp
ABSTRACT Depended Ontology of B Ontology B Imports
This paper discusses Hozo’s functionality for supporting a concept from Ontology A
Ontology A
distributed and collaborative construction of ontologies. In a Ontology B Dependent
Ontology of A
distributed environment, each ontology is revised asynchronously Imported concept
by different developers. In such a situation, one of the key issues Another concepts
is the maintenance of consistency among inter-dependent are defined by
extending an
ontologies. In order to realize consistent distributed development imported concept
of ontologies, Hozo provides two functionalities: to manage the Ontology B
dependencies between ontologies and to keep and restore depends on A
consistencies of ontologies when they are changed. Constructs
Ontology A Constructs
Developer A Ontology B
Keywords Developer B
Figure 1. Distributed ontology development.
Ontology, Distributed development, Dependency management
dependent ontology of A. The authors call a development of
1. INTRODUCTION ontologies in such a manner distributed ontology development.
Ontology is one of the key technologies to realize Semantic Web. The distributed ontology development applies to many situations:
In the Semantic Web, ontologies are shared and reused by cooperative development, understanding the total picture of
different developers in a distributed environment. To construct conceptual hierarchy of ontologies, reusing published ontologies
large scale ontologies, it is necessary to collaborate with many and so on.
developers. Therefore, distributed and collaborative construction In the distributed ontology development, developers construct
of ontlogies is one of the most significant issues. In this paper, we multiple ontologies in cooperation among the developers. They
discuss an ontology development system named Hozo to support a can reuse published components of other ontologies if possible. It
construction of ontologies. We focus on providing a framework is a common way for ontology development to extend an existing
for distributed development. Its main features include a ontology into a target-specific ontology. However, when
dependency management of ontologies and a framework for developers construct ontologies in parallel or reuse ontology
supporting to keep consistency of ontologies. Section 2 discusses which is under construction and thus unstable, consistency among
a distributed ontology development we assume. Section 3 the ontologies is easily broken because they are revised
summarizes Hozo and flow of distributed ontology development. asynchronously without notice. Furthermore, they are possibly
The functionalities of Hozo to support such a development are updated without concerning whether other ontologies depend on
described in section 4. In Section 5, discuss some related work. them or not and how those ontologies would be influenced by
We conclude with a summary of some future works in Section 6, . their changes because authorities for maintenance of the
ontologies are separated and distributed to each developer of them.
2. DISTRIBUTED CONSTRUCTION OF Therefore, when a developer changes his/her ontology, the change
ONTOLOGY influences on dependent ontologies of it. In many cases, such a
change may cause inconsistencies among the ontologies.
We assume a situation where several ontologies are constructed
separately in a distributed environment (and sometimes in parallel For consistent development of ontologies, a system should
by different developers). In such a situation, some ontologies may manage dependencies among the ontologies and support their
import concepts (classes) defined in other ontologies, and another developers to harmonize the ontologies. Practically, the system
concept might be defined in the ontology by extending the should have at least two following functionalities:
imported concepts (see Figure 1). And then, it means the ontology
B which imports concepts from Ontology A depends on ontology 1) To manage ontologies with its dependencies on others.
A. In this paper, we call ontologies which are depended by other 2) To provide a framework to keep and restore consistencies of
ontology and those depend on others depended ontologies, and ontologies when they are changed.
dependent ontologies, respectively. In Figure 1, Ontology A is the
depended ontology of Ontology B, and Ontology B is the Based on this observation, the authors have investigated how a
change of one ontology influences on others through its
dependencies. And they have devised strategies for the change in
Copyright is held by the author/owner(s). order to keep and restore the consistency of them [1]. They have
WWW 2007, May 8--12, 2007, Banff, Canada. implemented a framework for ontology development in harmony
among depended/dependent ontologies as an extension of Hozo
(our ontology development tool) [2].
Shared Space Version Management
Tracking Information Ontology Access Control
Pane of changes (server system) Ontology which
browsing （ modifying
Manager the developer builds
Dependency Ontology which
Ontology
Editor Management the developer refers to
Upload
Upload
building
Personal Space
Download
Ontology Server Upload Download (client system)
）
Ontology/Model
Management System Clients
Reference / Install
Developer
Language
Ontology (other agents)
support
Onto Studio Model Modification Modification Modification
(a guide system for Editing Editing Editing
ontology design) Developer Developer Developer
Figure 3. A Conceptual Framework for Distributed
Figure 2. Architecture of Hozo Ontology Development.
defined in them. It implies that each developer has two kinds of
3. HOZO ontologies: ontologies which the developer builds and ontologies
3.1 Overview of Hozo which he/she refers to.
We have developed an environment for building/using ontologies, Distributed ontology development proceeds in the repetition of the
named Hozo, based on both of a fundamental consideration of an following steps;
ontological theory and a methodology of building an ontology.
The features of Hozo include 1) Supporting role representation [3, 1) A developer gets latest information on ontologies which he
4], 2) Visualization of ontologies in a well considered format, and builds or refers to from the ontology server. And he
3) Distributed development based on management of downloads them form shared space to personal space (client)
dependencies between ontologies. Hozo is composed of Ontology through an ontology manager. If it is needed, he locks
Editor, Onto-Studio (a guide system for ontology design), ontologies to avoid that someone updates those ontologies
Ontology Server and Ontology Manager (see Figure 2). The while he is editing them.
ontology editor provides a developer with a graphical interface,
2) The developer analyzes changes in the updated ontologies
through which they can browse and modify an ontology locally.
and evaluate whether the changes are influencing on
The ontology server stores and manages ontologies under access
consistency of the ontology which he is constructing with the
control and version management. The developer can access and
help of ontology manager.
browse them through the ontology manager. Furthermore, the
ontology editor of Hozo provides a user support module to 3) If the changes cause inconsistency in his ontology, the
maintain consistencies of the dependencies among ontologies, developer modifies his ontology in order to keep and restore
called Tracking Pane. Hozo’s native language is XML-based its consistency with the updated ontologies. Hozo helps this
frame language and ontologies can be exported in OWL, and modification process by suggesting possible countermeasures
RDF(S). It does not support native OWL, but it can import OWL for coping with each of the changes.
partially 1 . The latest version of Hozo is published at the URL:
http://www.hozo.jp. 4) After the modification, the developer starts editing his
ontology as he needs. While editing the ontology, he can
imports and use concepts from other ontologies which he
3.2 Flow of Distributed Ontology Development refers to. Then the dependency between his ontology and the
Figure 3 shows a skeleton of our conceptual framework for referred ontology through the imported concepts is managed
distributed ontology development. It consists of two parts in a by the ontology manager.
server-client architecture. One is a shared space, where developers
store ontologies to be opened to other developers. The other is a 5) After editing, the developer publishes his ontology by
local space, where each developer builds and modifies each uploading it to the shared space. And then, he unlocks the
ontology which he is responsible for. The developers cannot edit ontology if he allows other developers to edit it.
the ontologies stored in the shared space directly. Under access Every developer goes over this process individually and in parallel,
control and version management, they edit the personal copies of and then the whole target ontology evolves. As a result of their
ontologies locally and upload them to the shared space when developing processes the whole target ontology is constructed in
necessary. the shared space.
In the distributed ontology development, a target ontology can be We suppose another collaborative development process such as
regarded as a system of interrelated ontologies stored in the shared constructing a single ontology by many developers. Our
space. They are constructed in cooperation among the developers. distributed ontology development also can support such process in
Each developer constructs some of them under his responsibility2. the repetition of the following steps:
Then, he may refer to other ontologies and import concepts
1) The developers share a target single ontology in the shared
space. The ontology server manages versions of the ontology
1
The OWL import mechanism is under improvement. and accesses to it.
2
A same component ontology may be constructed by several 2) When a developer edits the target ontology, he locks the
developers. ontology and downloads it to his personal space.
In the ontology editor, imported concepts are represented with
different color from other concepts, and the developer cannot
modify4 them to keep consistencies of ontologies.
4.2 Harmonizing Interrelated Ontologies in
their Conceptual Dependencies
Ontologies Ontologies 4.2.1 Checking changes of depended ontologies
in a client in a server Ontology Manager shows developers which ontology has been
changed. To maintain the consistency of dependency, the
Compare and Synchronize developer should get more information on, for example, that what
ontologies in a client and a sever concepts/slots in the depended ontology have been changed and
Show information which concepts in his ontology are influenced by the changes.
of ontologies Hozo shows such information on the tracking pane and the
browsing pane of its ontology editor.
The tracking pane lists the changes in depended ontologies which
Figure 4. A snapshot of Ontology Manger. influence on his ontology (see Figure 6). Those changes are
classified in three types (deleted, modified and added), and their
3) If the ontology has been updated by another developer, he types are represented by icons. The changes are shown by nodes
analysis the changes by comparing the ontology with old with icons in tree structure, and the developer can know which
versions of it. The ontology manager supports him by concepts are influenced by the change through child nodes of the
showing the changes and its influence. nodes. By clicking a node representing a concept, the selected
4) After the analysis, the developer edits the ontology. And then, concept in the ontology is pointed in the browsing pane of
he uploads the edited ontology to shared space and unlocks it. ontology editor.
In the browsing pane (see Figure 7), the ontology is visualized in
4. DISTRIBUTED CONSTRUCTION USING network structures, and the changed concepts are represented by
same icons5 as tracking pane shows. When the developer selects a
HOZO changed concept, the concepts influenced by the change are
Here, the authors summarize how Hozo supports distributed and highlighted on the browsing pane. And then, if the change type of
collaborative construction of ontologies. the selected concept is modification, the details are shown.
4.1 Dependency Management of Ontologies 4.2.2 Modifying the ontology to keep the consistency
4.1.1 Ontology Server and Ontology Manager To keep the consistency of the ontology, Hozo suggests possible
The ontology manager (see Figure 4) acts as a bridge between the countermeasures for coping with each of the changes to the
personal space (in a client) and the shared space which the developer. These countermeasures are devised through our
ontology server provides. It carries out the following functions: investigation on conceptual dependencies of ontologies and the
change type of Import Dialog
1) To show the latest information on the ontologies such as imported concepts [1].
“updated”, “locked by another developer” and so on. Selected
In the beginning, Hozo
2) Access control to ontologies (lock and unlock) shows the developer
3) Version management of ontologies two major strategies:
to accept the change
4) To search concepts defined in other ontologies
and to reject it. The
5) Synchronize ontologies in client with ontologies in server latter implies to
Concept depended by
redefine the changed
4.1.2 Import concepts form other ontologies concept in his
selected concept
When the developer find reusable concepts defined in other ontology. For example,
ontologies which are published in the server by other developers, if the change type is Selected concept
he can import them to his ontology. The ontology manager modification of an
supports him to import the concepts through Import Dialog of the imported concept,
ontology manager (see Figure 5). The dialog shows concepts in acceptance of the
the selected ontology by tree structure based on is-a relation of change corresponds to
them, and the developer selects a concept which he wants to replace the imported
import to his ontology. And then the system finds all the concepts concept with the Figure 5. Import Dialog.
depended by the selected concept form its dependencies3, and it is
imported with them.
4
The developer can use imported concepts to define another
concept. For example, he can define sub classes of them.
5
On the browsing pane, sky blue nodes represent imported
concepts from depended ontologies. Therefore, only sky blue
3
For example, super classes of the selected concept, and concepts nodes can have the icons because the changes appear only on
which the selected concept refers to. the imported concepts in the distributed ontology development.
Depended ontology
Details of
Modification
Changed concepts
and
its type of change
Concepts
which the change Selected Concept
influences
Legends Legends
Deleted
Deleted
Depended ontology Modified
Modified
Added
Added
Concepts which the change
Figure 6. Tracking Pane. of selected concepts influences
Figure 7. Representation of changes on Browsing Pane.
modified one. And, if the change type is deletion of imported
concept, the acceptance corresponds to deletion of the concept. among ontologies and its instance models based on our framework.
The developer can apply these countermeasures by selecting it (2) Supporting native OWL without transformation of file format.
through a pop up menu on the browsing pane. After applying (3) Functionality to deal with OWL imports which refer to OWL
countermeasures, he edits his ontology for coping with the change files that are kept elsewhere. (4) Functionality for checking the
if necessary. In that case, it is helpful to him that the system shows ontology with a reasoner.
the concepts influenced by the change. Furthermore, if he needs
advanced strategies, the system shows him all countermeasures6 7. ACKNOWLEDGMENTS
with their details on a harmonizing pane. We are grateful to Mr. Mamoru Ohta for his support to implement
our system.
5. Related Works
PromptDiff includes a version-comparison algorithm and enables
users to view the differences between the versions [5]. It takes 8. REFERENCES
same approach with us, but it does not support distributed [1] E. Sunagawa, et al.: An Environment for Distributed
development discussed section 2. DILIGENT [6] and ONKI [7] Ontology Development Based on Dependency Management,
supports distributed development of ontology through shared Proc. of ISWC2003, pp. 453-468, 2003.
space for ontologies in the same way with Hozo. But they do not
[2] Kozaki K., et al.: Hozo: An Environment for Building/Using
have functionalities to suggest countermeasures for coping with
Ontologies Based on a Fundamental Consideration of "Role"
each of the changes to the developer when depended ontologies
and "Relationship", Proc. of EKAW2002, pp.213-218,
are modified. KAON and ours focus on that changes in one
Siguenza, Spain, 2002
ontology can cause inconsistencies in other dependent ontologies.
And, in order to ensure their consistencies, they propose deriving [3] Sunagawa, E., et al. :Organizing Role-concepts in Ontology
evolution strategies [8]. But it does not provides strategies which Development Environment: Hozo, Proc. of 2005 AAAI Fall
reduce the influences against the changes although Hozo suggests Symposium on Roles, an interdisciplinary perspective, 2005
them (e.g. deletion of a concept can be canceled by redefining it in [4] Kozaki K., et al.: Fundamental Consideration of Role
another ontology). The difference is caused by different treatment Concepts for Ontology Evaluation, Proc. of EON2006
of relationship between depended ontologies and dependent Edinburgh, United Kingdom, May 22, 2006
ontologies.
[5] Noy, N., et al.: Tracking Changes during Ontology Evolution,
6. CONCLUSION AND FUTURE WORK Proc. of ISWC2004, Hiroshima, Japan, pp.259-273, 2004
In this paper, the authors discussed some functionalities of Hozo
[6] Tempich, C., et al.: An Argumentation Ontology for
to support distributed ontology construction. Harmonization of
DIstributed, Loosely-controlled and evolvInG Engineering
ontology is an essential issue especially in a distributed
processes of oNTologies (DILIGENT), Proc. of ESWC2005,
development. Our system contributes to resolving the issue based
Greece, pp. 241-256, 2005
on management of dependencies between ontologies. The
functionalities can support to construct a single ontology by many [7] Valo, A., Hyvonen, E. and Komurainen, V.: A Tool for
developers collaboratively. Collaborative Ontology Development for the Semantic Web,
in: Proc. of DC 2005, Madrid, Spain, 2005.
As future work, the authors plan to enhance our system according
to the following future plan: (1) Maintenance of consistency [8] Stojanovic, L., Maedche, A., Motik, B. and Stojanovic, N.,
User-driven Ontology Evolution Management, Proc. of
6
EKAW 2002, Madrid, Spain, pp. 285-300, 2002
We have not implemented some of advanced countermeasures
yet. But, we suppose the two major strategies are enough for
coping with the change in a lot of cases.