TPVortex: Intro, Call For Help

In my manifesto for collaborative tools, I cited Backlinks as an example of a common, yet oft-overlooked conceptual construct in collaborative tools. Those who know me well know that my strategy for implementing some of Doug Engelbart‘s ideas (which I crafted over three years ago) has always been to create simple, concrete tools that could easily be shoehorned into existing applications. The plan was to start with Granular Addressability (Purple Numbers), then move on to Backlinks.    (247)

For a number of reasons, now seems to be the right time for me to start shifting my technical focus to Backlinks. The strategy for doing this is to implement a generic, Open Source, Backlink database (dubbed “TPVortex” and integrate it into several existing tools: PurpleWiki, blosxom, MovableType, MHonArc. I’m looking for folks who might be interested in participating in this project.    (248)

The motivation for such a tool is straightforward: Backlinks provide useful, contextual information. Most Wikis already implement Backlinks. Some of them display Backlinks on the main page, which is the correct behavior. Others (including PurpleWiki) do not. In order to implement this properly, you need a Backlink database.    (249)

Once you have a Backlink database, you might as well use it for other applications besides Wikis, such as blogs. We have this integration in PurpleWiki (see Wikis As Topic Maps for the resulting benefits), but again, it would be much nicer to display the Backlinks on the page itself rather than requiring a person to click on a link to see them. In order to implement this properly, the database has to store document metadata, such as title and author, not just the Backlink. For this reason, I think that TPVortex should use an RDF database on the backend.    (24A)

Other thoughts:    (24B)

I welcome help in all forms — comments, critiques, and especially coding. I’ve set up a Wiki page at the Collaboration CollaboratoryCollab:TpVortex — to serve as the center of design discussions. If you’re interested in contributing or commenting, please do it there. Feel free to drop me an email as well.    (24F)

Blog Backlinks Enabled on PurpleWiki

If you view the Backlinks on any of my Wiki pages, it will now display Backlinks from both the Wiki and also this blog. For example, if you view the backlinks to “DougEngelbart”, you will see a list of all of my Wiki pages and blog entries that mention Doug.    (SG)

The beautiful thing about this feature is that it maintains context for all of the different concepts described on my Wiki. I list several Patterns on my Wiki, with some level of detail on each page. But when you look at the Backlinks to those Patterns, you see a list of all the stories where the Patterns are mentioned. I tell the stories as I have before, and the tool explicitly ties the concept to the stories that describe the context. That’s augmentation! As Chris Dent said, it “makes the universe bigger.”    (SH)

My essay, Wikis As Topic Maps, describes this phenomenon in further (and slightly more technical) detail.    (SI)

Open Source At Work    (SJ)

How this feature finally became implemented is a wonderful example of what makes Open Source so great. We’ve wanted it for a while, but didn’t have time to implement it. Last month, I started thinking more seriously about implementing the feature, because I wanted to demonstrate it to some potential clients. Unfortunately, I was swamped, and didn’t have time to do it myself.    (SK)

David Fannin to the rescue. David had installed PurpleWiki and the MovableType plugin, and liked it. However, he also wanted the Backlink feature. So, he wrote it, and contributed it back to us. Neither Chris nor I nor anyone else in the small PurpleWiki community knew David beforehand, but as you can imagine, we welcomed his contribution.    (SL)

David’s patch was just a hack. Chris had some ideas for refactoring the PurpleWiki code to better integrate this feature. So, he implemented them, and released a preview of the code. Chris’s refactoring made it very easy for me to write a similar plugin for blosxom. Suddenly, we had the feature I had been pining for.    (SM)

As an aside, I had grander plans for how to implement this feature, and those plans haven’t gone away. (See my notes on TPVortex for a preview.) The important thing is, David and Chris’s approach worked. It may not do all of the whiz bang things I eventually want it to do, but it does what I want it to do right now. More importantly, it may very well inspire others to implement some of the grander ideas. Release Early And Often is an extremely important pattern of Open Source development, because it enables collaboration, which accelerates the implementation and dissemination of ideas.    (SN)

Precedence    (SO)

Ours is not the first integrated Wiki and blog. Notable precedents include Kwiki and Bill Seitz‘s Wiki Log. These tools all had the integrated Backlinks feature before we did.    (SP)

The key difference between these tools and ours is that they require you to use a single tool. You have to use Kwiki as both your blogging tool and Wiki to get all of the features. Our approach integrates PurpleWiki with MovableType, blosxom, and conceivably any other blogging tool. This is consistent with our overall philosophy of improving interoperability between tools using Doug Engelbart‘s ideas as a unifying framework.    (SQ)

We’ve only taken baby steps so far. We plan bigger and better things. More importantly, we want to encourage other tool developers to adopt a similar approach, and to collaborate with each other to do so.    (SR)

PurpleWiki v0.9 Released

PurpleWiki v0.9 is now available. Chris Dent‘s announcement covers the basics. A few words on how we got here, and where we’re going.    (83)

The Wiki Experiment    (84)

When we launched Blue Oxen Associates last December, we made Wikis a core part of our infrastructure. We had two reasons for choosing Wikis. The first was practical. We needed a system for sharing documents and collaborative authoring, and Wikis fit the bill quite nicely.    (85)

The second reason was more philosophical. We wanted a knowledge management system like Doug Engelbart‘s Open Hyperdocument System (OHS), and felt that Wikis already resembled the OHS in many ways. It was immediately usable and useful, while also offering the perfect platform for coevolution.    (86)

PurpleWiki fulfills the following OHS requirements:    (87)

  • Backlinks. This is a core feature of all Wikis, but also one of its most underutilized. In a future version of PurpleWiki, we will create an open API to its Backlink engine, so that other applications (such as blogs) may use it.    (88)
  • Granular Addressability. PurpleWiki‘s site-wide, automatic Purple Number management had the additional benefit of enabling us to quickly experiment and evolve the feature. Node IDs are now document-independent, which has improved usability and enabled features like Transclusions.    (89)
  • Link Types. We’ve added a syntax for specifying link types, and have implemented our first new link type: Transclusions.    (8A)
  • View Control. We can easily add new or customize existing output formats, thanks to PurpleWiki‘s modular architecture. More importantly, we can implement dynamic views, such as a collapsible outline view, of any document on PurpleWiki.    (8B)

PurpleWiki‘s most visible feature is Purple Numbers, but its most important feature is its data architecture. In general, Wikis view the world as a graph of linked documents. PurpleWiki views the world as a graph of linked documents with a unified data model. The data model is sufficiently general and simple to apply to any kind of document. When you use this data model in other applications, you automatically inherit PurpleWiki‘s features. Integrating PurpleWiki with blogs was a piece of cake as a result, and we’ve only begun to explore the ramifications.    (8C)

Next Steps    (8D)

Our roadmap lists several enterprise features we plan on implementing: templates, pluggable database back-ends, mod_perl controller, etc. I consider these important, but relatively mundane. Blue Oxen Associates isn’t in the business of software development; we’re implementing these features because we need them.    (8E)

Blue Oxen Associates is in the business of research and improvement, and of facilitating coevolution. PurpleWiki is an amazing platform for this. One of Chris’s pet projects is to create universal ID space for nodes, possibly based on handles. Think of this as persistent URIs for nodes. Among other things, this will enable us to support Transclusions of content from other sites, not just the site on which PurpleWiki is installed.    (8F)

My long-term interests lie in three areas: the aforementioned open Backlink engine, Wiki page types, and Wiki namespaces. I’ll discuss the latter a bit here.    (8G)

One of the reasons I dislike TWiki is its notion of “webs.” You can partition your Wiki into multiple webs, and each web is contained in its own namespace. The problem with this is that it encourages people to balkanize their Wiki content. That, in my opinion, runs counter to the spirit of Wikis. Early balkanization prevents evolution.    (8H)

Several months ago, Richard Gabriel passed along some insight he had learned from Ward Cunningham: In computer science, you want to keep namespaces separate. With Wikis, you want namespaces to clash. Ward’s idea for SisterSites is one way to create namespace clash. This idea could be taken a step further by allowing site administrators to establish a system of namespace resolution. For example, if a certain page doesn’t exist on a local namespace, the Wiki would search another namespace for that page. If it existed there, the Wiki would simply take the user to that page.    (8I)

WikiWords Versus External Links

Suppose you are writing in a Wiki or WikiWord-enabled blog. Why would you use a WikiWord instead of an external link?    (3T)

For a more concrete scenario, consider a link to Blue Oxen Associates. You could either create an external link to http://www.blueoxen.org/, or you could use the WikiWord Blue Oxen Associates. I see several advantages to the latter:    (3U)

  • Easier to remember. Is it blueoxenassociates.com or boa.net? WikiWords are human-friendlier link names.    (3V)
  • Enter the link once. If your Wiki page includes the appropriate external link, and if that link changes, you only have to update the link once.    (3W)
  • Annotation. I often create Wiki pages to organizations that contain an external link and the contact information. Having the contact information on the Wiki page saves me from having to search the external site for that information.    (3X)
  • Backlinks. If you use a WikiWord, you inherit your Wiki’s Backlink functionality, which allows you to find other interesting and relevant pages.    (3Y)

The primary disadvantage occurs when the Wiki page simply consists of an external link. In this case, you force the user to click twice instead of once to get to the relevant information. I believe that this is offset by the other advantages of WikiWords.    (3Z)