Whatever you may think of the publishing revolution known as blogging, the advent of technology for posting “top-of-mind” thoughts to a Web site is an intriguing development in Internet history. Weblogs, or “blogs” for short, dramatically ease the process of uploading simple kinds of content, thus facilitating a loosely organized kind of collaborative publishing.
We’re at an important moment in the evolution of such publishing, and it is worth pausing to reflect on how things could go terribly wrong. The main virtue of blogging is that it closes the arms gap between informed, individual users and official outlets of information. And it has potential not only in the public world, but also in the corporate sphere.
For years, enterprises have been trying to find a way to flatten hierarchies by encouraging knowledge sharing, albeit in a way that keeps acquired knowledge in the family. Hence the craze for chief knowledge officers and data marts in the last several years. It’s quite possible that like instant messaging, blogging will become an extremely productive tool for businesses as well as individuals to gather and organize what smart people figure out daily.
But at the rate they’re going, blog tools are merely building simple heaps of information, giant mounds of unorganized content. Developers of these tools must implement technologies for moving and transforming entire weblogs before things get seriously out of hand.
Wherever You Go, There You Blog
The tools of blogging have evolved rapidly in the last few years — testimony to the ingenuity and dedication of the community building such programs, the simplest of which are free. The Web-based version of the Blogger program, hosted at Blogger.com or on a user’s own Web page, makes it so easy to post a chronological, text-based diary — with the occasional picture — that it’s fairly addictive. Meanwhile, tools like pMachine have introduced ever more sophisticated Web templates to open up the kinds of sites one can publish, and Movable Type provides integration with databases to make publishing of discussion threads more organized.
Tools are going beyond simple text publishing, too. Audblog, available for Blogger-based weblogs for $3 a month, lets users fire off rapid reflections from their cell phones. And Lifli Software’s iBlog for Mac OS (and soon for Windows) makes wonderful use of OS X’s integration of multimedia to let users add pictures, sound clips, file attachments or movie clips to a blog entry.
In addition, the inputs and outputs in blogs are getting better. Users of the Danger HipTop and wireless-enabled handheld devices report satisfactory results when sending posts from the road. The RSS standard, a protocol that details how to syndicate a blog, provides a nice way to package summaries of blog entries so that a blog reader program can alert a user when updates have been made, like a syndicated news service.
Look Out Below
It’s easy enough, though, to find things to complain about. A “style meter” might be nice, to remove the generally snide and petty tone that pervades many blogs. Missing in most tools is the ability to organize areas of a site without a lot of hand-coding. Jonathan Prinz, a New York-based branding consultant, says his greatest frustration in posting his personal blog is how much work must be done in HTML to make even the simplest changes to the look and feel of the site. Obviously, tools will need to sprout more controls as they move beyond diaries and become, in effect, the next generation of Web publishing programs.
The greatest problem, however, is not the limitations of the front end of this software, but rather what goes on behind the curtain, so to speak. As bloggers add content to their sites, the programs update and store HTML pages in a collection of directories spread throughout a Web site. Each tool has its own directory structure, its own names for the archives it compiles of past postings, its own method of updating each page.
That way lies trouble. While the actual pages in a blog may be simple HTML, the sum total of elements in a blog is a giant heap of files and folders understood only by the tool a blogger is using at present. What would happen if you were to switch tools tomorrow? With even the simplest blogs, many users would be daunted by the need to move files, change directories, get the new tools to hook up with the old. In short, each new tool would break your current blog. There simply is no portability under the current structure.
Tower of Blogging
While such a situation can be a frustration for individual users, it could be a huge barrier to entry for blogging in the enterprise. Just as instant messaging has been hit with claims that its security and bandwidth use are not efficient on local area networks, the heap of content produced by blogging is not the ideal knowledge store a company might wish to produce as a result of employee participation. It is just a big heap of stuff. What’s needed is a uniform way for every blog tool to understand the blogs created by another tool and to pick them up when a user switches tools, much like the way browsers can share HTML.
Some business users might reach for a relational database to solve the problem. But relying on a database as a universal back end for blog tools poses the problem of overburdening simple sites with complexity. Some weblogs will not be able to host anything other than simple Web pages, and they certainly won’t accommodate database engines.
A better idea, I think, would be something like the Linux Standard Base project, but far simpler. The standard base, or LSB, specifies data structures that Linux programs must contain in order to be portable. I don’t think weblogs need to be that strict, but some standard mechanism for specifying how files are laid out, which could be passed from program to program like a map, would be incredibly useful.
Metadata to the Rescue
In fact, the answer may be at hand. The RSS protocol, mentioned above, is used to tell reader programs where to find a blog. Why not use the same technology to tell blog software how to pick up the entire contents of a blog and integrate or repurpose those contents? In effect, the XML standard for structured Web data could be used as a uniform way to transform each tool’s blog into another’s, in order to hand off control. Not only would this avoid a knowledge disaster in the long term, but it would encourage blog sharing and collaboration in the near term.
I’ll leave it to the experts to iron-out the specifics. At some point, the community of coders will have to realize that adding more and more features to blogs won’t fix the problem of organizing and disseminating all the content piling up in the unfinished basement below. This problem should be addressed before the blog becomes the blob.
Note: The opinions expressed by our columnists are their own and do not necessarily reflect the views of the E-Commerce Times or its management.
Loading ...
I think the reasons are not technical, but more social. See my comments at http://www.psesd.org/weblogs/im/archives/000308.html#000308
Exactly. Blogging apps like Userland’s radio and Pyra’s blogger have done more to introduce interoperability to this space than any commercial API. The blogger API, RSS, OPML, Trackback, etc, etc. Not only that, these smaller players are able to implement shared formats and standards faster than many commercial software companies could dream of. Once again, an old school publication misses the point. Good try, though.
>>we need something organized by subject, not by date
In fact, most blog systems *do* let you organize posts by subject, except ordinary users tend not to bother with this feature. For example, Movable Type has a ‘category’ feature that lets you do just this.
I agree with limulus:
"So the jobs are (a) develop a common vocabulary consisting of labels for concepts that are dealt with in the company’s blogs; (b) categorize postings using those labels; and (c) figure out how to present the common vocabulary and blog entries that relate to each term."
This is where moving beyond the simple initial rss format and into the richer rdf-based 1.0 spec promises to help. I hold out hope for the blogging tools to incorporate this on the data entry side of things, especially after seeing that Moveable Type’s Notepad incorporates a similarly complex file format like FOAF as just another feature.
The whole concept of creating a common vocabulary within an organization and tracking it with the use of rdf namespaces in the rss feed seems like a pretty daunting task for a single developer to handroll by themselves, but I’ll find out the feasibility of this soon, as this is a direction that I’m working to implement at my work. We have a project that was already going to store the data as xml files and publish to the web, so we decided to try storing the xml files as rss feeds. If we can move beyond simple syndication to creating our own vocabularies, applying it in a consistent way to the data and then *doing* something of obvious benefit to the end user with that information, then we’ll consider this whole tangent a success.
i wish i could see a *social aspects* category in your referenced *information management* weblog
the danger is that *weblog based business solutions* are developed for the consumer market .. as-usual .. before there is a not-a-developer-or-a-research-team *user constituency* in place .. to negotiate the development work with ..
i believe social aspects might be addressed by taking a preliminary look back .. to the days when ready made off-the-shelf technology solution availability was not the norm .. and by saying something more about what your comment only hints at .. i.e.: the fear to look stupid if one takes a not-a-technically-or-marketing-blessed approach to
learning-by-doing what best suits an organization’s needs …
if the above wording sounds stupid … see how i’m presently proposing to share a *weblog-of-intent* with anybody willing to share the *stupido* problem … http://www.pharos-it.net 🙂
For a business to use blogged information effectively, it will need not only to gather the text but to figure out which entries relate to which topics and concerns. Tiernan Ray’s article focuses on the portability of the file structure, which relates posts to the people who wrote them and the time they were written. That’s a valid concern, to which anybody who has switched email systems can attest. But like piles of email, the knowledge contained in those bits and pieces of text needs to be indexed well in order to be useful for other purposes. So while metadata about the mechanics of the blog is necessary, I think it won’t be sufficient, at least not sufficient to motivate an executive to devote resources to collating the blog entries. What’s needed is a way to categorize the entries by subject, and a way for software to show the entries that deal with a particular subject and point to other subjects that are related. So the jobs are (a) develop a common vocabulary consisting of labels for concepts that are dealt with in the company’s blogs; (b) categorize postings using those labels; and (c) figure out how to present the common vocabulary and blog entries that relate to each term. Draw on the knowledge and skill of librarians to help with these tasks.
Blogs are fine for personal sites, IM is great for phone-like tidbits, and bulletin board forums are fine for exchanging opinions.
But for departmental or corporate knowledge-sharing, we need something organized by subject, not by date. We need the content to be collaboratively updated by more than just a single author or small group. And we need something with more permanence than e-mail or chat.
My group wrestled with this recently, and we were surprised how little was available that meets these needs. We selected the open-source TWiki software package, which provides an easy way to build an internal Web site for knowledge management. It has version control and login security when editing (to allay any concerns about collaborative editing) and it can be customized to have a respectable corporate look and feel.
The "heaps of information" problem may never be cured, but at least this tool helps us manage it. And it provides a very low barrier to getting people to contribute, which perhaps an even bigger KM problem.
I’m sorry, I must have missed a few paragraphs somewhere. Where is it stated that the current commercial CMS must adhere to standards-based data structures? I’ve only been in that business for a decade, but I just cannot seem to recall even any mention of any such interoperability standards.