ONTOLOGY BASED SEMANTIC
KNOWLEDGE REPRESENTATION FOR
SOFTWARE RISK MANAGEMENT
C.R.RENE ROBIN
Department of Computer Science and Engineering Jerusalem College of Engineering
Chennai-100, Tamil Nadu, India G.V.UMA
Department of Information Science and Technology Anna University, Chennai-25, Tamil Nadu, India Abstract:
Domain specific knowledge representation is achieved through the use of ontologies. The ontology model of software risk management is an effective approach for the intercommunion between people from teaching and learning community, the communication and interoperation among various knowledge oriented applications, and the share and reuse of the software. But the lack of formal representation tools for domain modeling results in taking liberties with conceptualization. This paper narrates an ontology based semantic knowledge representation mechanism and the architecture we proposed has been successfully implemented for the domain software risk management.
Keywords : Ontology, Semantic Web, Natural Language Processing, Protégé, Software risk management.
1. INTRODUCTION
Today many software development projects deal with huge risks and risks might occur in the entire development process irrespective of the type of applications. Most of the software projects try to advance current software capabilities and attain something that has not been done before while the opportunity for encroachment cannot be achieved without taking risks. So the risks must be narrowed for the success of a project, especially considering that current software market often demands updated software developed as quickly as possible. Application of knowledge-based computerised systems requires development of approaches to represent different kinds of knowledge. Nowadays modelling of static knowledge by ontologies is becoming more and more popular. This is not a surprise, that developers of IT environments try applying new approaches and methods to their domains first. There has been extensive research on ontologies for different areas of software engineering (SE) and software technology. In this paper we propose an architecture for ontology based semantic knowledge representation that helps the learners such as students, teachers and software developers to know all the areas of software risk management. For this proposed system, Software Risk Management Ontology (SRMONTO) has already been developed by the authors and it is used as knowledge base for the proposed work. The rest of the paper is organized as follows. Section 2 of this paper discuss on the related work that have been done on this area. Section 3 is dedicated for the domain description; Section 4 describes the architecture for the proposed; Section 5 describes ontology construction process used to construct SRMONTO; Section 6 presents the experimental results and Section 7 concludes the paper with some future work.
2. RELATED WORK
instances, which correspond to individual objects in the domain of discourse; each instance has a concrete value for each property of the class it belongs to. An ontology together with a set of individual instances of classes constitutes a knowledge base. An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions (semantics) of basic concepts in the domain and relations among them. Classes are the focus of most ontologies. Classes describe concepts in the domain. A class can have subclasses that represent concepts that are more specific than the superclass. Slots describe properties of classes and instances. So developing an ontology includes defining classes in the ontology, arranging the classes in a taxonomic hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances[8]. Despite efforts and experience in developing ontologies, there is no agreement on a methodology for building ontologies. The ontology development methodology problem has been investigated in several projects. First attempt was by [Noy et. al, 2001] that specifies some principles and criteria for the design of ontologies. We can create a knowledge base by defining individual instances of these classes filling in specific slot value information and additional slot restrictions.
Software engineering ontology [M Pornpit Wongthongtham et. al, 2007] is a great motivation for the initiation of the proposed work. The software engineering ontology defines common sharable software engineering knowledge including particular project information. Software engineering ontology typically provides software engineering concepts – what they are, how they are related, and can be related to one another – for representing and communicating over software engineering knowledge and project information. Similar ontology for software risk management (SRMONTO) has been constructed as the part of this research and it is used as a knowledge base for the proposed work.
Then the knowledge available in SRMONTO is represented using document Semantic descriptions [Toma´sˇ Vitvar et. al, 2010] must usually co-exist with other already existing descriptions. Semantics enrich existing descriptions with additional expressivity that systems can use for advanced content manipulation and provisioning. Semantic description usually refers to a description of a resource, e.g., service, message, data, and alike expressed in a semantic language, that is, in a language that allows formal definition of semantic information (e.g., classes of concepts, relations between classes, axioms, etc.), while at the same time some logical foundations for the language exist. For example, every description in RDFS[Beckett], OWL[Michael K et. al, 2004], RIF,WSML is the semantic description. On the other hand, non-semantic description is a description of a resource, e.g., service, message, data, and alike which is captured in a language that does not allow expression of semantic information. In this respect, any description in XML, XML Schema, or any other proprietary format is the non-semantic description. Please note, that in the IT world, there might be different views on what semantics are about. People might call semantics a description of data in XML Schema with attributes’ types, restriction on values, etc. However, XML Schema does not comply with our semantic description definition as it does not allow expression of classes, their properties, nor relationships between classes, while it does not have any logical foundation. In addition, the XML is often used as a serialization format of semantic descriptions, for example, a description captured in RDFS may be formatted in XML (such serialization is called RDF/XML). Thus, XML is usually understood as the language capturing the syntax. The semantic knowledge representation definition we use is based on the Semantic Web point of view.
The knowledge of the software risk management domain has been represented by means of ontology, which has been used to guide the design of the application and to supply the system with semantic capabilities. The domain ontology was developed using Protégé tool[John H et. al, 2003][ Holger Knublauch, 2004][14], which serves as a rapid environment in which ontology designers can instantly create individuals of their ontology and experiment with semantic descriptions. With ontology-based semantic risk management, the risk management terms can be parsed with risk management ontology concepts and can recall the necessary details and relevant information. 3. Domain Description
4. Proposed Architecture
Fig.1 illustrates the software architecture for the proposed application. It consists of several modules such as domain knowledge acquisition, ontology construction, Ontology merging, ontology store and semantic knowledge representation. In the ‘domain knowledge acquisition’ module information about various areas of risk management such as risk identification, risk analysis, risk planning, risk tracking and risk control has to be collected from various sources like text book, discussion with experts, internet, magazines etc. The gathered information collectively called corpus which is the domain knowledge for the domain software risk management.
Fig.1 : System Architecture for the proposed work
Ontology merging is a technique which is used to merge the existing ontologies. A Java program has to be written to automate the translation of the individuals from XML into OWL, using the syntax of the OWL exported from Protégé as a guide. The merged ontology called SRMONTO with the possible instances is stored in a ONTOSTORE which serves as the knowledge base for the proposed system. The following are the description of various components present in the proposed architecture Fig. 1
4.1. Ontology Construction :
Ontologies are built based on data obtained from the gathered domain knowledge. These Ontologies form the basis of the complete architecture. The Ontologies are built based on various concepts identified among each of the five processes. These Ontologies have well defined hierarchies, relations and properties.
4.2. Ontology Repositories :
Store of Ontologies identified based on the 5 different process of risk management along with unique case scenarios identified for future cross reference and analysis.
Risk Identification
Risk Analysis
Risk Planning
Risk Tracking
Risk Control Domain Knowledge
C C
C
C C
C
C C
C
C C
C
C C
C
Onto I
Onto II
OntoIII
OntoIV
Onto V SRMONTO Construction
Onto IV
Ontology Merging
Onto V Onto
I
Onto II
Onto III
Ontology (SRMONTO) Repositories
4.3. Ontology Merger :
The Ontology Merger and Analyzer merges the ontology that has been created with the existing Ontology Repositories. The Prompt Algorithm is utilized for merging process.
4.4. Semantic Knowledge Representation:
This module takes care of visualizing semantic description of the concept, hierarchal arrangement of the concepts as tree based structure, super class of the concept and the instances of the particular concept.
5. Software Risk Management Ontology ( SRMONTO)
The process of constructing SRMONTO has following six stages such as studying domain-related issues, building up a methodology for developing an ontology for the software risk management area, developing sub ontologies for the target ontology, merging of sub ontologies yields the target ontology, implementing the environment and investigating applicability of the environment. Figure 2. shows the architecture used for the construction of SRMONTO.
Fig. 2 : Architecture of Ontology Construction Process
The SRMONTO restrains software risk management knowledge and also enhance the sharing of software risk management knowledge across geographically multiple users. It assists in defining information for the exchange of semantic project data and is used as a communication framework. Its end users are software engineers sharing software risk management domain knowledge as well as learner of software risk management such as teachers and students.
Figure 3 demonstrates five top levels of the developed ontology i.e. SRMONTO. Lower levels trivially expand the hierarchy therefore we have hidden them. Fig 4 shows the portion of risk analysis ontology in OWL format. Risk Analysis Ontology is sub ontology of SRMONTO. SRMONTO is an integration of Risk Identification Ontology, Risk Analysis Ontology, Risk Planning Ontology, Risk Control Ontology and Risk Tracking Ontology where N(C) is the number of concepts and N(P) is the number of relationships each ontology has.
C C
C
C C
C
Ontology C C
Protégé Experts
Domain Book
Knowledge
Domain Knowledge
Ontology Construction Process
Relationship Extraction
class Extraction
SubClass Extraction
Integration of Class, Subclass and Relationship
Semantic
Fig. 3 :The Structure of SRMONTO (Software Risk Management Ontology)
<?xml version="1.0"?> <rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:j.0="http://protege.stanford.edu/plugins/owl/protege#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://www.owl-ontologies.com/unnamed.owl#" xml:base="http://www.owl-ontologies.com/unnamed.owl"> <owl:Ontology rdf:about=""/>
<owl:Class rdf:ID="Impact">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >The potential impact to {your organization} if the event occurred</rdfs:comment> <rdfs:subClassOf>
<owl:Class rdf:ID="Factors"/> </rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Priliminary_Risk_Analysis">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>This method was developed in the 1950s by reliability engineers to determine problems that could arise from malfunctions of military system. Failure mode and effects analysis is a procedure by which each potential failure mode in a system is analyzed to determine its effect on the system and to classify it according to its
severity.</rdfs:comment> <rdfs:subClassOf>
<owl:Class rdf:ID="Qualitative_Methodologies"/> </rdfs:subClassOf>
… <j.0:PAL-CONSTRAINT rdf:ID="Risk_Analysis_Instance_7"/> <j.0:PAL-CONSTRAINT rdf:ID="Risk_Analysis_Instance_9"/> <j.0:PAL-CONSTRAINT rdf:ID="Risk_Analysis_Instance_6"/> </rdf:RDF>
<!-- Created with Protege (with OWL Plugin 3.4, Build 125) http://protege.stanford.edu -->
Fig. 4: A Portion of OWL based SRMONTO SRMONTO
Risk Planning
Risk Control Risk Tacking
Risk Identification
Risk Analysis
N(C)=12 N(P)=03 N(C)=48
N(P)=06 N(C) =16
N(P) =04 N(C)=80
N(P) =04 N(C)=40
6. Experimental Results
The proposed architecture has been successfully implemented. A total of 234 source files have been automatically generated by OWL document generator and each represents a concept in SRMONTO. Fig. 5 shows the snapshot of the main page used to represent the software risk management knowledge. At left side all the major areas of software risk management are displayed. The desired knowledge can be obtained by selecting the area. Here the concept ‘Risk Analysis’ has been selected and the knowledge about the concept has been effectively represented. Fig. 6 to Fig. 9 show the semantic representation of risk tracking, risk planning, risk identification and risk control respectively. Our approach is not only gives the hirarical structure but gives four different types of knowledge. After selecting a particular concept, the name of the concept is displayed at the top as ‘class’ name followed by the semantic description of the concept is displayed. Then the taxonomical arrangement of the domain starting from the top level concept to the selected concept is displayed from SRMONTO followed by the parent concept is displayed and at the end the descendents of the selected concept is displayed. The users can move further by selecting one of the descendents.
Fig. 5 : Main page contains five major categories of the domain
Fig. 8 : Representation of software risk identification knowledge
Fig. 9 : Representation of software risk control knowledge
7. Conclusion
In this paper the ontology based semantic knowledge representation for the domain software risk management has been described clearly. Since ontologies provide semantic web agents with background knowledge about domain concepts and their relationships, using it in knowledge representation which will become more effective. By using the SRMONTO the knowledge about software risk management has been clearly represented. The experimental results show how the proposed system extracts key concepts and discovers the relations among the concepts from SRMONTO and visualize four different types of knowledge of the domain. In future the proposed approach can be applied in any domains, if the formal ontology for the particular domain exits.
References
[1] Barry W. Boehm, Software Risk Management, IEEE Computer Society Press, 1993. [2] Beckett (eds.), RDF/XML Syntax Specification, W3C Recommendation, http://www.w3.org/. [3] Fairley, R. Risk management for software projects. IEEE Software 11:3 pp 57-67, 1994.
[4] Gennari et.al., The evolution of Protégé: an environment for knowledge-based systems development, International Journal of Human-Computer Studies, Volume 58, Issue 1, Pages 89-123,January 2003.
[5] Gomez-Perez A, M. Fernandez-Lopez, and O. Corcho, Ontological Engineering, Springer press, 2005.
[6] Holger Knublauch, The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications, Springer Berlin / Heidelberg, Volume 3298/2004.
[7] Karolak D W Software engineering risk management. IEEE Computer Society Press, 1996.
[8] Michael K. Smith, Chris Welty, and Deborah L. McGuinness, OWL Web Ontology Language Guide, W3C Recommendation,2004.
[9] Myerson M. Risk Management Processes for Software Engineering Models. Artech House, 1996.
[10] Noy, N. F., McGuiness D. L., Ontology Development 101: A Guide to Creating Your First Ontology, Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report
[11] Pornpit Wongthongtham M, Elizabeth Chang, Tharam Dillon “Ontology Modelling Notations for Software Engineering Knowledge Representation” Inaugural IEEE International Conference on Digital Ecosystems and Technologies, IEEE DEST 2007.
[12] Toma´sˇ Vitvar, Vassilios Peristeras, and Konstantinos Tarabanis, “Semantic Technologies for E-Government : An Overview”, Springer Publishing Company, Incorporated, 2010.
