Generic structural levels

The first two layers of change operations are generic. These layers include atomic and composite level change operations. As these change operations are generic, such change operations can be used on any specified domain ontology. Below, we discuss each layer.

Add Class Add subclassOf Delete Class Delete subclassOf Add Object Property Delete Object Property Add Individual Delete Individual ... Integrate Class Context Integrate Property Context Remove Class Context ... Integrate Individual

Merge Split Copy Move

LEVEL 1 LEVEL 2 LEVEL 3

Manage Faculty Manage Student Research Student_{Registration Department}Add New ...

Mange Person Manage

Structure ...

LEVEL 4

...

Figure 4.2: Architecture of layered change operators (university ontology) 4.2.1.1 Level one - atomic changes

Definition 4.1: Level one change operators are the atomic operators that can be used to perform a single ontology change. These operators add or remove a single axiom about a target entity in the domain ontology. A single change operator performs a single task that can add a single class, a single property or delete a single cardinality axiom, etc.

One can identify the atomic change operations based on the constituent components of the ontology. In terms of RDF triples, an atomic change can be represented using a single RDF triple. The subject and the objects of such RDF triple can be the named entities or the blank nodes (that point to other resources). An example of atomic change could be addition/deletion of a declaration axiom.

Example 4.1: Every defined class in a domain ontology is (at least) a subclass of owl:Thing. This can be accomplished using classDeclarationAxiom. However, in order to create a new class as a subclass of an existing one, implementation of such change operation alone is not sufficient. To do so, the change operations are always applied in a set where a class is declared in the ontology and added as a subclass of an existing class in the class hierarchy. For example, one can create a new class PhD Student as a subclass of Student by using two atomic level change operations (Figure 4.3):

- creating a class PhD Student using Add classDeclarationAxiom(PhD Student) and

- making PhD Student as a subclass of Student using Add subClassOfAxiom (PhD Student, Student) Student Person Student Person PhD_Student (1) (2)

Figure 4.3: Atomic level change operations

4.2.1.2 Level two - composite changes

Many evolution tasks cannot be done by a single atomic change operation. A sequence of atomic change operations, defining a generic change pattern, is required. In terms of defining a composite change operation, there are two main approaches prominent in the literature. In the first approach, a user can combine different atomic change operations in different numbers depending on the specific goal in an ontology evolution situation. Such specific goals may come with their own set of atomic change operations

and represent a “mental” operation [Klein, 2004]. Adding disjointness among the sibling classes (addDisjointness), stating that all individuals are different (allDifferent) or moving siblings (moveSiblings) are examples of such an approach. In the second approach, a composite change specifies a target entity in the form of “context” of the change and modifies (creates, removes or changes) the neighborhood of that target entity in the domain ontology [Stojanovic, 2004]. Such composite changes can be identified by looking into the neighborhood of any ontology entity. Splitting a class into two or more sibling classes (Split class), moving a property higher in the class hierarchy (Pull up property) or merging two or more classes into one (Merge classes) are examples of such an approach. In our research, we adopted the first approach as the composite change operations identified using second approach are actually a subset of the former.

Definition 4.2: We consider the composite change operations as generic change patterns that are identified by grouping atomic change operations to perform a composite task. For example “Remove Class Context” not only deletes a class from the class hierarchy, but also deletes all its roles3. To delete a single class Faculty in the university ontology, removing the class from the class hierarchy is not sufficient. Before we remove the class, we have to remove it from the domain and the range of properties like hasPublication or supervises that are attached to it. In addition, we need to either delete its subclasses (cascade delete) or attach them to the parent class. Depending on this context of an element, we use different operators from level one, resulting in a generic change pattern.

Example 4.2: In the database teaching domain, if an instructor wants to add a single chapter SQL to his/her course outline, the operator “Integrate Class Context” can be used. For example,

- create class SQL using Add classDeclarationAxiom(SQL) 3

a role is an ontology axiom by which an entity (Class, Property, Individual) is attached to another entity of the domain ontology.

- make SQL subclass of QueryLanguage using Add subClassOfAxiom (SQL, QueryLanguage)

Example 4.3: If an ontology engineer wants to merge two or more classes, the opera- tion requires operators higher than the “Integrate Class Context”. For example, if the ontology engineer wants to combine two sibling categories of students, i.e. PhD Student and MSStudent, into one single class ResearchStudent, the Merge classes composite change pattern can be used (Figure 4.4).

Merge classes((PhD Student, MSStudent), ResearchStudent): - Integrate Class Context by creating class ResearchStudent using

Add classDeclarationAxiom(ResearchStudent) and then adding a subclass re- lationship using Add subClassOfAxiom(ResearchStudent, Student)

- Add Object Property Domain by adding domain ResearchStudent to affiliatedTo using Add domainOfAxiom(affiliatedTo, ResearchStudent)

- Add Object Property Range by adding range ResearchStudent to isSupervisorOf using Add rangeOfAxiom(isSupervisorOf, ResearchStudent)

- Remove Class Context by deleting class PhD Student using Delete Class

(PhD Student) and then deleting class MSStudent using Delete Class (MSStudent)

PhD_Student

Student Student

ResearchStudent (1) (2) MSStudent

affiliatedTo isSupervisorOf affiliatedTo isSupervisorOf

(3) (4)