Phil Murray wrote:
> This is actually rather humorous -- not because it is wrong or
> unreasonable in any way, but because this is one classic perspective
> on "knowledge management" (KM) ... and because the majority of KMers
> decided that [this] was not possible and/or not the right thing to do. (01)
I plead first that my reports of what CEOs think they want are pure
hearsay. They are summations, or more accurately my interpretations, of
what I have been told, either directly or by other consultants. "... I
only relate what was told to me by the Chinese plate." And I was (I
thought) re-affirming Toby's observations from another industry. (02)
I only offered that I see some advantage in ontologies vs information
modeling and other technologies in addressing these needs. (03)
My experience is that KR technologies are still largely impractical for
business applications, but precisely because, apart from the work of
people like Martin Hepp, there is very little formalized knowledge that
is available off-the-shelf. As a consequence, it takes a large
investment to get anything useful out. (04)
Finally, I think Phil and I have only slightly different perspectives on
the following: (05)
I wrote: (06)
>> The problem with delivering any of these results is tying the bell on
>> the cat's neck. Some team of knowledge engineers has to get down and
>> dirty with the text resources and the individual company practitioners,
>> and tease out and formulate all of the knowledge that is presumably
>> resident in them. And then the knowledge engineers have to go back to
>> many of these resources to resolve some of the confusion and conflict.
>> That is an expensive process for the CEO, ... (07)
Phil wrote:
> Well, first of all, if you view the solution solely from the
> perspective of C-level personnel (on the one hand) or
> technologists/knowledge engineers (on the other hand) you've already
> lost the battle. (08)
The point I was trying to make is that there is a significant investment
involved here, and without the commitment of upper management, that kind
of investment simply won't be made. (09)
> The desirable starting point is the relationship between communication
> and work as a method of producing value, efficiencies, or improvements
> -- *not* representing and reconciling concepts, although the latter is
> also essential. (010)
What Phil means, I think, is that nature of the analysis is not "what
all do we know", but rather, "who needs to know what" in order to get
his job done, or to do it better or differently. I fully agree. And
for upper management that comes down to: what do I need to know in order
to make good decisions about what we should and should not be doing. I
also believe that is the underlying concern that begot the comments I
summarized. (011)
Everyone agrees that analysis and engineering (knowledge and otherwise)
is about what is relevant to the problem you are asked to solve. The
problem for ontology development is that you need a lot of foundation
before you can build the relevant hut. (012)
For example, we have multiple published ontologies for basic concepts
like process and time, and you have to pick a pair that actually work
together, just to be able to talk about "work". But the pair you choose
must also be consistent with the business unit understanding of
"process". Organizations do scheduled things and orchestrated things
and event-driven things and ad hoc things and their priorities and
performance assessments and capability assessments and value assessments
are partly based on which of those dominates a domain of activity. As
one colleague observed, "if I am restricted to Petri Net semantics, I
can't capture what some of my clients do". And that is pure
foundational stuff -- it is largely separable from what the actual tasks
and events are -- but it has everything to do with whether your
reasoning engine will be able to make any sense of your operations models. (013)
This is why KR is still relatively impractical for any large business
undertaking. We need to get the foundational ontologies out there, so
that each project doesn't have to build them on the job. And we need to
pick and choose our targets of opportunity carefully, in order to
establish credibility and encourage further investment. (014)
[EU Framework Programme 7 has an objective to do this kind of thing, but
it very much depends on finding academic/industry teams that have a
useful solvable problem and the talent to do good reusable knowledge
engineering in the process of solving it. And in my experience, if any
team actually succeeds, it will form a company for whom that foundation
and the associated talent is its protected IP and its applicability to
other real industry needs is its value proposition.] (015)
-Ed (016)
P.S. We are not allowed to have any pompous titles. Officially, I have
been "Computer Scientist" for 30 years, with a few meaningless
management titles along the way. One of my colleagues in industry
thought his proper title would be "Corporate Engineeering Knowledge
Repository"; another suggested "Fire Fighting Consultant". :-) (017)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (018)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (019)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|