<scribe> Scribe: Jeff Waters

<scribe> ScribeNick: jeffw

jeffw: Welcome to the Nov 11, 2010 meeting of the Decisions incubator
... Today, we will (if we are lucky) get an update from Eva in Shanghai at the International Semantic Web Conference 2010.
... If we aren't so lucky, then I will move forward to present some updates that I have made to the Common Decision Exchange Protocol (CDEP) version 3 which
... is available here http://www.w3.org/2005/Incubator/decision/wiki/CDEP_Examples
... We'll also proceed around the call-in and see if we can get an update from the other incubator participants on their activities directly or indirectly related to our decision requirements and modeling efforts.
... Hi, Piotr
... Will you be calling in?
... We may have a light attendance today since it is a holiday, Veteran's Day, here in the states.

Welcome and Intro

jeffw: We are just past the midpoint in our incubator activity and it's been a fun, an opportunity more about modeling in particular using patterns approach which Eva has educated on,
... and is best represented ontologydesignpatterns.org to enable reuse and this has also given us an opportunity to consider what we mean by decisions
... What components, certainly like maybe there's a question, maybe there options, perhaps criteria, there's the notion decision states which might metric for measuring information flow
... (jeff summarized)
... Aaron: ways to represent domains are important, the terminology, how things are organized, is that sign
... there are specific domains such as emergency management but for this to be generic, the terms are more relevant to generic decision-making like metrics, options, answer, question

piotr: my goal is to develop underlying requirements for the decision-making process, I'm trying to develop a model for describing such requirements
... a domain expert to develop an ontology could be aligned to a format, and it can be complicated even for a domain expert and my primary goal is criteria helpful to those kinds of folks
... I will let you know when I make progress with my requirements ontology

Aaron: could you have multiple states simultaneously or maybe start time and end time, etc

jeffw: yes, certainly, and we should treat this as a living document

Aaron: we envision some people not needing to know all the details of the decision

piotr: The information gathering component is interesting because it deals with validation and great impact on the deciding process
... level of confidence is something we should add into our outline, for example in healthcare this could be very important

jeffw: I think if we setup a matrix showing how a format like this can be applied to say 4 different domains at 3 different levels of granularity, e.g. (1) quick, simple question, answer, datetime, who; (2) more elaborate with options and metrics; and (3) with normValues and weights and subdecisions
... then we can determine the significance of the decision format and draw out the requirements by iterating on an initial format, instrument a tool, try in testbed, gather feedback from users, improve the format and repeat the process.

CDEP XML format for decision-making

jeffw: actually, we've been discussing this already, but I put the topic title in now and I will summarize the examples that I was discussing (but unable to take notes because I was talking) :)
... Example 1 shows three decisions listed by reference. Each decision is represented by a URL (although these are fake urls). This example shows how it's easy to list a number of decisions concisely for any purpose.
... Example 1a shows the same three decisions referenced but with the basic info of who made the decision and when. The who is represented by a URL which serves as both a unique id and as a reference to more info on the person. The when is the standards xsd dateTime.
... The point of Example 1a is to show that a list of decisions can be represented concisely, but in addition to the URLs for each decision, a little bit of basic info can be
... included which is useful for situational awareness applications that may want to put these decisions on a timeline, or tag them to particular users, or display them on a map (although the lat/lon is not shown in these examples and needs to be added to the schema by reusing for example georss/GML Point)
... Example 2 shows the basic decision in the form of a question and answer. Any decision might be modeled in this manner, for example "Which evacuation route should we recommend? (Emergency Management domain)"
... Or "Which city should I visit on my vacation? (Travel domain)" or "Which computer should I purchase for my office? (Business domain)"
... In this example, the question is about which topic should be used for a research proposal. The answer is to develop a proposal based on technique A.
... The only other significant information is the basic info about who made the decision and when. Also the globally unique id (guid) for this decision is important
... both as a unique id but also as a URL reference for the more detailed complete decision information.
... A couple points to note. Modularized components of the decision can be hidden away concisely by using the URLs as a placeholder and reference. So
... the format is expandable as needed but not overly burdensome for those who just want to do simple representation of quick decisions.
... Example 3 introduces decision states. Rather than have a hard-coded set of enumerated types, the suggestion is to reference an externally managed list or ontology of states and then specify values from that list.
... In this example, there are two decision states noted "NotYetStarted" and "GatheringInfo". Each state has a dateTime at which it began. These states are useful
... for two reasons (among others), first the visibility which it offers others to know where we are in the decision process allows them to help us make good decisions.
... If our colleagues can see what decision we're considering, what options, etc. and where we are in the decision process, they can advise us if they have relevant information.
... Second, the time spent in various decision states can help us measure information flow. If we are getting the right information to the right person at the right time, for example,
... then we shouldn't have to spend much time in the state "GatheringInfo". By recording time spent in decision states, we can derive a metric for measuring information flow.
... In Example 4, we introduce options. For this decision, there are two options, represented in their most basic way, by simply noting the idea.
... For this sample decision about picking a research topic, the first option is to base the research on Technique A and the second option is to base it on Technique B.
... Only the title of the idea is shown here, but the schema provides for description, semantic triple, who, what, where, when, how, why and other items.
... One issue is the general sadness of simply using text fields with strings of text for sharing information. This treats the computer like a fancy telephone and we can do much better.
... however, we also want a format that can be used in this bare bones way to support current uses while allowing folks to grow into the better uses as those uses are shown to be effective in testbed efforts.
... The GRDDL specification, see http://www.w3.org/TR/grddl/, is a good solution for allowing automated conversion of this type of XML format into a semantic format, assuming the more detailed XML elements are utilized.
... Example 5 introduces metrics and the concept of modularized components. In this case, this example is not a decision or list of decisions, instead it is a list of metrics.
... In this case, the metrics are for a generic computer purchase and include cost, performance and warranty. Each metric comes from a URL-referenced externally managed ontology (that's the concept although these URLs are not active).
... Each metric has a Value from that list/ontology, and optionally can have a normalized Value to allow assessment/ranking of the options across all the diverse metrics
... and a weight so that a user can specify metrics but weight them as the user sees fit. For example, perhaps cost is weighted more than warranty.
... The concept is that our format should support both subjective and quantitative decisions (or perhaps one might think in terms of informal or formal decision processes).
... Sometimes metrics can be or are normalized and weighted, and sometimes they aren't. The format should support both types of users.
... This example also points out that metrics (and other decision components) can be modularized, referenced and reused, which is important for applications where an organization
... or other user has gone to the effort of developing a set of metrics for a given type of decision, or where someone wants to capture the expertise of a good decision-maker by reusing the good decision-maker's metrics in place of their own.
... Finally, Example 6 introduces pros and cons. For example, in this case of a research proposal, the first option has two pros and a con. The pros
... are that option 1 is within the appropriate time frame (in this example one year in duration) and it's a favored research area by this organization.
... The hypothetical con is that there are no current applications for this research. Note that these same concepts of pros, cons, metrics, options, question, answer can be applied to any other domain.
... The goal of these examples is to introduce in a measured, simple way the concepts of decision-making in an XML format that can be simple and concise for casual, subjective decision-making
... and yet expand as needed to more formalized sets of metrics, normalized values and weights for modular represenation and reuse of expertise and requirements.
... More expansive examples are possible and the near-term goal is to demonstrate the previously mentioned three levels of granularity across
... 4 domains of interest to explore and understand whether we are capturing the requirements for representing decisions in a flexible and usable manner.
... Thanks to everyone for attending and we will towards an iteratively improving and expanding modeling effort for our decision work.