A bit of history: in the early days of the Web (1993-1995 or thereabouts), I developed a Web-base knowledge management Perl application called the Thomson Consumer Electronics Corporate Technical Memory (or CTM for short). [This was before the term "knowledge management" was coined which had made it hard to explain why Thomson should spend any resources on CTM's development.] Recently, I've notice that Wikis encompass most of the functionality of CTM as first proposed. As a CPAN contributor, I have paid special attention to Kwiki because of its extensibility. Kwiki has been extended enough to cover almost all of the functionality of the original CTM specification.
Bear with me, as I step through the original CTM spec point by point, noting Kwiki's corresponding capabilities.
Inputs to System
- Images (anything on paper)
- PC files (WinWord, P870, schematics, netlists)
- Computer programs (source and/or executables)
- With any new input the author must specify subject, author, keywords, related documents, outside references, and related projects.
With Kwiki::Formatter and Kwiki::Attachments, you can have any type of file directly placed into your Kwiki. The core module Kwiki::Formatter shows images the most common kind of attached file.
Subject, author, and keywords are covered by Kwiki::Formatter, Kwiki::User*, and Kwiki::Keywords. Kwiki's linking facilities allow you to include related documents, outside references, and related projects. Looks like System Inputs are covered by Kwiki.
- The users needs the ability to search by author, subject or keywords. A browse mode and a content-search should be available as an aid when keywords are unknown. Cross reference links should be available.
Kwiki::Search handles searches for subject and body text by performing a full-text search. Kwiki::Keywords handles search by keywords and author (Kwiki user) searches. Wikis are Webs, so you get cross-reference links for free.
- The system needs to be able to annotate existing information. A reader may add information or comments into an existing document but cannot edit the original content.
Wikis do this naturally. Kwiki::Comments provides a mechanism to keep annotations separate from the main page text.
- The system needs to be able to be updated by creation of an a new document from an existing document. The existing information cannot be changed even by the author but he or she can create a new document as a revision of an existing one.
Kwiki::Archive, Kwiki::Revisions, and Kwiki::RecentChanges give you a handy way to implement source control, which is even better than the mechanism proposed for CTM.
- A user may request to be notified when a new document is created under the keywords of his or her choice.
The various RSS modules provide much of this functionality (maybe even all of it I haven't looked at those yet).
- Who has reader access? Anybody within the engineering community.
- Who has author access? Anybody within the engineering community.
Again, Wikis do this naturally. Kwiki::User* can be used to provide as little or as much protection for individual pages as you desire (as long as you don't need Kwiki::UserGroups).
- Documents deemed to have special technical merit will be included in an "Authority Section". This is a continuation of the Authority File already in existence at TCE.
As far as I know, Kwiki does not have this functionality. I don't think I've seen it in other Wikis, either. Off-hand, Authority Section documents sound to me to me like they could be documents with special tags where only a few people are allowed to edit those tags.
Wikis particularly, Kwiki provide almost all of the originally specified functionality of the TCE Corporate Technical Memory. Ward Cunningham's genius in creating the initial Wiki (paraphrased as "What's the simplest way to create a website that could work?"), along with Brian Ingerson et.al. work in creating Kwiki, has built a strong foundation for an easy to use, general-purpose, Perl-extensible, Web-based knowledge management application.