Winer on wikis: Just add OPML

According Dave Winer, wikis could use a bit of OPML (Outline Processing Markup Language).  Now that I've had my hand at running a public facing wiki for three months (see the Web site for Mashup Camp) to which many other people have contributed, I'm in agreement with Dave that integrating OPML with wikis makes sense. 

A quickie on wikis for those not up to speed on them: To me, wiki and blog technologies accomplished the same thing for the masses. Like blogs, wikis make Web authoring a snap until you want to do something beyond the publication of simple text. They turned the "write" part of the read/write Web into child's play. Whether they know it or not, blog authors (the masses) are actually Web authoring everytime they write a blog.  But, had it not been for the way blog technology takes care of 99 percent of the heavy lifting that's needed to Web author a blog page (between the blog entries, the automatic navigation, recent links, blogrolls, comment handling, etc.), most people would never have bothered.  To the extent that it's primarily and narrowly focused on a single application of the read/write Web, it could be said that the category of blogging solutions fills one of at least two read/write Web "verticals." 

The other major read/write Web vertical is wikis.  (Are there or will there be other categories? Feel free to chime in).   With blogs, each blog entry (like the one you're reading now) is usually authored by one person and isn't subject to change.  To the extent that they facilitate productive and often public discourse, there's a collaborative nature to blogs.  But wikis take that a step further by making it possible for anybody who has access to a specific previously authored wiki page to edit it as well, usually with nothing more than their browsers.  From the homeowner looking to simply create an owner's manual for his or her house (something I'm going to do for mine) to businesses and enterprises that generate tens, hundreds, or thousands of electronic documents a year, the impact of wiki technology can be profound.  First, instead of documents being locked up in proprietary file formats or document management systems, wikis make them available, networkable, and very easily searchable using standard Web technologies such as browsers, HTML, and HTTP (the protocol of the Web).  Second, the documents are easily editable by anybody, which means wikis are great in collaborative environments where more than one person may end up contributing to one or more documents that are kept on a wiki.

But there are some gotchas with wiki technology: Gotchas that I've been thinking about with respect to the Mashup Camp wiki and gotchas that OPML might provide some relief to.  For example, take a look at any of the documents that were created by the Mashup Camp 1 attendees on the Mashup Camp Wiki.  Two really good examples are the the notes from the discussion on mashups and mobility and the notes from the discussion on Creative Commons that was  led by Lawrence Lessig.  As you can see from the first set of notes, the page has some bullet points but is otherwise voided of any formatting or outlining.  Currently, wikis are at their best when they're used to store unstructured information like this (note that I said unstructured and not unstructurable). 

The percentage of world's digitally stored data that has no structure to it is supposedly north of 80 percent of all data.  So, any technology -- like wiki technology -- that makes it easier to create, archive, connect to, search on, and collaborate over the biggest category of data (by far) is a cool technology. That wikis do this more deftly and at a far lower price point compared to systems that are way more costly, more proprietary, harder to universally access, and that are for the most part not interoperable is one of the best kept secrets of the commercial content management systems business. 

So, what if anything has OPML got to do with this? Well, for starters, one reason some wiki documents have structure to them while others don't has to do with the authors' familiarity with what's known as "wiki markup."  Like blogs, wikis make Web authoring a snap until you want to do something beyond the publication of simple text.  Harkening back to the early days of word processers, with blogs, the ability to do so and do it easily may depend on the blogging tool being used and the extent it offers conveniences like WYSIWYG editing.  The same goes for wikis.  With the Kwiki-based wiki we used for Mashup Camp, we had some difficulty getting the WYSIWYG plug-in working so we turned it off completely.  For people editing the pages on the mashupcamp.com, this meant mastering Kwiki's wiki markup language which is different from the wiki markup languages of other wikis (eg: the wiki markup language behind mediawiki; the wiki technology behind Wikipedia).  Outlining is one of several ways that structure can be added to a wiki page's text (another is tables), but it's also an example of where the markup needed to get the desired results differs from one wiki to the next.   Lack of a universally adopted wiki markup language is not only one of the category's biggest shortcomings, it's also an impediment to widespread wiki use on the behalf of end users.  Why should users have to master different wiki markup languages for each wiki they visit?

OPML support could help to alleviate the problem.  Provided all the wikis offered the right level of OPML support, an OPML editing solution like Dave Winer's OPML Editor might be all an end user would need in order to write and/or structure the documents they might publish to any wiki.  Not just for outlining, but for a lot of what one might do to the text in a wiki document.  As it turns out, Winer's OPML Editor is pretty handy at HTML and XML editing as well.  So, if for no other reason than just to overcome the non-standard wiki markup problem, OPML support could be a breakthrough.  Even more so if you consider that an OPML editor can also be used to edit blogs as well.  So, for the "Web author" keeping busy in a multitude of blogs and wikis, an OPML editing solution could be just what the doctor ordered.

But wait, there could be more (if wikis supported OPML).  As can be seen from the Mashup Camp examples, wikis can be great for storing hierarchically structured text over which people collaborate.  One beauty of OPML is how, through a process known as inclusion, outlines can automatically cascade through the Internet from their original source. To me, inclusion is very reminiscent of the way database reporting packages go through SQL and ODBC (Open Database Connectivity) to do live database queries every time a report is opened up.   For example (with OPML), if each department in a company maintained its own OPML-based organization chart (org charts are perfect for OPML), then they can feed the company's overall org chart automatically.  In fact, the company's overall org chart is nothing more than a shell that just includes the org charts (aka: the outlines) of each of its departments.  When including, it's also not necessary to take an entire outline, starting with its root. The way OPML works, you can take a branch, a twig, or even just one leaf. 

So what you say?  Well, let's just say that you had a wiki in your organization that had a special page for interesting events to attend and let's say your wiki, the Wikipedia, and your word processor all supported OPML.  If Wikipedia supported OPML, you could include the related events section of the Wikipedia's page on mashups on your wiki's event page.  And you could include similar event "branches" from other pages all over the Web (wikis or not, as long as they supported OPML).  From that point forward, managing your interesting events page gets a lot easier because now it's just relying on the people who are maintaining all those other event branches on those other pages that your events page links to.  No matter when someone opens your events page, it should always reflect any changes that were made on any of the others.  In a funny way, OPML turns the editors of those other pages into collaborators on your wiki and they don't even know it.  More importantly, if you merge the collaborative context of wikis with the power of OPML, you end up with the ability to automate knowledge aggregation in ways that far exceed the capabilities of any high-brow content/knowledge management system that I know of.

Finally, why did I mention "word processor" in the last paragraph? Between wikis and blogs, you really have to think long and hard before creating a document with a word processor.  In most business cases, you're better off publishing using a blog or a wiki than you are with a word processor.  Maybe (just maybe), you may have to distribute an uneditable document, in which case I'd sooner author it in PDF than I would with an ordinary word processor.  But word processors do excel in polishing up the documents they create (for example, for reporting purposes). For this reason, their support of OPML would be just as welcome since there are plenty of word processor-related documents that could benefit from the inclusion of live data (much the same way there are currently spreadsheets that draw upon live data via SQL/ODBC every time they're opened).