WikiWikiWebs: New Ways to Communicate in a Web Environment


Brenda Chawner
and Paul H. Lewis





Brenda Chawner (brenda.chawner@vuw.ac.nz) is Senior Lecturer, School of Information Management, Victoria Uni-versity of Wellington, New Zealand. Paul H. Lewis (paull@usca.edu) is Government Documents Librarian, Gregg-Graniteville Library, University of South Carolina–Aiken.



This paper introduces WikiWikiWeb software, also known as Wiki, for use in library and information management contexts. Wikis provide an environment for Web-based collaboration and can also be used for Web site content management. The article includes an overview of the history and development of Wiki, as well as discussing basic and advanced Wiki features. It compares three Wiki engines and describes seven case studies of real-world library and library-related Wiki applications. The paper concludes with a discussion of factors that can contribute to a successful Wiki project.


Tim Berners-Lee originally saw the Web as “a system in which sharing what you knew or thought should be as easy as learning what someone else knew.” 1 However, early Web browsers just provided read-only access to existing hypertext markup language (HTML) pages, and this publishing model for the Web has predominated. It was not easy for people to share what they knew on the Web; the process involved learning to add HTML to text and using network file transfer software to upload content to a Web server. WikiWikiWeb, or Wiki, software provides one option for realizing Berners-Lee’s early vision by enabling authorized users to edit and create new Web content using only a Web browser.

In 1994–95, Cunningham developed the first Wiki for the Portland Pattern Repository. It can be found at http://c2.com/cgi/wiki, and is sometimes called Ward’sWiki or TheOriginalWiki. Wikiwiki is the Hawaiian word for fast, and a WikiWikiWeb is a quick Web site. Cunningham wrote the original Wiki in Practical Extraction and Report Language (PERL). There is now a wide choice of software for WikiWikiWebs, and Wikis are growing in popularity as people explore their potential in different contexts.

This paper, based on a presentation at the 2004 LITA National Forum, will:
  • describe the history and development of Wiki;
  • list typical Wiki features and concepts;
  • outline factors to consider when choosing a Wiki engine;
  • illustrate Wiki applications in a library and information management context using selected case studies; and
  • identify issues associated with using Wiki.

What is a Wiki?


A Wiki is a server-based collaborative tool that allows any authorized user to edit Web pages and create new ones using nothing more than a Web browser and a text entry form on a Web page. Wikis free writers from the burden of mastering HTML editing and file transfer software before they can publish on the Web. Instead, Wikis use very simple text-based markup to format page text and graphic content. While the idea of letting anyone change anything they want may seem radical or naive, most Wiki engines have features to let community members monitor changes, control user-edit permissions if necessary, restore previous versions of pages, and delete unwanted pages.

Wikis make it possible for people to collaborate in a Web environment by creating, organizing, and maintaining a Web site of automatically linked pages. As such, it is one example of what is known as social software, software that makes it easy for groups of people to communicate or work together in a virtual environment. 2 Other examples of social software include Web-based discussion forums, Internet relay chat (IRC), weblogs or blogs, and instant messaging (IM). Large, successful Wikis usually have some type of constitution or philosophy that establishes goals and provides guidelines for individuals who want to participate in the group.

Some of the words in this paper have StrangeCapitalization. This is because the first Wikis used this convention to name a WikiPage. The software used to operate a Wiki is known as a WikiEngine, and is available in a wide variety of languages, and with a range of features.

Why Wiki?


When might a Wiki be an appropriate choice? Consider the following situations:
  • a state library association is looking for an easy way to create and maintain its Web site;
  • a professional association special interest group wants to provide an easily updated Web-based resource for its members;
  • a library would like any authorized staff member to be able to update content on its intranet as necessary, without needing to use specialist software;
  • an open-source software application project has participants from a range of countries who need to be able to contribute to a shared knowledge base for all software users;
  • a conference planning committee needs a Web-based tool to keep track of their activities and who is doing what;
  • a cross-organizational working group is preparing a collaborative report on a study trip to a range of institutions using a new type of software package; and finally,
  • two people in different parts of the world are jointly writing a conference paper and would like to be able to see each other’s work in context, rather than as individual word processing documents.

A Wiki could be used for each of the above scenarios. This paper will provide selected library and information Wiki examples.

History and development of Wikis


Since Cunningham developed the original Wiki in the mid-1990s, the Wiki concept has spread to many other groups, and people have written Wiki engines in a wide range of scripting/programming languages. Core Wiki features such as ease of editing, simple markup, and automatic linking of pages have been present since the beginning, but as the number of people using Wiki engines grew, extra features have evolved. These include a command to compare the current version of a page with earlier versions (PageHistory or QuickDiff), and one to browse a list of recent changes.

It is hard to determine how many Wikis exist, but SwitchWiki (www.worldwidewiki.net/wiki/SwitchWiki) lists some one thousand public Wikis, and there are many more that are restricted to specific groups (known as GatedCommunities in the Wiki world).

WikiFarms (both free and commercial) are servers that run a Wiki engine and allow people to set up their own Wikis without having to install any software. SeedWiki (www.seedwiki.com) is one example that lets individuals set up Wiki sites for personal use.

Leuf and Cunningham identify six types of Wikis, based on read- and edit-access permissions. 3 These are:
  • fully open, meaning that anyone has full access to the Wiki;
  • lockable, with restricted editing for some or all pages;
  • gated, with some public pages (that may be locked), but other pages restricted to authorized users;
  • members-only, where access is limited to registered users;
  • firewalled, where access is restricted to a range of specific IP addresses; and
  • personal, where access is limited to a specific computer or private site.

Wikipedia ( http://en.wikipedia.org/wiki/Main_Page) is an ambitious project to build a free, open-content encyclopedia. It was begun in 2001 by Jimmy Wales and Larry Sanger, using Wiki software, and as of December 2005, included more than 880,000 articles in English. They based the idea on the open-source concept of “many eyes make all bugs shallow,” and anyone can edit articles and add new ones. While the idea of an encyclopedia that anyone can edit seemed ludicrous at first, during the last four years the project has gained credibility, and the Wikipedia community has put in place mechanisms to monitor and improve the quality of its content. Observing Wikipedia pages over time generally shows that article quality initially improves, and then stabilizes. Non-English versions of Wikipedia are also available; the languages range from Arabic to Chinese to Esperanto, as well as most of the European languages. Wikipedia-related projects now include Wiki-quote ( http://en.wikiquote.org/wiki/Main_Page), Wikispecies ( http://species.wikipedia.org/wiki/Main_Page), and Wiktionary ( www.wiktionary.org).

WikiTravel ( http://wikitravel.org/en/article/Main_Page), inspired by Wikipedia, is a Wiki-style travel guide begun in 2003. It uses a modified version of the Wikipedia engine, MediaWiki. By August 2004, it had 2,325 destination guides, as well as related articles.

The OpenGuides ( http://openguides.org/) project, started in 2004, takes a similar approach to city travel guides. So far, Guides have been started for Glasgow, London, Northern Ireland, Nottingham, Ox--ford, Vegan Oxford, and Reading in the U.K.; Bologna, Oslo, and Vienna in Europe; and Orlando, Saint Paul, and San Francisco. They use the PERL OpenGuides software.

Typical Wiki features


This section describes features that are found in most Wiki engines, although in some cases the syntax may be different. It is by no means exhaustive, and the help pages for each Wiki engine will normally list the range of features and markup it supports. In contrast to HTML, Wiki markup is intended to be simple and nonintrusive.

Creating a new page


Creating a new Wiki page is a simple process. Most modern Wikis use a method known as “free linking” to create new Wiki pages. A free link is created by enclosing any word or phrase within square brackets when editing a Wiki page—i.e., [[New Page]] will create New Page. When the page is saved, the Wiki software interprets this markup and presents it as a hyperlink followed by a question mark to denote that the new Wiki page is an unedited page. Clicking on the new page hyperlink invokes a blank editing form on which content for the new page is entered. When editing is completed, the new page is saved and becomes a part of
the Wiki.

The result of adding the text [[New Page]] to an existing page is shown in figure 1.
figure 1. saved page with the new link indicated by a "?"
Figure 1. Saved page with the new link indicated by a “?”


The free-link markup can also be used to link to existing local Wiki pages, local file attachments, e-mail links, external Web site pages, and other networked resources. The approach to hyperlinking varies from one Wiki to another—for example, MediaWiki uses a single set of brackets while PmWiki employs double brackets.

Early Wikis commonly employed a convention known as CamelCase to create a new Wiki page. A typical CamelCase word consists of any two words joined together with the initial letter of both words capitalized. CamelCase is still used in some Wikis. These normally provide a way to prevent accidental WikiWords resulting from proper names like McIntosh or other situations where CamelCase occurs naturally, such as Ph.D.

Text formatting


Because Wikis use an HTML form to enter and edit content, the markup is text-based, using characters to signal special formatting. Typical formatting conventions are:
  • blank lines signal new paragraphs;
  • asterisks at the left margin (*) indicate a bulleted list;
  • number-signs (#) at the left margin indicate a numbered list;
  • two single-quotes (''), i.e., two apostrophes, indicate emphasis (usually italics);
  • three single-quotes ('''), i.e., three apostrophes, indicate strong emphasis (usually bold); and
  • four or more hyphens (----) at the beginning of a line create a horizontal line.

In figures 2 and 3, two screenshots illustrate a range of Wiki markup and the way it is displayed.
figure 2. range of wiki markup as entered
Figure 2. Range of Wiki markup as entered


figure 3. the way the markup is displayed
Figure 3. The way the markup is displayed


This illustrates one of the benefits of text-based markup—the page of text displaying the Wiki markup is more readable than the associated HTML source.

Linking to an external Web page or resource


Including the text “http://,” “mailto,” or “ftp://” (or even “gopher://”) before a URL or e-mail address will create an automatic link to the location or e-mail address. Some WikiEngines also recognize “www.” as a reference to a Web resource.

Sandbox for new users


Most open Wikis have a page called SandBox or PlayGround for new users to experiment with such things as entering and formatting text, building unordered and numbered lists, and creating hyperlinks. The general rule is that anyone can edit anything on the SandBox page.

File uploads


Wikis usually provide a method for uploading images and other file types (e.g., Adobe Acrobat portable document format [PDF], Microsoft Word) to the Web site. File transfer protocol (FTP) software is the traditional approach to uploading files (such as image files or Adobe Acrobat PDFs) for posting on a Web server. One of the negative aspects of FTP is that the protocol has no way of encrypting username and password information and this is widely regarded as a major security vulnerability. FTP security issues are explained in detail at http://en.wikipedia.org/wiki/Ftp.

A key benefit of Wiki engines is that the process for uploading files is built into the program. File uploads are accomplished using a Web browser and an HTML form; no separate FTP program is needed. Wiki administrators can set upload parameters specifying allowed file types and file size limits in a server-based configuration file; they can also limit file upload capabilities to authorized users. This Wiki file upload process provides a more secure approach than FTP, because it does not involve sending unencrypted user account information over the Internet.

The simple syntax for hyperlink referencing of uploaded files makes it possible to use a Wiki to archive collections of document, image, and multimedia files on the Web. Leo LaPorte, the self-styled “Tech Guy” at the KFI AM-640 radio station in Los Angeles, uses the PmWiki engine to maintain a podcast archive of his radio programs at http://leoville.tv/radio/pmwiki.php/Main/AudioArchives.   The South Carolina Library Asso-ciation (SCLA) Governance page, www.scla.org/Governance/HomePage, is an archive of association annual reports, newsletters, and other documents in Adobe PDF, Microsoft Word, and Wiki page
formats.

Recent changes


A list of recently changed pages is maintained automatically by most Wiki engines (see figure 4).   As a rule, only the latest change is shown for a given page. This is a particularly useful feature, as it allows Wiki community members to easily see what has been changed. Some Wiki engines also support e-mail notification or really simple syndication (RSS) feeds for page additions, changes, and deletions.
figure 4. sample recent changes page
Figure 4. Sample recent changes page

Other features


Wiki functionality is continuing to evolve as developers improve Wiki engines. One example of a newer feature is Page History. This feature tracks previous versions of a Wiki page. With Page History, previously saved versions of a Wiki page may be recalled, reedited, and restored if necessary. This feature is essential for a fully open Wiki, which is vulnerable to malicious damage, or WikiSpam. New Wiki content contributors often find this aspect of Wikis a comfort, as it serves as a safety net to prevent them from doing harm to the Wiki page on which they are working.

Even the simplest Wikis available today usually include a basic keyword search engine to search the contents of the entire Wiki Web site. Of the Wiki engines already discussed, only PmWiki offers full Boolean search capabilities.   PmWiki’s search engine can be tailored in a number of ways to limit searching to specific Wiki groups or pages.

More advanced Wiki engines, such as MediaWiki, PmWiki, and TikiWiki provide additional capabilities to organize groups of pages by hierarchical categories. Wikipedia uses hierarchical categories to organize its entries. For an example of the use of categories to manage linking to geography-related topics, see http://en.wikipedia.org/wiki/Category:Geography. The PmWiki engine offers WikiTrails as another feature for organizing groups of pages. An example of a WikiTrail for a library circulation manual is shown in figure 5.
figure 5. sample wikitrail page
Figure 5. Sample WikiTrail page


The WikiTrail appears at the top and bottom of the Web page, allowing quick access to the preceding, home, and next pages in the manual. WikiTrail links facilitate logical movement through the pages in the circulation manual.

Other Wiki concepts

Collaboration versus discussion mode


There are two main writing modes used by members of a Wiki community. In collaboration or document mode, the focus is on creating a piece of text that the community is happy with, and the content of which can be edited by anyone. Discussion, or thread mode, on the other hand, is a form of dialog in which individual contributions are kept separate (more like a conversation). Rather than editing the existing content, different authors add their own comments, and may “sign them.” Horizontal lines are often used to insert a break between authors. The original version of this paper was written using collaboration mode. Figure 6 illustrates discussion mode.
figure 6. selection from discussion mode page (accessed july 1, 2005, http://wiki.lianza.org.nz/index.php/itsig/commentonthewiki)
Figure 6. Selection from discussion mode page (accessed July 1, 2005,  http://wiki.lianza.org.nz/index.php/ITSIG/CommentOnTheWiki)


Communities whose main purpose is online discussion might find other software tools, such as discussion forums, more useful. Wiki-based discussion mode, however, can be particularly useful as a technique to support comments on pages created in collaboration mode.

Refactoring


This term is used to refer to the editing of one or more pages to make the content more coherent, or move it to a more appropriate location. Refactoring is often done when an extended discussion has created a number of similar pages, or when related points have been made on different pages. Good practice is to include a note on all edited pages to say what changes have been made, or to indicate the location to which content has been moved. Refactoring may also involve adding structure to a page—for example, by including headings or a table or contents, to allow a long page to be browsed more easily.

Choosing a Wiki engine


Currently there are at least one hundred separate publicly available Wiki engines to choose from, according to an extensive list of Wiki software projects maintained at http://c2.com/cgi/wiki?WikiEngine. Wiki engines have been developed in many computer-scripting languages, though the most popular appear to be personal home page (PHP), PERL, Python, and active server pages (ASP). Some Wiki engines work only on specific operating systems. For example, Wikis developed using the Microsoft ASP programming language only run on Microsoft Windows Web servers. However, most of them are multiplatform and will function properly if their requirements are met. With so many different Wiki engines from which to choose, selecting the right Wiki can seem like a difficult task.

Wiki documentation


One can quickly begin to get a clear picture of the level of quality of a given Wiki project by checking out the Wiki developer’s Web site. Is clear documentation provided on all facets of the Wiki project, including system requirements, installation, upgrading, core functions, and expanded features?

Project maturity


Every individual Wiki is a unique software project unto itself. As such it can be thought of as existing in a particular stage of development. Has the Wiki been around a while or is it just getting started? Does the project Web site have a section detailing the development history of the Wiki? In general, a more mature project is more stable and reliable with fewer software bugs.

Wiki community


Is the Wiki developed by a single individual working essentially alone, or is there an active core of developers? What might become of the Wiki project if the original sole developer loses interest or otherwise cannot continue development? Also, what methods of feedback are provided for end users and developers to communicate? A mature project Web site will often offer a combination of e-mail, bulletin board, electronic discussion list, and possibly IRC for fast responses to requests for support. Are developers friendly and helpful when new users have questions? Is there an underlying philosophy or design principle, and how closely is it aligned with the library’s goals for a Wiki?

W3C standards compliance


Does the Wiki offer compliance with Extensible Hypertext Markup Language (XHTML) and cascading style sheet (CSS) guidelines recommended by the World Wide Web Consortium (www.w3c.org)? In January 2000, the W3C issued guidelines urging adoption of XHTML, the successor markup language for HTML. Any library considering an upgrade of its main Web site or any new Web project that will be publicly available should consider XHTML compliance as a basic requirement. However, if the Wiki is to serve solely as the library’s intranet or for some other nonpublic Web project, then XHTML compliance might be less of a concern. For more information about XHTML, see  http://en.wikipedia.org/wiki/Xhtml#The_XHTML_2.0_draft_specification. A CSS is essential for developing a consistent look and feel for a Web site. Mature Wiki projects provide CSS functionality for site-wide aesthetic control over the color, layout, fonts, and so on.

Local resources and expertise


Does the library have its own Web server or does it share space on the parent institution’s Web server? Although not required, it may be more convenient in the long run to have a Web server dedicated to Wiki. Every Wiki contains one or more configuration files that reside on the Web server. The Wiki administrator will need access rights to the Web server in order to edit configuration files. Most likely this person will be the current library webmaster. Is there a staff person available with the knowledge, skills, and abilities to serve this function? Also, are local staff who contribute content on board with the changes? One of the biggest obstacles to implementing new Web technology may be reluctance by content contributors to try something new.

A choice is a commitment


Moving from traditional Web site development to a Wiki or other type of content management system requires a substantial investment of time and effort. Very few systems offer batch transfer options to automatically migrate the content of an existing Web site to another format, though preliminary discussions about a WikiInterchangeFormat have begun ( http://c2.com/cgi/wiki?WikiInterchangeFormat). It might be useful to identify a short-list of potential Wiki engines, and install each on a trial basis before making a final decision.

Beyond the basic Wiki


Simplicity in form and function was part of the original allure of Wiki software. Today Wikis have evolved beyond being simply a workgroup collaboration tool. They are now replacing traditional Web sites. As such, some Wikis include advanced, interactive elements that modern Web sites offer such as permissions control for content contributors and users, e-mail feedback forms, calendars, photo galleries, and RSS feeds. A library organization looking to replace its traditional Web site with a Wiki, for example, might want to consider whether a given Wiki engine offers any extra functions.   Additional features are often called plugins or modules. Plugins should be stable and simple to install, and supported by an active plugin community. A list of plugins a library Wiki might consider are (to name but a few): an interactive calendar application, graphical user interface edit controls, a keyword searchable image gallery for managing a local history digital photo collection, project management issue tracking, RSS link feeds from national and international news organizations or professional associations, a Java-based interactive image editing application, and a geographic map and data server.

Disadvantages of Wikis


Though their flexibility and simplicity mean that Wikis are useful in a variety of contexts, there can be issues associated with their use. WikiSpam can be a major problem for fully open Wikis. This usually takes the form of unwanted links to commercial or pornographic sites. While active Wiki communities generally rely on members monitoring changes and reverting spam, less active ones might need to implement a form of spam protection. Techniques for dealing with WikiSpam are evolving, and currently include:
  • increasing the level of security, usually by requiring a password to use the Edit function;
  • blocking updates from IP addresses of known spammers;
  • blocking updates that contain specific unwanted words or phrases;
  • restricting the number of links that can be added in a single update;
  • “hiding” the Wiki site from search engines by implementing “no index” and “nofollow” metadata tags on Wiki pages, as well as asking community members to avoid posting its URL on Web sites; and
  • requiring any links to external sites to be approved by an administrator.

The lack of a standard for Wiki content markup, which makes it difficult to migrate content to another Wiki engine or Web content management, is another issue, though this applies to all Web content environments, not just Wikis. The lack of a “what you see is what you get” (WYSIWYG) editing environment can be a barrier for participants used to working in a word-processing environment.

Although all Wikis share a set of key characteristics, Wiki projects vary considerably in their underlying architecture and the feature sets they offer. The result is a rich diversity of Wiki engines designed to meet a range of needs for managing Web content. The DocuWiki site includes an extensive table comparing features of different Wiki engines at  http://wiki.splitbrain.org/wiki%3Acompare. This section examines three Wiki projects, which represent different approaches to Web content management; these range from extreme simplicity to (perhaps) feature overkill.

QwikiWiki

Project Home Page:  www.qwikiwiki.com
Download:  http://prdownloads.sourceforge.net/qwikiwiki
Download file size: compressed: 57 kilobytes
Real world deployment: PeacefulFuture.Net http://wiki.peacefulfuture.net/

QwikiWiki packs an impressive amount of power and flexibility in a very small amount of PHP code. It is a testament to the creativity that can be achieved by a single software developer. QwikiWiki includes an installation wizard program to walk the Wiki administrator through the process of installing the program on the Web server. The Wiki includes three template files to choose from that control the basic layout of the Wiki and four separate CSS that control such things as font types and sizes for section headings and text. The Wiki administrator is free to edit existing templates and style sheets or create completely new versions to suit personal preferences.

According to Barrett, the original developer, QwikiWiki’s core design goal is simplicity. This is reflected in the limited Wiki syntax users are required to learn to begin editing and in the feature set. QwikiWiki permits HTML to work along with the Wiki syntax and this can be especially helpful—for example, when migrating Web pages that include lengthy tabular data from a traditional Web site. QwikiWiki stores its Wiki pages as data in flat text files as opposed to using a database. This is also in keeping with the focus on simplicity.

QwikiWiki includes a very basic Web site search engine, with no Boolean capabilities. An edit password feature is included to prevent page edits by unauthorized users if that option is desired. Other helpful features include an option for automatic e-mail notification when changes are made to individual Wiki pages, ability to list pages that have recently been changed, and a built-in link to a help page containing info on QwikiWiki syntax. Clear, basic documentation is provided on all features. The QwikiWiki project Web site includes a discussion forum where users can ask questions and post feature requests, and an electronic discussion list.

QwikiWiki currently does not offer W3C XHTML compliance so it would be more suited for a library intranet or other nonpublicly accessible library Web project. However, the availability of only a single-site password for this Wiki could also be a limiting factor if, for example, a site has multiple-content providers who each need separate password protection for sections they manage.

PmWiki

Project Home Page:  www.pmwiki.org
Download:  www.pmwiki.org/pub/pmwiki
Download file size: compressed: ~140–200 kilobytes
Real world deployment: University of Minnesota Libraries Staff Web Site http://wiki.lib.umn.edu

PmWiki, like QwikiWiki, also uses flat text files to store its data. Overall, however, PmWiki is more ambitious in its approach to Wiki design. Numerous developers collaborate with Michaud, PmWiki’s creator, on the PmWiki core code, on plugins that extend the capabilities of PmWiki, and on project documentation. The main PmWiki Web site itself is an exemplary demonstration of the power of Wiki technology to support detailed project documentation. The PmWiki project Web site is an open Wiki, and users and developers regularly contribute to and refine the project Web site documentation. The basic PmWiki installation includes extensive documentation.

Updated versions of PmWiki are released on a very frequent basis. Developers and users have multiple channels to provide input and feedback, including a very active electronic discussion list, an IRC channel for real-time troubleshooting, and, of course, e-mail.

One feature that distinguishes PmWiki from other Wikis is its support of the concept of Wiki groups. A PmWiki Web site may have multiple groups that can be created according to organizational function or for individuals within an organization, or by topic, or any combination of groupings. These distinct groups may have separate stylistic elements and password settings apart from the main Wiki. Read-and-edit passwords may be set for individual pages, groups, or the entire Wiki site. This granularity of read-and-write password protections for individual pages and groups can be very useful in library or other Web site contexts where site content providers need to exercise control over who may edit their pages.

With PmWiki it is possible to establish a WikiFarm on a single server. WikiFarm is a feature somewhat similar in concept to a Wiki group. With a WikiFarm, multiple independent Wikis are maintained through a single configuration file.

PmWiki’s editing syntax is more extensive than that found in QwikiWiki, and yet it is still quite simple to learn. CamelCase WikiWords can be spaced when pages are displayed, or turned off completely. This approach gives hyperlinks a more natural, grammatically correct presentation.

Like QwikiWiki, PmWiki also permits mingling of Wiki syntax and HTML markup; this option is configurable by the site administrator, since enabling some types of HTML markup on an open Wiki can be a security risk. PmWiki has given significant attention to ensure compliance with W3C XHTML markup requirements. The look and feel of the site is controlled by templates and CSS. Its user community has contributed numerous templates to the project. As with QwikiWiki, users are free to edit existing templates and style sheets or create new ones. This design flexibility makes it possible to marry the PmWiki engine with a variety of Web site layout designs.

PmWiki offers a rich feature set. The PmWiki Web site search engine offers Boolean search capabilities. The search engine can also be configured to search selected Wiki groups within the Web site. An interactive calendar, photo galleries, graphical editing buttons, RSS feeds, and a random quote plugin are just some of the many enhancements beyond the core Wiki program. Most plugins are installed easily by uploading a single script file to the Web server and then editing a main configuration file to add a single line in the code referencing the script file. The PmWiki project Web site has a Cookbook section where all available plugins are listed along with installation details.

PmWiki is a powerful Web site content management system that can be used for a large number of applications. The ability to set read access rights for the entire Wiki makes PmWiki an excellent choice for organizational intranets. PmWiki is a good choice for small, medium, or large library Web sites and Web projects. It is one of the more widely used Wiki engines, with a Google search showing more than one million hits in mid-2005.

TikiWiki

Project Home Page:  www.tikiwiki.org
Download:  http://tikiwiki.org/Download
Download file size: compressed: ~4.7 to 6.9 megabytes
Real world deployment: Damosoft UK www.damosoft.co.uk/Home

TikiWiki is a large, open-source content management system (CMS) software project with more than six thousand registered users and more than 260 registered developers. TikiWiki has been called a “kitchen sink” Web CMS because of the numerous features and functions it offers. The actual Wiki component is but one of many modules included in TikiWiki. Other TikiWiki modules include public and private discussion forums, workflow management tools, interactive chat, a photo gallery, file download archives, a map server, and many others. TikiWiki, like many other traditional CMSs, is more focused on managing time-sensitive news articles, discussion forums, and blogs rather than on building Web pages. Indeed some CMS packages have created static-page plugin modules well after the initial release of the core package as a way to address user needs for traditional Web page management. By fully integrating a Wiki into its feature set, TikiWiki represents a hybrid CMS/Wiki and may well set a trend that other CMS projects emulate in the future.

TikiWiki employs a MySQL database to store all its data, including its Wiki pages. This requirement for MySQL database management skills adds a significantly higher threshold for the would-be Wiki administrator that can be somewhat intimidating. It should be noted, however, that many Wikis use a database backend and that learning how to manage a database-backed Web site is not an insurmountable task. Several excellent, free, open-source software tools are available to simplify the process. TikiWiki includes detailed installation documentation and a software wizard script to streamline initial Web site setup. Like PmWiki, the TikiWiki developers have used their Wiki to develop extensive documentation for all facets of the program.

TikiWiki includes extensive user and group read-and-edit permissions settings for its Wiki and all other modules. TikiWiki administrators pick and choose the modules they wish to deploy using a Web browser-based site control panel; other modules are turned off by default. It offers W3C XHTML and CSS compliance. There are numerous stylistic themes from which to choose. The project is under constant development with frequent updates. TikiWiki can be fine tuned to serve just a about any type of Web site need.

Selected library and information management case studies


There is an increasing number of library and information management Wikis; some are public while others are gated or closed, such as library staff intranets. Lamb identified four educational Wikis in use at the University of British Columbia, including course management, job postings, conference planning, and collaborative writing technology. 4 Frumkin describes the use of Wiki software for a reference librarian knowledge base and a Web site content editing tool, and suggests that Wikis also have potential in digital libraries—for example, as a tool for user annotations or comments. 5 Farkas set up an unofficial American Library Association 2005 conference Wiki, which was used by a number of conference attendees for conference tips, location information, and session reports (http://meredith.wolfwater.com/wiki). More recently, Farkas has set up Library Success: A Best Practices Wiki (http://libsuccess.org).

LIANZA/ITSIG Wiki


http://wiki.lianza.org.nz

A Wiki used to develop a shared resource for members of the Infor-mation Technology Special Inter-est Group (ITSIG) of the Library and Infor-mation Association of New Zealand/Aotearoa (LIANZA). This was launched in October 2003, using the PmWiki engine.   It includes information about ITSIG and its activities, as well as a resource page with links to useful sites. It also hosts a research register for the Research Special Interest Group (SIG), which allows anyone to create a page about research projects relevant to New Zealand libraries. A template is used to format the initial edit page for a new research project page, displaying the fields and basic markup. WikiSpam (like e-mail or blog comment spam) has become an issue, and the Wiki has recently changed from being fully open to requiring a password to save changes. Known Wiki spammers are blocked.

Koha Project Wiki


www.saas.nsw.edu.au/koha_wiki

A locked Wiki set up to support members of the Koha open-source library management system project. It includes a register of Koha users, pages about installation and migration, information about reporting bugs, and documentation about Koha features. It uses the WikkiTikkiTavi engine.

New Zealand Government Tertiary e-Learning Standards Wiki


http://wiki.tertiary.govt.nz/~TertiaryELearningStandards/Main/HomePage

This is a gated Wiki set up to allow people to comment on an overview of standards for e-learning. People who wish to comment must first register, but the content is available for anyone to read. Part of a project to develop a national tertiary e-learning framework, the interim framework document was developed using a password-protected closed Wiki, with participants from a number of government departments, including the Ministry of Education and the National Library. Both Wikis used the PmWiki engine.

New Zealand Institutional Repositories Feasibility Wiki


http://wiki.tertiary.govt.nz/~InstitutionalRepositories

The National Library of New Zealand set up a project to investigate options for institutional repositories for the New Zealand research sector in May 2005. This Wiki site was set up to provide a shared resource for project members, in particular to allow them to document their findings. It uses the PmWiki engine.

South Carolina Library Association


www.scla.org

The South Carolina Library Asso-ciation (SCLA) Web site serves the library community in South Carolina. It is a moderately sized Web site with more than three hundred separate pages. Page editing is password protected. Association committee, section, and round table chairs are authorized to maintain their respective pages. This Web site uses the PmWiki engine.

University of South Carolina (USC)–Aiken Library


http://library.usca.edu

The USC Aiken (USCA) Library Web site is a typical small academic library site employing PmWiki software for site content management. PmWiki is also used to manage the USCA Library’s intranet. The intranet portion of the site includes the circulation department procedures manual, a section for development of the library’s strategic planning and assessment, a section for collaboration for this Library and Information Technology Association (LITA) paper and presentation, and other content.

The USCA Library migrated to PmWiki from another content management system software, phpWeb site (http://phpWeb site.appstate.edu), during the summer of 2004. Librarians and some general staff contribute content to the main Web site and the intranet.

USC—Campuses Library Council


http://library.usca.edu/clc

The USC Campuses Library Council Web site is a very small site whose purpose is to support communication and planning for the eight libraries of the USC statewide campus system. This Web site uses the PmWiki engine.  

Wiki success factors


Getting people to contribute to a Wiki is as much about culture as it is about technology. Even though it is very easy to add and edit Wiki content, it is not always a case of “build it and they will come.” People accustomed to the WYSIWYG approach in MS Word (or even Dreamweaver) may take a while to adjust to the idea of text-based markup, for example. Some Wiki engines, such as MediaWiki and PmWiki, are now moving to a more WYSIWYG approach, with graphical edit buttons on the edit page to help people learn the markup.

Creating the right conditions for a Wiki involves:
  • setting up an effective initial structure, so that people can see where their contribution might fit;
  • monitoring new and changed content, so that inappropriate content is dealt with promptly. This might also require clear guidelines on appropriate content, and a statement about the identity of the intended audience;
  • having a statement about copyright and content ownership. If people sign their contributions, then it might not be considered appropriate for someone else to edit them; a comment (i.e., discussion or thread mode) might be better;
  • providing an explicit Page History link to make it obvious that content can be restored if necessary;
  • having basic text formatting tips displayed when someone edits a page, to help them remember the markup; and
  • having suggested page naming conventions and writing style guidelines. The basic idea here is to remove some of the uncertainty associated with a totally open environment, which might help people overcome their initial hesitation about contributing.

In the early days, it might be useful to “shoulder tap” selected community members for specified Wiki contributions, to start the habit. Some Wikis have lists of “wanted pages” to identify topics they’d like someone to write about.

In some cases having a “comment on the Wiki” section encourages people to describe their reaction to the idea of editable Web content, and it can overcome their initial fear of breaking something if they edit a Wiki page.

Conclusion


The case studies in this paper illustrate just a few situations where Wikis can be effective. Because of their flexibility and simplicity, they can be used in a wide range of contexts, and provide an environment in which Berners-Lee’s early vision for the Web can be achieved. A totally open Wiki might suit a widely distributed organization like the LIANZA ITSIG, while a members-only Wiki would suit a work group collaborating on policy documents or procedure manuals (or simply wanting an easy electronic notice board). Features like Recent Changes and Page History make it easy for community members to keep up with changes. Wikis are also gaining in popularity as simple, lightweight Web site CMSs for groups and individuals. Wikis offer libraries and other organizations a tool that can be used when upgrading traditional Web sites or implementing new Web-based projects—their potential for enabling Web-based communication with staff and users is just beginning to be appreciated.

Libraries were early and enthusiastic adopters of the Web as a medium to enhance and expand access to information for the communities they serve. The Web is constantly changing, and in the next few years we expect organizations to move to more interactive e-services. New technologies offer new opportunities and evolving Web accessibility standards present new challenges for libraries. For libraries looking to take advantage of new technologies and build Web sites that comply with Web accessibility standards, Wikis offer a relatively easy path to build the next generation of library Web sites. At the same time, they raise the possibility of having more interaction with users.

Finally, Wikis illustrate a shift to an increasing ability to use a Web browser as a person’s main application tool, and they foreshadow other browser-based capabilities, such as table or drawing editors, which would make it possible to create complex documents using nothing more than a standard browser.




Author’s note: all URLs in the text were accessed in early July 2005.

References and notes


1. Tim Berners-Lee with Mark Fischetti, Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web (New York: HarperBusiness, 2000), 33.

2.  Wikipedia, s.v. “Social software,” June 30, 2005. Accessed July 1, 2005, http://en.wikipedia.org/wiki/social_software.

3. Bo Leuf and Ward Cunningham, The Wiki Way: Quick Collaboration on the Web (Boston: Addison-Wesley, 2001), 277.

4. Brian Lamb, “Wide Open Spaces: Wikis Ready or Not,” Educause Review 39, no. 5 (Sept./Oct. 2004): 36–48.

5. Jeremy Frumkin, “The Wiki and the Digital Library,” OCLC Systems & Services: International Digital Library Perspectives 21, no. 1 (2005): 18–22.

  Graphical Table of Contents for Library Collections:
The Application of Universal Decimal Classification Codes to Subject Maps


Victor Herrero-Solana,
Félix Moya-Anegón,
Vicente Guerrero-Bote,
and Felipe Zapico-Alonso





Victor Herrero-Solana (victorhs@ugr.es) is Associate Professor and Félix Moya-Anegón (felix@ugr.es) is Professor, Department of Library and Information Science, University of Granada; Vicente Guerrero-Bote (vicente@alcazaba.unex.es) is Associate Professor and Felipe Zapico-Alonso (fzapalo@alcazaba.unex.es) is Associate Professor, Department of Computer Science, University of Extremadura, Badajoz, Spain. All of the authors are also affiliated with the SCImago Research Group (www.scimago.es/).



The representation of information content by graphical maps is an extended ongoing research topic. The objective of this article consists in verifying whether it is possible to create map displays using Universal Decimal Classification (UDC) codes (using co-classification analysis) for the purpose of creating a graphical table of contents for a library collection. The application of UDC codes was introduced to subject maps development using the following graphic representation methods: (1) multidimensional scaling; (2) cluster analysis; and (3) neural networks   (self-organizing maps). Finally, the authors conclude that the different kinds of maps have slightly different degrees of viability and types of application.


Advanced techniques for information retrieval (IR) currently make up one of the most active areas of research in the field of library and information science. New models representing document content are replacing the classic systems in which search terms supplied by the user were compared against the indexing terms existing in the inverted files of a database. The objective of this article consists in verifying whether it is possible to create map displays using Universal Decimal Classification (UDC) codes, a classification system based on Dewey Decimal Classification, for the purpose of creating visualizations of a library collection.

One related topic of study in recent years is bibliographic browsing, a useful complement to querying strategies. Since the 1980s, a number of authors have dealt with this topic. For example, Ellis establishes that browsing is based on three different kinds of tasks: identification, familiarization, and differentiation. 1 Cove distinguishes three different browsing types: searching browsing, general purpose browsing, and serendipity browsing; whereas Bates presents six different types. 2 Yet most interesting is Bawden’s browsing classification, which addresses similarity matching, structure-driven displays, and global vision. 3 Global-vision browsing implies the use of graphic representations, referred to in this article as map displays, that allow the user to grasp a global idea of the nature and structure of information in a database.

Several authors worked on this line of research throughout the 1990s, developing different types of maps. One of the most active authors was Lin, who introduced the concept of a graphical table of contents (GTOC) that is functionally analogous to the table of contents in the printed environment. 4 Lin applies the self-organizing map (SOM) algorithm to his own personal bibliography, analyzed by title and abstract fields, and represents it in a two-dimensional map. 5 The SOM algorithm is a major method for unsupervised learning, based on a grid of artificial neurons whose weights are adapted to match input vectors in a training set. It was first described by the Finnish professor Teuvo Kohonen and is thus sometimes referred to as a Kohonen map. 6 The algorithm takes a set of input objects, each represented by a vector in the matrix, and maps them onto nodes of a two-dimensional grid. Later on, Lin included such maps in the creation of GTOC Web sites based on a Java application.

Vectorization, the transformation of any information element into numerical data, using words from the title and abstract fields for   co-word analysis, generates too large of a matrix, but this technique can be applied to reduced document sets. In this context, it is important to find some element that allows a less complex or “lighter” vectorization. Online public access library catalogs (OPACs) have certain elements, such as the subject codes of UDC, that can be more easily vectorized than free text in order to create GTOCs of a library collection.

Materials and methods


The OPAC selected for this study is that of the Public Library of Granada, which contains 32,700 records and 43,900 UDC codes, an average of 1.34 codes per record. These records were vectorized using the UDC codes, so as to group them into twenty-seven major subject categories, derived from the hierarchical structure of UDC. The Pearson correlation index was applied to this matrix of data (27 x 32,700) to measure the similarities among these twenty-seven major classes and to generate a new matrix (27 x 27), to which the visualization method will be applied. This correlation index approach is widely used for science mapping construction. 7

Two basic approaches were adopted in creating the display maps: (1) statistical (based on multivariate analysis); and (2) connectionist (usually, but not exclusively, based on artificial neural networks or ANNs).

Within the techniques of multivariate statistical analysis, three basic methods deserve mention at this point: (1) cluster analysis, (2) principal component analysis (PCA), and (3) multidimensional scaling (MDS). 8 According to Kinnucan, Nelson, and Allen, “These methods are referred to as dimensionality-reduction methods because this function is to simplify what might at first appear to be a complex pattern of associations among many entities.” 9

In the following sections, we review and summarize the characteristics of the three methods:

1. Cluster analysis. This technique is used to create two-dimensional displays (e.g. dendrograms) of clusters of different objects whose relationships are represented by matrix values. This type of automatic classification, also known as numerical taxonomy, currently comprises more than 150 different techniques that are grouped in families according to shared procedures. Information science as a discipline generally involves polythetic clustering hierarchies, producing trees that illustrate the hierarchy of relationships among elements on the basis of individual characteristics. 10

2. Principal Component Analysis (PCA). The basic premise of PCA is that the linear relation between any two variables is best summarized by a regression line. In other words, the variable that represents the regression line as a point cloud contains essential information about both variables. The two variables are thus combined into a single factor. This mechanism can be used to reduce pairs of variables to single dimensions in order to simplify the graphic display of the elements included in the matrix. 11

3. Multidimensional Scaling ( MDS). This multivariate analysis technique is used to identify the dimensions that best explain similarities and differences between variables. Because the purpose of MDS is to generate a map of objects, this approach can be considered an alternative to PCA. 12


Neural networks are analytic techniques modeled after the (proposed) processes of learning in cognitive systems and the neurological functions of the brain. Neural networks use a data “training set” to build rules capable of making predictions or classifications on data sets. Neural networks can learn to assign multidimensional outputs to multidimensional inputs, and they do so while maintaining a great capacity for generalization. For this reason the better choice is the SOM algorithm. Kohonen’s interest in discovering how an organization of this type might arise led him to investigate the subject. 13 The product of that research was the network model, bearing his name, that
is capable of performing a topological organization of the inputs presented to it.

This type of network has recently been extrapolated to domain analysis, textual data mining, the extraction of semantic relationships among words in their contexts, and to the generation of topological maps of sets of documents, which may include labeling the zones of influence of each word or term. 14

MDS maps


In the MDS-based display map each major subject category is placed in a certain point, depending on its relationship to other subject categories (figure 1). Also, each category is represented with a circle whose area is proportional to the volume of documents that it contains. The largest circles are located in the periphery, following the principle of center/periphery established by White and Griffith. 15
figure 1. mds map
Figure 1. MDS map


The categories are classified in two large clusters: (1) science and technology, and (2) social science and humanities. This classification corresponds to its clustering, as in a Ward dendogram. 16 There are only two categories that do not seem to be in the expected cluster (economics and law); however, we should bear in mind that economics is related with categories of the science and technology cluster (mathematics). On the other hand, MDS places both categories at the edge of the map; in this way the dividing line can integrate them into the social sciences area.

SOM maps


The map display based on SOM is quite different from the MDS-based map (figure 2). The SOM-based map is clearer, more schematic, and better ordered than the MDS-based map, but the size of each category is not proportional to the volume of documents, which might confuse the user. It is also very difficult to perceive the division of the categories in two big clusters as in the previous MDS-based map. The categories group according to neighboring relationships, a typical feature of Kohonen’s algorithm, and the general structure of the collection that one could observe in the MDS-based map is much more difficult to discern here.
figure 2. som map
Figure 2. SOM map


The neighboring relationships among the categories indicate the frequency of the co-occurrences of the classification codes. It is important to point out that the SOM searches out the best topology. This implies that when the representation must be reduced to two dimensions, the areas spread and the greater or lesser contact among them is indicative of the degree of interrelation. The proximity/distance among the areas is conditioned by co-classification frequency; however, this does not mean that the codes of classification of two categories that are far away from each other cannot co-occur at all.

To some extent the shapes of the areas are also determined by the co-classifications. These relationships cannot always be represented by the simplest geometric forms, for which reason their final appearance may strike the user as odd or unusual.

Conclusions


Despite the fact that user-based evaluation experience of this kind of map display is very limited, the following conclusions can be put forth:
  • MDS and SOM are algorithms that can be used to generate bibliographic map displays
  • An OPAC can be represented through co-classification analysis using UDC codes
  • It is possible to use other decimal classifications, like DDC, but not Library of Congress
  • MDS-based maps enhance viewing the structure of relations among the subject categories
  • SOM-based maps are easy to use, because the view is clear, schematic, and well ordered
  • SOM is easier to compute than MDS, especially when a lot of variables are involved

References and notes


1. D. Ellis, “A Behavioral Approach to Information Retrieval System De--sign,” Journal of Documentation 45, no. 3 (1989): 171–212.

2. J. F. Cove and B. C. Walsh, “Online Text Retrieval via Browsing,” Information Processing and Management 24, no. 1 (1998): 31–37; M. Bates, “The Design of Browsing and Berrypicking Techniques for the Online Search Interface,” Online Review 13, no. 5 (1989): 407–424.

3. D. Bawden, “Browsing: Theory and Practice,” Perspectives in Information Management 3, no. 1 (1993): 71–85.

4. X. Lin, “Graphical Table of Contents,” Proceedings of the First ACM International Conference on Digital Libraries (New York: ACM Pr., 1996): 45–53.

5. X. Lin, “Map Displays for Information Retrieval,” Journal of the American Society for Information Science 48, no. 1 (1997): 40–54.

6. T. Kohonen, Self-organizing Maps (Berlin: Springer, 1997).

7. L. Egghe and R. Rousseau, Introduction to Informetrics: Quantitative Methods in Library, Documentation, and Information Science (Amsterdam: Elsevier, 1990); M. Kinnucan, M. Nelson, and B. Allen, “Statistical Methods in Information Science Research,” Annual Review of Information Science and Technology 22 (1987): 147–78.

8. Egghe and Rousseau, Introduction to Informetrics.

9. Kinnucan, Nelson, and Allen, “Statistical Methods in Information Science Research.”

10. H. D. Howard and K. W. McCain, “Visualizing a Discipline,” Journal of the American Society for Information Science (JASIS) 49, no. 4 (1998): 327–55.

11. F. Moya-Anegón, E. Jiménez-Contreras, and M. D. L. Moneda-Corrochano, “Research Fronts in Library and Information Science in Spain (1985–1994),” Scientometrics 42, no. 2 (1998): 229–46.

12. Howard and McCain, “Visualizing a Discipline”; Moya-Anegón, Jiménez-Contreras, and Moneda-Corrochano, “Research Fronts.”

13. Kohonen, Self-organizing Maps; T. Kohonen, “Self-organized Formation of Topological Correct Feature Maps,” Biological Cybernetics 43 (1982): 59–69.

14. H. D. White, X. Lin and K. W. McCain, “Two Modes of Automated Domain Analysis: Multidimensional Scaling vs. Kohonen Feature Mapping of Information Science Authors,” Structures and Relations in Knowledge Organization: Proccedings of the Fifth International ISKO Conference (Wurzberg, Germany: Ergon Verlag, 1998); S. Kaski, K. Lagus, T. Honkela, and T. Kohonen, “Statistical Aspects of the WEBSOM System in Organizing Document Collections,” Computer Science and Statistics (Fairfax Station, Va.: Interface Foundation of North America, 1998), 281–90; T. Honkela, V. Pulkki, and T. Kohonen, “Contextual Relations of Words in Grimm Tales, Analysed by Self-organizing Map,” Proceedings of the International Conference on Artificial Neural Networks ICANN-95 (Paris: EC2 et Cie, 1995); F. Moya-Anegón, V. Herrero-Solana, and V. Guerrero-Bote, “Virtual Reality Interface for Accessing Electronic Information,” Library and Information Research News 22, no. 71 (1998): 34–39; F. Moya-Anegón et al., “NeuroISOC: un modelo de red neuronal para la representación del conocimiento,” Actas del IV Congreso ISKO-España EOCONSID ’99 (Granada, Spain: ISKO-España, 1999), 151–56; V. Guerrero-Bote and F. Moya-Anegón, “Reduction of the Dimension of a Document Space Using the Fuzzified Output of a Kohonen Network,” Journal of the American Society for Information Science and Technology 52, no. 14 (2001): 1234–41.

15. H. D. White and B. C. Griffith, “Author Co-citation: A Literature Measure of Intellectual Structure,” Journal of the American Society for Information Science 32, no. 3 (1981): 163–71.

16. Ward’s method, based on the minimum variance principle, is a specific method used in cluster analysis for dendogram construction. A dendogram is a branching, tree-like diagram based on one or several criteria that can be used to illustrate the relationships between elements.