Extending OWL to Support Custom Relations in Knowledge-Driven Intelligent Systems

Abstract— Ontology is one of the popular models for knowledge representation, and Web Ontology Language (OWL) is the current industry standard for supporting ontology in semantic web and knowledge encoding for various application domains. But ontology only supports the relation “is-a” (inheritance) between the entities. Various other relations, such as part-of, are essential for representing information in various fields including all engineering disciplines. Even though OWL introduced object properties to emulate other relations, but they add syntax burden to knowledge modelers and don’t support accurate semantics for inference engines. This paper introduces the design and implementation of minimal syntax extension to OWL, which allows domain experts to declare and apply custom relations with various mathematical properties in knowledge representation. This extension to Stanford University’s Protégé project so that it can be used to encode intuitively knowledge with custom relations. We also present our additions to the OWL API for the declaration, application, and visualization of custom relations. Moreover, Work relating to our modifications of the OWLViz plugin for custom relations visualization is also discussed. Finally, we introduce the application of custom relations in the knowledge-driven intelligent systems.

Index Terms— Knowledge Representation; OWL; Custom relation; OWLAPI; Protégé

I.  Introduction

NOWLEDGE can be defined as understanding, facts, information and description of some real or imaginary entity. In computer science domain, knowledge is a critical component of reasoning and logical decisions, which are important characteristics of intelligent system. Knowledge representation is dedicated to representing knowledge in a format that machines can understand. When the developers try to build better suited intelligent system, knowledge representation is a critical and necessary approach.

Ontology is one of models for knowledge representation of a particular domain of discourse, which is a formal logic-based model for using semantics to describe knowledge about objects in a specific domain, and to define concepts and relationships between them. The Web Ontology Language (OWL) is the dominant industry standard for representing well-understood relations among the abstractions or classes of entities to encode domain knowledge as ontologies.

There are some tools that make it easier to build ontologies such as the Stanford University Java Project Protégé [1, 2, 3], an open-source IDE for visually developing OWL based knowledge representation. Along with editing and creating OWL files, Protégé also provides support for validators for validating ontology models. OWLAPI [4, 5, 6] is an open source Java library which provides APIs and data structures for parsing and manipulating OWL files.

    Relations between different concepts or entities are the key component of knowledge representation. The primary relation supported by OWL is the “is-a” (inheritance) relation which is rather limited, and current Ontology/OWL has no direct support for the declaration and application of custom relations. Some methods or solutions for representing such kinds of information do exist but they add syntax burden to knowledge modelers, don’t support accurate semantics for inference engines, and lack relation visualization support.

Most knowledge cannot be properly represented by ontologies or OWL. For example, algorithms represent most knowledge in computer science, and they heavily depend on the time order or temporal relation not supported by ontology. Most science and engineering knowledge heavily uses “part-of” in various flavors (physical or logical inclusion, intrinsic or optional inclusion, etc.; meronymy). Different knowledge domain needs different relations with various mathematical properties. Knowledge encoding must be executed by domain experts who usually have limited IT skills. By allowing OWL documents to declare and apply new custom relations, we can solve these problems as well as introducing new information representation mechanisms.

In this paper, we introduce the design and implementation of a syntax extension for OWL. This extension will help us define and apply custom relations. This syntax extension not only allows us to increase the knowledge representation capabilities of OWL documents, but also empowers us to get rid of many of side effects arising from using workspaces in the current OWL. We introduce custom relations as a new entity will help users to declare many features to OWL documents later that are only applicable to relations and not to other entities. We modify OWLAPI library to provide APIs and data structures for creating and modifying new relations. Since Stamford Protégé Project is an industry standard development environment for creating and manipulating OWL documents or knowledge, we also modify Protégé project to support our proposed custom relation declaration and application. Moreover, we also would modify OWLViz plugin using in Protégé for knowledge visualization, to support visualization of the custom relation declaration and application.

The remaining of the paper is structured as follows. In Section II, we discuss the limitations of current OWL along with examples. In Section III, we analyze the importance of custom relations in knowledge representation. In Section IV, we introduce the basic setup process of our new syntax extension. In Section V, we present the design and implementation of our new syntax. In Section VI, we present the definition, justification and usage examples of our new syntax, then present modifications of the Protégé project to support the visualization of custom relation declaration and application. We also discuss our modification of the OWLViz plugin for custom relation visualization along with the UI benefits. In Section VII, we present the application of custom relation in the knowledge-driven intelligent systems. We will conclude and present the future work in Section VIII.

II. MOTIVATION AND THE LIMITATIONS OF CURRENT OWL

The semantic web has been proposed in order to solve the deficiencies of the current HTML-based web. The current HTML-based web is focused on the display of data and information, while ignoring the relationships and meaning of data and information [7]. To put it another way, Web browsers do not actually understand the content of web pages. Web automation and data mining are hindered greatly due to this kind of issues [8], so that the semantic web could be the extension and expansion of the world wide web. With deepening development of the Internet, traditional web technology has been unable to meet the needs of e-Commerce, e-Learning and e-Science. The semantic web provides a solution to these problems, and holds great promise for better collaboration between humans and computers.

Ontologies are used to capture knowledge about some domain of interest [9]. An ontology describes the concepts in the domain and also the relationships that hold between those concepts. Different ontology languages provide different facilities. The most recent development in standard ontology languages is OWL from the World Wide Web Consortium (W3C) [10]. OWL makes it possible to describe concepts with a richer set of operators – e.g. intersection, union, and negation. It makes it possible for concepts to be defined as well as described. Complex concepts can therefore be built up in definitions out of simpler concepts. Furthermore, the logical model allows the use of a reasoner which can check whether or not all of the statements and definitions in the ontology are mutually consistent and can also recognize which concepts fit under which definitions [11].

One of the most important relationships among objects in the real world is specialization. Specialization can be described as the “is-a” relationship. The statement, “A dog is a mammal”, means that the dog is a specialized kind of mammal. Having all the characteristics of any mammal, (the fact that it bears live young, nurses with milk, has hair etc.). “The specialization and generalization relationships are both reciprocal and hierarchical. Specialization is just the other side of the generalization coin: Mammal generalizes what is common between dogs and cats, and dogs and cats specialize mammals to their own specific subtypes.” [12] The most popular tool for creating OWL document is the Stanford University Protégé project. This protégé uses only one relation the “is-a” relation, we will use the following example to describe “is-a” relation among classes.

Fig. 1. “is-a” relation in Protégé

In the above Figure 1, there are five classes: organ, body, retina, eye and heart. Because Stanford University protégé only can use “is-a” relation, we can’t describe the relation between body and heart. In fact, most knowledge cannot be properly represented by ontologies or OWL and most science and engineering knowledge heavily uses custom relation in various flavors according to the specific situation.

Although there are some workarounds such as using object properties to simulate these custom relations [13, 14], they come with their own limitations.

• Relations between entities are generally considered to be dynamic in nature as they evolve as new information becomes available, but these workarounds generally force static nature on relations [15, 16].
• The limitation encountered by using workarounds based on object properties arise from the fact that restrictions in relations and object properties behave differently. For example, we cannot use object properties to express the fact that a crankcase can be a part of at most one engine. In this case, setting the maximum cardinality of crankcase to one will not work because part-of is a transitive relation and engine is part-of car therefore crankcase will be part of both engine and car thereby violating our maximum cardinality criteria.
• The limitation includes less stability of knowledge library, increased computation and memory requirement arising from the fact that we are emulating with object properties but we don’t truly need full functionality of object properties. Custom relation emulation with object properties is usually long and complicated with artificial intermediate notations thus hard to use by domain experts for knowledge representation and validation.
• The limitation includes the complexity of current OWL syntax. If users would like to represent relations in Stanford Protégé, they can use object properties to create relationships between two individuals/classes, but object properties must have a domain and a range specified, it will link an individual/class from the domain to another individual/class from the range. For example, the user wants to represent the engine is a part of the car, the OWL document is shown below. The user must understand the concepts of object property, range, domain, sub class of, restriction, on property, some value from and class. It is clear that this is complicated and boring process.

<! — Object Properties –> <owl:ObjectProperty rdf_about=”#partOf”> <rdfs:range rdf_resource=”#Car”> <rdfs:domain rdf_resource=”#Engine”> </owl:ObjectProperty> <owl:Class rdf: about=”#Engine”> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf_resource=”#partOf”> <owl:someValuesFrom rdf_resource=”#Car”> </owl:Restriction> </rdfs:subClassOf> </owl:Class>

III.   IMPORTANCE OF CUSTOM RELATIONS IN KNOWLEDGE REPRESENTATION

Ontology only supports “is-a” or inheritance as its primary relation. Other important relations are not supported by ontology have been acknowledged by various researchers and research projects [17]. Many research projects based on ontology rely heavily on relations rather than “is-a” relation. Generally, these projects define their own sets of custom relations which vary from project to project.

The Gene Ontology (GO) project is a collaborative effort to address the need for consistent descriptions of gene products across databases [18]. They use custom relations like part-of, has-part, regulates, negatively regulates and positively regulates for various aims [19]. Building image file catalog system are other fields where ontologies with custom relations are heavily used [20]. Image catalog systems generally use the classify relation, part-whole relation, dependency relation, instance relation and conception subjection relation [21].

Cyber learning is characterized by endless volume and type of learning resources freely and readily available to the students through the web. But the lack of personized guidance by experienced instructors as to learning resource selection and learning order recommendation, and the lack of an assessment-based learning process. The web based tutoring system needs describe the main concepts of the course, and describe various relations among the concepts. Commonly used relations in the field of tutoring system are part-of, implement, implemented-by and include [22].

Drug adverse reaction data contains important constraints about side effects and conflict avoidance of component and compound drugs. The user that many of these constraints are transitive in nature due to the relationship between drug and drug classes. Current drug side effects representations in XML does not have a proper knowledge representation mechanism to clearly specify all kinds of dependencies among the drug components and drugs. Even the recently introduced OWL based approach for medical drug side effects data representation still suffers from several shortcomings inherent to the OWL restrictions like using “is-a” relationship and usage of object property emulations. In the intelligent telehealth system, the need for custom relations is clearly evident from the aforementioned analyses [23].

A cyber engineer wants to build a set of cyber security terminology using a semantic approach to bridging the gap between different levels of technicality from layman to technological sophistication. He posits that for any topic, there are different versions of terminology [24]. Some are formal, others are less formal thus necessitating the need to bridge the communication between different groups of people so that the

terminology at the different levels of formality can work together and be reconciled to some extent. The benefit of reconciling these different versions of terminologies is to make searches of documents more effective. Cyber security has threats, networking concepts, and cyber security terminology. Threats are cyber security concepts that have threat actors, threat vectors, threat types, and threat mitigations. There must be various relations between them not just “is-a” relation.

Different companies in the same line of business can have similar equipment of applications with built-in diagnostic procedures, and the ability to regularly send error information or event-driven environmental diagnostic messages back to the system manufacturer. The system manufacturer typically uses these to determine faults in the system. The outcome of this troubleshooting can also assist end-users and clients in solving problems, and provide the production team valuable information that can be used to improve future versions of the product. In these similar business data, there are many needed relations case by case, the custom relations are important and necessary [25].

Many projects using custom relations define their own syntax and tools [26] for defining and parsing additional relations. Defining separate syntax for each relation is not possible as there is an uncountable number of custom relations. Another problem arising from different syntax for each relation is pertinent to knowledge transfer [27]. Knowledge created by one community can’t be utilized by someone else because each community uses different syntax for custom relations. Our proposed syntax will help solve these problems.

IV.   BASIC SETUP OF SYNTAX EXTENSION

1. Setting up the development environment

• JDK: First install Java JDK from oracle official website. Please note that must download JDK not JRE. Make sure you have JAVA_HOME variable setup in the local computer. Also make sure you have Java binaries in your OS path.
• Graphviz: Visualization tools in Protégé project use Graphviz for creating graphs. You can get latest copy of graphviz from this graphviz official website.
• Maven: Maven is based on the project object model (POM), which can manage the project’s construction, reporting and documentation by a short description of the information.
• Git: This is an optional tool. You will only need it if you want to checkout different commit from our repository and have something to share with rest of the group.

2. Downloading the Source Code

Before we start our development process, we should get all necessary source code at one place create a new folder somewhere in your computer to contain all required source code. For now, let’s assume that it is “source_container” located at desktop. ALL these repositories are necessary for working with Protégé development environment go through them one by one to get all source code.

• Protégé: Visualization tools in protégé project use Graphviz for creating graphs. You can get latest copy of graphviz from this graphviz official website. We can get latest version of Protégé. You can clone latest version of Protégé by using a command in git command line.

git clone https://github.com/Protégéproject/Protégé 

After this you should copy Protégé folder from working directory to “source_container”. You should also delete. git folder from Protégé folder in “source_container”.

• OWLAPI: The OWLAPI is a Java API and reference implementation for creating, manipulating and serializing OWL Ontologies. Currently Protégé use two versions of OWLAPI: 3.5.0 and 3.5.1. The developer must get these two versions. Run the command below to get OWLAPI folder in your working directory.

git clone https://github.com/owlcs/owlapi

Go to OWLAPI directory using command “cd owlapi”.  All our source code lies in branch “version3” of OWLAPI. To use version3 of OWLAPI run a command in git command line.

git checkout version3: git checkout version3. To get version 3.5.0 in your current working directory run

git checkout 7c36925. To get version 3.5.1 in your current working directory run git checkout 9c36641.

• Protégé OWLAPI: Protégé-OWLAPI introduces some extension to OWLAPI. It is only used by Protégé. Current Protégé use 3.2.6 version of Protégé-OWLAPI. You can clone protégé-owlapi from its GitHub page by using a command in git command line. You should get protégé-owlapi folder in your working directory.

git clone https://github.com/Protégéproject/Protégé-owlapi

Go to protégé-owlapi directory using a command “cd Protégé-owlapi”. To get version 3.2.6 in your current working directory run git checkout 5675ee7.

• OWLViz: Any version of OWLViz is fine by Protégé. So let’s get latest version of OWLViz. You can clone latest version of OWLViz by using a command in git command line:

git clone https://github.com/Protégéproject/owlviz

3. Building project from the set of source code

For each source code, we compile them in a same way. Run the following command in a command line.

mvn -DskipTests  clean  install  -Dmaven.javadoc.skip=true

Each tag has a different meaning. “clean” is to clean project repository; “Install” is to create all binaries and JAR files; “-DskipTests” is to skip running test files, and including the option to reduce the building time. “-Dmaven.javadoc.skip=true” is to skip building Javadoc documentation. The Figure 2 is shown below to represent the order of compilation.

Fig. 2. The order of source code compilation

If you change any point of this project, make sure you compile that project as well as all dependents of that project. For example, if you modify owlapi 3.5.1, please recompile in this order owlapi 3.5.1  Protégé-master  OWLViz.

V.   THE DESIGN AND IMPLEMENTATION OF SYNTAX EXTENSION

Working with OWL documents in textual format using some text editors can be quiet daunting. Interactive development environment provides necessary tools for us to work with OWL documents in a convenient manner. Knowledge base of a particular domain is encoded by domain experts in OWL documents. Interactive development environments for managing OWL documents are important for domain experts as they come from diverse fields and may not have necessary knowledge of OWL syntax. One of the popular interactive development environment for managing OWL documents is Protégé. Protégé project is supported by a strong community of academic, government, and corporate users, who use Protégé to build knowledge-based solutions in areas as diverse as biomedicine, e-commerce, and organizational modeling. Critical components required from any interactive development environment by domain experts include creation of knowledge library, import and export of knowledge library, and validation of knowledge library. For domain experts to make proper use of our proposed syntax, we must extend all these core functionalities of Protégé to support our syntax extension.

There are four essential components of Protégé project OWLAPI, Protégé owlapi, Protégé master and OWLViz. OWLAPI is used for parsing and rendering OWL documents. It also provides essential APIs and data structures for modifying in memory ontology objects. Protégé-owlapi is used for some extensions to OWLAPI. Protégé master is used for UI components of protégé project. OWLViz is a plugin provided by Protégé for visualization of ontology currently loaded in Protégé. In this section we will first present modifications to OWLAPI followed by modifications to Protégé owlapi, and present modifications to Protégé master, then Protégé UI components and OWLViz plugin.

1. OWLAPI

Parsers, renderers and data structures are three core components of OWLAPI. OWLAPI consists of many parsers for parsing different variations of OWL syntax like Manchester syntax. OWLAPI uses RDF/XML format parser for OWL documents written in XML syntax. We modified the RDF/XML format parser of OWLAPI as our syntax deals with OWL documents written in XML format. RDF/XML parser uses SAX parser to parse XML documents. A stack of states is maintained by the RDF/XML parser to direct the flow of the parsing process.

We introduced new state RelationRestrictionElement to parse restrictions of our relation element such as transitive restriction. This state will be pushed to stack of states in the RDF/XML format parser whenever we encounter restriction in a relation declaration. RDFConsumer component is responsible for taking actions based on instructions from the RDF/XML format parser. We introduced appropriate modifications in RDFConsumer to handle instruction concerning syntax for declaring relation and syntax for relating one concept to another.

OWLAPI provides a set of renderers for storing an ontology in a document. As in case of parsers there are various renderers handling different variations to OWL syntax. Our proposed syntax mainly deals with RDFRenderer. We introduced two new methods renderRelations and renderClass. The first one is used for rendering declaration of new relations. The second one is used for rendering relation between two entities or classes.

The third and most important component of OWLAPI is the internal data structures for representing the OWL documents. We introduced three new data structures in OWLAPI. The first one is OWLRelation. Namespace, simple name and different restrictions of a new relation like whether it is transitive or not is stored in this data structure. This data structure provides standard APIs for getting and setting namespace, simple name and different restriction. Different kinds of relations that can be represented in this data structure are asymmetric, functional, inverse functional, irreflexive, reflexive, symmetric and transitive. The second data structure provided is OWLRelationInstance. A class in OWL can have many relation instances. Each relation instance holds information regarding a single relation from this class to another. For example, if class A is related to class B by relation R, a relation instance will hold information regarding class B and relation R. It will also provide APIs for modifying relation and the related class in question. The third and last data structure provided is OWL Relation Instance Container. A class in OWL will have exactly one container and it will contain all relation instances of that class. It provides APIs concerning addition and removal of relation instances from the container in question. Apart from these data structures we provide three functionalities in an ontology object of OWLOntology. The first functionality is the addition and removal of an OWLRelation object. The second functionality handles requests for addition and removal of relation instances in a class. The third important functionality is for management of relation change listeners. We invoke each of the listeners whenever a change to relation has been made. You can add and remove your own listeners. This functionality is important for plugins which use relation as we can signal them whenever a change has been made in a relation.

OWLAPI has many parsers for different variations to OWL syntax. If you open a Protégé document tries to parse it using all parsers one by one. If it finds a parser which don’t give an error, it would stop. Parser of our interest is RDFXMLParser. Flow of reading an OWL document is shown as Figure 3.

Fig. 3. Reading an OWL document in OWLAPI

RDFXMLOntologyStorer is called by Protégé to store an ontology to a specified file. It calls RDFXMLRenderer to do all rendering. RDFXMLRenderer use XMLWriterImpl to perform actual writing to file inside a document system. It also uses OWLOntologyXMLNamespaceManager to manage namespaces of current ontology. RDFXMLRenderer implements RDFXMLRendererBase, which implements some of the functionality of RDFXMLRenderer. Dependency graph for writer can be represented by following Figure 4.

Fig. 4. Writing an OWL document in OWLAPI

2. Protégé owlapi

Protégé owlapi introduces some extensions to owlapi. It is only Protégé no other application using owlapi. For example, owlapi does not provide write safe ontology whereas Protégé-owlapi. We did not introduce any extension to Protégé-owlapi but as we are introducing new APIs in OWLOntology so we must declare them in WriteSafeOWLOntologyImpl which is implementing OWLOntology. As you can see in all implementations we are simply passing execution to delegate which is our original OWLOntologyImpl object. Our modification to WriteSafeOWLOntologyImpl are: add relation, remove relation, get relation, print all relations functions and so on.

3. OWLViz

OWLViz tool is used for visualization of ontologies currently loaded in Protégé. Among various documents present in OWLViz, one of interest is AbstractOWLClassGraphModel. It forms base of all other graph models if we include our edges in this model it will be displayed in OWLViz. As you can see we are calling our APIs in OWLOntology to introduce edges created using our proposed syntax. After using the updated OWLViz plugin, we can use it for visualization of custom relations as shown in Figure 5. The figure shows that engine is part of car. There is no support for visualization of relations created by workarounds [28]. Visualization is a key component of various applications so we modified OWLViz to support visualization of relations using our proposed syntax.

Fig. 5. Visualization using OWLVIZ

4. Protégé master

Protégé provides various extension points like view extension, tab extension and menu extension for developers to extend functionality of Protégé project. For creating new relations, we introduced a new view component in the entities tab of Protégé. The user interface for creating new relations looks like Figure 6. We introduced two more view panels, one for creating a relation instance from one class to another which is seen in Figure 7, and another for declaring relation properties which can be seen in Figure 8.

Fig.6. UI for creating new relation

Fig.7. UI for creating relation instance

Fig.8. UI for declaring relation properties

VI.   PROPOSED SYNTAX FOR NEW RELATIONS AND ITS USAGE

Before proposing a syntax extension, we lay down our criteria for a good syntax. Firstly, a syntax extension for new relations should allow users to introduce multiple new relations with a way to declare properties of the relations. Second, the syntax for new relations should be concise, consistent and similar with the syntax of the subclass relation. Third, it should be intuitive without resorting to artificial secondary concepts such as object properties for emulation. Domain experts should be able to use it easily and directly. Thus, there should be minimal conceptual and syntactical overhead [29]. Fourth, a logic reasoner such as Hermit must be able to support the new syntax [30]. We should be able to derive new knowledge based on this enriched syntax. Visualization of the new relations between classes would be a nice addition. Industry standard tools like Protégé and OWLAPI should have support for the proposed syntax.

Our proposal consists of two parts. The first part deals with the declaration of a new relation with its properties. DTD syntax for creating a new relation is as follows:

<? xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?> <!DOCTYPE rel:NewRelation [ <!ELEMENT  rel:NewRelation  (rdf:type* )> <!ATTLIST    rel:NewRelation xmlns:rel CDATA #FIXED “http://www.pace.edu/rel-syntax-ns#” xmlns:rdf CDATA #FIXED “http;//www.w3.org/1999/02/22-rdf-syntax-ns#” rdf:about CDATA #REQUIRED> <!ELEMENT  rdf:type EMPTY> <!ATTLIST     rdf:type  rdf:resource                           ( &owl;AsymmetricRelation| &owl;FunctionalRelation| &owl;InverseFunctionalRelation| &owl;IrreflexiveRelation| &owl;ReflexiveRelation| &owl;SymmetricRelation| &owl;TransitiveRelation)       #REQUIRED> ]>

The second part deals with declaring a relation between two concepts. Our proposed syntax currently uses dynamic tags depending of relations that are already declared therefore we can’t present DTD syntax for this case. Syntax in XML format is as follows:

<! — Syntax for applying new relation. –> <owl: Class rdf: about=”#URI_ClassA”> <!– Create a relationship from Class A to Class B with relation whose simple name is sName –> <rel:sName  rdf_resource=”URI_ClassB”/> </owl: Class>

As an example we illustrate the creation and usage of the transitive relation “PartOf” below, and illustrate it in Figure 9.

Fig.9. Visualization of part-of relation

<rel:NewRelation rdf_about=”#partOf”> <rdf:type rdf: resource=”&owl;TransitiveRelation”/> </rel:NewRelation> <owl:Class rdf: about=”#HiddenField”> <rel:partOf rdf: resource=”#HtmlForm”/> </owl:Class>

We present another simple ontology example illustrating usage of user defined relations in conjunction with “is-a” relation. This is small subset of a popular camera ontology. Figure 10 illustrates this example.

Fig.10. Visualization of camera ontology

<rel: NewRelation rdf_about=”#hasSpec”/> <rel: NewRelation rdf_about=”#ownedBy”/> <owl: Class rdf_about=”#Digital_Camera”/> <owl: Class rdf_about=”#Photographer”/> <owl: Class rdf_about=”#Point_And_Shoot”> <rdfs:subClassOf  rdf_resource=”#Digital_Camera”/> </owl: Class> <owl: Class rdf_about=”#SLR”> <rdfs:subClassOf  rdf_resource=”#Digital_Camera”/> <rel:hasSpec  rdf: resource=”#Specification”/> <rel:ownedBy  rdf: resource=”#Photographer”/> </owl: Class> <owl: Class rdf_about=”#Specification”/>

Our syntax specifies custom relations between classes in similar manner as we specify an “is-a” relation, thus it is easy to use by domain experts.

Our proposed syntax uses a feature beyond the capability of DTD or XML Schema as a new tag is introduced for each user defined relation. This approach may be controversial but the benefits from it such as conciseness, clarity and resemblance to inheritance outweigh the associated additional development effort to support it. Currently, OWL domain experts use various workarounds to simulate such custom relations, but they are based on the use of intermediate concepts such as object properties. This leads to the loss of clarity in the code, and mixing of different concepts.

Our solution is straightforward, separating these different concepts, and bringing clarity. This is in line with the thought processes of domain experts, without using artificial concepts for representation.

There are several limitations associated with these workarounds as stated in the section two, e.g. relations need to be dynamic. They should be able to change as new knowledge become available, but the structure of object properties is static therefore relations created using object properties are incapable of qualifying as true relations. Another type of limitations arises from the fact that restrictions in relations and object properties behave in a different manner. For example, we cannot express the fact that a crankcase can be part of at most one engine using object properties. In this case if we set maximum cardinality of crankcase to one it will not work, as partOf is a transitive relation and engine is partOf car. Therefore, crankcase will be part of both engine and car. Other side effects of using workarounds include higher computation and memory cost in many cases. Our proposed syntax gets rid of all these limitations. Additionally, it is very intuitive in the sense that it is almost similar to the primary relation supported by OWL, which means the custom relation can be used as the first-class relation like “is-a” in any level.

Other kinds of workarounds use annotations to represent and visualize custom relations [31]. This approach only facilitates visualization, while providing no other advantages. Those annotations cannot be used by a logical reasoner to make inferences. We cannot derive new information. On the other hand, the logical reasoner can make use of the information coded using our approach. We have yet to make changes to the reasoner Hermit to do reasoning based on custom relations.

In contrast to other approaches for visualization, this is an integrated solution, wherein we have a GUI for defining new relations, constructing ontologies with the new relations, and visualizing the created ontology, with slight modification to Protégé and OWLViz. Thus, our syntax satisfies the aforementioned criteria.

VII.   THE APPLICATION OF CUSTOM RELATION IN THE KNOWLEDGE-DRIVEN INTELLIGENT SYSTEMS

1. Drug Side Effects Inferencing using custom relations in Knowledge-driven Intelligent Telehealth

Drug adverse reaction data contains important constraints about side-effects and conflict avoidance of component and compound drug. These are critically important in checking out prescriptions to avoid complications. Although website MedWatch FAERS drug data are in XML format, it doesn’t have a proper knowledge representation mechanism to clearly specify all kinds of dependencies among the drug components and drugs. Therefore, one has to depend on human interpretation to check prescriptions which can be error-prone.

The newly introduced OWL based approach for medical drug data representation still suffers from several shortcomings inherent to the OWL restrictions like using “is-a’ relationship and usage of object property based workarounds losing the clarity and dynamic relationship building expected by domain experts to represent knowledge. It’s often difficult for the domain experts to process and derive meaningful information quickly for patients or doctors.

Drug side effect relationships are highly transitive in nature and often inherit, important adverse reaction constraints from their compound drugs, which is not represented in the current OWL. Since OWL only supports is-a relationship the domain experts are left with the option to use workarounds using object properties which don’t behave the same way as true relationships during interpretations.

In this domain, the developer can use custom relation of our extending OWL to link all of drug and drug side effects concepts. So that drug domain data can be easily understood by machines allowing them to process and derive meanings for doctors. The visualization of extending OWL in drug domain is shown as Figure 11.

Fig.11. Visualization of custom relation in drug domain

2. Knowledge-Driven Tutoring System for effective Cyber learning by custom relations

Tutoring systems are computer-based learning systems that should present human-like tutoring capabilities in order to be intelligent. Tutoring systems are expected to be able to adjust the content and delivery to students’ characteristics and needs by analyzing and anticipating their effective responses and behaviors. However, contemporary tutoring systems lack of the ability in dynamically offering instructions according to learners’ needs. The main challenge of this issue is that relations between knowledge objects cannot be effectively recognized by computers, such that the course design is usually formed.

In this domain, the tutoring system can go beyond the “is-a” relation and use custom relations of the extending OWL to link all of courses concepts. So that the learner can be provided the recommended feedback. The recommended feedback consists of evaluating learner’s outcome and semantically mapping learner to learning path using recommended resources. The visualization of extending OWL in tutoring system is shown as Figure 12.

Fig.12. Visualization of custom relation in tutoring system

3. Diverse address business data in e-commerce domain using custom relations

Worldwide retail e-commerce sales reached $1.915 trillion in 2017 and double-digit growth will continue through 2020 with sales topping $4 trillion. There is a huge growth of popularity in e-commerce and internet technologies have led to the creation of great amount of business data. The context of e-commerce application requires that an effective communication channel between machines. Semantic interoperability between the information systems involved in the data exchange and communication is crucial.

Since the same type of business data is often represented by many different syntaxes in the same domain, we need to maintain a large growing pool of different versions of semantic constraints, which could easily lead to chaos and consistency errors. This problem is finding a cost-effective means of validating data from disparate sources to successfully reduce the complexity of documents caused by multiple similar dialects. It seeks to provide a way of handling the semantic constraints complexity in a uniform way by using ontology technology. But there are many relations between the metadata of address information, we must use the custom relation to emulate the concept set. The visualization of extending OWL in e-commerce domain is shown as Figure 13.

Fig.13. Visualization of custom relation in e-commerce domain

VIII.   CONCLUSION AND FUTURE WORK

In this paper we discussed more effective knowledge representation in OWL. Currently OWL only support the “is-a” relation, and does not provide a mechanism for representing custom relations between concepts in an ontology; our work rectifies this limitation of OWL/Ontology. A minimal set of syntax extension to OWL is introduced so domain experts could declare custom relations with various mathematical properties concisely, and apply them between concepts as they do for declaring the “is-a” relation between concepts. The Protégé project has been revised to support custom relation declaration, application, visualization, and usage in any knowledge-driven intelligent systems. We are ready to extend OWL inference engines so they could derive new knowledge from the knowledge bases enriched by our custom relation support.

References

1. M. Horridge and S. Bechhofer, “The OWL API: A Java API for working with OWL2 Ontologies” OWLED 2009, 6^th OWL Experienced and Directions Workshop, Chantilly, Virginia, October 2009.
2. M. Horridge, S. Bechhofer and O. Noppens, “Igniting the OWL 1.1 Touch Paper: The OWL API” OWLED 2007, 3^rd OWL Experienced and Directions Workshop, Innsbruck, Austria, June 2007.
3. S. Bechhofer, P. Lord and R. Volz, “Cooking the Semantic Web with the OWL API” 2^nd International Semantic Web Conference, Sanibel Island, Florida, October 2003.
4. R. Goncalves, M. Horridge, M. Musen, et al, “Protégé,” Stanford.edu, May 2009. [Online]. Available: http://Protege.stanford.edu [Accessed: July. 4^th, 2015]
5. W3C Technology and Society Domain, “Semantic Web Best Practices and Deployment Working Group,” W3C.org, October 2006. [Online]. Available: http://www.w3.org/2001/sw/BestPractices [Accessed: July, 10^th, 2015]
6. W3C Technology and Society Domain, “Ontology Engineering and Patterns Task Force,” W3C.org, April 2006. [Online]. Available: http://www.w3.org/2001/sw/BestPractices/OEP  [Accessed: July, 10^th, 2015]
7. J. Cui, Y. Zhang and C. Xing, “Build the Image File Catalog System Based on the Subdivision of Part-Whole Ontology”, Web Information Systems and Applications Conference (WISA), Haikou, China, November 2012, pp. 229-232.
8. C. Maria Keet and A. Artale, “Representing and reasoning over a taxonomy of part-whole relations”, Ontological Foundations of Conceptual Modelling, vol. 3, Issue 1-2, pp. 91-110, January 2008
9. Mejino Jr, J. Agoncillo, Augusto, Rickard and L. Kurt, “Representing complexity in part-whole relationships within the foundational model of anatomy”, In: Proc. Of the AMIA Fall Symposium, pp. 450-454, 2003
10. Gene Ontology Consortium, “Documentation”, June 1999. [Online]. Available: http://geneontology.org/page/documentation [Accessed: July, 5^th 2015]
11. Gene Ontology Consortium, “Ontology Relations”, June 1999. [Online]. Available: http://geneontology.org/page/ontology-relations   [Accessed: July, 5th 2015]
12. Gene Ontology Consortium, “Gene Ontology obo-relations”, June 1999. [Online]. Available: http://code.google.com/p/obo-relations  [Accessed: July, 5th 2015]
13. B. Glimm, I. Horrocks, B. Motik, G. Stoilos and Z. Wang, “HermiT: an OWL 2 reasoner”, Journal of Automated Reasoning, vol. 53, No. 3, pp. 245-269, 2014
14. Morales-Gonzalez, Fernandez-Reyes and Keet. C.M, “OntoPartS: a tool to select part-whole relations in OWL ontologies”, 9^th Extended Semantic Web Conference(ESWC’12), Heraklion, Crete, Greece, pp. 29-31, May 2012
15. Liyang. Yu, Introduction to the Semantic Web and Semantic Web Services, Chapman and Hall/CRC 2007, ISBN: 978-1-58488-933-5
16. C. Maria Keet, “Introduction to part-whole relations: mereology, conceptual modelling and mathematical aspects”, KRDB Research Centre Technical Report. KRDB Research Center, Faculty of Computer Science, Free University of Bozen-Bolzano, Piazza Domenicani 3, 39100 Bolzano, Italy, 2006
17. C. Maria Keet, “Build position ontology for geography repository”, Geography Information World, vol. 1, No. 4, pp. 248-259, 2008
18. A. Yang, et al, “The Geo-ontology’s building and comparison in GIS”, Journal of Wuhan university information science, vol. 12, pp. 1108-1111, 2006
19. S. Schulz, M. Romacker and U. Hahn, “Part-whole reasoning in medical ontologies revisited–introducing SEP triplets into classification-based description logics”, Proceedings of the AMIA Symposium, pp. 830-841, 1998
20. P. Gerstl and S. Pribbenow, “A conceptual theory of part-whole relations and its applications”, Data Knowledge Engineering, vol. 20, No.3, pp. 305-322, 1996
21. C. Hudelot, J. Atif and I. Bloch, “Fuzzy spatial relation ontology for image interpretation”, Fuzzy Sets and Systems, vol. 159, No. 15, pp. 1929-1951, 2008
22. H. Stenzhorn, E. Beibwanger, S. Schulz et al, “Towards a top-domain ontology for linking biomedical ontologies”, MEDINFO 2007, IOS press2007, pp.1225-1227,2007
23. Sette, M., Tao, L., Gai, K., Jiang, N.: A semantic approach to intelligent and personal tutoring system. In: The 2^nd IEEE International Conference of Scalable and Smart Cloud (IEEE SSC 2016), Beijing, 25-27 June 2016
24. Asamoah, C., Tao, L., Gai, K., Jiang, N.: Powering filtration process of cyber security ecosystem using knowledge graph. In: The 2nd IEEE International Conference of Scalable and Smart Cloud (IEEE SSC 2016), Beijing, 25-27 June 2016
25. Alipui, G., Tao, L., Gai, K., Jiang, N.: Reducing complexity of diagnostic message pattern specification and recognition on in-bound data using semantic techniques. In: The 2nd IEEE International Conference of Scalable and Smart Cloud (IEEE SSC 2016), Beijing, 25-27 June 2016
26. Jayaraman, S., Tao, L., Gai, K., Jiang, N.: Drug side effects data representation and full spectrum inferencing using knowledge graphs in intelligent telehealth. In: The 2nd IEEE International Conference of Scalable and Smart Cloud (IEEE SSC 2016), Beijing, 25-27 June 2016
27. Patel, k., Dube, I, Tao, L., Jiang, N.: Extending OWL to support custom relations. In: IEEE 2^nd International Conference on Cyber Security and Cloud Computing, pp. 494-499, New York (2015)
28. Sette, M., Tao, L., Jiang, N.: A Knowledge-Driven Web Tutoring System Framework for Adaptive and Assessment-Driven Open-Source Learning. In: 41st IEEE Annual Computer Software and Applications Conference, COMPSAC 2017, Turin, Italy, July 4-8, 2017.
29. Lixin Tao.: Extending OWL with Custom Relations for Knowledge-Driven Intelligent Agents. In: Multiagent System Technologies – 15th German Conference, MATES 2017, Leipzig, Germany, August 23-26, 2017
30. Jiang, N., Tao, L.: A Knowledge-Based Approach to Reducing Complexity of Maintaining Semantic Constraints in Data Exchange and Integration. In: The 5th IEEE International Conference on Cyber Security and Cloud Computing, Shanghai, China, June 23-25, 2018
31. Jiang, N., Qiu, M., Dai W.: SROC: A Speaker Recognition with Data Decision Level Fusion Method in Cloud Environment. In Journal of Signal Processing Systems 86(2-3). DOI: 10.1007/s11265-015-1100-7