Social Glass

The semantic web is often heralded as the next evolution of the internet, Web 3.0. Wikipedia describes the semantic web as an:

evolving extension of the World Wide Web in which web content can be expressed not only in natural language, but also in a format that can be read and used by software agents, thus permitting them to find, share and integrate information more easily.

Indeed the semantic web promises to make entities like “address”, “contact info.”, etc. which appear within unstructured text on web pages, to be machine parsable through the use of microformats. Other semantic web standards, such as OWL, aim to define the relationships between objects and attributes within a pre-determined ontology.

Behind the firewall, an intranet marked up according to these standards would be information Garden of Eden with relationships between knowledge and metadata about content items being deeply embedded. The Discovery process on such an intranet would certainly be very rewarding given this abundance of “information about information”.

All of this works if content is published using the structural components the semantic web requires. And herein lies the problem - structure.

Within the context of Enterprise 2.0 we often talk about wikis and blogs being emergent - meaning they adapt to the needs and requirements of the knowledge worker. We want knowledge workers to impose their own structures, perhaps with minimal guidance through the use of patterns like scaffolding.

So how are we going to enforce the use of, say, microformats every time a knowledge worker writes an address or somebody’s contact information? Personally, I can’t think of a way without imposing structure. And I’d hate to see said structure reduce participation.

I believe in the value proposition of the semantic web, but to maintain current emergence capabilities, wiki and blog technology will have to be significantly enhanced to automatically mark up content when published. I think we’re a long way off from that being possible.

Most people who read this blog are probably familiar with Wiki Patterns - “…a toolbox of patterns & anti-patterns, and a guide to the stages of wiki adoption”. One pattern I find intriguing is that of the Wiki Gnome. A Wiki Gnome is somebody who’s detail oriented and makes cosmetic changes to wiki pages, improves information flow, fixes punctuation etc.

We use Confluence for sharing project information, and it’s amusing to see wiki patterns in action. My project is based in Australia and is staffed with Australians. Yet the other day I noticed an edit to one of our pages by somebody based in Washington D.C. A wiki gnome.

The change was minor, but it made me realize that my project’s activities are visible to and grab the attention of a wider audience across my company. After all, wiki gnomes have to read wiki content before they decide to modify it. So perhaps the presence of wiki gnomes is an indicator that an enterprise wiki is accomplishing its task - diffusing knowledge and connecting people.

Mediawiki is the popular, open source wiki application that powers wikipedia. Many organizations run mediawiki on their intranets including Avenue A Razorfish. One of the issues with the out of the box version of mediawiki is its categorization (or tagging) feature. Users are required to type the text “[Category:” followed by the category, then “]” (”[Category:design]”, for example) on the wiki page.

While this does not seem overly complicated it, becomes very difficult for users to reuse categories as there’s no feature on the edit page that shows them which categories have already been used. As a result, we might end up with two categories “design” and “designs” that should be the same.

A colleague of mine, Andreas Rindler, has solved this problem with a mediawiki Category Suggest extension.

CategorySuggest provides a Google Suggest like functionality to the edit page of articles. A separate “Categories” input box is added below the article page. When a user starts typing the name of an existing category, the extension retrieves a list of existing categories from the Mediawiki database and suggests matches to the user. The user can either type the name of a new extension or pick from the list of suggested categories.

Click over to his blog post describing the extension for a better overview.

Avenue A Razorfish was one of the first companies credited with attempting Enterprise 2.0. They based their solution on mediawiki and made modifications to the codebase for Wordpress and Active Directory integration (AD integration is a great way to avoid the hassle of registering users manually). They also encouraged their employees to use a certain tag on delicious when bookmarking links. The solution then automatically presented newly bookmarked items on the home page by invoking a delicious API to retrieve all bookmarks tagged with that tag.

Avenue A Razorfish is now evolving their wiki to include more features. I’d like to direct you to their blog post which contains an embedded slideshare presentation that explains their approach. They’ve definitely got some great ideas.

Within my organization we’re working hard to socialize the benefits of socially-oriented collaboration tools and have made great progress with our initiative. But an interesting dilemma has surfaced, and I’ve read about this happening elsewhere too (but I can’t remember where - otherwise I’d link to it). The dilemma revolves around whether an enterprise should focus its energy on promoting a single instance of a collaboration tool (i.e. wiki), or if it should instead embrace wiki federation. The inherent benefit of having everybody use a single instance is, of course, that all collaboration occurs in one spot. This makes it easier to find content and people since there’s only one place to look. From an IT perspective this approach also makes sense as it consolidates governance of the tool and makes it more manageable.

But the “single instance” approach might be more of a utopian ideal. We often talk about having a bottom up, non-sanctioned approach to Enterprise 2.0 adoption. Bottom up often entails disparate groups creating their own collaboration environments for specific needs, and the result is wiki proliferation. And I’m not sure there’s much corporate IT can do to keep this from happening.

So, pragmatically speaking, it makes sense for the enterprise to embrace wiki federation. This can be accomplished through Enterprise Search. Slap a Google Search Appliance or FAST instance inside the firewall, point it to the federated wikis, and we have discoverability across all collaboration tools. This negates the impetus behind moving the enterprise toward a single collaboration tool instance. Of course the challenge here is to keep the search index up to date with all of the new wikis that popup. But that’s why we have IT guys.