See also: IRC log
<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.
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.
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.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Jeff Waters Found ScribeNick: jeffw WARNING: No "Present: ... " found! Possibly Present: Aaron ScribeNick jeffw piotr You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://www.w3.org/2005/Incubator/decision/wiki/Decision_Mtg_17_Agenda Got date from IRC log name: 11 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/11-decision-xg-minutes.html People with action items:[End of scribe.perl diagnostic output]