IDblog: And still more What's in a name?

And still more What's in a name?

Over on infoSophy, mentor is doing yet another version of "what's in a name?" by asking how is knowledge different from information? For example:

In order to differentiate KM from information and data management it needs to be shown that knowledge is different than data and information. Blairs (2002) explication that knowledge is different than data and information is based on the information theory stratification which puts data as the raw thing, then information which means data arranged in a certain way that presents and brings forth an obvious interpretable meaning, and then knowledge as the next level up, mainly stating that knowledge, exhibited through it characteristics, is different because it resides in peoples minds and it is not tangible (p. 1020). ...

An argument for the necessity to differentiate knowledge from information in such terms appears to respond to a need to clearly and unambiguously distinguish knowledge management from information and document management (Blair, p. 1019), perhaps more so for KM practitioners.

I found this an interesting read. As I did this entry from experience curve on same problems, different decade which quotes Victor Papanek as writing in 1971:

...the various sciences and technologies have become woefully compartmentalized and specialized. Often, more complex problems can only be attacked by teams of specialists, who often speak only their own professional jargon. Industrial designers, who are often members of such a team, frequently find that, besides fulfilling their normal design function, they must act as a communication bridge between other team members. Frequently the designer may be the only one who speaks the various technical jargons. Because of his educational background, the role of team interpreter is often forced upon him. So we find the industrial designer in a team situation becoming the "team synthesist."

Ah, back in the good ole days before "design" was a four-letter word :)

But back to knowledge and information. A recent post on the weblog with the cool name (Diary of a Superfluous Man) recently pointed to Nathan Shedroff's New Methods for Experience Design. It's hard to tell for sure, but this seems to be some slides that support some kind of seminar or tutorial (there are multiple exercises in it). But what I can't really figure out (after my comment a week or so ago about professional presentations) is ummm, Nathan's design choices (then again, I never got his website designs either).

But Nathan sure could do some nice infographics, which this one (from Unified Field Theory of Design shows:
Shedroff diagram

I'm still a bit confused by the experience cube, or about the usefulness of yet another term (Shedroff's information interaction design), but I think his document (which is also a chapter in Bob Jacobson's ) holds up extremely well for something that is 10 years old (I have a copy I downloaded in 1995, dated 1994) in a rapidly changing field.

06:46 PM | linkme | home

Comments

I think the experience cube denotes the fact that the movement from information to knowledge (an information-as-thing viewpoint of information) cannot be attained only through the manipulation of information objects and/or knowledge artifacts. It shows the 'thing' necessary beyond what is represented in knowledge artifacts. The experience cube partially resides (or is part of) in Popper's World II.

From: http://www.kmentor.com/socio-tech-info/archives/000073.html

-- Posted by mentor on July 1, 2003 10:57 PM

Good topic, I'll just throw in my 2 cents.

Data=information lacking structure (for instance the alphabet is data)
Information=data with structure (a word, a sentence etc.)

Those two definitions I'm pretty comfortable with. Using those definitions I then find it very ironic that Information Technology really about moving and managing "Data". And knowledge management has, in the vast majority of cases, been about moving and managing "Information".

As for knowledge, I've used a working definition information with context is knowledge. I'm not super comfortable with that, but hey. Larry Prusak, who I think is one of the most pragmatic KM gurus, said "knowledge is what a knower knows" and that's that.

Inspired by Liz Sanders point about designing Experience is impossible but we can create scaffolds for people to have experiences in/with. Then KM is really about putting structures in place that are contusive to the creation and use of knowledge.

-- Posted by karl long on July 10, 2003 08:36 PM

As I pointed out in the piece "Why a CIO Isn't" the relevant definition I came up with (after considerable mental wrangling/testing) was 'user-relevant context'.

In addition, for all that Prusack and the others have done for KM, they've failed to do the one thing I have felt was necessary from the beginning: change the term. Knowledge is far more 'fleeting' than Information. Knowledge is the application of Information within a specific scenario. That being the case, Knowledge cannot be 'managed' -- end of discussion. The real goal that those who claim to be involved in the pursuit of KM should be to 'facilitate thinking'. The goal is to build infrastructures that help facitate the exchange of relavent data and the specifics of 'contexts' that have been tested in the past.

This same 'issue' relates to my favorite definition for 'expert'. From physicist Werner Heisenberg -- another testiment to the global
applicability of truths across disciplines: "Many people will tell you that an expert is someone who knows a great deal about his subject. To this I would object that one can never know much about any subject. I would much prefer the following definition: an expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them." The aforementioned infrastructure would be designed to optimize this principle.

-- Posted by Paula Thornton on July 31, 2003 06:30 AM