The Hypertension In Pregnancy Ontology

Published Date: 02 Nov 2017

CHAPTER 4

4.1 Introduction

In this chapter, the ontology design and data translation process will be presented. The ontology design and data translation process are carried out with the help of Protégé software. Besides that the integration of knowledge base into Microsoft visual studio 2010 in C sharp language will also be included. For the integration of knowledge base, a library named DotNetRDF is utilized. SPARQL is used to develop the query engine of the system.

4.2 Ontology design process

The design of knowledge framework in this project is performed according to the ontology development process since the knowledge acquired will be stored in ontology file. First of all, there is no universal method to model ontology. The ontology is normally designed according to the requirements of the system itself. In spite of this, there are some basic rules to be aware of:

As mentioned previously, there is no universal and correct method to design ontology. It relies on the application the ontology will be used.

Developing an ontology is a repetitive process

Try to build the concept of the ontology as close as to the real world objects.

It is stated in the second rule that developing ontology is a repetitive process, so the ontology will be developed roughly at the first attempt, and then the ontology will be revised and refined afterwards. The construction of the ontology follows the recommendation from "Ontology Development 101: A Guide to Creating Your First Ontology" [54]. A step by step approach proposed by the document will be presented in the next section.

4.2.1 Step by step approach

In the step by step approach, there are eight main stages in the ontology development. The eight main stages are illustrated in Figure 4.1.

Figure 4.1: Step by step approach in ontology

4.2.1 .1Determine scope

The first step in constructing ontology is to determine the scope of knowledge to be included in the ontology. The scope is usually influenced by the usability of the ontology in the present as well as in the future. The following questions can be of use in determining the ontology scope.

Which domain should the ontology include?

What is the application that the ontology will use?

What types of answers should the ontology provide?

Who will be the user of the ontology and the person to maintain the ontology?

Answers to these questions may change during the ontology development process but it helps to limit the scope of the model.

4.2.1.2 Consider reuse

In the beginning, ontologies are designed to be shared with others. With the advancement of semantic technology nowadays, it is very easy to find ontology available from the libraries on the Web. Therefore, if any suitable ontology is found, they should be used or at least provide us with a guide on where to start. Unfortunately, there is no ontology that constructs particularly in the hypertension in pregnancy domain. Nevertheless, there are some similar ontologies to be used as reference.

4.2.1.3 Enumerate terms

Enumerating related terms of the domain that are expected to appear in the ontology is a gateway to the actual definition of the ontology. Usually, the class names will be the noun form of the objects while the properties will be named after the verb form. For instance, class names like Disease or Treatment, the related terms will be something like hasSymptom, isFindingsOf, etc.

4.2.1.4 Define taxonomy and classes

In this section, there are two steps that will be carried out simultaneously. It is hard to determine the sequence of these two steps as they are closely related to each other. Furthermore, these two steps are the most crucial step in the ontology development. There are three different approaches to develop a class hierarchy.

Top-down: This method begins with defining the most general concepts of the domain and the specializations are defined afterwards. The benefit of using this method is that the detail level can be controlled better while the drawback is that this method might create needless top level classes.

Bottom-up: Opposite from top-down approach, this method starts from the most specific classes to the general concepts. This method usually yields a high detailed level. However, the more detailed the level, the harder the general concepts are characterized.

Middle-out: This is a combination of the top-down and bottom-up methods. This approach may begin with the more general concepts first and refine it, generalize the concepts afterwards.

4.2.1.5 Define properties

After the taxonomy and classes are defined, properties that express the relations between the classes have to be characterized. In semantics, subClassOf element affects the property statement between the instances that connected to subClassOf. For example, when A is a subclass of B, every property statement that applies to instances of B is inherited by instances of A. In other word, subclasses inherit the class properties. Therefore, attaching properties properly to classes is an extremely critical step to avoid any inconsistencies and misconceptions in the ontology.

4.2.1.6 Define facets

Up until here, the knowledge is expressed only with RDF schema without any expression language provided by OWL. In this step, the semantics are further enriched with OWL language by adding information to the previously defined properties. Cardinality is one of the features provided by OWL language. We can use cardinality to constraint a certain number of values a property should require. Additionally, the OWL expressive also allows us to define a particular value to the property of a class.

In addition, the type of values a datatype property may contain can also be defined using element like Boolean, Int, String and Float. Another important feature in OWL is the capability to characterize the properties using symmetry, transitivity, inverse properties and functional values. After the properties has been refined, it is now better to check consistency of the ontology since the inconsistency of ontology often happens after the property refinement. Inconsistency occurs when the features added to the properties are not compatible to each other.

4.2.1.7 Define instances

The next step is to create the instances of class. Usually, if the ontology covers large domain which consists of hundreds classes, the instances are not created manually; instead the instances are retrieved from database due to the large numbers of instances.

4.2.1.8 Check for anomalies

The final step of ontology development is consistency checking. This is one of the unique features of using OWL over RDF schema, the ability to detect anomalies in the ontology. Some of the sources of inconsistencies: the incompatible domain and range definitions for transitive, symmetric, or inverse properties, the conflict between domain and range restrictions, cardinality restrictions on properties and many more.

4.3 Overview of Protégé

Protégé is a free, open source ontology editor and knowledge-base framework [55]. Protégé provides platform to model the ontology into two types which are frame-based and ontology for Semantic Web. Protégé supports the creation, visualization, and manipulation of ontologies in a variety of representation formats like RDFS, OWL, and XML Schema with its knowledge-modeling structures [55]. Protégé is a Java-based platform which can be extended by third –party plug-in and this has made it a flexible and well-supported base for building knowledge-based tools and applications [55].

Figure 4.2 shows a screenshot of the ontology editor of Protégé. Tabs like active ontology, entities, classes, object properties, data properties, individuals, OWL Viz, DL query, and OntoGraf are the basic tab in Protégé. The OWL2Query tab is one of the available plug-ins for Protégé. This plug-in tab allows the conversions of owl graphs to SPARQL query.

Figure 4.2: The ontology editor Protégé

4.4 The hypertension in pregnancy ontology

4.4.1 Determine scope

As presented in the previous chapter, the domain and scope of the project will be hypertension in pregnancy, therefore the ontology are developed to provide thorough information about hypertension in pregnancy. The ontology mainly covers the fundamental information needed to be integrated in CDSS, it also include useful information that could be shared to the public after all the initial purpose of developing an ontology is a way to share and reuse the domain knowledge.

4.4.2 Consider reuse

Unfortunately, there is no available ontology that constructs particularly in the hypertension in pregnancy domain. Nevertheless, there are some similar ontologies for example tropical diseases to be used as reference.

4.4.3 Enumerate terms

In this step, it is an exercise on how to map the real world concept into ontology structures. It is very important for the ontology definitions to stay close with the original concept. The list of relevant ontology concepts are shown in Table 4.1. Since this is still a draft, the ontology concepts can be changed later on.

Table 4.1: List of relevant ontology concepts

Classes

Properties

Disease

hasSymptomOf

Diagnosis Method

hasDignosis

Diagnosis Findings

hasFindings

Management

hasManagement

Gestation Week

hasGestationPeriod

Risk factor

hasRiskfactor

Severity

hasSeverity

isSymptomOf

isDiagnosedBy

isFindingsOf

isManagementOf

isGestationPeriodOf

isRiskFactorOf

isRiskFactorOf

4.4.4 Define taxonomy and classes

After the analysis from evidence-based sources, the classes were identified and are shown in the radial graphical presentation of hypertension in pregnancy in Figure 4.3. The identified classes are then reorganized to form a taxonomy hierarchy structure as shown in Figure 4.4. The technique used to organize the taxonomy is middle-out where the hierarchy was form from the more general concepts first and then refines them followed by organizing the other subclasses concepts.

Figure 4.3: Radial graphical representation of hypertension in pregnancy ontology

Figure 4.4: Taxonomical hierarchy of concept in hypertension in pregnancy ontology

4.4.5 Define properties

The relationship between the classes was defined after the construction of the taxonomy and classes. There are two types of properties in this ontology which are object properties and data properties. Object properties describe the relationships between two individuals. The list of object properties is shown in Figure 4.5. Every object property has a corresponding inverse property for example the inverse property of hasManagement will be isManagementOf. Data property links an individual to a data values. Opposite from object property, data property does not have any inverse property. The list of data property can be seen at Figure 4.6.

Figure 4.5: List of object properties

Figure 4.6: List of data properties

4.4.6 Define facets

The properties are further refined in this step with description logic syntax. There are main two types of restrictions used in this project which are existential restrictions and universal restrictions. Existential restrictions represent by keyword "some" describe the set of individuals that have at least one specific kind of relationship to individuals that are members of a specific class [56]. The keyword for universal restrictions is "only", it is used to describe the set of individuals that, for a given property, only have relationships to other individuals that are members of a specific class [56].

The complex class descriptions are also used to refine the properties. Typically, two logical operators are used to describe the classes: intersection (AND) and union (OR). Intersection classes are formed by the intersection of the individual classes meaning that the individual must satisfy both classes to become intersection class. Union classes describe the classes that satisfy either one of the individual classes. Figure 4.7 shows the snapshot of the properties refinement in mild preeclampsia.

Figure 4.7: Properties refinement in mild preeclampsia

4.4.7 Check for anomalies

The reasoner that is used in this project is Pellet, a third party plug-in direct reasoner from Jena API. Reasoning is a crucial process in developing ontology so that the inconsistency of the ontology can be detected and corrected. A reasoner must be chosen from the Reasoner main menu option in Protégé before invoking it. In order to start the reasoner process, select the start reasoner menu from the Reasoner main menu or simply press Ctrl+R button.

Figure 4.8: Reasoner main menu

After the reasoning process, the inferred classes and errors are shown on the interface. For example, whenever a property has an inverse property, the reasoner will automatically add the inferred assertion to the inverse of the property. The inconsistency errors can be identified by looking at the red colour of any classes or properties. Figure 4.9 shows inconsistency ontology. By using Pellet reasoner, the reason for the inconsistency can be easily checked by clicking on explain inconsistent ontology menu.

The information of the ontology can be queried under the DL query tab. The query will only function when the reasoner is active because it needs reasoner to infer answer from the ontology. An example on querying the information is shown in Figure 4.10.

Figure 4.9: Inconsistent ontology

Figure 4.10: DL query example

4.4.7.1 Overview of Pellet

One of the most important features in Protégé is the reasoning API. Protégé provides build in DIG (DL Implementation Group) reasoners such as Fact++, HermiT, Racer and also other third party plug-ins. The DIG reasoners are no longer recommended to be used as it does not support the complete expressiveness of description logic in owl. Therefore, a third party plug-in direct reasoner, Pellet is imported into Protégé.

Pellet is a complete and capable OWL-DL reasoner with acceptable to very good performance, extensive middleware and provides a wide range of standard and unique features [57]. All the standard inference services that are necessary to a typical practical DL reasoner can be found in Pellet [57]:

Consistency checking – to make sure that the ontology does not have any inconsistency or in other words contradictory facts.

Concept satisfiability – to check if the possibility of a class to have any instances. If the class is unsatisfiable, then the instances created in the class will cause inconsistency of the ontology.

Classification – to develop a complete class hierarchy by computing the subclass relations between every named class.

Realization – to find most specific classes that an individual belongs to for example the direct types of the individuals. Realization process is normally carried out after the classification process since the direct types are defined according to the class hierarchy.

Besides these typical inference services which can be found in DIG reasoners, Pellet also incorporates with other unique features in its system as follow:

SPARQL-DL Conjunctive Query Answering – queries about instances do not get much attention in the literature when compared to reasoning with classes. Pellet has taken the initiative to include the Abox conjunctive query answering engine. The queries can be written in SPARQL language.

Datatype Reasoning – this feature is used to check the consistency of the intersection of datatype. Pellet supports all the build-in datatypes defined in XML Schema together with any type derived from numeric or date/time types.

SWRL Rules Support – Direct tableau algorithm implemented in Pellet enables reasoning with DL-safe rules encoded in SWRL and support for some SWRL built-ins are included.

Ontology Analysis and Repair – A number of heuristics are included in the system to repair the OWL FULL that is expressed in OWL DL.

Ontology Debugging – Pellet provides two kinds of services which are clash detection and axiom tracing to explain why the error occurs. This feature is generally not supported by other reasoners.

Incremental Reasoning – Pellet also covers reasoning with updated knowledge bases.

Figure 4.11 illustrates the architecture of Pellet reasoner. As can been from the figure, the main component of Pellet is the tableau reasoner which checks the consistency of the ontology after species validation and ontology repair process.

Figure 4.11: Architecture of Pellet reasoner

Lastly, the ontology needs to be validated. The knowledge inside the ontology has to be correct before proceeding to the next stage. The validation of ontology needs to be done with the help of a medical expert. Since the medical expert will not be able to understand the system in Protégé, a solution came up as to solve this problem. The ontology is loaded into an Ontology browser which uses the Tomcat 7.0.30 server and the hypertension in pregnancy ontology can be accessed in the browser. By clicking on any classes, the relationships of the classes can be viewed in normal knowledge language which helps the medical expert to easily understand the information in the ontology and check the medical errors in the ontology.

4.5 Overview of dotNetRDF

Since most of the Semantic Web tools supports are Java-based, there have been few projects working on creating tools for .Net applications. One of them is dotNetRDF which aims to provide a powerful and easy to use API for working with RDF, The library which is based on the latest .Net releases also strives to develop an API which is extensible to allow innovative applications to be based on it. dotNetRDF are designed similar to the Jena API where the Nodes are created and asserted in the Triples form into the created Graph.

dotNetRDF provides the following features:

RDF representation as Nodes, Triples, Graphs and Triple Stores

Parsing concrete RDF syntaxes

Serializing to concrete RDF syntaxes and other formats

SQL backed storage using SQL Backend

Storage in native Ttriple Stores

Querying RDF

Updating RDF

ASP.Net Integration

The dotNetRDF library is available as pre-compiled DLL or as source code. In order to use this library, the following requirements are needed:

Microsoft.Net Framework 4.0 or 3.5 SP1

JSON.Net

HtmlAgilityPack

4.6 Integration process

Query engine is where the process of getting the information from the knowledge base based on the description and condition provided and returns the results to the user. In order to make use of the data stored in the developed ontology, a query engine has to be created. In this project, the dotNetRDF library is used to implement the query engine. Ontology developed from Protégé is saved in RDF/XML form so that the information from the ontology can be retrieved using dotNetRDF library.

In order to use dotNetRDF, the dotNetRDF library must first be imported into the library of Visual Studio project. The pre compiled HtmlAgilityPack DLL and Newtonsoft.Json DLL must also be imported to the project’s library as to fulfill the requirement of using dotNetRDF. First of all, the ontology has to be loaded into the project by creating a graph and assert the ontology file into created graph.

g = new Graph();

g.LoadFromFile("exData\\PregnancyInducedHypertension.owl");

Listing 4.1: Creation of the OWL Graph

After the graph has been created, the information can now be queried from the ontology file. In this project, local query is carried since the ontology file is saved in the project’s database. SPARQL is the query language that used to retrieve the data from the ontology file. In the SPARQL language, any SPARQL query must start with the declarations of prefixes.

PREFIX base: <http://www.semanticweb.org/ontologies/2012/6/PregnancyInducedHypertension.owl#> "

+ " PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>"

+ " PREFIX owl: <http://www.w3.org/2002/07/owl#>"

+ " PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>"

+ " PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>"

Listing 4.2: Prefix declarations

Followed by the declarations of prefixes is the construction of the SPARQL query. The function of the query engine is to query the possible disease based on the parameters related to hypertension in pregnancy. There are four basic parameters in the query engine which are diastolic value, proteinuria value, gestation week and sign and symptom.

+ " SELECT ?disease "

+ " WHERE {?disease rdfs:subClassOf ?object. " + dataQuery + " } ORDER BY ?disease";

Listing 4.3: SPARQL Query

Originally, dotNetRDF is used to query over RDF data. Since the ontology file is saved in RDF/XML, dotNetRDF can also be used to query an OWL file. The challenge is that the SPARQL query might not that simple and easy anymore, the query can be very long and time consuming. The hypertension in pregnancy ontology consists of five deep layers, therefore the SPARQL query have to be constructed with more efforts.

dataQuery = " ?object owl:onProperty base:hasDiastolicValue."

+ " ?object owl:someValuesFrom ?obj3."

+ " ?obj3 owl:withRestrictions ?obj4."

+ " ?obj4 rdf:first ?obj5. "

+ " ?obj5 xsd:maxExclusive \"90\"^^xsd:integer";

Listing 4.4: Branch of SPARQL Query

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.semanticweb.org/ontologies/2012/6/PregnancyInducedHypertension.owl#hasDiastolicValue"/>

<owl:someValuesFrom>

<rdfs:Datatype>

<owl:onDatatype rdf:resource="&xsd;integer"/>

<owl:withRestrictions rdf:parseType="Collection">

<rdf:Description>

<xsd:minInclusive rdf:datatype="&xsd;integer">110</xsd:minInclusive>

</rdf:Description>

</owl:withRestrictions>

</rdfs:Datatype>

</owl:someValuesFrom>

</owl:Restriction>

</rdfs:subClassOf>

Listing 4.5: RDF/XML ontology file