COSMOS: A Web-Based, Collaborative Knowledge System Using Ontologies and Managing Uncertainty Michail Giannoulis Department of Informatics Engineering, Technological Educational Institute of Crete, Heraklion, Greece
[email protected]
Haridimos Kondylakis FORTH-ICS N. Plastira 100, Heraklion, Grete, Greece
[email protected]
Emmanouil Marakakis Department of Informatics Engineering, Technological Educational Institute of Crete, Heraklion, Greece
[email protected]
kind of sources (e.g. experts) and converting to formalistic explicit knowledge (i.e. rules) [1].The quality of decision making depends a lot on the quality and quantity of the underlying/supporting knowledge base. Although for decades, efforts have been made to create knowledge systems that can simulate brain functions in decision-making [2], [3], [4], [5], [6], judging from the state-of-theart in knowledge systems there is a lack of sufficiently supporting temporal data [2], [3], [5].
ABSTRACT The huge diversity, big quantity of data and information, and the requirements for knowledge extraction out of them put new challenges for knowledge management, synthesis, conflict detection and reasoning. In this paper, we present COSMOS, a knowledge system that fully addresses these challenges, in an efficient way, paving the way for a new generation of knowledge systems. Using our approach, it is possible for domain experts to generate temporal knowledge rules. As those rules are saved to our knowledge base, a conflict detection mechanism detects and solves rule conflicts. Then, an inference engine is able to perform efficiently, accurate decisions, based on available factual information using reasoning and handling uncertainty. Ontologies are used to model both the factual information and the data items in the rules enabling also interoperability with existing systems. To validate our approach, as an application scenario, we deploy our infrastructure in a health environment where doctors provide rules that are activated over a patient health record. Preliminary results indicate the benefits of our approach for decision support based on health data, successfully identifying adverse events and enabling intelligent patient monitoring.
Consider for example that we are interested in identifying a possible kidney failure for a patient out of his symptoms. In addition, we would like to propose also a hemodialysis scheme to kidney failure patients. Table 1 shows two example rules trying to capture this information. Rule 1 is a standard if-then rule, representing non-temporal knowledge, which can be expressed in state-of-the-art knowledge systems. However, Rule 2 although intuitive, is not supported by current state of the art. This is because it includes temporal restrictions, specifying the duration and the time sequence of an event. We argue that temporal information (i.e. how long, when, how many times, etc.) should be effectively captured and handled, especially in the field of medicine. Table 1. Example rules for kidney patients (extracted from http://www.healthline.com)
CCS Concepts
Rule 1: if patient feels weakness and shortness of breath and lethargy and swelling and confusion then there is a possibility of having a kidney failure. Rule 2: if patient has kidney failure and the Glomerular Filtration Rate (GFR) is lower than fifteen then the patient has to do hemodialysis for 5 hours every 48 hours.
Computing methodologies → Knowledge representation and reasoning
Keywords Temporal Reasoning, Temporal Rule, Collaborative Update, Conflict Detection, Uncertainty
In addition, existing systems usually focus in a single domain or disease (e.g. cardiology). However, there is a need for more complex reasoning scenarios, where rules from different knowledge domains are combined in order to derive a decision. For example, consider a real-world scenario of a patient with cardiac problem, where a knowledge system has to be able to make a decision combining rules of three different knowledge domains, cardiology, oncology, and dermatology. Moreover, generating those rules is an error prone and time-consuming process. Collaboration between the domain experts has the potential to increase the quality of the captured knowledge.
1. INTRODUCTION A Knowledge System (KS) is an information system supporting a decision making process. Through the use of a KS, decision makers are able to find solutions to various problems, including problems that involve multiple attributes and goals. Knowledge systems are directly linked with knowledge management to enable business and scientific decision making. Moreover, knowledge management can be described as the practice of capturing knowledge from different Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. PETRA '18, June 26–29, 2018, Corfu, Greece © 2018 Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-6390-7/18/06…$15.00
In this paper, we present a knowledge system, called COSMOS, effectively supporting the real time collaboration of experts, as well as the management of their knowledge for any problem domain. In addition, COSMOS has a powerful inference engine which combines both event-driven and goal-driven reasoning. In eventdriven reasoning the inference engine is provided with the facts trying to derive a decision, whereas in goal-driven reasoning a decision/goal is provided to the inference engine and the engine tries to identify the facts that led to this decision. We deploy our
https://doi.org/10.1145/3197768.3201555 441
infrastructure in a health environment showing the benefits of our approach. More specifically the contributions are the following: • We present the architecture of the COSMOS, a collaborative, web-based knowledge system using ontologies and managing uncertainty (Section 2). • We describe the syntax and the semantics of the temporal rules supported by COSMOS. At the same time, we show how uncertainty is embedded in those rules (Section 3.1). • We present the syntax and semantics of the data items which are used to model available factual information (Section 3.2). • We include an inference engine for handling temporal rules, and data items able to handle uncertainty (Section 4). • We propose an effective method for knowledge conflict detection between temporal rules (Section 5). • We present the cross platform and collaboration features of COSMOS for creating more accurate rules through a user friendly interface (Section 6). • We describe precisely how COSMOS is able to support knowledge and experts from a large and over-time extendable range of knowledge domains (Section 6). • We compare our system to the state-of-the-art knowledge systems showing the benefits of our approach. (Section 7, 8) and the potential impact when used for health data monitoring. To the best of our knowledge, COSMOS [7], [8] is the only system combining temporal rules, a powerful inference engine handling uncertainty, conflict detection and possess collaboration features.
•
•
•
2. ARCHITECTURE
•
The main components of COSMOS are a knowledge base, an inference engine and knowledge management tools, using state-ofthe-art techniques and libraries, while at the same time containing multiple APIs and controllers. The COSMOS system is available online and can be accessed through the internet (http://www.cosmoss.duckdns.org:8082).
• •
•
updating specific rules. The import function imports automatically data objects from possibly connected external sources (in our case an external Personal Health Record System). Finally, the reasoning function, enables an expert to use the inference engine. The External Authentication Manager actually, is a list of supported external platforms through which the domain experts can be authenticated. Currently, accounts for Google and from an external personal health record system (iPHR [9], [10]) are supported, but the list is extensible. The authentication procedure is implemented through the Expert Authentication Controller. The Ontologies Search Platform is an external system that uses Apache SOLR [11] to enable elastic match and ontology annotations to the terms provided by the users when constructing the rules. Currently the SNOMED-CT, EDAM, ICD-10, FMA, GENETICS, FOOD, DRUGS and Computer Network (CN) ontologies (https://bioportal.bioontology.org) are used but the tool is extensible supporting other ontologies as well. External Entity Provider. Besides being able to authenticate users using external applications, it is possible, if those external applications provide the necessary APIs, to import available information as well. The simplicity of the adopted internal data model (entity-relation model) and the flexibility/generality of the mechanisms provided by our platform make the connection to an external application a really simple task. As an application scenario, again we used as an external entity provider the iPHR system providing information about the medical history of patients supervised by a doctor (an expert). Graphical User Interface (GUI): all COSMOS features are available through a user-friendly and intuitive GUI. An appropriate Restful API is available for communicating with other systems and sharing all available information. The Long-term Memory is the persistence layer of COSMOS for storing knowledge and data. It contains two parts: (a) the Database, (b) the Knowledge Base. In the Database, data and metadata are stored about Experts (e.g. personal data, actions, requests, etc.) and data items (e.g. attributes, entity, owner, etc.). In the Knowledge Base the rules are stored either in their executable or their draft form. The Short-term Memory is the temporal storage layer of COSMOS. All executable temporal rules are loaded at runtime in this short-term memory and the reasoning process can then be applied in the available data items.
3. KNOWLEDGE AND DATA In this section, we present some basic notions underlying our approach. In Section 3.1, we present a general knowledge model for temporal rules, which will be used throughout the paper. In Section 3.2, we present how we model data items. Figure 1 - Architecture of COSMOS
3.1 Temporal Rule
The architecture of the system is in Figure 1. More specifically, the components of the system are the following: • The Core Knowledge System is the inference engine of our knowledge system. It uses two models: (a) Event-Driven Model (EDM), (b) Goal-Driven Model (GDM) (refer to Section 4). • The Collaborative Knowledge Management System is in charge of providing functionalities for creating, cloning and collaborative updating temporal rules, sending collaboration requests, importing data and reasoning on object entities. The clone function creates an exact copy of a specific rule, while at the same time generating a parent-child relationship between the original and the copied rule. The function of collaborative update enables experts, in real-time or asynchronously, to collaborate for
A temporal rule (TR) is an independent piece of knowledge in a concrete knowledge domain. A TR is a sequence of temporal conditions that should hold in order for a temporal result to be produced. Furthermore, weights are used in the form of certainty factors, in order to declare the certainty of specific rule parts [7], [12], [13]. Bellow we define in detail the corresponding parts forming a rule. Certainty Factor. COSMOS uses the Certainty Theory to model TR’s certainty factors [14]. There are four different Certainty Factors: • Condition CF represents the expert’s confidence, for the specific condition to hold.
442
• Temporal Rule CF represents the expert’s confidence for the entire TR to hold. • Evidence CF represents the system’s confidence, for all conditions to hold, combining in essence the confidence of the individual conditions. For example, if two conditions are connected logically with conjunction, then the formula keeps the minimum Condition CF between them. Otherwise, if two conditions are connected logically with disjunction, then the formula keeps the maximum Condition CF between them. • Result CF represents the system’s confidence for the result of the rule to hold. The formula that COSMOS uses to express that is: Result CF = (Evidence CF * Temporal Rule CF)/100
time between each other. The result of a rule is also a condition, which it is called result condition or simply result (CR). Example 1. Consider the result condition (CR) of the rule 2 in Table 1: “then s/he has to do hemodialysis for 5 hours every 48 hours”. By using Def. 2, this sentence is transformed into the following expression: CR = (hemodialysis, (CRV, =, true), _, 50, (_, (CRD, =, 18.000), (CRB=, 172.800), _)). The underscore symbol (_) is used for undefined variables, i.e. variables with no values. The Name of this condition is the ontology term hemodialysis from the SNOMED-CT ontology and the Value of this condition is the (CRV, =, true). The Unit of this condition is not declared. The CF of this condition is 50%, which is the default value of a CF. The Event of this condition is (_, (CRD, =, 18.000), (CRB=, 172.800), _), where the StartPoint is not declared, the Duration is (CRD, =, 18.000), i.e. 5 hours, the BreakTime is (CRB=, 172.800), i.e. 48 hours, and the Repetitions field is not declared
Instead of using the range [-1, 1] for certainty factors, as in the original certainty theory [13] (-1 the maximum uncertainty and 1 the maximum certainty), according to our experts (clinicians), it was more natural to adopt a different scale [0,100] where 0 stands for absolute uncertainty and 100 absolute certainty. In case the experts leave a certainty factor undefined, the default value is set to 50. Next, we define a temporal rule.
Table 2. Example temporal rules for Table 1 Temporal Rule 1 Meta-Data: MD = (50, (R1, Nephrology, Patient, _, _, _, _)). Precondition DNFC: C1 and C2 and C3 and C4 and C5. C1: (weakness, (C1V, =, true), _, 50, _). C2: (shortness of breath, (C2V, =, true), _, 50, _). C3: (lethargy, (C3V, =, true), _, 50, _). C4: (swelling, (C4V, =, true), _, 50, _). C5: (confusion, (C5V, =, true), _, 50, _). Result Condition: CR: (kidney failure, (CRV, =, true), _, 50, _). Temporal Rule 2 Meta-Data: MD = (50, (R2, Nephrology, Patient, _, _, _, _)). Precondition DNFC: C1 and C2. C1: (kidney failure, (C1V, =, true), _, 50, _). C2: (GFR, (C2V,
