Winer on wikis: Just add OPML

Winer on wikis: Just add OPML

Summary: 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.

TOPICS: Browser

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

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It would work for me

    One of the reasons that I've not been more active in Wiki's is the lack of a standard "language".

    I think that OPML would be an ideal tool to standardize and move this technology forward
  • Why OPML?

    I can see the potential of what you describe, what I don't see is any reason for using OPML rather than (X)HTML except for Dave Winer's editor.

    HTML has all the capabilities of OPML for structuring data/content and a lot more besides (especially if you consider Javascript, CSS, XSL). Given the mature-standard status and huge deployment of HTML compared to OPML, wouldn't it be easier (and more web-friendly) to encourage the outline-editing mode in existing HTML editors?

    Also given that the normal view of Wiki is as HTML, isn't introducing OPML just an unnecessary complication?

    For posting from client tools, Dave's suggesting using the MetaWeblog API. Again, this is introducing an unnecessary complication (XML-RPC). You get the data from a Wiki directly over HTTP, why not simply post it that way too?

    btw, Murray Altheim's sketched out a subset of HTML that would be suitable for interacting with Wikis, see:
  • OPML wikis at OPML Workstation

    We have been experimenting with OPML wikis at OPML workstation. You can create an OPML file, and then allow anybody to edit it. For example, I started a list of cooking blogs, and then opened it up for anybody to add to. Somebody might, as you say, add a link to another OPML file that they maintain (inclusion).

    Similarly groups of people could utilize OPML to maintain notes, lists, presentations etc.
    The next version of OPMLWorkstation (to be released later this week), will have security - so you can have a private OPML wiki where only people who you give a private password to can edit the OPML.

    OPML wikis have potential - particularly when one wants to maintain distributed information in an organized manner.
  • makes no sense

    Using OPML to persist Wiki documents is a ridiculous proposition. Why would you want to turn such a simple solution into something that is so complicated that no one will want to use? If David is convinced that OPML markup is simpler to generate and manage than MediaWiki markup and/or ODF markup then David should be working on evangelizing outlines and the OPML editor <b>instead of</b> Wikis.
  • Structured wikis exist already

    OPML looks promising, but I have to agree with the previous post that you can do most of what applies to wikis already with XHTML.

    Wikis that handle structured content exist for a while, but they are mainly used behind corporate firewalls. The open source TWiki Enterprise Collaboration Platform [1] has a WYSIWYG editor [2] for easy content creation. It also supports structured data in many ways:

    1. Includes: Other wiki pages and HTML pages can be included [3] as a whole or selectively. This is useful to create large documents (manuals etc.), or to create dynamic content with parameterized includes [4].

    2. Forms: The TWiki Forms [5] allow users to easily build database tables in a wiki where each table row is represented by a wiki page that has a form attached to it. When you look a page you just see a table, when you edit it you can change the form fields (text, chack boxes, radio fields, etc.)

    3. Reporting: Formatted Search [6] is used to report and format on structured data. The ChartPlugin [7] is used to produce nice graphs.

    4. Capture structured content: The CommentPlugin [8] allows users to quickly post comments to a page without an edit/save cycle. Content can also be captured in a structured way. For example, EditActionItems [9] has three input fields that are appended to a table.

    5. Spreadsheets: The SpreadSheetPlugin [10] adds spreadsheet capabilities to wiki pages. Formulae can be placed in table cells and outside of tables. Tables can easily be edited with the EditTablePlugin [11].

    6. Database conectivity: Data can be pulled from a relational database using DBIQueryPlugin [12] or DatabasePlugin [13] and summarized with spreadsheet formulae.

    7. There are many more structuring elements, such as wiki webs, parent/child relationship of wiki pages, tagging, XML and XSL transformations, and more.

    Interested readers are invited to try TWiki out on [1]. Read also a recent presentation [14] I gave at LinuxWorld on "Wiki Collaboration and Wiki Applications for the Enterprise".

    -- -

    • Twiki user here...

      I delved into the not so wide world of Wiki publishing early last year and have since set up no less than three wiki installations, Twiki being one of them.

      Its been a while since I've done much of anything with them since getting them set up, primarily due to the arcane and mostly unfamiliar markup required for integrating and structuring documents and data into the world wide information network that is the the core nature of the wiki concept.

      What was needed was a WYSIWYG tool, and from the sound of it, Twiki now has that feature - thank you - thank you - thank you. And all these other plugins are now also available? Time to book a flight back to Twiki land and do some more investigative research I guess.

      Docuwiki is one of the other wiki implementations I tried. Docuwiki helped simplify the outline structures of a nested wiki document (book with chapters, TOC, index, etc).

      There are some standards established for the wiki format, including provisions for creating an outlined document, but in their raw form they're rather complex and unfamiliar to most, and perhaps well beyond what can be expected from the average user (Think HTML).

      I'll have to investigate these new plugins for Twiki (the WYSIWYG plugin in particular).

      The third wiki that I toyed around with was a wiki plugin module for an open source CMS (content management system) that I had been working with. It was still in beta, and therefore wasn't all that advanced, but combined with all the other features of the CMS - forums, file sharing, calendar, chat, etc., well - the wiki part (once its been fully developed) could be the final stop for the information being produced/managed, ready for sharing with the rest of the world.

      The real power of the wiki collective is the openess of it. When it comes to digital rights management, that's where third party solutions such as the PDF format might have some merit, but for general information sharing, PDF is overkill, unneccessary, and generally speaking, a waste. A simple one page test document can turn into a mega-byte monstrosity, less than optimal in terms of bandwidth and storage concerns, for sure.

      Furthermore, I'm usually sitting here in my browser and to view a PDF file, this monster of a plugin from Adobe has to be loaded, and even then, perusing a PDF document is a tedious experience as well. I hate them.


      • Almost forgot... PDF to HTML

        In addition to what I already said, I also wanted to add this little trick that I recently discovered (came to realize).

        When confronted with a PDF document on a web site, rather than click on the link and wait for Adobe's PDF reader to load (which has on more than one occasion caused my browser or PC to lockup), I'll copy the title or filename for the PDF file and post it into Google's search engine, and more often than not, the results listing will find the file and offer the option to [b]view the file as HTML[/b].

        It loads much faster, and nixes all the superfluous formating. I like doing that, and you might give it a try.