Sounds like a simple enough question, right? However, a question like this, especially when raised among techies, runs the risk of triggering deep philosophical—I would call them religious—debates. In no time at all, the debate focuses on a fundamental issue: What is knowledge?

I figured I could find such a debate-in-progress when I noticed the following comment in Roland Tanglao's Weblog:

I am not an AI guy, but I think knowledge *can* be contained within a weblog post if the post is [in a] format where the blog system can automatically extract categories/keywords/topics.

I didn't have far to look.  Roland was commenting on dueling posts by John Robb, former Userland CEO and active K-log (Knowledge webLog) champion, and Vikas Kamat, computer scientist.  Naturally, John think blogs can contain knowledge; Vikas does not.  Roland offers a qualified "yes".

Who's right?  Everybody (given each his own definition of knowledge, anyway).

Let me suggest a pragmatic definition of knowledge for those of us who are trying to chip away at real world KM problems (to use the overloaded, seriously baggage laden, "KM" term):

Knowledge is information that improves a person's ability to act wisely.

This is a simple but powerful definition.  It defines knowledge implicitly in terms of its enabling effect—improved ability to act wisely—rather than any specific attributes.  (By the way, the Turning Test uses a similar technique to define intelligence.)  Ultimately, it is this enabling effect that we value; that we create software to help achieve; that companies are willing to pay for.  Any specific attributes are just "implementation details".

So, can a blog post contain knowledge?  If you are talking about information that improves a person's ability to act wisely, then certainly, the answer is yes.

The grass roots days of blogging are ending.  Not that blogging is dying; in fact, just the opposite.  Blogging is going mainstream and its going corporate, like it or not.  Blogging (or blog-like technology, if you prefer) is moving inside the firewall, into marketing departments, into research tools, into intelligence tools—in short, into the world of knowledge management.

As I read Amy Wohl's recent posting on The Sanctity of Blogs, I found myself thinking, "yes, but only if you are talking about grass roots type of blogs".  Specifically, Amy makes three points that got me thinking...

"The intellectual content of blogs belongs to the blogger who wrote it and not to the blogging site which happened to host it. Therefore, [it should be possible] for bloggers to move their content for any reason."

Organizations are recognizing that knowledge is the new capital, and blogging is poised to play an important role in capturing and managing knowledge assets.   As I have described elsewhere, the needs of enterprises are very different from the needs of individuals.  As weblogs emerge as corporate assets, it should become, in general, not possible "for bloggers to move their content for any reason."  (Does anyone believe that a company employee is free to move company documents—even those he or she authored—for any reason?)

"Blog site owners should not remove blogs except for good reason (breaking a well-known rule, such as including sexually explicit material) and even then, with reasonable notice, considering the problem."

Again, I agree, if we're talking about truly personal blogs.  However, if we're talking about a company electing to remove from its own corporate server the blog of the company's COO who just resigned—as in the cited case of Userland taking down John Robb's blog—I have to disagree.  (Does anyone believe that a company should leave a former officer's bio on the company web site?)

"Link owners should be mindful of the blogs they are attached to and make every effort to keep links stable and enduring."

I take issue with this only in that it is not stated strongly enough!  Information is an asset; but, only if you can find it.  I consider any blogging technology that does not assign a unique, immutable identity to every information artifact to be broken.  (Does anyone believe an operating system should permit a filename to change on its own?)

Most people look at me like I'm from a different planet when I advocate the use of multiple weblogs for different purposes, especially inside corporate environments. Typically, bloggers believe that weblogs are for one purpose - a personal journal; this is extremely narrow-minded thinking. A few bright people are starting to realize that they could be useful for customer-facing content, but they too carry baggage concerning the assumed use of blogs on the Public Web. Some go so far as to define what a blog must and must not have - rubbish - a blog doesn't need a 'voice'; it could have hard facts and science - it's simply a medium for conveying information. Some of it may be subjective, some of it may be objective.

Unfortunately very few companies realize the potential of friction-free, personal publishing for enterprise use, but Chad Dickerson get's it, and further recognizes that varying types of content need to be streamed (or channeled) to different types of users and with secure methodologies.

"Not everything I deal with on a daily basis can be distributed publicly, but there is still information that needs to be disseminated regularly and made available to a group on an ongoing basis."

Chad correctly points out that corporate weblogs have a different set of requirements that revolve around security, permissions, and discovery. The blogging framework must be designed to meet these requirements.

"I think one of the biggest mistakes people in corporate IT make is wrongly assuming that documentation is something that ends at some point. In reality, IT is an organic beast, and documentation is never really complete. Fortunately, the Weblog paradigm gives corporate IT the means to create documentation that works the way people think -- in dates (When did this happen to the system?), incidents (What happened, and how was it fixed?), and people (Who fixed it?). We've used the Groove discussion to manage the IT logistics of office moves, server migrations, and the RFP (request for proposal) process for Web hosting. This method of group documentation works better in practice than anything I've ever seen."

Chad also recognizes the need for chrono-based content; something that blogs tend to force. However, the architecture of the blog tool should allow other types of displays and content reuse that may require other formats (ergo, XSLT, XML-based persistence model, etc.).

Wouldn't it be convenient to be able to post to a channel by simply sending an e-mail?  It's easy to imagine reasons to want this capability; for example, you could:

• compose wegblog items right in your favorite mail client;
• post items from a cell phone;
• update an FAQ (frequently asked questions) by CC-ing or BCC-ing a channel when answering a question via e-mail;
• make a group of people aware of an e-mail message by CC-ing or BCC-ing a channel to which they are subscribed; or
• collect applications-generated e-mail notifications in a channel.

An e-mail gateway opens up a world of useful possibilities.  Unfortunately, it also opens up a world of security concerns.  Clearly, you would not want a competitor, a hacker, a disgruntled employee, or a spammer to be mailing content into your channels.  (Just imagine what might show up in your weblog if a spammer found the mailbox--scary!)  Passwords are not the answer either.  E-mail (specifically, the underlying SMTP protocol) is simply not secure; it passes all e-mail content as plain text.

After scratching our heads on the security issues for a while, we designed a new service, called the Mail2Channel Gateway--just released in beta--that offers a secure e-mail gateway to MySmartChannels.  Mail2Channel does not require login names, passwords, or any other special mail formatting, nor does it even require that you set up an actual mailbox.

Mail2Channel creates virtual mailboxes.  When an authorized user wants to send mail to a channel, he or she obtains a virtual mailbox for that channel.  Virtual mailbox names are intentionally cryptic (they are based on an encryption scheme that is, for all practical purposes, not guessable) and are valid only for a specific user and channel combination.

When a message is received at that virtual mailbox, Mail2Channel bases the sender's identity on the message's From or Reply-To address (both of which are easy to spoof, of course, just stay with me).  If the sender appears to be the authorized user for the virtual mailbox, Mail2Channel creates a new channel item using one of two methods:

• Method 1--A channel item is created, but in an embargoed state.  A confirmation e-mail is sent to the authorized user informing him or her that the channel item was created and providing links for previewing, editing, and un-embargoing the item.  Acting on any of these links requires true authentication (i.e., logging in with username and password).
• Method 2--A channel item is created and immediately posted.  A confirmation e-mail similar to that of Method 1 is also sent.  Method 2 is less secure but may be appropriate for certain inside-the-firewall use cases.

Mail2Channel is currently available to all registered MySmartChannels users (click the channel resources icon for any channel).  We encourage you to take it for a test drive and welcome any thoughts or comments you might have.