If I might add $.02---First, it is often important to
recognize the line that separates workflow/functions, explicable to
stakeholders and users, from design/implementation.
"Decision support" is "above" the line, because
system designeres should be able to communicate the type of support users
receive in language they understand; "ontologies lie
"below".the line, because of the technical knowledge needed to
appreciate them. "Documents" are above the line, because they
are directly readable by users. Ontology structures are, again, below,
because they are primarily machine readable.
What I don't see discussed in KM postings---and perhaps I misunderstand
scope or realities---is knowledge representation (KR): transforming
above-the-line knowledge into computable formats other than ontologies,
such as rules, guidelines, logic rule bases, probability networks, etc.
I
s there a reason why the focus on KR seems always to be on the ontology
to support document access and retrieval rather, as was mentioned, than
the decisions (alternatives) and utilities/tradaeoffs, as well as other
decision-theoretic concerns, like underlying probabilities, structures,
time horizons, outcomes, applicability, and perspectives? (acronym: You
SHOULDT: You (perspective), Structure, wHo (applicability), Outcome,
Uncertainty, List of aLternatives, Desires/traDeoffs, Time
horizon).
Harold
At 01:07 AM 1/2/2008, you wrote:
Thanks for your
perspective. See my comments below.
On Tue, 1 Jan 2008, Phil Murray wrote:
> Ken --
>
> Excellent way to start the discussion. I agree with everything you
propose,
> but -- especially given the Project's broad goals ("The need to
effectively
> administer 'knowledge space' to yield meaningful connections that
are
> scalable and sustainable is a strategic challenge of all
institutions,
> whether that knowledge resides primarily within, outside, or across
an
> institution's span of control.") -- I would add some
perspective and points
> of emphasis. My comments are interspersed, below.
>
>
> On Jan 1, 2008 12:16 AM, Ken Baclawski <kenb@xxxxxxxxxxx>
wrote:
>
>
> KB> Welcome to the New Year! I propose that the first
"resolution" for the
> OKMDS community this year should be to examine the definition of
decision
> support.
>>
>> It is easy enough to define "decision support system"
to be a
> computer-based information system that supports decision making
activities.
> However, this says very little, since so many activities are related
to
> decisions in some way. As a result, decision support is a very
broad
> concept, and there are many different kinds of system that are
considered to
> be decision support systems. This may partly be due to the fact
that
> decision making is a process. A particular decision support
system will
> usually be designed for and have an impact on only a few parts of
the
> decision making process. The decision making process has at
least the
> following parts:
>>
>> 1. Acquire relevant background knowledge. This could
include other
> decisions.
>
> I would emphasize the *discovery* aspects of knowledge
acquisition.
>
> And the "knowledge" discovered should be expressed in a
way that is ...
>
> -- Easily understood -- in a variety of contexts -- by a broad
cross-section
> of participants.
>
> -- Retrieved and managed predictably and easily by
applications.
>
> -- Encapsulated in such a way that the decisions (or, perhaps more
broadly,
> the "assertions") can be referenced easily. (Also relevant
to your point
> #2.)
>
Excellent points.
>>
>> 2. Identify the alternatives from which a choice must be
made.
>
> Given the potentially very large set of assertions that could be
contributed
> in an open community, we need to address the negative in a positive
way --
> that is, we need explicit ways to quickly evaluate any assertion
as
> irrelevant. Separating the wheat from the chaff effectively is
especially
> important when making important decisions.
Agreed. It is important both to eliminate the irrelevant
alternatives and
to avoid missing alternatives that might not immediately be seen to be
relevant. However, this is a rather different notion of relevance
than
that used by search engines, even search engines that are sensitive to
ontologies.
>>
>> 3. Determine the criteria that should be used to distinguish
the
> alternatives from one another (typically in the form of a value or
utility
> for each alternative).
>>
>> 4. Select the best alternative.
>>
> Here's where the ambitious goals of the OKMDS community present a
challenge,
> which you also address in points #1 and #2 of "managing the
process," below.
>
>
> Decision support (whether in the model of military situational
awareness or
> in making decisions that reflect enterprise business strategy)
typically
> involves a limited set of alternatives and a relatively small number
of
> vetted participants. The "collaborative environment" of
the OKMDS needs
> scalable methods and tools for evaluating assertions.
>
> One of the first things we need is to have participants in this
community
> help identify the strategies and technologies that most effectively
enable
> distributed evaluation of a *large* set of alternatives. Of course,
I'm not
> talking about a popularity contest. This isn't "American
Idol." (Give
> yourself 5 culture points if you *don't* understand the reference.)
Or Digg.
>
> If John Sowa, Leo Obrst, Pat Hayes, or Ken Baclawski submits an
evaluation
> of an assertion, that evaluation should be worth more than, well,
mine. Is
> this where we get into some form of Social Network
Analysis?
There is a place for popularity in a democracy. In that context my
vote
is worth the same as any other. However, it would much better if
the
choices presented to the electorate were in terms of the outcomes
(utilities) rather than the alternatives. The role of the experts
should
ideally be to elucidate and quantify the relationships between the
alternatives and the outcomes. This is where there is a distinction
between individuals and where social network analysis could be
valuable.
>
>> Both knowledge management and ontologies can play a role in each
of these
> parts. They can also play a role in managing the process, such
as:
>>
>> 1. Manage the process workflow in structured decision making
processes.
>>
>> 2. Provide a collaboration environment for decision making.
>>
>> 3. Manage the documents associated with the process.
>
> But, as noted above, not just the documents ... or multimedia. We
also need
> to manage the decisions themselves.
Agreed. However, that is what I meant by #1 and #2 above.
-- Ken
>>
>> I suggest that this framework could be the starting point for a
more
> in-depth discussion of decision support.
>>
>> Kenneth Baclawski
>> College of Computer and Information Science Northeastern
University
> Thanks,
>
> Phil Murray
> Founding Member
> The Center for Semantic Excellence
http://www.semanticexcellence.org
>
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/okmds-convene/
Subscribe:
mailto:okmds-convene-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe:
http://ontolog.cim3.net/mailman/listinfo/okmds-convene/
Shared Files:
http://ontolog.cim3.net/file/work/OKMDS/
http://ontolog.cim3.net/cgi-bin/wiki.pl?OKMDS
To Post:
mailto:okmds-convene@xxxxxxxxxxxxxxxx
*******************************************************************************
Harold P. Lehmann, MD PhD
Associate Professor, Health Sciences Informatics
Joint: Pediatrics, Health Policy and Management
Johns Hopkins University
2024 E Monument St, 1-201
Baltimore, MD 21287-0007
Phone 410.502.7569; 443.287.6083
Fax 410.614.2064
lehmann@xxxxxxxx
http://dhsi.med.jhmi.edu
WARNING: E-mail sent over the Internet is not secure. Information
sent by e-mail may not remain confidential.
SISCLAIMER: This e-mail is intended only for the individual to whom it is
addressed. It may be used only in accordance with applicable laws. If you
received this e-mail by mistake, notify the sender and destroy the
e-mail.
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/okmds-convene/
Subscribe: mailto:okmds-convene-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/okmds-convene/
Shared Files: http://ontolog.cim3.net/file/work/OKMDS/
http://ontolog.cim3.net/cgi-bin/wiki.pl?OKMDS
To Post: mailto:okmds-convene@xxxxxxxxxxxxxxxx (01)
|