Contributions by: Piotr Nowara (Invited Expert of the Decision Incubator)
Purpose of the sample decision ontology
The purpose of this document is to describe the Decision Ontology in the context of its intended use. This is not a proposal for a standard ontology, merely an illustration of how a core Decision Ontology might look like.
What is a Decision Ontology?
The Decision Ontology (DO) provides basic means for describing decisions and decision-making. It is formalized in the Web Ontology Language (OWL) and can be accessed at here. The current DO prototype is intended to evolve and be extended with additional features as the work on the decision format progresses, and consensus is reached in the community.
The image below illustrates some of the core classes of the ontology, and their properties. The ontology imports and uses several ODPs for describing decisions, e.g. the Situation ODP and the Criterion Setter ODP. Below the image (Figure 1) is an excerpt of the statements contained in the ontology, in this case showing the preliminaries and the definition of the decision class itself, expressed in an XML serialization of OWL.
Figure 1: An illustration (created through TopBraid Composer) of some of the core classes and properties of the DO.
<rdf:RDF xmlns="http://decision-ontology.googlecode.com/svn/trunk/decision.owl#" xml:base="http://decision-ontology.googlecode.com/svn/trunk/decision.owl" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:cpannotationschema="http://www.ontologydesignpatterns.org/schemas/cpannotationschema.owl#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:question="http://question-modeling.googlecode.com/svn/trunk/question.owl#" xmlns:situation="http://www.ontologydesignpatterns.org/cp/owl/situation.owl#" xmlns:decision="http://decision-ontology.googlecode.com/svn/trunk/decision.owl#"> <owl:Ontology rdf:about="http://decision-ontology.googlecode.com/svn/trunk/decision.owl"> [...] <owl:imports rdf:resource="http://question-modeling.googlecode.com/svn/trunk/question.owl"/> </owl:Ontology> [...] <owl:Class rdf:about="&decision;Decision"> <rdfs:label xml:lang="en">Decision</rdfs:label> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty rdf:resource="&decision;indicatesAcceptedSolution"/> <owl:someValuesFrom rdf:resource="&owl;Thing"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="&question;isAnswerFor"/> <owl:someValuesFrom> <owl:Restriction> <owl:onProperty rdf:resource="&question;initiates"/> <owl:someValuesFrom rdf:resource="&decision;DecisionMaking"/> </owl:Restriction> </owl:someValuesFrom> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="&question;isResultOf"/> <owl:someValuesFrom rdf:resource="&decision;DecisionMaking"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="&situation;Situation"/> <rdfs:comment xml:lang="en">Recognizing something as the right/appropriate/best possible solution to the initial question/problem. What validates this act could be an objective evaluation of clearly defined criteria but also an intuition, emotion or other subjective factor.</rdfs:comment> </owl:Class> [...]
What it can be used for?
In general, there are two main usage scenarios for such a core DO:
* archiving current or historical decision-making processes and their outputs (data-driven use) * outlining decision-making scenarios (patterns, templates) in order to provide guidelines for the decision-makers (normative use)
Combining these two approaches would enable confronting the normative descriptions with actual decision-making data and thus giving sophisticated means for analyzing archived decisions which could be particularly useful for validation purposes.
Recording facts by using OWL individuals. DO provides a conceptual framework and semantic foundation for analyzing decision-making data. The OWL file can be filled with data that can be used in many ways.
Modeling decision-making patterns by defining OWL classes containing an outline of a generic decision. This could be useful for representing knowledge derived from some legal regulations, requirements, industry standards or obtained from domain experts. What can be achieved here is a description of the domain decisions enabling new ways of sharing, understanding, reusing this knowledge (for example by users of common standards, clients seeking information etc.).
The OWL file here contains a simple example: a decision-making case of choosing the appropriate therapy for a patient, used to illustrate the data-driven scenario mentioned above. It covers the following stages:
STAGE 1. A patient is diagnosed with a bacterial throat infection. The doctor needs to decide what treatment would be most appropriate. In order to prescribe the right drug he/she has to know whether or not the patient has an allergy for the drugs being considered for prescription and some parameters to evaluate correct dosing rules.
STAGE 2. Patient P1 returns with some symptoms of allergic reaction, which suggests that P1 has allergy for Penicillin. The doctor decides to prescribe the other antibiotic.
A complex process that starts with a question and may result in indication of a an answer being solution to the initial problem. It is important to note that a decision-making is something substantially different than decision, which is an output of the process of deciding. Usually it can be represented by the following pattern:
In most cases stages 2-3 consist of many (concurrent or sequential) actions, events, processes related to information gathering, processing, verifying etc. In some cases a decision-making can be viewed as a complex process involving many “sub-decisions” preceding the recognition of the initial problem solution. In our current work we have focused on the basic elements of the above pattern (the question, gathering information, considering options, choosing solution). It should be considered to what extent the DO should support the modeling of correlated issues such as: information verification and retrieval etc.
Allowing different criteria for identity (or continuity) of the decision-making
Sometimes it may be hard to tell when one decision-making ends and the other begins. Even in the mentioned example: is it a single decision-making process or two distinct ones connected with each other by the same issue they both concern? The case could become even more complicated when dealing with subdecisions and decision-processes with changing participants. It seems appropriate to leave that issue open enabling the core decision ontology to be extended with modules containing various solutions of that particular problem.
Decision as an outcome of decision-making process
There is a fundamental ontological difference between the process of deciding and its outcome - a decision. Moreover, allowing more elastic boundaries of decision-making (see above) can result in single decision-making having more than one decision as its outcome.
Allowing incomplete decision-making stages
In some cases it may be useful to record a decision-making stage even if it doesn’t have any decision as its outcome. For example a patient may be ordered some further tests which may last a couple of days in which some other crucial parameters of decision-making can change resulting in a new stage of the deciding process (the newly recognized facts may encourage to continue modelling with a new stage of decision-making).
Representing temporal context
This is a general methodological issue, that still implies many discussions. Some of these discussion involve well-known ontology experts unable to find a reasonable consensus. The main problem is: how to represent the mutable entities or the change of their properties in an ontology? What I did in my example is using OWL individuals to represent the same person in different stages of the decision-making process. What would be needed in a real-life application is to add some property which could allow the unambiguous reference to a person (for example insurance number). This is necessary because during decision-making one would often ascribe different or even contradict attributes at different stages of the process. Additional benefit: using different instances to provide “snapshot” view of reality allows developing fine-grained view of the reality - consider an example from my scenario: the throat infection diagnosed at t1 is represented by different OWL individual than the same kind of infection diagnosed at t2 (after the allergic reaction), which illustrates that the medical disorder has probably undergone some change and may require a different treatment. This approach is one of the possible choices and the users of DO will have to decide whether or not it satisfies their needs.
The decision ontology should provide a foundation for modelling decision-making on different granularity level. Ideally, the decision ontology would consist of basic decision ontology and a set of modular extensions enabling more detailed modelling for more advanced use scenarios. When possible the core classes should be general enough to enable using them in different ontological and methodological contexts (for example we should not make assumptions about the definition of a “process” because existing ontologies use different definitions of a process). So in order to enable scalability and wide adoption we should try to avoid or at least minimize making ontological assumptions about concepts originated from other domains. It seems that the successful adoption of decision ontology will probably significantly rely on the capability to be used as basis for community-based extensions.
In the figure below (Figure 2), another possible module of the decision format is illustrated, modelling the decision making process, rather than the actual decision (cf. illustration above). This model is based on the Transition ODP, and models a decision process as consisting of a set of states and transitions between those states. A transition is initiated by some event and affects some object.
Figure 2: An illustration (created through TopBraid Composer) of a potential extension including the decision process modelled as a transition between states.
1. develop extensions of the core DO for modeling of: 1. information gathering, processing and verification 2. decision metrics 3. decision-making criteria 2. implementing a use case 3. develop detailed documentation.