Ontology Recovery and Visualization. Asad Masood Khattak, Khalid Latif, Sharifullah Khan, Nabeel Ahmed. School of Electrical Engineering and Computer ...
4th International Conference on Next Generation Web Services Practices
Ontology Recovery and Visualization Asad Masood Khattak, Khalid Latif, Sharifullah Khan, Nabeel Ahmed School of Electrical Engineering and Computer Science, National University of Sciences and Technology, Rawalpindi, Pakistan {asad.masood, khalid.latif, drsharif, nabeel.ahmed}@niit.edu.pk ontology recovery, undo/redo functions, to keep ontology in consistent state, and for visualization of change effects on ontology to make ontology changes temporally traceable. Currently, no such system is available that provides facilities like, proper and complete undo and redoes operations [6], ontology recovery in case of abnormal shutdown of application (using or editing ontology), reverting to any previous state of ontology on user request, and visualization of changes and change effects on ontology. The need is to maintain all the ontology changes, to provide ontology engineer’s the facilities to recover ontology to any previous state and to visualize the change effects on ontology. Goal of this research is to build a framework for ‘Change Tracer’, which will help in automatically detecting and logging all the changes happened to ontology using Change History Ontology (CHO), triggered by the change request from ontology engineer. Our focus is to develop a plug-in for Protégé (an ontology editor), which will listen all the changes and then log these changes using CHO. After that, whenever required the Change History Log (CHL) changes will be accessed, and the plug-in will have facility to roll-back and roll-forward any changes and get the ontology in any previous consistent state. The plug-in will also provide facility, to make the ontology changes temporally traceable by providing user a facility to visualize the effects of all the changes on ontology, which happened to ontology when ontology evolved from one state to another state. This will give user a complete idea of how the ontology has evolved and reached to the current state. This remainder of the paper is arranged as follows: Section 2 is the related work. Section 3 presents our proposed framework for the plug-in, while implementation details and results are discussed in Section 4. Finally we conclude our findings in Section 5 and talk about future directions.
Abstract Change is the only constant. The way life evolves with the passage of time, the same way ontology also evolves with time. When new changes come in the domain then these changes are accommodated in ontology by evolving the ontology from one state to another state. Now all the new changes needs to be maintained for not only to provide the undo and redo facility, but also to provide the facilities like: recovering any previous state of ontology, and to visualize the change effects on ontology to make the ontology changes temporally traceable. In this paper a protégé plug-in is presented with major functionalities; maintaining all the ontology changes in Change History Log (CHL) using Change History Ontology (CHO), visualize the change effects on ontology, and reverting ontology to any previous state, and recovering ontology from an inconsistent state to a consistent state.
1. Introduction Change is the only constant. As explained in [1] ontology change management deals with the problem of deciding the modifications to perform in ontology in response to a certain need for change, as well as the implementation of these modifications and the management of their effects in depending data, ontologies, services, applications, and agents. Ontologies are formal description of shared conceptualization of a domain of discourse. Ontology evolution process deals with the growth of the ontology and capturing/accommodating new information [3, 4]. The evolution process may involve different strategies such as merging and integration but ontology evolution is fundamentally different [1]. Changes do occur in ontology and are then reflected in ontology by implementing them and evolving/upgrading the ontology as mentioned in [3, 4, 5], but the crucial task is to maintain these changes which happened to ontology for the purpose of 978-0-7695-3455-8/08 $25.00 © 2008 IEEE DOI 10.1109/NWeSP.2008.35
2. Related Work As mentioned above, ontology evolves as conceptualization of the domain changes and then 90
changes are also not in a format which can help in ontology recovery.
these changes will be reflected in ontology. Now these changes are very important for ontology and for the purpose of undo, redo, and ontology recovery, so should be maintained properly for future use. In [6] the author discussed about the change management facilities provided in Protégé. In protégé all types of changes, discussed in [9], are stored temporally in a file as a script for undo/redo operations, and when a user request for undo or redo then these are used. The same way a complete command history is also maintained in protégé. But these all are stored temporally and when the project is closed then all these changes and the command history entries are lost. Author also suggested to maintain all the changes for future use. Y. David Liang in [7] presented a concept of Log Ontology. The author developed a Log Ontology and used that ontology for logging all the changes that happened to ontology for the purpose to answer user queries transparently. The author main focus is not to update the system for the evolved ontology, but to use the Log Ontology entries for user query reformulation over the evolved ontology. Using the Log Ontology [7], the author has also eliminated the necessity of propagating all the changes to dependent artifacts, and updating the application for the new changes. In [8], author introduced their own schema for logging all the changes that has happened to ontology. Their system provides two basic facilities: Change Tracer: Here all the changes between two versions of ontology are detected through PromptDiff [10] and OntoView [11], and then all the detected changes are logged using their own format. A parser was also developed to transform the changes to own format. Change History Manager: It keeps user informed about: a) all the changes that were detected and are logged, b) inform user about the effects on ontology. M. Klein in [9], also developed change ontology for changes and stores all the changes (atomic & complex). Author main focus is distributed ontologies and the changes happened to them during evolution. The Changes tab [15] in protégé is also listing changes that happens to the opened model, and also persist those changes. It only stores the changes and present those changes in tabular view to user but do not use it for other purposes. The differences of our system from the above discussed systems are: every system discussed above, log the changes but none of the systems provides the facility for proper undo/redo operations, they do not use the log for ontology recovery, reverting ontology to previous state, and visualization of changes and change effects on ontology. The way they log these
3. Proposed Framework Here, proposed architecture for the Change Tracer with all its components is presented in detail. The aim is to develop a system having modules given in Figure 1, which in integration provides functionalities of change recovery and visualization of change effects on ontology. Our proposed system will be a plug-in that will work in integration with any ontology editing tool which support the hooks. For proof of the concept, we are developing it as a plug-in for Protégé.
3.1. Change Listener Change listener is a module that actively listen all types of changes happening to the ontology model opened in protégé and list of some changes are given in Table 1. Whenever a change is triggered, it collects complete information about the change. For listening changes, we use the action listener interfaces provided in PROTÉGÉ and PROTÉGÉOWL API’s, to name few: KnowledgeBaseListener, ClsListener, ClassListener, SlotListener, and PropertyListener. For every change their respective listener interface action is triggered and change listener capture information of that change, available in event object of method implemented in that interface.
Figure 1: System architecture for Change Tracer
3.2. Change Logger In this module, all the changes, captured in previous module, are logged using CHL with conformance to CHO.
91
Figure 2. Snapshot representing core classes of Change History Ontology (CHO) We claim that we handle all the changes at atomic level, no matter it is atomic change (e.g. deleting a single concept) or complex change (e.g. deleting a sub tree). Atomic change is simple, let’s consider the complex change. Consider the CHO given in Figure 2; if we delete Change_Agent class then it is a complex change, because it will also result in deletion of its subclasses. Protégé internally provide us the facility that when such a deletion occur, then first its leaf level classes are deleted one by one and then classes a level above leaf level are deleted and so on going to the top. So every deletion triggers its own event and we capture these changes atomically and then its information will be logged. When this module is activated then it first initializes the ontology model from CHO and logs all the changes in CHL using CHO representation.
a few extensions to Log Ontology and come up with CHO as shown in Figure 2. Some of the extensions include: 1) Capturing such provenance information as the change author, reason, timestamp. 2) We introduced a class Ontology_Change. It has further subclasses including Atomic_Change and Change_Set. The Atomic_Change tackles with all types of changes that can be applied to ontology at its class and property level, which are addition, deletion and renaming. 3) Change_Set holds information about the changes that whether it is an instant or composite and stretched change over a defined time interval. Change_Set also helps in properly maintaining the sequences of the changes applied. With Change_Set, all the changes of some defined time interval are organized and managed together, which help us to undo/redo the changes.
3.3. Change History Log
3.4.
To recover database from failure, several different techniques [14] are used, to name few: logging, checkpointing, shadowing, and differential tables. Among these, logging technique is most practical and most suited for recovery. We have adopted the logging technique of database recovery for ontology recovery. We log each and every single event related to ontology change, which later on help us in cases like abnormal shutdown, and closing model in Protégé without saving or discarding changes, to undo/redo changes and get ontology to some consistent state. Change Log is a repository that keeps track of all the changes made to ontology. It is also required for reversibility purpose when an ontology engineer want to undo or redo some of the changes then this log is accessed and changes are simply reverted. The log uses Jena based triple store and change description is provided by CHO, to preserve changes for later use. The baseline for CHO is the Log Ontology presented by Y. D. Liang [7]. We have modeled quite
Parser job is to: 1) Parses CHL for all the changeset(s) that corresponds to the open model in Protégé on user request. 2) It also produce the reverse changes of the stored ones, because, user might require to recover pervious state of ontology, then all the Class_Addition instances will be converted Class_Deletion as shown in Figure 3. The sequence of applying the changes back is also in backward order, i.e. changes in a Change_Set applied at the end will be reverted first, then second last changes and so on. Then these reverse changes are given to the reverser module which implements these changes.
Parser
3.5. Recovery Recovery module is responsible for implementing the applied changes on model opened in Protégé, in forward and reverse manner, based on user request. When user request to undo/redo any changes or request for recovering previous consistent state of
92
Table 1: Representing types of changes Change in Hierarchy
Change in Classes
Change in Properties
x
Adding a class or property
x
Changing label, comment or cardinality of a class
x
Renaming a property
x
Removing
x
Removing parent class
x
Changing the domain
x
Adding a child class
x
Changing the range
x
Removing a child class
x
Changing the sub-property reference
x
Adding a property to a class
x
Changing label or comment
x
Removing a property from a class
a
class
or
property x
Merging
two
or
more
classes or properties
x
Splitting a class/property into two or more classes
module will first request the recovery module to revert the current state of ontology to its previous state with the help of corresponding Change_Set changes. The recovery module request parser to extract the required Change_Set with complete changes and produce its reverse changes. The result of the parser is implemented by the recovery module, which revert ontology to its previous state and return that state to visualization module, which then visualizes it. The same way if user keeps on requesting, then the same steps are followed. If, at some previous state of ontology, user wants to shift to its next state, rather than previous, then the steps will be same but the parser will not generate the reverse changes, as by implementing the next logged Change_Set changes will get ontology to next state. The next and previous state navigation facility is also visible in Figure 6.
ontology, then this module is activated. For any of the above requests, this module makes request to parser module to retrieve the required Change_Set entry and all its corresponding changes. Parser then make reverse changes of all those. When parser returns the reverse changes of the corresponding logged Change_Set, then recovery module implements it on the opened model. default:Class_Addition_1 a default:Class_Addition; A default:hasChangeTarget ; default:isSubClassOf http://www.niit.edu.pk/Documentation.owl#Documentation: default:isPartOf default:Change_Set_1 .
----------------------------------------------------------------------default:Class_Deletion_1 B a default:Class_Deletion; default:hasChangeTarget ; default:isSubClassOf http://www.niit.edu.pk/Documentation.owl#Documentation>; default:isPartOf default:Change_Set_1 .
4. Implementation and Results
Figure 3: Using N3 notations, (A) shows the change log entry for Class_Addition change, while (B) shows the parsed listing of (A) for reverting the change.
For the purpose of validating our claims, we envision our proposed framework as an enabling component for the ontology editors. In itself it doesn’t provide ontology editing services. The framework architecture is designed to be implemented as a plug-in for different ontology editors. Different tasks, related to change history management, are delegated to individual components in the framework. Change Logger component, for example, is responsible to preserve the changes and the visualization component on top of all other components should provide visualization services to navigate through the changes. The component based framework architecture is depicted in Figure 1. For the purpose of validating the working of the proposed framework, we have developed a TabWidget plug-in, Change Tracer Tab, for Protégé ontology editor, where procedure for plug-in development can be found in [16]. As discussed above, there are five main tasks to enable ontology recovery and visualization of change
3.6. Visualization Visualization module is responsible for visualizing the ontology, ontology changes, and the change effects on ontology. The visualization is in graph like structure rather then tree like structure, because the ontology with class and subclass hierarchy can also have associative relationships with other classes [9]. Jobs of this module are: 1) A user can request for visualization of the changes in change log, then these changes are simply parsed and passed to visualization module by the parser without performing any revert operations. On receipt, these changes are visualized. 2) The visualization module also visualizes the current loaded model in Protégé to the user on request. 3) If user wants to visualize the history of ontology evolution process, then visualization 93
Table 2: List of Change Listeners Implemented in the Change Tracer Plug-In. Change Listener ProjectListener
KnowledgeBaseListener
ClsListener
ClassListener
SlotListener PropertyListener
FacetListener InstanceListener
Description It listens all the project related events: like saving, closing, form changed, and runtime class widget created. Helps in listening changes related to the model. It overlaps in its provided methods with all the listeners listed below. Helps in capturing the class, subclass, and super-class level changes. Similar to ClsListener, it helps in capturing the class, sub-class, and super-class level changes. Helps in capturing the slot, subslot, and super-slot level changes. Helps in capturing the clas property, subproperty, and superproperty level changes. It helps in capturing the changes, such as restrictions, on frames. It helps in capturing changes related instances and individuals.
Figure 4: Code for logging sub class deletion information
effects on ontology and their implementation details are given below. Change listener is a module that actively listen different types of changes in the ontology model. Whenever a change is triggered, it invokes an appropriate change listener to collect complete information about the change. In order to listen and to log ontology changes loaded in Protégé, we used Jena and Protégé OWL API’s. The plug-in was developed using NetBeans 6.0 IDE. With the help of these API’s and their provided interfaces, we have been able to listen and identify an extensive list of change events (see Table 2). Each change triggers its respective listeners and sends the relevant information about the change in the event object. Then using Jena API, we saved all these changes in the CHL by confirming to CHO. Captured changes are stored in the Change History Log after structuring them based on Change History Ontology. On a request from the visualization or recovery component, the CHL is parsed to get different states or version of the ontology. We also claim that we handle and log all the changes at atomic level; no matter it is atomic change (e.g. deleting a single concept) or complex change (e.g. deleting a sub tree). Atomic change is simple, lets consider the complex change. Consider the CHO given in Figure 2; if we delete Change_Agent class then it is a complex change, because it will also result in deletion of its subclasses i.e. Change_Person and Change_Software. Protégé architecture internally provides the facility that when such a deletion occur, then first its leaf level classes are deleted one by one
and then classes a level above leaf level are deleted and so on going to the top. For this deletion request, the deletion steps internally are: first Change_Software class is deleted and it triggers the event directSubclassRemoved(ClsEvent e) of ClsListener interface, so its information will be logged, secondly Change_Person class will be deleted and will also trigger the same event, at last, Change_Agent class will be deleted and will trigger event clsDeleted(KnowledgeBaseEvent e) of knowledgeBaseListener interface and its information will be logged. When the change logger module is activated then it first initializes the ontology model from CHO and logs all the changes in CHL using CHO representation, where code for logging information about sub class deletion is shown in Figure 4, and information about logged changes is shown in Figure 5, when their respective Change_Set instance is selected. For undo/redo, the recovery module is activated, which takes the Change_Set and its corresponding reverse change entries from parser and implement these changes on ontology in reverse order to get previous state of ontology. We know that, when changes are implemented to ontology then it might cause inconsistencies in ontology [12], so to get ontology back in consistent state some extra (deduced) changes are also made to ontology. But for recovery we do not need to check the ontology consistency, nor will ontology go into an inconsistent
94
recovery module to take ontology to a previous or next state. We have extended the TouchGraph API for graph drawing in order to visualize the graph view of the ontology structure. Resources, such as classes, are depicted as nodes. These nodes are connected through properties which are depicted as the edges in the visualization. The direction of the edge depicts the direction of the relationship among the nodes. Though it is out of scope of this paper, but it is worth mentioning that a number of filters are supported in the graph view such as zooming in and out of the graph and fish-eye view. A modified version of the Spring graph drawing algorithm is implemented in the visualization that ensures esthetically good looking graph structured and well separated nodes. We have provided the playback feature where not only the ontology but the changes could also be navigated and the trend could be analyzed (c.f. Figure 6). Starting from the very fist version of the ontology, the user can play the ontology changes. The changing concepts are highlighted and color coded to reflect the changes. For example, the deleted concepts fade out and the new additions gradually appear in the graph.
Figure 5: Tabular view of change sets and atomic changes in the ontology.
state, because the recovery module only implement back the logged changes in reverse order, which were stored at ontology evolution time from ontology engineer request, and were considered consistent. The changes are now stored in CHL. Parser, on request from visualization or recovery, parses the CHL and make the reverse changes of all these, where its sample is given in Figure 3. Ontology recovery module is responsible for implementing the applied changes on the ontology model, in forward and reverse manner, depending on the user context. The process is executed in forward manner when user has requested to redo the changes. While for reverse implementation, the complete set of inverse changes are applied in descending order of their timestamp value. To revert the changes back on the ontology, the changes are converted to their inverse changes, such as: Class_Addition instances are reversed to Class_Deletion, and Range_Addition instances are converted to Range_Deletion. These inverse changes are then applied to the ontology and ontology recovery is achieved. For reverting changes for recovery, the parser job is to parse the Change History Log for all the change sets corresponding to the currently loaded model in descending order of their timestamp value. This order is also followed for implementing back these inverse changes to revert the ontology to previous state. Visualization module visualizes the components in the ontology (such as concepts and their relationships) as well as the changes made in the ontology. Effects of these changes, for example how it evolved to the current state, are emitted by navigating through the life of ontology. In order to visualize changes, the ontology change parser processes the requested change sets and their corresponding changes. The changes are reverted or implemented in the ontology with the help of
Figure 6: Graph visualization of ontology with history playback feature. Users can visually navigate through the change sets and atomic changes.
5. Conclusions and Future Work Ontology evolution and change management are relatively new areas of research. Most of the existing research work conducted in this field has incorporated ideas from other related fields such as database recovery, ontology merging, and integration. In this paper we presented a framework for tracing ontology changes. The backbone of the system is the Change History Ontology, which acts as a glue to bind different components in the framework and to guarantee effective recovery and proper 95
12. P. Haase, Y. Sure. “State of the Art on Ontology Evolution”, D3.1.1.b, SEKT Project: Semantically Enabled Knowledge Technologies, August 2004. 13. J. R. Hobbs, and F. Pan, “An Ontology of Time for the Semantic Web”. ACM Transactions on Asian Language Processing (TALIP) vol. 3, No. 1, pp. 66-85, 2004. 14. Ramez Elmasri, and Shamkant B. Navathe, “Fundamentals of Database Systems (4th Edition)”, Publisher: Addison Wesley, 2003. 15. W. Liu, T. Tudorache and T. Redmond, “Changes Tab in Protégé”, http://protegewiki.stanford.edu/index.php/Changes_Tab 16. M. Musen, N. Noy and Team, “Protégé Developer Documentation”, http://protege.stanford.edu/doc/dev.html
communication between the components. This ontology is used to record the changes by creating the semantically structured Change History Log. We have adopted the notion of change sets from concurrent versioning systems. The log is later on used by recovery and visualization components of the framework to undo/redo or browse through the changes, respectively. The framework and methodology for traceability of ontology changes is validated by implementing a plug-in for the Protégé editor. We are planning to extend the framework for detection of change patterns and pattern mining through machine learning techniques.
6. References 1.
2. 3.
4.
5.
6. 7.
8. 9. 10.
11.
G. Flouris, D. Plexousakis, and G. Antoniou, “A Classification of Ontology Changes”, In the Poster Session of Semantic Web Applications and Perspectives (SWAP), 3rd Italian Semantic Web Workshop, PISA, Italy, 2006. N. F. Noy and M. Klein, “Ontology evolution: Not the same as schema evolution”, Knowledge and Information System, vol. 6, no. 4, pp. 428–440, 2004. L. Stojanovic, A. Madche, B. Motik, and N. Stojanovic, “User-driven ontology evolution management,” In European Conference on Knowledge Engineering and Management (EKAW), pp. 285-300, 2002. M. Klein and N. F. Noy, “A component-based framework for ontology evolution”, In Proceedings of the (IJCAI-03) Workshop on Ontologies and Distributed Systems, CEUR-WS, vol. 71, 2003. S. Castano, A. Ferrara, G. Hess, “Discovery-Driven Ontology Evolution”. The Semantic Web Applications and Perspectives (SWAP), 3rd Italian Semantic Web Workshop, PISA, Italy, 18-20 December, 2006. Y. D. Liang, H. Alani, and N. Shabdolt. “Ontology Change Management in Protégé”. In: AKT DTA Colloquium, Milton Keynes, United Kingdom. 2005. Y. D. Liang, “Enabling Active Ontology Change Management within Semantic Web-based Applications”. Mini PhD Thesis, University of Southampton, 2006. D. Rogozan, and G. Paquette. “Managing Ontology Changes on the Semantic Web”. IEEE/WIC/ACM International Conference on Web Intelligence. 2005. M. Klein. “Change Management for Distributed Ontologies”. PhD Thesis, Department of Computer Science, Vrije University, Amsterdam, 2004. N. Noy, S. Kunnatur, M. Klein and M. Musen, "Tracking changes during ontology evolution", 3rd International Semantic Web Conference, Florida, USA, pp. 259-273, 2003. M. Klein, A. Kiryakov, D. Ognyanov and D. Fensel, "Finding and characterizing changes in ontologies", 21st International Conference on Conceptual Modeling, International Conference on Conceptual Modeling, Tampere, Finland, pp. 79-89, 2002.
96
