I think I should apologize for rather snarky and facile comments on
your thoughtful post. I commented precisely because I thought your
observations were important.
Edward Barkmeyer 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.
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.
I think the hearsay and your summations are accurate.
I only offered that I see some advantage in ontologies vs information
modeling and other technologies in addressing these needs.
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.
I think ontologies are hugely important. And I believe the technologies
and formalized knowledge already developed by experts in this space can
help make other forms of KR much more usable and less costly than you
Finally, I think Phil and I have only slightly different perspectives
on the following:
And I agree that we have only slightly different perspectives.
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, ...
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.
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.
There is, indeed, a significant investment. But
(1) I believe there are ways to show both the necessity and benefits
of such an investment.
(2) I believe that we need to frame the necessity and benefits in a way
that makes sense to everyone in the organization. Because everyone in
the organization can benefit -- and contribute -- with the right model
for capturing, evaluating, and integrating the "knowledge" of the
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.
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.
That's part of it. We also need to look much deeper into the problems.
- An overabundance of information reduces our ability to understand
what's actually happening and request appropriate solutions.
- A key and simple reality is that you cannot accurately and
reliably interpret and apply lots of unstructured information.
- There's so much stuff -- and information about stuff -- in the
world that it is impossible to adequately understand that information
in a reasonable timeframe, especially when you need to act on that
- The complexity of reality (which includes complex ideas) has
outpaced language. We are challenged to
- Remember the meaning of that stuff.
- Detect both duplicate and related stuff.
- Understand which is important.
- Put it to use effectively.
And that's still just part of the challenge.
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.
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
Broadly useful foundational ontologies and "micro-ontologies" will both
be useful. We need ways of developing them rapidly. David Eddy's
emphasis on building from existing information is a key part of any
strategy. Incremental formalization, as described by Shipman and McCall
(and others) is essential.
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.
[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.]
Here's a minor disagreement: We need both bottom-up and top-down
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". :-)
As a company of one, I exercise complete authority over job titles.
That includes meaningless management titles. For a fun (off-topic) take
on job titles, I recommend
And I agree completely with the horrified comments on that article.
The Semantic Advantage
Turning Information into Assets
Web site: http://www.semanticadvantage.com