Databases Reference
In-Depth Information
facilities to accept/reject performed changes for curators. Besides these two plugins,
the Protege environment provides functionality for editing in a client-server mode
as well as transaction and undo support.
The
KAON
prototype (Karlsruhe Ontology and Semantic Web Tool Suite) pro-
viding a graphical user interface for incrementally editing ontologies within a
process of six phases (
Stojanovic et al. 2002
). For each change, the following
sequential phases are needed: (1) Change Capturing, (2) Change Representation,
(3) Semantics of Change, (4) Change Implementation, (5) Change Propagation, and
(6) Change Validation. The evolution process can be cyclic, i.e., after the last phase,
the process can be re-executed for further ontology changes.
In the first phase (Change Capturing), the ontology engineer decides about the
necessary ontology changes, e.g., to delete a concept. In phase 2 (Change Repre-
sentation), such change requests are translated into a formal change representation.
The approach distinguishes between elementary (simple) as well as composite
(complex) changes that can be expressed by a series of elementary ones. In total,
16 elementary changes (additions/deletions/modifications of concepts, properties,
axioms, and subclass relationships) and 12 composite changes (merging and moving
of concepts, concept duplication/extraction, etc.) are distinguished.
Phase 3 uses the formal change representation to identify potential problems
(inconsistencies) that the intended changes can introduce within the ontology. For
example, the deletion of a concept C impacts its children and instances. Different
evolution strategies can be specified to deal with such situations, e.g., one can delete
the children as well or move the children to be subconcepts of C's parent concept.
To reduce the manual effort for such decisions, different default evolution strategies
can be specified. Furthermore, the evolution strategies to resolve inconsistencies
may be automatically determined controlled by general goals such as minimizing
the number of ontology changes or keeping the ontologies flat.
The resulting changes are presented to the user for confirmation and are then
implemented in phase 4. All performed changes are logged in a version log; an
explicit versioning does not take place. The following phase 5 (Propagation) is
responsible to propagate the ontology changes to dependent applications or other
ontologies that extend the modified ontology. This approach assumes that the con-
sumers of the ontology are known and that the ontology evolution process can be
recursively applied on the dependent ontologies. The final Validation phase gives
ontology engineers the possibility to review the performed changes with the option
of undoing changes. Moreover, she can initiate further change requests by starting
another evolution cycle.
The
OntoView
system (
Klein et al. 2002
) focuses on versioning support for
RDF-based ontologies. The system is inspired by the concurrent versioning sys-
tem (CVS), which is used in collaborative software development. One of its core
functions is to structurally compare ontology versions to determine different types
of changes (representing a Diff evolution mapping). Nonlogical changes denote
changes in the label or comment of a concept. Logical definition changes may affect
the formal semantics of a concept, e.g., modifications on subClassOf, domain/range
of properties, or property restrictions. Further change types include identifier
