A Critical Analysis of lifecycles and Methods for Ontology Construction and Evaluation

Transcription

1 1st International Conference on Advanced Technologies for Signal and Image Processing - ATSIP'2014 March 17-19, 2014, Sousse, Tunisia A Critical Analysis of lifecycles and Methods for Ontology Construction and Evaluation IFI-130 Hafedh Nefzi RIADI Laboratory National School of Computer Science Campus of Manouba, Tunisia hafedh.nefzi@gmail.com Mohamed Farah RIADI Laboratory National School of Computer Science Campus of Manouba, Tunisia mohamed.farah@riadi.rnu.tn Imed Riadh Farah and Basel Solaiman ITI laboratory TELECOM-Bretagne, France imed.farah@telecom-bretagne.eu basel.solaiman@telecom-bretagne.eu Abstract Evaluation is a crucial phase in ontological lifecycle, especially for ontologies that are produced using automated or semi-automated methods. In this paper, we focus on the evaluation phase in the frame of the ontology building process. We begin by a review of different ontology construction lifecycles. Next, we try to review state-of-the-art methods for ontology construction with a special interest on evaluation for assessing the quality of ontologies. Afterwards we highlight the main limits and difficulties of these methods with respect to evaluation. We conclude with a first sketch on how evaluation should be undertaken for guiding the development of high quality ontologies that are more relevant to the requirements of a particular domain. Keywords Ontology, lifecycle, quality, evaluation, remote sensing imagery I. INTRODUCTION Remote sensing is one of the disciplines that play a very important role in the geographic information acquisition and interpretation. In fact, satellite images help studying major facts affecting the world, such as the urbanism expansion and the vegetation or water resources evolution. They are also considered as a fundamental support to monitor natural phenomena such as erosion, flooding, fires, deforestation, desertification, etc. The continuous progress in remote sensing technologies has led to a phenomenal increase of data making human experts no more able to deal with such data manually. Researchers definitely agree that processing such data can only be automatically dealt. Nowadays, ontologies are considered as one of the most powerful models for knowledge representation and reasoning. An ontology that models geographic objects, their characteristics and relationships is considered as a good support for automatic content processing of satellite images. There are many approaches for the specification and conceptualization of ontologies. Since there are many geographic ontologies in the literature, we propose to reuse these ontological resources for the construction of a high quality remote sensing image ontology which models the knowledge related to remote sensing objects, their relationships and their spatial, spectral and contextual characteristics. The quality of the resulting ontology strongly depends on the underlying ontology construction lifecycle which has been chosen for the fulfilment of the task, and more particularly on the way evaluation is considered therein. In fact, numerous studies in the literature have shown that evaluation is very important in the process of ontology building. Actually, there are numerous methodologies for the development of ontologies. Also, there are many evaluation methods and metrics. In this paper, we try to review and compare different ontology construction methods and lifecycle models, focusing on the evaluation phase. The rest of this paper is organized as follows: In section 2, we present a brief review and comparison of existing ontology construction lifecycles. In section 3, we analyze the main methods which are used for ontology construction reusing existing ontological resources. In Section 4, we present our approach for building high quality satellite image ontology. Finally, we conclude in Section 5. II. ONTOLOGY LIFECYCLE : STATE OF THE ART A. The V lifecycle model The V life-cycle [1] starts with the Identify purpose and scope stage in which requirements are developed by identifying the intended scope and purpose of the ontology. The second stage, that is named Knowledge Acquisition, consists in defining the process of acquiring domain knowledge from which the ontology will be built and selecting different sources that cover the complete domain knowledge: database metadata; standard text books; research papers and other ontologies. This stage is followed by a conceptualization stage that allows identifying the key concepts that exist in the domain, their properties and the relationships that hold between them; identifying natural language terms to refer to such concepts, relations and attributes; and structuring domain knowledge into explicit conceptual models. Conceptualization can be extended by an integrating stage in which it is possible to use or specialize an existing ontology. The encoding stage allows representing the conceptualization in a formal language. The output of this stage is an ontology implemented in RDF(S), OWL, or any other language that can be used by applications. To promote the appropriate use and re-use of the resultant ontology, it is necessary to document it and its different elements. Documentation includes informal and formal complete definitions, assumptions and examples. Documentation is important for defining the exact meaning of terms within the ontology. The last stage in this model /14/$ IEEE 48

2 is the evaluation: it allows determining the appropriateness of ontology for its intended application. Evaluation is done pragmatically, by assessing the ability of the ontology to satisfy the requirements defined previously, as well as determining the consistency, completeness and conciseness of the ontology. Fig. 2: The four-phase waterfall ontology network lifecycle model Fig. 1: The V lifecycle model B. The waterfall ontology lifecycle model This model [2] is essentially based on four phases starting from the initiation phase, going through the design and the implementation phases and ends with the maintenance phase. The initiation phase includes requirements that the ontology should satisfy, takes into account knowledge about the concrete domain, identifies the development team and establishes the resources, responsibilities, and timing. The design phase produces a model, either formal or informal, that satisfies the requirements coming from the previous phase. The implementation phase produces an ontology implemented in OWL or other language that can be used by semantic applications or by other ontology networks. The maintenance phase aims to overcome errors or missing knowledge that could be detected during the use of the ontology. In this case, the ontology development team should go back to the design phase to fill the gap. Additionally, in this phase the generation of new versions of the ontology network should also be carried out. The waterfall ontology lifecycle model is a sequential model, i.e. it forbids backtracking, excepting at the maintenance phase. This model can be completed by two other phases: reuse phase and re-engineering phase. In the reuse phase already ontological resources can be reused in the ontology network being developed. The output of this reuse phase could be either an informal model or a formal one to be used in the design phase, or an implemented model to be used in the implementation phase. After this phase, the non-ontological resources are transformed into ontologies in the reengineering phase; the ontological resources, on the other hand, can or cannot be re-engineered, a decision that should be taken by the ontology development team. C. Iterative-Incremental Ontology Network Lifecycle Model This model [2] is based on the continuous improvement and extension of the ontology resulting from performing multiple iterations with cyclic feedback and adaptation. In fact, the development of ontology is organized in a set of iterations. Each individual iteration can comply with any of versions of the waterfall model. For this, ontology requirements can be divided in different subsets. The result of each iteration is a functional and partial ontology network that meets a subset of the ontology network requirements. Such a partial ontology network can be used, evaluated, and integrated in any other ontology network. This model focuses on a set of basic requirements; from these requirements, a subset is chosen and considered in the development of the ontology network. The partial result is reviewed, the risk of continuation with the next iteration is analyzed and the initial set of requirements is increased and/or modified in the next iteration. D. EU-UNSF Lifecycle Model EU-UNSF (European Commission - U.S. National Science Foundation) is iterative and incremental lifecycle that has four phases: initial design, conceptual refinement, evaluation and evolution, with several possible feedbacks [3]. Fig. 3: EU-UNSF ontology lifecycle The feasibility study stage is not being considered as part of the development cycle of the ontology. It allows identifying the problem and performing its relative feasibility study. This leads to select the necessary tools and resources people. The following four steps are directly related to the lifecycle of the ontology: 49

3 - Launch Phase (Initial design or kickoff) in which the objectives are defined, the requirements are specified and the sources of information are identified. This allows reaching a qualified first semi-formal ontology. - Improvement phase (conceptual refinement): the ontology created previously is improved based on feedback from experts. Relations and axioms are also specified. This allows achieving operational ontology which is in conformity with the objectives identified during the launch phase of ontology. - Evaluation Phase: This phase involves three levels of evaluation(technological,user and ontological) and can lead to an ontology used in production. - Production phase and evolution (Application and Evolution): Once the ontology will continue to evolve, it is therefore necessary to identify the person who will support its maintenance and its evolution. E. The Spiral OWL model Spiral OWL model is generated based on knowledge engineering methodology and spiral model which is developed by Barry Boehm [4]. The Spiral OWL is a risk-driven process model, depending on specific risks associated with a given project, may be tailored to create a project specific process model. Each cycle of the spiral begins with determining, from the results of previous cycles, or preliminary needs analysis, the specification of the ontology being developed, the alternative means of implementing this ontology, and the constraints imposed on the application of these alternatives. The second step is articulated around the risk analysis, the assessment of alternatives, and possibly prototyping. In the following step, the proposed solution is developed and tested using a classic model as Waterfall or V model. The final step of each cycle allows to review the results and to plan the next cycle. This lifecycle model articulates around five stages called essentials [5]. 1) Ontology specification, alternatives and constraints: This step leads to determine the purpose and the domain of the ontology. The purpose of ontology can be set by listing typical query that the ontology has to answer or by describing a usage scenario. In this step, we must find the reason of the construction of ontology, its intended use and its users. Besides resolving all the points, we have to identify who is going to be a domain expert in the project. 2) Essential 2: acquisition, formalization, population: The second step for the lifecycle is reserved to the knowledge acquisition, formalization and population. For the acquisition, three different stages of acquisition process are proposed: determining the scope of the ontology, selecting a method to capture the ontology and defining the concepts in the ontology. Determining the concept can be achieved by elaborating a list of competency questions that a knowledge base based on the ontology should be able to answer. These questions allow verifying at each stage of ontology construction if the correct relationships have been created between the concepts, and if they are properly describing the domain. The acquired knowledge needs to be organized and structure by using representations that both computers and humans can understand. Such representations are formatted templates and independent of the ontology engineering tools or implementation languages used. Population is a process to transform the output of acquisition process that describes the domain in question to construct a concept network from knowledge. This network visualizes ontology as nodes (concepts) and links (relationships between concepts). 3) Spiral OWL Essential 3 : refinement, testing, and evaluation: The refinement process consists in changing the code either during the coding phase in order to correct errors and fulfil new requirements or during the maintenance phase to overcome the errors that are uncovered in testing and enhancements. The testing process covers all stages of ontology development. It aims to determine defects in functional logic and implementation. In evaluation process, knowledge engineer should verify the conformity between all information captured during interview with domain expert and modeled knowledge in the ontology. The conceptual ontology can be evaluated against several criteria such as logical consistency, conceptual accuracy, minimal ontological commitment and clear differentiation between ontologies. Fig. 4: The spiral OWL diagram 4) Spiral OWL Essential 4 : maintenance and plan for the next phase: Maintenance process consists of three types namely: corrective, adaptive, and perfective [6]. Corrective maintenance involves considering the problem faced by the users while querying the ontology and correcting the ontology to overcome these problems. Adaptive maintenance involves modifying the ontology to fulfil new requirements in the future. Perfective maintenance involves improving the ontology, to further refine it. 5) Spiral OWL Essential 5 : document validation and ontology validation: The document validation involves validating 50

4 the knowledge that has been captured during interview sessions. The document contains all structured knowledge in form of table format. Domain expert has to validate the document base on questionnaires and its respective answers. Ontology validation, also called code inspection, involves validating the structure of ontology. The principal aim of this validation is to reduce inconsistency data thus will ensure the knowledge is accurate and meet the user need. F. Comparison of ontology development lifecycle models The ontology which we want to build is obtained by enriching an existing core reusing a selection of existing geographical objects ontologies. Besides, it must be evolutionary because it has to support the update according to the requirements for the community and for the emergence of new concepts. To guarantee a good quality of the knowledge which models the content of the satellite images, we intend to incorporate the evaluation in different stages of development in order to reduce as much as possible the risks of errors and their propagation in the following phases. The evaluation has to overcome its descriptive role, so that it can help and direct us to the construction of high quality ontology. We try in the following paragraph to compare the different ontology lifecycles with an emphasis on their adequacy to the constraints expressed above. The main disadvantages of V and waterfall lifecycle models are the lack of flexibility in the development or modification of the requirements. In fact, they demand that the requirements are fully and clearly defined initially. In addition, they lead to a high degree of uncertainty and risks as the evaluation can be made only on the final product. In response to the weaknesses and failures of the models evoked previously the iterative-incremental ontology network lifecycle model and the spiral model allow development to begin even when all the system requirements are not known or understood by the development team. There produces working software early during the lifecycle and guarantees more flexibility in terms of requirements. In addition, in the spiral model, as each prototype is tested, user feedback is used to adjust and rectify the project. The risk analysis allows determining the adequacy of the project to the user s requirements. The development team adds functionality for additional requirements in ever-increasing spirals until the application is ready for the installation and maintenance phase. Despite its flexibility and simplicity, the iterativeincremental ontology network lifecycle model is composed of a set of phases that are rigid and do not support the overlapping. For its part, the spiral model involves a higher cost and combines the Project success to the risk analysis phase and requires a highly specific expertise in risk analysis. With regard to the constraints expressed at the beginning of this paragraph, we can conclude that only the EU-UNSF lifecycle model and the spiral model can suit us seen their flexibility, their opening on new requirements and their incorporation of the evaluation of the resultant ontology on several occasions. To better understand the processes of ontological building and to locate the evaluation stage in these processes, we try in the next section to review the main methods of ontology development. Our choice will concern the methods that allow the reuse of existing ontological resources. III. ONTOLOGY BUILDING METHODOLOGIES: STATE OF THE ART In general, methodologies specify a set of guidelines of how we should carry out the activities identified in the ontology development process, what kinds of techniques are the most appropriate in each activity and what produces each one. In this section, we review the main methodologies of ontology construction based on the reuse of existing sources, focusing on the evaluation stage if it exists. A. The Uschold and King s Methodology This methodology is based on the experience of developing the Enterprise Ontology [7] and it does not impose any specific lifecycle. It starts by identifying the purpose of resultant ontology. In this step, we must also specify the reason for building the ontology and its intended users. The following step is building the ontology by capturing knowledge, coding and integrating the knowledge with existing ontologies. The following three steps are: evaluation of the ontology, documentation, and guidelines for each phase. The evaluation [8] is to make a technical judgement of the ontologies, their associated software environment, and documentation with respect to a frame of reference which can be requirements specifications, competency questions, and/or the real world. B. The METHONTOLOGY Methodology It is created for building ontologies either from scratch or reusing other ontologies. It starts by identifying the ontology development process which generally corresponds to a subset of the following tasks: planning, control, specification, knowledge acquisition, conceptualization, integration, implementation, evaluation, documentation, configuration management, etc. [9] [10] once the process is identified, the ontological construction follows these steps or activities: (1) specification in which we have to identify the purpose of the ontology, include the intended users, scenarios of use, the degree of formality required and the scope of the ontology. The output of this phase is a natural-language ontology specification document. (2) Knowledge acquisition can be realized largely in parallel with the previous step. It consists in extracting knowledge from several sources as experts, books, figures, tables and even other ontologies using particular techniques like brainstorming, interviews, formal and informal analysis of texts, and knowledge acquisition tools. (3) Conceptualization lead to identify domain terms as concepts, instances, verbs relations or properties and each are represented using an applicable informal representation. During both specification and conceptualization, a process of (4) integration was completed using other ontologies that better bit the conceptualization. It allows obtaining some uniformity across ontologies, definitions from other ontologies. (5) In the implementation 51

5 step, the ontology is formally represented in a language, such as Ontolingua. (6) Evaluation is performed largely in the step of conceptualization. Nevertheless it may be carried out during each phase and between phases of corresponding lifecycle. It means verification and validation. The verification aims to guarantee the correctness of ontology, its associated software environments, and documentation with respect to the specification document. The validation guarantees that these elements correspond to the system that they are supposed to represent. (7) Documentation refers to grouping the documents that result from other activities. C. The KACTUS Methodology One of the objectives of the KACTUS project is to investigate the feasibility of knowledge reuse in complex technical systems and the role of ontologies to support it [11]. Ontology is constructed from a library of small-scale ontologies, which requires mapping between the various ontologies included in the development of the new ontology. The ontology development starts by (1) Specification of the application, which provides an application context and a view of the components that the application tries to model. (2) Preliminary design use the list of terms and tasks developed during the previous phase as input for obtaining several views of the global model the model that corresponds to the new ontology. This step covers research of ontologies developed for other applications, which are refined and extended for use in the new application. (3) Ontology refinement and structuring guide to achieve the definitive design. In this respect, the minimum coupling principle can be used to assure the dependence between modules and their consistency. This methodology assumes that the lifecycle should be the same as is used in the development of the application associated with the ontology. The main inconvenient of this method is that does not provide an assessment stage. D. The STANFORD Methodology This method allows building a new ontology reusing existing ontologies that share the same domain. It consists of seven steps [12]: (1) Determine the domain and scope of the ontology, (2) reuse of existing ontologies, (3) list the key terms of the ontology, (4) define the classes and the class hierarchy, (5) define the class properties (attributes), (6) define attributes and (7) create instances of classes in the hierarchy. As the previous method, STANFORD does not introduce the evaluation in their activities. E. Discussion Most of these methodologies have in common three key steps: a specifications step in which the context and objectives are defined, a conceptualization step for the representation and organization of the main concepts of the study area, a construction step for translating the conceptual model into a formal language. Only the first two methodologies incorporate a step of evaluation. Concerning the methodology of Uschold and King, assessment is carried after the construction of the ontology and it aims to assess the suitability of the ontology with the user s requirements. In Methontoloy, evaluation is performed largely in the step of conceptualization, but it may be carried out during each phase and between phases of corresponding lifecycle. It allows verifying the correctness of ontology with respect to the specification document and to validate the correspondence between modeled elements and the system they are supposed to represent. IV. TOWARDS AN ITERATIVE AND QUALITY-DRIVEN ENRICHMENT PROCESS According to the current study concerning lifecycle models and methodologies for building ontologies, it seems interesting to combine a methodology like Methontology with an iterative lifecycle model. This can ensure better control of the construction process which is an iterative and incremental process that incorporates assessment in its various phases. For the construction of our ontology that is dedicated to satellite imagery, we propose to consider the ontology of Durand [13] as a core ontology and enrich it conceptually reusing a selection of existing geographical objects ontologies. The quality of the resulting ontology is strongly conditioned by the order of choice of these ontologies. We are supposed, in this regard, to find the means necessary for the selection and the ordering of its ontologies according to their proximity to our study field, their richness, their structure, etc. These ontologies will be used later as a support for the extraction of concepts that will enrich the core ontology. The alignment is one of the most used techniques for this purpose. This task depends on several factors such as the used similarity measures, their order or weights, the nature of the available information in the ontology, the quality of ontologies, etc. Therefore, it is very important to build a good process for the matching between the existing ontologies and the core ontology. We should also monitor the construction process till reaching a required level of detail. This can be reached by carrying out an iterative enrichment process starting from extracting generic concepts, then trying to specialize them from one iteration to another. This also allows to better check the risks associated with each iteration. V. CONCLUSION In this paper, we firstly presented a literature review of different lifecycle models and methodologies which allow reusing existing resources in the ontology development process and which also incorporate an evaluation stage. We tried secondly to emphasize the advantages of each of these lifecycles and methodologies. As a progressive work, we intend to develop an approach that benefits from iterative lifecycles and Methontology methodology properties. This intended approach should enhance the quality of the enriched ontology at each iteration of the ontology construction process. REFERENCES [1] Marthn A. Ould, Strategies for Software Engineering: The Management of Risk and Quality, Wiley series in software engineering practice, Wiley,

6 [2] M. Suárez-Figueroa, A. Gómez-Pérez, M. Fernández-López, The NeOn Methodology for Ontology Engineering, Ontology Engineering in a Networked World, pp. 9-34,2012. [3] S. Antipolis, Semantic Web: Workshop Report and Recommandations, EU-UNSF, [4] R.S. Pressman, Software Engineering: A Practitioner s Approach, 3 rd Ed., McGraw-Hill, New York, [5] A. H. Hafizullah, and A. Aniza, The Spiral OWL Model? Towards Spiral Knowledge Engineering, World Academy of Science, Engineering and Technology Vol: , [6] Z. Li, V. Raskin, and K. Ramani, A Methodology of Engineering Ontology Development for Information Retrieval, International Conference on Engineering Design, ICED 07. Paris, France [7] M. Uschold, M. King, Towards a Methodology for Building Ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing, [8] A. Gómez-Pérez, N. Juristo, J. Pazos, Evaluation and assessment of knowledge sharing technology. Towards Very Large Knowledge Bases. KBKS 95. IOS Press, Amsterdam, pp , [9] A. Gómez-Pérez, M.Fernanadez, A.J De Vicente, Towards a Method to Conceptualize Domain Ontologies, ECAI-96 Workshop on Ontological Engineering, Budapest [10] M. Fernanadez, A. Gómez-Pérez, N. Juristo, METHONTOLOGY: From Ontological Art Towards Ontological Engineering, AAAI-97 Spring Symposium on Ontological Engineering, Stanford University, March th, [11] G. Schreiber, B. Wielinga, W. Jansweijer, The KACTUS View on the O World, In Proceedings of the National Dutch AI Conference. NAIC [12] F. Noy Natalya, L. Mcuinness Deborah, Développement d une ontologie 101 : Guide pour la création de votre première ontology, Université de Stanford, Stanford, CA, 94305, USA, [13] N. Durand, S. Derivaux, G. Forestier, C. Wemmert, P. Ganarski, O. Boussaid, A. Puissant, Ontology-Based Object Recognition for Remote Sensing Image Interpretation, ICTAI (1), pp ,