ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Quote for the day -- KR and KM

Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Phil Murray <pcmurray2000@xxxxxxxxx>
Date: Wed, 05 Jan 2011 15:47:59 -0500
Message-id: <4D24D8FF.7040501@xxxxxxxxx>
Ed --

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:
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.

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 assume. 


Finally, I think Phil and I have only slightly different perspectives on the following:
And I agree that we have only slightly different perspectives.


I wrote:

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, ...

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.

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 organization.

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 knowledge.
  • 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 models.

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 approaches.

-Ed

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

http://www.boston.com/jobs/employers/hr/hrcolumns/2009/05/whats_in_a_name_strategies_for.html

And I agree completely with the horrified comments on that article.

Thanks,

     Phil
-- 
---------------------

The Semantic Advantage
Turning Information into Assets
phil.murray@xxxxxxxxxxxxxxxxxxxxx
401-247-7899

Blog: http://semanticadvantage.wordpress.com
Web site: http://www.semanticadvantage.com

_________________________________________________________________
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    (01)

<Prev in Thread] Current Thread [Next in Thread>