Change operators are the building blocks of ontology evolution. Elementary, composite and complex change operators have been suggested. While lower-level change operators are useful in terms of finegranular representation of ontology changes, representing the intent of change requires higher-level change operators. Here, we focus on higherlevel composite change operators to perform an aggregated task. We introduce composite-level evolution strategies. The central role of the evolution strategies is to preserve the intent of the composite change with respect to the user's requirements and to reduce the change operational cost. Composite-level evolution strategies assist in avoiding the illegal changes or presence of illegal axioms that may generate inconsistencies during application of a composite change. We discuss few composite changes along with the defined evolution strategies as an example that allow users to control and customize the ontology evolution process.
Ontologies can support tasks ranging from capturing the conceptual knowledge,
architecture and process models/patterns to the organisation and
traceability of digital content and other information artifacts. Ontologies are essential
for knowledge sharing. In such domains, ontologies can convey useful semantic
information for content managers, ontology engineers, domain experts etc. to
understand and process. However, information systems are always subject to
change and ontology change management can pose challenges. The reason for
such changes can be the changes in the domain, the specification, the
conceptualization or any combination of them [
Many ontology evolution tasks cannot be done by a single atomic change
operation and require higher-level change operations. Based on different
perspectives, different combinations of atomic change operations can be utilized to
perform a composite task. While performing an ontology change using atomic
change operations, users can utilize different atomic-level evolution strategies
[
The paper is structured as follows: A description of our empirical study and the layered change operator framework is given in Section 2. In Section 3, we discuss higher-level composite change operators. In Section 4, we present higherlevel evolution strategies suitable for the specific composite change operations. A brief evaluation is given in Section 5. We end with related work and conclusions. 2
Layered Ontology Change Operator Framework We studied the evolution of domain ontologies empirically in order to investigate the relationships between generic and domain-specific changes and to determine common patterns of change. Based on our observation of common changes, we proposed a layered framework of change operators: – level one captures atomic changes which are elementary tasks, – level two captures aggregated changes to represent composite tasks, – level three captures domain-specific change patterns.
In this paper, we focus on level two composite change operators only. As a case
study [
Composite Ontology Change Operators Atomic level operationalisation and representation of ontology changes can only describe the addition or deletion of an ontology element. The semantics of applied change(s) are missing from such representation. Level two composite change operators fill this gap. They can be utilized to perform aggregated generic tasks and present the intent of the applied changes more explicitly. Composite change operators are identified by grouping atomic change operations of level one.
LEVEL 3
LEVEL 2 LEVEL 1
Manage Faculty
Manage Student Research Student
Registration
Add New Department .....
Merge
Split
Copy
Move .....
Integrate Class Remove Class
Context Context
Integrate Property Context
Integrate Individual Add Class
Add subclassOf
Delete Class
Delete subclassOf
Add Object Property Delete Object Property
Add Individual
Delete Individual ..... .....
Composite change operations come in two layers (Figure 1). First layer of composite change operations includes group of those atomic change operations that in general are executed together. For example, “Remove Class Context” which not only deletes a class from the hierarchy, but also deletes all its roles1. To delete a single class “faculty” in a university ontology, deleting the class from the hierarchy is not sufficient. Before we delete the class, we have to delete all axioms that contain class “faculty” as a parameter, such as deleting from the domain and the range of properties like “isSupervisorOf ” or “hasPublication” etc. In addition, we need to either delete its subclasses or link them to the parent class in order to keep the ontology consistent. If an ontology engineer wants to merge two or more classes, the operation requires operators higher than the integrate/remove class context. In such a case, composite change operations from layer two can be used. “merge classes”, “move classes” and “pull up property” are the examples of layer two composite change operations. In this paper, we primarily focus on layer two composite change operators. For simplicity, we refer them as “composite change operators” here onwards. 1 a role is an ontology axiom by which an entity (Class, Property, Individual) is attached to another entity of the domain ontology.
While atomic change operators are useful for fine-granular representation of ontology changes, representing the intent of the changes at the atomic level is not feasible. If a class x is removed from a parent y and is attached (as a subclass) to another class s, the semantics behind such change (at atomic level) only refers to a change of the class hierarchy for class x, i.e. Move class (x, y, s). However, if we represent that class s is actually a superclass of y, the semantics behind such a change will refer to a Pull up class (x, y, s) change.
There is no agreed standard set of composite change operations that one could
based on. It is obvious and also mentioned in research [
As, a composite change is a combination of different atomic level change
operations, inconsistent states may emerge during the application of a composite
change operation. In such cases, different sets of atomic change operations can
be additionally utilized, along with the change request, to achieve the
consistent state of the domain ontology. However, each solution may lead to a
distinct consistent ontology version. Here, the term consistent state not only refers
to a structural consistency but also a semantic consistency [
DoB studentId
FName
DoB studentId
Student
ResearchStudent enrolledIn
hasSupervisor Robert
Zubair FullTimeRS
PartTimeRS Change Request: Split class (ResearchStudent, (PhDStudent, MSByReasearchStudent))
Student ? enrolledIn
? hasSupervisor PhDStudent
MSByResearcgStudent ? Robert
? FullTimeRS ?
Zubair ?
PartTimeRS - Delete subclassOf (Student, ReserachStudent) - Delete class (ResearchStiudent) - Add class (PhDStudent) - Add subclassOf (Student, PhDStudent) - Add class (MSByResearchStudent) - Add subclassOf (Student, MSByResearchStudent) deleted from the class hierarchy, – the individuals of class ResearchStudent will lose their type (rdf:type), – the subclasses of ResearchStudent will become direct subclasses of owl:Thing – properties will lose their domain/range.
Leaving the individuals without a type and properties without a domain/range
has a semantic impact [
Different sets of change operations can be utilized to resolve the composite change resolution point. Each set of change operations will lead to a distinct ontology version. It would be too restrictive if we enforce one single solution for a resolution point. Such solution may fulfill requirements of one ontology engineer but not of others. A flexible mechanism is required here that allows ontology engineers to resolve the resolution points based on their requirements and needs. This can be achieved by using composite-level evolution strategies. The evolution strategies are to preserve the semantics of a composite change in such a way that domain ontology stays consistent.
To identify different sets of evolution strategies, we started by exploring the set of composite changes that can be applied to a domain ontology. Later, we inspected what structural and semantic impact each composite change may have on ontology entities and in which circumstances the domain ontology may become inconsistent. Here, we examined the involved ontology entities of the composite change and their inter- and intra-dependencies to other neighborhood ontology entities. We scrutinized the changes that may lead to the subsequent changes. Next step was to identify the resolution points. For each resolution point, we defined evolution strategies and each evolution strategy represents one possible way to resolve the (structural/semantic) consistency issue.
Split class: In the example for composite change Split class, the newly added sibling classes PhDStudent and MSByResearchStudent adopt roles from class ResearchStudent. Thus, deleted relationships (axioms) of ResearchStudent must be preserved and re-attached to the newly added classes. The question arise here how to re-attach the deleted roles? Different users may adopt different approaches to resolve this resolution point. A user can either – distribute the deleted roles of class ResearchStudent among the replacement classes, OR – re-attach the roles to one of the replacement class, OR – re-attach roles to both the replacement classes, OR – do nothing.
Here, a role can be re-attached to two or more classes using the “or” or “and” property. For example, we can re-attach the property hasPublication as domainOf(hasPublication) = PhDStudent or MSByReseachStudent, i.e. if an individual instantiate the property hasPublication, the individual is either a PhD student or a MS by research student.
Now, we present five different defined composite changes, their structural and
semantic impacts, resolution points and proposed evolution strategies to resolve
such resolution points. The list below is not exhaustive.
2 Resolution points are the branch points where application of different sets of change
operations may lead to different sets of consistent ontology versions [
type(I) = X ⇒ ¬ type(I) = C (and vice versa) Composite change may make ontology inconsistent if a predefined disjointness exists among the siblings of class C (i.e., X and C become disjoint classes in version 2). In such case, any instantiation of property P whose domain/range consists class C, by any individual of class X, is not valid anymore. If such instantiations of P exist, ontology will become inconsistent. – Evolution Strategies: – If the property P does not fit for the class C anymore, user can delete the instantiation of the property P for the individuals of C, OR – If the individuals of class X can still be individuals of C, user can delete the disjointness between the classes C and X, OR – If individuals of class X cannot be considered as individuals of class C anymore however the property P is still valid for the individuals of class C, in such case user can explicitly add class X as domain/range of the property P i.e., domainOf(P) = C or X.
Pull down class (A, B): – Structural impact: The class A is pulled down in the class hierarchy and became a child of its previous sibling class B. – Semantic impact: Individuals of class A are individuals of class B as well. – Resolution point: Given two classes A and B,
subclassOf (A, B) ⇒ ¬ disjointClasses(A, B) Domain ontology will become inconsistent if the classes A and B were disjoint to each other before the execution of the composite change. In such case, individuals of class A cannot be referred as individuals of class B. – Evolution Strategies: In order to resolve the resolution point, user may – delete the disjointness between class A and B.
Merge classes ((C1, C2), X): – Structural impact: classes C1 and C2 are replaced by one single class X. – Semantic impact: classes C1 and C2 are merged into one single class X and the relationships (axioms) of classes C1 and C2 (that had to be adopted by the class X) become un-attached. – Resolution point: The newly added class X adopts relationships from the classes C1 and C2. Thus, the deleted relationships (axioms) of classes C1 and C2 must be preserved and re-attached to the newly added class X. – Evolution Strategies: To resolve the resolution point, user can either – aggregate all the deleted roles of classes C1 and C2 to the replacement class X, OR – aggregate selected roles of classes C1 and C2 to the replacement class X. InstanceOf (defined) InstanceOf (defined) Y Y
C X I X A
I I A C1 A B
Y Resolution Point: Given concepts C1 and C2 merged into a single concept X, how to re-attach the roles of deleted concepts ? InstanceOf (Inference)
InstanceOf (Inference) I
initiates property P primitive siblings disjoint (X, Z)
Y B X I InstanceOf (defined) Y
X C1 A X
I I J B
A P Z
I
P InstanceOf (Inference) initiates property P
P
P
I C2
C InstanceOf (Inference) initiates property P InstanceOf (Inference)
A
P
InstanceOf (Inference) initiates property P
Resolution Point: Once the property P is pulled up in the concept hierarchy from concept B to A, the individual (that instantiate P) is no more (inferred) instance of subclass B. loss of knowledge ? primitive siblings disjoint (X, Z) P
Y B C2
J
P P
P X InstanceOf (defined)
Z I
InstanceOf (Inference) initiates property P
Resolution Point: Given two concepts A and B if A issubclassOfB =>¬ A is disjoint to B InstanceOf (defined) Y
A B
A I
X Resolution Point: Given a concepts X split into two concepts C1 and C2, how to re-attach the roles of deleted concept X ? primitive siblings disjoint (B, C) primitive siblings disjoint (B, C, X) Resolution Point: Given, a concept X is disjoint with concept C type(I) = X => ¬ type(I) = C (and vice versa)
primitive siblings disjoint (Y, B, A) primitive siblings disjoint (Y, B, A)
We evaluated the composite change operators along with the proposed evolution strategies based on their change operational cost. The change operational cost has been evaluated in terms of no. of step to be performed and the time required performing the specified steps. To do so, we selected split and merge composite change operations along with evolution strategies (Table 2). No. Change 1 Split class (ResearchStudent, (MSByResearchStudent, PhDResearchStudent)), Strategy: Split the Roles 2 Split class (ResearchStudent, (MSByResearchStudent, PhDResearchStudent)), Strategy: Attach to both classes 3 Split class (ResearchStudent, (MSByResearchStudent, PhDResearchStudent)), Strategy: Attach to one classes 4 Merge classes ((MSByResearchStudent, PhDResearchStudent), Research
Student), Strategy: Aggregate all roles 5 Merge classes ((MSByResearchStudent, PhDResearchStudent), Research
Student), Strategy: Aggregate selected roles
Comparison between two levels (i.e., atomic and composite) of change operations, in terms of number of required steps and the average operational time (in seconds), is given in Figure 4. The learning affects (of different users) on the performance of the operational time has been considered and omitted in our controlled experiment. Usage of evolution strategies and pattern-driven data entry 0:19 0:17 0:33 0:20
0:19 0:08 0:10 0:09 0:14 0:14 forms (for performing composite change operations) reduce the required evolution effort. For example, in case of Merge classes - Strategy 1 change operation, user need to take eight (8) steps in comparison to thirty (30) atomic change operations. The biggest difference was seen in case of Split class change operation where the selected strategy was to join the roles to both the newly added classes (change 2). The result is fairly understandable as in case of atomic change operators, user need to attach each role one after the other and hence increases the number of required steps. More the roles (to be attached), more the steps it requires. On the other hand, in case of composite change operator, user only need to select the appropriate evolution strategy and all the roles will automatically be attached to the newly added split classes. Hence, increase or decrease of roles did not have any effect on the number of required steps. 6
Representation of ontology changes using higher-level change operations was first
proposed by Stojanovic [
Evolution strategies were first proposed by Stojanovic [
Ontologies are dynamic entities and will continue to evolve. Scalability beyond manual evolution and change support is required for both stand-alone ontologies that live over very long periods of time and also ontologies used in conjunction with other information systems that themselves can trigger change. Supporting this process by automated management of change and its analysis is a solution.
Most of the ontology evolution tasks cannot be done using a single atomic change operation and thus requires combination of them. We focused on the operationalisation of ontology changes using higher-level change operators and proposed composite-level evolution strategies. These higher-level evolution strategies can deal with the semantic inconsistent states that may emerge during or after the applied composite change. As different users may construct their own composite changes, evolution strategies can be customized to resolve any resolution point. Such higher-level evolution strategies were missing in the past and need to be incorporated in any ontology editing framework. This research is supported by the Science Foundation Ireland (Grant 07/CE/I1142) as part of the Centre for Next Generation Localisation (www.cngl.ie) at Dublin City University.