I've recently tried to define (for my own benefit) what a kLog is and what an example might look like. Perhaps this is like describing beauty—describing it in words is difficult, but you know it when you see it.

I think a weblog (or any collection of time-based, free-flowing business content) is a kLog when it provides an increased capacity to act more intelligently. A good example of a kLog can be seen when you combine Office XP Smart Tags with MySmartChannels.

What’s an example of how a Smart Tag and a channel might work together?

Imagine you have a channel that documents contract negotiations with a number of clients. For each client, you create channel items with the client’s name as the item title. Further, imagine that your team of eight (and you) continually update these items with the latest information about ongoing negotiations and issues. This is a group note-pad of thoughts, ideas, and challenges of getting the work done. Since each of your staffers are subscribed to the channel (for Office XP Smart Tags), in every document, every e-mail, and every slide presentation referencing your client names, Smart Tags would be automatically present in the Office documents. This happens automatically and without any human intervention. It allows your staff to immediately access the channel content without thinking about where it is, or what the discrete URL's might be. Your team is able to immediately put their hands on the latest information about a client from any Office document that includes the client's name.

Further, imagine that other people (not on your staff) need to be kept informed about the contract progressions. They require access to information, but only with viewing rights.

MySmartChannels, is able to share access with appropriate read-only permissions. This makes it possible for people that are peripheral to your team, to gain the same access to links (and insights) from any of their own Office documents that reference your client negotiation content. To be clear about this amazing functionality - it means that any Office documents - even ones that you and your team are not reading or writing, will contain automatic references to your channel content based on each subscriber's granted permissions.

Integrating Office XP with MySmartChannels is one way to transform what appears to be a simple Weblog, into a kLog. Like I said, you know it when you see it...

In my view, one of the many possible ways to transform weblogs into kLogs is to integrate them with other enterprise information tools; instant messaging is a good example. But when you tackle this idea, come prepared with XML API support. This is not just about posting an item to one blog account. Search requires different XML feeds than processes like selecting the channel you want to focus on, or publish to. The MyST XML API provides a collection of possibilities that makes it quick work when integrating with XML-aware platforms.

Using ActiveBuddy we were able to create a fairly powerful collection of integration services that allow authenticated MyST users to freely "converse" with channels to do things like search, read, and compose. We've only scratched the surface on this idea but I anticipate many types of solutions that have the potential to address a wide variety problems for information workers.

If this is something your company can benefit from, give us a call - we're implementing IM-independent platform solutions with MySmartChannels on a consulting basis.

"The more I talk with 'real people working in real companies' (meaning: not nerds spending their whole days hacking), the more convinced I am that a news aggregator is the ideal center for any Intranet." —Paolo Valdemarin

The entire site (http://klognews.com/) is fundamentally based on the aggregation concept and requirements articulated in Paolo's Weblog post. As an example, emergic.org is syndicated at klognews.com.

To achieve this, we simply had to create a resource in MyST that identifies RSS content as an aggregation source. All other aspects of the process happen naturally through XSLT rules-based models, including style and scheme of the presentation.

The MyST platform addresses each of Paolo's stated server-side aggregation requirements; it also goes a step further in terms of scraping. Scraping is useful in some cases, but is decidedly brittle. MyST uses a scriptable "channel gear" that provides powerful content integration capabilities with things like Amazon's API, RSS, RDF, Google's API, and screen scraping through an xHTML parser. The unique aspect of channel gears is that they are built in concert with our business logic plug-ins (an API for business process scripting involving channels). All items [regardless of their source] fall under the MyST user's security context so search, RSS feeds, etc, all conform to the security and permissions model.

Amy's right about that -- with MyST we take that viewpoint to the extreme. For example, the MyST platform provides extensive support for semantic relationships by using typed associations (part of the information architecture of the MyST platform).

Why is this important?

Typed associations don't require a bunch of relational actions - there is no need to "sort" per-se. Instead, the platform offers the ability to "triangulate" semantic relationships at an abstract level. For example, when I share something with you, a trinary relationship is automatically created between me, you, and the content I shared. Using these association objects, we can easily understand who knows what, who shared what, and who finds what interesting.

I suspect there are numerous companies that are using weblog tools as the basis for knowledge content management. This is a sign that a foothold on the shear face of corporate knowledge management challenges has been established.

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