Draft Final Report

From Decision XG
Jump to: navigation, search

Final Report - Decision-Making Incubator Activity

The following Final Report summarizes the major findings and accomplishments of the Decisions and Decision-Making Incubator Activity. The final report describes a pre-study and motivation for the development of a (semantic) format for representation of decision information.

To provide the reader with an overview, detailed information regarding the topics can be found on the pages linked from the main headings, while a summary of the same content is given directly on this page.

Abstract

What if there were a standard format for representing decisions on the web and in our organizations? What might it look like and what could it do for us as individuals, our organizations and the web overall? The Decisions and Decision-Making Incubator Activity explored this question over the last year, including use cases, requirements and formats for representing decisions in a machine-understandable format. In fact, a standardized decision format would allow the decisions that occur everyday to be managed, archived, shared, and tracked. Two key benefits include the ability to expand and advance the meaningful use of web linked data, as well as the ability to tie-in domain knowledge to provide decision context. This final report captures the major accomplishments and results of the incubator activity. The report ends with a recommendation that the activity transition into a W3C Working Group for the establishment of a Decision Markup Language (DecisionML).

Introduction

The mission of the Decisions and Decision-Making Incubator Group, part of the Incubator Activity, is to determine the requirements, use cases, and a representation of decisions and decision-making in a collaborative and networked environment suitable for leading to a potential standard for decision exchange, shared situational awareness, and measurement of the speed, effectiveness, and human factors of decision-making.

The time and effort we spend converting our decisions into work products, such as briefs, proposals, and communication of decisions in meetings, conversations, and emails, could be reduced if we had a standard format for representing and sharing decisions. Our tools could be instrumented to generate our decisions in a format that could be shared and also track the state of decisions within the decision-making process. Instrumentation could support the development of a metric of information flow and help us optimize our decision processes across our organization or enterprise. Visibility of the decisions in their formation and evolution would enable proactive management and assistance from others.

This final report of the Decisions and Decision-Making Incubator Activity summarizes the finding and accomplishments of the activity, including the approach, usage scenarios, requirements, components and potential formats. The report ends with a set of recommendations, including the recommendation to form a Decisions and Decision-Making Working Group to formulate a formal W3C Recommendation for representing decisions.

Background and Need

We all make important decisions in the daily accomplishment of our duties. The aggregate of these decisions constitutes the current state of our organizations, and charts the course for our future direction and progress. In a sense, our decisions represent us as individuals and the organizations we represent. The effective representation, management, evaluation, and sharing of these decisions determines the success of our enterprise. Especially in a distributed, self-organizing, networked environment where digital media are the main interaction among members, distribution and tracking of decisions is particularly important for understanding what others are doing. Our decisions serve as information-work products; both as inputs and outputs. We use others decisions as references and our decisions become references to the decision process of others. The significant time and effort we spend converting our decisions into work products such as briefs, papers, proposals, and communication of our decisions in meetings, teleconferences, conversations, and emails, could be recaptured if we had a standard concise format for representing and sharing our decisions. Our tools could be instrumented to generate our decisions in a format that could be shared and also track the state of decisions within the decision-making process. Instrumentation could support the development of a metric of decision flow and help us understand and optimize our decision processes across our organization or enterprise. Visibility of the decisions in their formation and evolution would enable proactive management and assistance from others.

For these reasons, the members of the Decisions and Decision-Making Incubator are exploring and determining the requirements, use cases, and a potential standard format for representing our decisions efficiently and effectively in a collaborative networked environment for the purpose of information exchange for situational awareness. To reach its full potential, the proposed decision format must be extended by the Semantic Web tools and standards to provide semantic interoperability and to provide a basis for reasoning that can ease development of advanced applications. Simplicity and understandability of decisions is particularly important in distributed, dynamic settings such as emergency management.

The work performed by this incubator activity is designed to help organizations improve integration of human decisions into computer systems, to digitally track and manage the decision-making process, to enable improved information-flow metrics, to maintain an archive of the decisions and the decision-making process, to enable semi-automation of certain decision-making processes, to improve information sharing, and ultimately, to support better, rapid, and agile decision making.

The potential standard format should provide concise, generic, structured assessments and decisions that allow "drill down," support pedigree and confidence, enable approvals and vetting, define options considered, including decision criteria with weighting, links to previous decisions and sub-decisions, and support flexible structuring of complex decisions.

Scope

The potential Working Group following this Incubator Activity is to specify a format for representing decisions, so they can be used across diverse systems. Because of the great variety of applications and decision technologies, this format will focus on the generic, core components of decisions and decision-making information. This mission is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing, as seen in several application areas:

  • Decisions as an information source. Decisions themselves represent a valuable form of information for which there is not yet a standard interchange format.
  • Decisions as a means of communicating. Decisions could be the representation of choice for communicating status between information systems.
  • Decision-making and sharing as a Semantic Web use case. As part of the Semantic Web architecture, decisions can provide a broad, important and useful representation for demonstrating the significance of and empowering the application of the OWL Web Ontology Language and the Linked Open Data initiative.

The work performed aims to help organizations improve integration of human decisions into computer systems, to digitally track and manage the decision-making process, to enable improved information-flow metrics, to maintain an archive of the decisions and the decision-making process, to enable semi-automation of certain decision-making processes, to improve information sharing, and ultimately, to support better, rapid, and agile decision making. However, the main focus is on how to express and represent information about decisions and decision-making, and not on how to perform the actual decision making task.

Related Work and State of the Art

Much of the inspiration of this incubator has come from the side of traditional decision support research, e.g. the definition and description of what a decision really is, as well as applications in the emergency management domain, where decision-making plays a crucial role. These areas have provided the basis of our work, as well as providing usage scenarios.

When considering decisions one can distinguish between a traditional view of decision making, and more complex views involving additional aspects. The traditional view describes decision making as a three-step process; (1) Identify the alternatives, (2) study the implications of each alternative, and (3) compare the alternatives based on criteria, such as goals, purposes, constraints and pressures, and finally pick one of the alternatives as the decision. In addition to this, a decision may also be viewed as a piece of knowledge. This knowledge can be descriptive, i.e. describing some commitment to future actions, but it can also be procedural, i.e. describing how to actually perform those actions. This knowledge based view of decision making actually results in the conclusion that decision making is also a process of knowledge creation, i.e. we are creating some new knowledge, which is a representation of the decision, based on a set of premises.

Although many decision support systems provide quite elementary support and leave the reasoning and actual decision-making to the human user, it is at least obvious that many of these systems use some sort of model of 'relevance' when providing information to the user, or apply some criteria or special-purpose procedures on the information. Such notions might be more useful if they are made explicit, e.g. what does relevance mean in a specific case? What criteria were applied? How can we represent the fact that this information is used as the basis of a certain decision-making process? Can we learn from others by studying what information was used in other processes? For the more advanced systems it soon becomes evident that the system could also benefit from some learning capabilities, e.g. to keep track of what previous decisions have been made, on what grounds, and what the outcome was, and the possibility to drill-down into the motivation of a decision proposal. To support such functionalities a system must have a formal representation of decisions.

Sharing decisions across a broad and diverse set of users and systems is an important aspect of situational awareness in many domains. Perhaps no domain needs such capability more than the domain of emergency management. During an emergency, a diverse set of decisions must be shared among emergency managers and first responders from multiple organizations, jurisdictions, and functional capabilities. The Organization for the Advancement of Structured Information Systems (OASIS) has a family of emergency management standards known as the Emergency Data Exchange Language (EDXL). Together, these emergency management XML-based standards provide a more machine-friendly format for exchanging emergency information in a non-proprietary manner. An important next step for improved sharing of emergency information is to utilize the semantic web standards, to enable the conversion of the XML-based information into the more flexible RDF format as needed and show the ability to integrate the various emergency management information for dynamic queries across datasets, for inferencing with underlying ontology support, and for enabling a more expressive format for representing policies.

This, and experiences from other domains, imply that one of the fundamental developments that drives this work is the emergence of the Semantic Web, and in particular the endorsement by the W3C of a set of standards for the Semantic Web. The incubator has explored this as a foundation for developing an interchange format for decisions, and among Semantic Web and Linked Data applications we can also find some of the applications that inspire new possible usages of a decision representation format.

Requirements Analysis

This section describes the work performed by the incubator to elicit requirements for a potential standard decision representation format. The intention has not been to gather all possible requirements of such a format. That would be the task of an official standardization effort. Rather the aim has been only to gather enough requirements to show that (i) such a format it needed, and (ii) typical requirements are in fact feasible to realize using current Web and Semantic Web standards.

Requirements Analysis - Methodological Approach

Usage scenarios and use cases were mainly gathered from the experiences of the incubator participants, as well as invited experts and invited speakers in the incubator meetings. Usage scenarios aim at giving high-level descriptions (from a user perspective) of scenarios when a potential decision format would be useful. From these scenarios, more specific ("lower-level") use cases can be derived, i.e. describing specific tasks that a decision format should be able to perform or support. Based on those use cases, a set of high-level requirements have been developed, which in turn are broken down into individual Competency Questions (CQs), i.e. requirements on the query- and reasoning level of the format. Competency Questions are today commonly used in Ontology Engineering to express a certain type of requirements for an ontology, i.e. the type of queries that the representation should be able to support. For more complex tasks, CQs need to be combined with descriptions of reasoning requirements and other constraints that are needed for the task. Finally, the orthogonal aspect of security has been taken into account, in order to investigate what requirements the security aspect sets on a decision format.

Usage Scenarios

The following usage scenarios express idealized situations where we envision that a standard decision representation could in the future be useful and support functionalities that are today poorly supported, from a user perspective. To see full scenario descriptions, click on the heading above. Below, a short summary of each scenario is given.

Selecting Among Alternatives

Sarah is trying to select a city to visit on her vacation. She has a limited time and budget and a specific geographic region she is planning to visit. She has access to a variety of web resources describing the cities, their amenities, museums and schedules. Through a web interface Sarah can specify her question, and her preferences, and is then presented with a set of choices to select from. When she makes a selection her decision is saved, together with the options she considered and the metrics she used to make the decision, and the decision can then be displayed on her calendar, timeline, maps, and shared with her friends on her social networks.

Capturing Expertise

Sue is an expert in her domain with 25 years of experience. Sue is a valuable resource for her organization and her community. She is consulted on a variety of matters and her judgment and assessments are highly valued. Fortunately, her decisions and methods of decision-making are represented in a standardized format which allows those decisions and their components to be archived, searched, reused, and managed on the web. Others can review her decision process. Her metrics for certain types of decisions, as well as other decision components, can be reused by others. Sue also has control over this information, meaning that she can set different access restrictions on parts of her decision information.

Collaborative Decisions

Soraya is the chair of a working group at a standards organization. She remembers that when she participated in previous working groups, it was difficult for many, other than long-time participants, to understand the issues and their resolution. During the course of email and telecon discussions over a period of months, her working group participants would make many key decisions that impact the form of the final product. It was difficult for new members and non-participants to understand what were the issues, the options, the pros, the cons, and why certain decisions were made. Fortunately, Soraya's group now has the ability to capture the decisions, the questions, the options, the pros/cons, and the metrics during the meetings and discussions utilizing tools that support the standard decision format. The decisions can be linked, viewed, mapped, and the resolution method noted, along with any dissenting opinions. New participants can now quickly get up to speed.

Historical Decisions

Adam is a historian focusing on reviewing and considering the decisions made by key leaders of organizations which preceded a man-made disaster. Many decisions were made and the sequence and combination of the decisions led to the disaster. The historian is able to document each decision, the sequence of these decisions, and the resulting combined assessment in a machine-understandable format. This allows the historian to use tools for viewing, mapping, searching, and managing the historic decisions and sharing them with other researchers.

Emergency Management

A fire at a chemical plant has released a harmful chemical that is now forming a plume which will move over a portion of the city. Emergency managers are instigating evacuation plans and an important decision is to select among the proposed evacuation routes based on the current conditions. Fortunately, as part of the planning, the decision has already been stored in a machine-understandable format that can be retrieved and all relevant authorities notified that the evacuation route decision is being considered, including details on the options and metrics for evaluating the options. One of the agencies responsible for infrastructure notes that a key overpass is closed due to a repair and updates the options from a remote location. Civilians and rescue workers that are moving through the disaster area are using their mobile phones to enter information about the situation in their location. Within moments, the best of the pre-planned evacuation routes is recommended and a decision made.

In each case, conventional decision technology is enhanced not only by the usual economies of standardization, but also by the ability to exchange and merge decision data from different sources.

Use Cases

Inspired by the motivating usage scenarios the incubator has described a set of use cases, in order to derive more specific requirements of a potential format. The incubator chose to focus on the following (non-exhaustive) set of use cases:

  • Measuring Information Flow (decision states): This use case is derived from the need to analyze decision processes and possibly even measure the speed of information flow within an organization or enterprise. The decision process can be modeled as a sequence of states, some of which involve information gathering or information packaging and distribution.
  • Open Linked Data: This use case is derived from the need to make good use of open linked data and the need to use, as the subject matter for decisions, information which is already represented in a machine-usable semantic format. Currently, decisions are either not represented in a computer understandable format, or are represented in a proprietary format, or are represented in a format consisting largely of free text (such as e-mails, reports, or slide presentations). Recording both decisions themselves, and the information they are based on, in a machine-usable semantic format would be of great benefit.
  • Metrics for Automatic Assessment: This use case is derived from the need to make and document reasoned, rational decisions. Often a decision is made and there is no record of what criteria or metrics were used in the process and how they were weighted and what thresholds were considered. The result is that the decisions may appear arbitrary or ill-considered. The ability to easily access and reuse decision components, such as metrics, is not well supported. The rationale behind a decision is often not apparent to those not involved in the decision process. A format that can explicitly express the metrics and criteria of the decision would be of great benefit.
  • Interoperability: This use case is derived from the need to be able to exchange information in a standards-based way to properly inform decision makers of all available possible outcomes, i.e. a classical motivation for standardization as such.
  • Situational Awareness: This use case is derived from the need to understand the status of the organization. Every employee is a decision-maker at some level. An effective decision representation standard could be implemented in tools to enable capturing the real-time status related to decision-making, for example what decisions are being considered, where are we in the decision process, and what options are being considered. The combined representations could provide a real-time snapshot of the applied knowledge of an organization.

Requirements

From the use cases described previously, as well as the discussions during incubator meetings, a number of requirements have emerged. The set of requirements in this document should not be viewed as a final set of requirements for a standard decision representation format, but rather as exemplifying the need and usefulness of such a format in the first place.

The requirements can be classified in two broad categories, which can be compared to the classes of functional and non-functional requirements as used in software engineering. The functional requirements express things that should be possible to do with the format, e.g. to aggregate or retrieve certain information, make calculations etc., while the non-functional requirements express general characteristics of the format, e.g. modularity, ease of use etc.

High-level Functional Requirements

The functional requirements are divided into high-level requirements (HLR), and supporting Competency Questions [ref] (see extended version of chapter) that express particular information the format should be able to store and provide to applications and users exploiting it.

  • HLR 1: The format should be able to record basic information about decisions, such as what the decision was about, what information it was based on, what were the options, who made the decision etc.
  • HLR 2: The format should be able to support the assessment of efficiency of a decision process through describing time-aspects of a decision process.
  • HLR 3: The format should be able to support users to assess improvement in decision making from changes in organizational structure or tools designed to improve information flow.
  • HLR 4: The format should be able to support users to track individual information flow in the form of decision flow and time to process decisions across an organization, to measure capability and efficiency of innovation.
  • HLR 5: The format should provide the possibility to align a decision with some available set of data/information, e.g. open linked data.
  • HLR 6: The format should effectively represent the metrics used to evaluate the options, including the weighting and thresholds given to those metrics by the decision-makers.
  • HLR 7: To support the representation of the current operational picture of some operation or organization, along with anticipated actions of operational individuals driven from operational data.
  • HLR 8: To support the representation of the status of the organization through the capture and analysis of its decisions.

Non-functional Requirements

Non-functional requirements include requirements on the understandability, reusability and means of using the format.

  • The format should be easy to understand by different user groups, such as web developers and decision makers in organizations.
  • The format should be modular, in the sense that reusing it should not imply having to reuse all aspects of the decision representation, rather just reusing the part/components that expresses elements relevant to particular needs.
  • The format should be expressed based on web standards, such as XML, RDF and OWL, in order to be easily exchangeable and interpreted by applications on the web.
  • The format should provide different levels of expressivity, e.g. ranging from a simple XML format to an OWL ontology, so that users can choose the level of expressivity that is needed in a specific case.

Security

We begin by making the distinction between a decision-making process about security and the security, or accessibility, parameters of components of the decision-making process. A decision-making process about security might include the decisions needed to secure a corporate computer network. The security, or accessibility parameters, of each component of the decision-making model refers to who can know about particular parts of the decision and under what conditions. The following discussion concerns the latter issue of providing security meta-data to individual components of a decision-making process. To better understand how we might use security in the decision-making model, consider a decision-making model for a marketing plan created during a strategy meeting by the board of directors of a large company. Decision points in the marketing plan may reference confidential intellectual property of the company itself, or confidential intellectual property of partnering companies obtained through non-disclosure agreements, or sensitive financial information from all participants. Awareness that the marketing plan used this information and the details of this information should have accessibility restrictions placed on components of the plan, so that only particular information components go to the right people in the right departments of the companies involved.

Security management of components of a decision process generalizes to a three part restriction based on the hierarchical level of the recipient, the release group to which the individual belongs, and whether the person needs to know that part of the decision. Access to a particular detail of a decision means a person must be at the appropriate hierarchical level, belong to a group to which that decision detail has purview, and have a need within that group to have access to that decision detail.

Security management, including security hierarchical levels, release groups, and need to know descriptors included in decision meta-data, affords several benefits. First, security management improves the ability and willingness of people and organizations to share their decisions. Second, security management improves the ability to deliver the right information to the right person at the right time. Third, security management addresses the issue of tracking controlled information. Security management is most effective and efficient if the information managed is modular, which allows the security to be applied in a granular way on only those components that require it. This modularity also has other benefits, such as the opportunity to tailor the information flow to the receiver and avoiding information overload.

Towards a Decision Format

In addition to studying the need for a decision representation format, and its potential requirements, the incubator activity has also drafted some potential solutions. The intention has been to show the feasibility of such format, e.g. represented in common web standards such as XML and RDF/OWL.

Format Development - Methodological Approach

In order to develop some drafts of potential decision representation formats meeting the requirements discussed previously, the activity adopted a highly modular approach. This means that first a set of requirements were selected, e.g. a subset of the requirements of one use case, and subsequently a format was developed to support that specific set of requirements. For the XML and pure RDF format examples below, much of the inspiration has come from the emergency management standards (see discussion in the state-of-the-art section), while the OWL vocabularies were developed 'from scratch' based only on OWL modelling best practices, such as Ontology Design Patterns (ODPs).

Analysis of Decision Components And Conceptual Patterns

Before moving to the actual modelling of different formats, we need to consider the theoretical implications of what a decision actually is (cf. the theoretical background given in the state-of-the-art section above). For instance, what are the primary components of a decision? For our purposes, we are interested in a decision format capable of representing a generic decision, independent of any particular domain, and we'd like the format to be relatively concise and understandable to a wide audience. Yet, we'd also like to represent enough information to allow a person who was not involved to appreciate more than just the final result. Moreover, what was the question being asked? What options were considered? On what basis were the options evaluated? How do we think about these aspects, and subsequently model these components? One solution is to look for patterns. Is the component something that is entirely unique to decision-making or is it similar to components used in other designs. Perhaps there is a design solution already addressing this pattern. If not, at least the identification of the pattern suggests other examples to aid with the design and allows us to develop a modeling solution which has the potential to be reused.

So let's consider the bare bones components of a decision and the implied patterns that exist in those components to drive our design:

  • The Core Components and the "Event" Pattern
    • The core components, i.e. the bare minimum, of a decision are those which you must know to gain any usefulness. Certainly, you'd like to know what was decided, which consists of two parts, first what question was being asked and second what was the answer. So the core components are (a) the question, (b) the answer, (c) the decider, and (d) the date/time of the decision. These components are basically the who, what, and when components that are used in many domains and could be considered part of an Event pattern, where an Event is anything that happens or could happen involving, for purposes of decision-making, a person or other entity capable of making a decision.
  • The Question and the "Statement with Variable" Pattern
    • Before a decision is made, there is an underlying question that is being asked. A question can be phrased as a statement with a variable where the variable represents an unknown item, and the decision process results in the variable being assigned to one or more known items. This pattern occurs regularly in all sorts of situations where one is inquiring, such as in search queries.
  • The Options and the "Filter" and "Aggregation" Patterns
    • For the question to appear as a decision question, the context must be one where the decision-maker has some control over the answer and there are reasonable options, so a decision normally implies multiple options. An option is simply one item among a category of items, any of which could be assigned as the answer to the question. This is a familiar pattern which occurs whenever we filter things. Also, the options may need to be aggregated in some manner, for example in the form of a list. So we should expect to see a Filter pattern and potentially an Aggregation pattern to enable the representation of options.
  • The Metrics and the "Normalizer", "Weighting" and "Aggregation" Patterns
    • Another aspect of decision-making is that there should be some rational basis for the decision, some rationale. The measures should be identified, and in many cases they are measurable and comparable in some fashion. Some measures are objective and some subjective, but for a measure to serve as a rational discriminator among options (re)usable by automated processes the measure must have some scale and some repeatable process for determining the value and a way to state that value. Metrics are an important component of the Filter pattern mentioned above. To filter or discriminate, one must have options and metrics which can be used to compare the options. What scale do we use that allows this cross-comparison? An effort to develop a common scale can be considered a Normalize pattern which occurs whenever two or more items must be compared across different aspects with different scale. Another aspect of metrics is that they may not all be given the same weight by the decision maker. For example, the decision-maker may consider cost more important than quality, or vice versa. This is a "Weighting" pattern which involves a common scale to adjust the relative importance of different criteria. Also the Aggregation pattern recurs here where multiple metrics may need to be combined into one set or list.
  • The Assessment and the "Ordering" Pattern
    • The assessment is where the metrics are used to discriminate the options based on the perceived qualities of those options. Although the assessment is more of an action than an information format, the results of the assessment are important for the information format. In the simplest sense, the representation of the assessment might simply be an ordering of the list of options, so this presents an "Ordering" pattern.
  • The Choice and the "Selection" Pattern
    • Finally, the selection of the decision-maker must be noted in the information format. This is the abstract conceptual "Selection" pattern and occurs wherever one or more items must be selected among many.


The above has been an initial look at key components of decisions and which generic conceptual patterns they imply in terms of information representation. The mapping of the components to their implied patterns is an important step for helping to proceed with the modeling of these components as reusable patterns.

Issues & Challenges

Some of the main issues encountered are concerned with modularity and reusability. The format needs to be useful both for simple use-cases as well as more complex ones (e.g. involving reasoning based on the semantics of OWL), and it needs to be easy to understand even for non-experts. By building an extendable format, i.e. with a simple core that can then be extended for more complex use cases, we hope to achieve this.

Developing Ontological Patterns and Solutions

This section contains some descriptions of the work process and analysis of the requirements and use cases that was carried out as a part of this incubator (for details, please click on the heading). The purpose is to give the reader and idea on one hand of how the incubator worked in order to reach its conclusions, and on the other hand to illustrate and exemplify the general process of proceeding from requirements to modelling solutions.

As basic sources of solutions, we used the Content ODPs available from the ODP Portal. Other interesting resources to reuse would be the LOD vocabularies (a list of common vocabularies is available here), however these were not considered at this time. Three of the use cases were studied more in-depth, i.e. UC1-3 above. For each use case, based on its specific requirements (see previous sections) possible solutions were analyzed and drafted. This means drafting OWL/RDF models that could realize the requirements, e.g. answer a certain set of competency questions. The modelling was done following the eXtreme Design methodology, and using modelling environments like Protege, TopBraid Composer and NeOn Toolkit (according to the individual preferences of the participants). In some cases Content ODPs are already available, and can be specialized and reused, while in other cases modelling had to be done from scratch. For instance, modelling decision states and state transitions can be done using the Transition ODP, creating specific classes for decision states, events and so on.

During the course of the incubator there was not enough time and resources to reach consensus on the models, nor to provide models solving all the requirements. This section, and the solution examples given later just intend to give a hint to what kind of solutions are possible, in order to solve the requirements listed previously.

Representation Formats - Solution Examples

To support a wide range of users, multiple representation formats are considered for any decision format. A traditional XML format is useful for a wide range of users who are familiar with and utilize common XML parsers and libraries. Although not as expressive or semantically able, the traditional XML format is easy to understand, useful for entering the basic data, and data can be converted into the more expressive RDF/OWL formats to enable querying across datasets and inferencing utilizing supporting decision ontologies and domain knowledge.

The goal of the Incubator Activity was to explore potential formats and several potential formats were considered. As a first example, let's look at a decision format using a traditional XML approach. Subsequently, we show an example of a format directly using RDF, and finally a sample decision ontology in OWL, representing a more expressive format.

Example Traditional XML

A schema describing an XML format is the Common Decision Exchange Protocol, for a listing of and excerpt of the XML code see detailed example by following the link at the heading above. The basic decision components are represented including the decision question, answer, options, and metrics in the form of pros and cons. In this example, an professor must make a decision about the topic for a research proposal. Two options are under consideration, Technique A and Technique B. The former has a couple advantages (pros), it has a short duration and is a high priority, but has a disadvantage (con), there are no current applications. Technique B has a disadvantage that it is not a favorite topic of this researcher. The decision has is currently in the "Information Gathering" state, and the basic info of who and where is provided. Unique identifiers in the form of URIs are provided for each component so that the components can be referenced and managed independently or combined as needed. So for example, the decision state or basic info could be referenced, rather than included, to save bandwidth.

One of the challenges with the traditional XML approach is that it is hard to dynamically combine information from different XML datasets, since XMLSchema usually prescribes the format of each schema. One way to overcome this limitation is to use, or convert to as needed, a more flexible and expressive markup format, such as the Resource Description Framework (RDF).

Example Resource Description Framework (RDF)

RDF is based on a graph model where each RDF statement is a triple (subject - property - value) resulting in a graph model. Subgraphs can easily be combined into a larger graph and then queries can be formed using the standard SPARQL query language. RDF is another format useful for representing decisions. For details of how to represent the same example as given in XML above in RDF, see the page linked from the heading above.

Sample Decision Ontology

Contributions by: Piotr Nowara (Invited Expert of the Decision Incubator)

The most expressive representation format considered here is the Web Ontology Language (OWL). With OWL, one has the advantage of being able to define properties among terms, such as class/subclass from RDFSchema, as well as symmetric, reflexive, transitive, functional, and equivalence. These properties enable inferencing and more flexible interconnection of decision components with components from other datasets such as those represented by the linked open data initiatives. An example of a potential OWL formatted decision is shown below, and details are given in the page linked from the heading above.

The Decision Ontology (DO) provides basic means for describing decisions and decision-making. It is formalized in the Web Ontology Language (OWL). 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, the Criterion Setter ODP, etc. Below the image 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 x: An illustration (created through TopBraid Composer) of some of the core classes and properties of the DO.


Decision-making process

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:

  1. Decision-making starts with a question.
  2. The decider gathers and analyzes some information
  3. The decider evaluates possible options.
  4. One of the options may get recognized as the right/appropriate/best possible solution to the initial question/problem or the decider may choose to restrain from choice. What justifies this act could be an objective evaluation of clearly defined criteria but also an intuition, emotion or other subjective factor.

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.

In the figure below, 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 x: An illustration (created through TopBraid Composer) of a potential extension including the decision process modelled as a transition between states.


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.


Scalability issues

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.


DO in Use - An example

This OWL file 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.

Looking Ahead

While the results of this incubator certainly are valuable as such, the most important result is the conclusion to proceed this work, and our suggestion on how this can and should be done.

Recommendations

Over the year of this incubator activity, the members have come to appreciate the significant need and importance of decisions and decision-making for advancement of the web. Based on the lessons learned, the following recommendations are made:

* A standardized Decision representation should be developed.
* A W3C Decision Working Group should be created for this purpose.
* The decision representation should consider multiple formats (XML, RDF, OWL) for broad application. 
* The decision representation should leverage semantic standards and linked open data.
* The Working Group should include representatives covering the major usage scenarios.

To help advance these recommendations, a Draft Working Group Charter has been developed. The representation formats and approach developed by the Decision Incubator provide a solid foundation for the advancement of the Working Group mission.

Conclusion

The members and invited participants of the Decisions and Decision-Making Incubator Activity would like to thank the W3C staff and the W3C members for the opportunity and support for exploring this important area of decisions and decision-making. The members have spent a fruitful year developing a sound patterns-based approach for developing a decision representation. They have explored the topic and discussed its importance for expanding the web in a number of key decision usage scenarios. The group concluded with this document summarizing the accomplishments and a recommendation to transition the activity to a working group for the development of a formal Decision representation.

Decisions are made by every user of the web, on every day of the year, on any topic of interest. Currently, these decisions go largely unshared, undocumented, and unmanaged. Even in the cases when decisions are carefully documented, it is often doen within a decision support system representing them in a proprietary format, not allowing them to be shared and integrated with other available information. The list of usage scenarios, use cases, and subsequent requirements presented in this report constitute the main contribution towards a standardization effort. Although the list is most certainly not exhaustive, it clearly points as the need of a shared and standardized format for (semantic) representation of decision information.

The members of this incubator recommend that a decision representation be finalized to enable all web users and other decision makers to document, share and manage this vital resource ... their decisions!