Mt. Everest - data to wisdom
We use the words “data”, “information”, and “knowledge” in informatics-related conversations all the time. Do we know what we mean?
Some days, I don’t think so.
The field of Knowledge Management has defined these terms rigorously. The general view is that data is at the lowest level of the stack, with knowledge at the top. As you go up the stack, you add context, abstraction, and synthesis. And yet I frequently find that people have different notions in their heads about what these terms really mean and how they are used. (In part because when you read phrases like “context, abstraction and synthesis”, you should think “what the hell does that mean?”) And even with rigorous definitions, the terms overlap and get confusing.
When people talk to each other using terms that are interpreted differently by everyone involved, the conversations are hopeless and the decisions are poor. (This drives me crazy. We do it all the time. One of the best things you can do in a complex discussion is stop and say, “Let me make sure I understood you. Is this what you meant?”)
With “Information Lifecycle Management” (ILM), Information Access, and Organizational Knowledge all becoming increasingly active topics these days (and didn’t that happen in the 80s too?), I looked around a bit to see if I could find useful definitions for these terms that were easier to apply than the usual textbook explanation.
I like real examples that stick. I was quite happy to come across examples in Wikipedia’s Data page that I think work wel, so I’m passing these along, with some extensions.
- Data:
- The height of Mt. Everest. (Measurements.)
- Information:
- A book on Mt. Everest geological characteristics. A map of the Himalaya region. (Collections of measurements and interpretations.)
- Knowledge:
- A report containing practical information on climbing Mt. Everest. Routes. Recommendations. (Analysis and assessments.)
- Wisdom:
- The instinct an experienced climbing guide uses, assessing weather, snow lines, and client conditions in making a decision.
A book can contain aspects of all of these. This is why differentiating them can be so hard. (And let’s be real: some days you don’t need to differentiate them. At every level of the stack - keep it if it’s useful. Get rid of it if it’s not. Make sure others can find and understand it.)
The extension into “wisdom” is due in part to Steve Cleaver, who found some reference to this last year that I really liked – but then I lost. (Steve, if you ever read this, could you post the reference in a comment?)
In NIBR, we have all kinds of challenges with data, information, knowledge, and wisdom. Chief among them:
- Data: Keeping too much of it. Not keeping enough data about the data (metadata) to allow us to contextualize it into knowledge.
- Information: Keeping too much of it - and yet not being able to find it.
- Knowledge: Not creating enough of it. Not capitalizing on it. Confusing it with information.
- Wisdom: Learning how to recognize, capture, share, and act on it.
We’re not alone… every significant organization struggles with these. One could even say that the ability to capture and act on wisdom is what defines an organization over time.
Whoever gets this right wins.