Mentioning "knowledge centricity" is like using the word "paradigm." People really roll their eyes when the abstract terms slip off tongues as evidenced by the way my colleague Dan Farber characterized my usage of the phrase as a dropped bomb at the end of yesterday's Dan & David Show. The subject came up during a conversation about the document format battle between the OpenDocument and Open XML camps. Dan, who was about to end the show pinned me down and asked me to explain what the heck I was talking about. it's a fair question and rather than transcribe the entire dialogue, here's what I said in the punchline:
Imagine if the way the Wikipedia was built was through all of the contributors to it passing around documents to each other via email... It would just grind to a halt and the Wikipedia would never be what it is today. Take the same way the Wikipedia has been built and figure out how to organize the way your company runs so that knowledge is easily collaborated on an distributed in a very efficient manner and you don't rely on proprietary systems [to manage your content].
In fairness to Dan, I poo-pooed on the idea that document formats are relevant in this wiki/blog/rss world which isn't totally true. For example, HTML may be the standard format for accessing and searching knowledge and information. But HTML is not a good native format for housing the raw material (not to mention that it can't house some raw material like images). So, we do need authoring standards for the raw material. PNG and JPG for images for example. And when creating text with WYSIWYG, the final resting place for that text should be a place that all systems can equally access (much the same way so much software can access JPG and PNG images).
Imagine for example, you edit some text with SocialText, MediaWiki, or JotSpot and press the save button. Should that text be natively saved in the non-standard markup language used by whichever of those wikis are using? Or should it be stored in a format that can be easily accessed or authored by not just wikis, but other software -- perhaps word processors -- as well? I could see myself using a my favorite word processor to author some knowledge (not a document per se) while on an airplane and clicking "save to wiki" when I'm done. Then, when I land and connect to the Internet, that knowledge is automatically poured into a wiki where it instantly becomes available as highly accessible (via a browser) and highly searchable (because of HTML) knowledge. A common format for encoding that knowledge -- a format understood by both the word processor and the wiki -- would be the enabler.
Here's another example. As I write this, Dan Bricklin is huddled in his study somewhere in Massachusetts, toiling over his next brain-child: WikiCalc. What wikis are to text and images, WikiCalc is to spreadsheets (the etymology dating back to the first electronic spreadsheet, invented by Dan Bricklin and Bob Frankston -- known as VisiCalc). Back to the airplane, should I need to be connected to the Web to author a WikiCalc formatted body of information or knowledge? Or, should I be able to encapsulate knoweldge that's well-suited row-and-column with any spreadsheet software and click Save To Wiki when I'm done?
So, in my podcast with Dan, where I did at one point say "who cares about formats?," I erred. Standard formats are critical to the sort of frictionless authoring, flow, accessibility to, and collaboration over knowledge. But the minute we pidgeon hole ourselves into thinking about knowledge and information as documents, we also doom ourselves to requiring bloated, expensive, and largely non-interoperable layers of software that add friction to the creation and distribution of important knowledge and the generation of business value. The sort of value that the Wikipedia generated in its world. Either that, or we should start referring to knowledge workers as document workers. Which brings up a final point. In some ways, the OpenDocument format has the wrong name. Perhaps it should be called the OpenKnowledge format.