2004¦~11¤ë3¤é

SOAP meets RSS Fri, Jan 5, 2001; by Dave Winer. Parallel development  I have been fortunate to participate in several successful group development processes in the last few years including XML-RPC which lead to SOAP, a collaboration between UserLand, Microsoft and IBM; and RSS, which was a joining of two syndication formats, one from Netscape and one from UserLand. Radio UserLand bridges the two technologies. Now it's possible, using the information in an RSS channel, to request that a centralized coordinator, a "cloud", send notification that a channel has changed. Either side of this conversation can use either XML-RPC or SOAP to communicate. Publish and subscribe  Most aggregators scan for changes once an hour, but in some situations we want to know immediately when a channel has changed. For example, we include RSS Boxes on many of our sites. When an editor routes a item to a box, we want the news to be displayed immediately, but we don't want to read the RSS channel on every hit. Notification makes it possible to always be current yet conserve bandwidth and server cycles. A new feature for RSS  There's a new <cloud> sub-element of <channel>. It specifies a Web application that supports the rssCloud interface, described below, which can be implemented in either XML-RPC or SOAP. A <cloud> has five required attributes: domain is the domain name or IP address of the cloud, port is the TCP port that the cloud is running on, path is the location of its responder, registerProcedure is the name of the procedure to call to request notification, and protocol is xml-rpc, soap or http-post (case-sensitive), indicating which protocol is to be used. Example  Here's an example of a RSS file that includes the new <cloud> element. <cloud domain="radio.xmlstoragesystem.com" port="80" path="/RPC2" registerProcedure="xmlStorageSystem.rssPleaseNotify" protocol=XML-RPC /> This is telling the aggregator to send an XML-RPC message to radio.xmlstoragesystem.com on port 80, with path /RPC2 to the procedure named xmlStorageSystem.rssPleaseNotify to request notification. Most RSS files produced by Radio UserLand have a <cloud> element. rssCloud interface  A workstation calls the cloud to register. The procedure takes five parameters: the name of the procedure that the cloud should call to notify the workstation of changes, the TCP port the workstation is listening on, the path to its responder, a string indicating which protocol to use (xml-rpc or soap, case-sensitive), and a list of urls of RSS files to be watched. The cloud can determine the IP address of the caller from the request. A workstation cannot make a registration call on behalf of another. The cloud returns true if it was able to do the registration, false otherwise. When a subscribed-to channel changes the cloud calls back to the procedure named in the registration call with one parameter, the url of the channel that changed. At that point the workstation could read the channel, or notify other workstations that the channel has changed, clear a cache, send an email or do nothing. The workstation returns true. By convention registrations expire after 25 hours. Workstations should register every 24 hours for each subscription to keep them current. UserLand is operating a cloud that conforms to this spec at radio.xmlstoragesystem.com. The workstation side is implemented in Radio UserLand. Important caveat  By design, this protocol/format will not work for aggregators that are isolated from the Internet by firewalls or NAT. It will work for systems with non-fixed IP addresses if the workstation software re-registers at startup. See also: RSS 2.0 spec. 6:04:08 PM

Payloads for RSS Thu, Jan 11, 2001; by Dave Winer. The click-wait system  When I started talking with Adam Curry late last year, he wanted me to think about high quality video on the Internet, and I totally didn't want to hear about it. Like a lot of people, I had tried it, and found it unsatisfying and frankly, exhausting. I thought that video on the Internet was a loser for three reasons, that build on each other: 1. When I click on a link to view some video, I have to wait. 2. The wait is longer than the video. (In other words I have to wait two minutes for ten seconds of video.) 3. The quality is horrible. All three effects are bad, but the first is the worst. The Internet lifestyle is frenetic. There's no time to wait. The remaining two negatives only make video less attractive, but the first is the killer. But Adam persisted and showed me that if I was willing to change my point of view, it could work, without any waiting and with very high quality. No click-wait  What if, in the middle of the night, while I'm not using my computer, it downloads huge video and audio stuff to my local hard drive. Then when I arrive in the morning there are fresh bits, news clips, a song of the day, whatever, provided by all kinds of content providers, from big TV networks like CNN and MSNBC, to a Dutch school where kids are taking a film class using inexpensive video recorders and iMacs. Let's see what happens with 1, 2 and 3 in this scenario. 1. When I click on a link to view some video, it starts playing immediately, because it is already on my local disk. 2. The wait is zero. 3. The quality is limited by the size of my local disk, not by the capacity of my connection. A different user interface  What's different about this system is that you subscribe to channels instead of clicking-and-waiting. I feel that nothing is lost with this approach, because video on the Internet never worked for me, and probably for many others. However, streaming news items through RSS works quite well, and it's a simple matter to teach RSS about multimedia payloads. Of course there's a change in user interface. You never see a video or music document until it's fully downloaded. The computer does the waiting, not you. In the system that Adam envisions, a video DJ, someone like Adam at MTV in the 80s and 90s, someone whose judgment you trust, or whose tastes you like, is pushing high fidelity bits onto your hard drive, using no more hardware and network connections than you already have. There is no central authority, no spectrum to allocate, it's open to amateurs, like the Internet itself. A new element  So that's the philosophy, now let's put some meat on the bones. RSS already does most of what we want. With the addition of the <enclosure> sub-element of <item> any RSS element can describe a video or audio file (actually any type of file). <enclosure> has three attributes: url says where the file is located, length says how big it is, and type says what its type is. This way a workstation or aggregator can know in advance, without having to do any communication, what it's going to get, and apply scheduling and filtering rules. An example  Here's an example of a RSS file that links to several Grateful Dead songs. Each <item> contains an <enclosure> as explained above. <enclosure url="http://www.scripting.com/mp3s/touchOfGrey.mp3" length="5588242" type="audio/mpeg"/> I've configured my system to download enclosures between 2AM and 4AM, a time when I don't use my computer. When I arrive at work, I check the incoming Log and see there's a new song. I click. It plays. No wait. Software  My company, UserLand, has a product in development called My.UserLand On The Desktop that supports both sides of this format. You can use it to create channels that have <item>s with <enclosure>s, and it manages downloads for these channels. So it's both an authoring and viewing tool. It's a bootstrap, and it's open, meaning that anyone can develop software that works on either or both sides of this connection. Adam's company is doing a graphic environment for music and video on PCs in Java. Others are welcome to join up and do software for all kinds of computers, content and people. "This is just email"  First, everything on the Internet is just like something else. Or if it's any good it's just like everything else. If you try to push video and audio through email you'll find the client user interface as daunting as the wait-click Web experience. How do I keep enclosures from downloading while I'm accessing email from a phone connection in a hotel? Sure, you could add a complex dialog to an already overly-complex email client user interface, and the result would be that no one could set it up properly and no new video would actually get to the desktop. (You'd hate the feature until you figured out how to turn it off.) Homage  I'd like to pay special homage to the Grateful Dead, who have generously allowed their creations to be used to bootstrap new technology in non-commercial ways. To get this process going, we need a content base to get started with. So many technologists, me included, love the music of the Dead. I think they may have left a legacy for technologists that's as important as the legacy they left in music. See also  1/5/01: SOAP meets RSS describes a publish-and-subscribe notification system based on XML-RPC and SOAP and of course RSS. 6:03:39 PM

PMDs: Big Drives, Small Size There's a new Portable Media Device in town (well, a few, actually) but you might not recognize it (them). No screen? Well, the screen isn't part of the portable equation, you see. The portable part only applies to the media itself, and quite a lot of it at that: up to 400GB on some of these which, for something roughly the size of an external hard drive enclosure, isn't bad. In fact, you'd be forgiven for thinking these were just bulky USB 2.0 drives until you saw the myriad of connectors on the back panel, including at least RCA audio and video outs¡XS-Video and SPDIF adorn the higher class models. These relatively small players (compared to a Media Center PC, for example) are made possible by Sigma Designs media processors, which have started appearing in products with increasing frequency. MobileMag claims these 'next-gen' high capacity, smallish players are available from their manufacturers, but I had a hard time finding purchase links. Regardless, they're sure to become more widely available before long. New Category of PMDs Announced [MobileMag] Related Sigma Designs Media Processor Product Guide [SigmaDesigns] - Ryan [Gizmodo] 5:45:23 PM

BMW's Dog Safety Belt While it's not a gadget, exactly, we felt it would be pretty rad of us to inform you of a new product from BMW¡Xthe "dog safety belt" represents the world's first dog-only safety belt from an actual automobile manufacturer. Scheduled to be available for about 21,000 yen from dealers all across Japan on November 5th, the three sizes of safety belt can suit dogs between 7 and 40 kilograms (15 - 88 pounds). BMW's introduction of this product in Japan should come as no surprise; dogs are all the rage over there, and have been for quite some time now. Still, since the risk posed to dogs riding in cars seatbelt-less is the same in Japan as any country, there's a slight chance BMW will decide to bring this one over to other countries. By the way, BMW: "shoot out like a missile" probably isn't the best way to describe what happens to an unbelted dog in a car accident. You sick bastards. Press Release (PDF) [BMWJP] - Liam (zmcnulty@techjapan.com) [Gizmodo] 5:43:56 PM

LighTalk LED Pen The LighTalk pen is pretty great. You can use it like a regular pen to draw a doodle, then 'scan' the image to activate a series of LEDs, then flick it back and forth to achieve a persistence-of-vision display of whatever it is you've scanned. I can think of dozens of uses for something like this, the vast majority of which are totally vulgar. Okay, all of them. LighTalk [CoolHunting] - lev (joeljohnson@gmail.com) [Gizmodo] 5:42:35 PM

Feature Quickiwiki, Swiki, Twiki, Zwiki and the Plone Wars Wiki as a PIM and Collaborative Content Tool by David Mattison • Access Services Archivist • British Columbia Archives, Cananda In July 1991 I had my first taste of hypertext when a neighbor loaned me his Classic Macintosh. I created a HyperCard stack simulating an orientation to my workplace. Working in a Wang shop as I did at the time, I couldn't show it to anyone except in printed form. I remember it was pretty tough to convey my excitement over hypertext on the basis of ink on paper. Over my many years of research and writing, I could see the personal potential for either a stand-alone or a Web-based hypertext system. Over the 2 decades I've worked with personal computers, I tried a few personal information manager (PIM) and free-form database products such as AskSam [http://www.asksam.com/], but decided to wait. Even then, others were already working out solutions to using a Web browser as a hypertext writing tool. While researching and writing my February 2003 Searcher article on RSS and blogging ("So You Want to Start a Syndicated Revolution?"), I kept running across references to "wiki" software. Since I still haven't grasped the subtle distinction between when and when not to capitalize wiki, I've made it lowercase throughout except when referring to a specific wiki site or wiki software. (See the "Wiki Words" sidebar interview with Bo Leuf on page 42.) Since I come from Hawaii, the word "wiki" itself caught my attention first. "Wiki" is Hawaiian for quick. "Wikiwiki" means real quick. Ward Cunningham, the creator of the first wiki, liked the name, learned through frequent rides on the WikiWiki shuttle buses at the Honolulu International Airport. His first WikiWikiWeb [http://c2.com/cgi-bin/wiki], rendered into HTML through a Perl script written in 1994-95, still runs today at its original home on the Portland Pattern Repository site. In The Wiki Way (2001), the one and only book devoted solely to wiki, Bo Leuf and Ward Cunningham define wiki as "a freely expandable collection of interlinked Web 'pages,' a hypertext system for storing and modifying information — a database, where each page is easily editable by any user with a forms-capable Web browser client" (page 14). Wiki pages are controlled — created, linked, edited, deleted, moved, renamed, and so on — by a programming or scripting language, and stored either as plain ASCII text files or in an external relational database, such as MySQL, Oracle, or PostgreSQL. Wiki pages are only rendered or displayed as HTML through templates by the wiki Web server. Ward's original wiki was written in Perl, and he released the script as copyright-limited open source. Since 1995, many other talented individuals have produced dozens of wiki clones or wiki-like Web content management systems (WCMS), most often under an open source license, in various programming or scripting languages that run on every microprocessor platform imaginable, including PDAs and smartphones. Some of these implementations are free for personal and commercial use, others are free for personal use only. Still more are strictly commercial only and may offer either a downloadable limited-feature or time-limited executable program. This article looks chiefly at completely free (both personal and commercial use allowed) or shareware open source products. An excellent starting point, and one Ward calls canonical, for wiki clone software is at WikiWikiWeb WikiEngines[http://c2.com/cgi/wiki?WikiEngines]. If you wish to delve deeper into the philosophical and metaphysical realms of wikidom, go to these pages on Ward's WikiWikiWeb: • ElementsOfWikiEssence [http://c2.com/cgi/wiki?ElementsOfWikiEssence] • WikiEssence [http://c2.com/cgi/wiki?WikiEssence] • OneMinuteWiki [http://c2.com/cgi/wiki?OneMinuteWiki] • InternationalOneMinuteWiki [http://c2.com/cgi/wiki?InternationalOneMinuteWiki] • WhyWikiWorks [http://www.c2.com/cgi/wiki?WhyWikiWorks] • WikiDesignPrinciples [http://c2.com/cgi/wiki?WikiDesignPrinciples] • WikiHistory [http://c2.com/cgi/wiki?WikiHistory] • WikiWikiWebFaq [http://c2.com/cgi/wiki?WikiWikiWebFaq] Built around object-oriented programming, wikis are extremely popular within the software development community, especially among those that practice the principles of Extreme Programming (XP, not to be confused with Windows XP). (For definitions of some of the wiki and Web content management system terminology I use, see the sidebar "Wiki Words Glossary" on page 39.) Wiki Uses "Not everyone needs a wiki. Not everyone wants a wiki. Not every situation benefits from becoming an open discussion or collaboration forum." ­The Wiki Way (2001, p. 30) Wikis are everywhere, but, unfortunately, the online literature has not begun to focus on wikis yet. Why aren't wikis on our radar screen the way blogs are right now? Walt Crawford, a senior analyst at RLG and active writer and speaker in the library field, reported to me by e-mail that he had "tried out a library-related one quite a while ago and, at the time, found the mechanisms and content both either uninteresting or problematic. Since I didn't have any need that cried out for wikis as a solution, I didn't pursue the matter. That also explains the absence of any mention of wikis in my American Libraries 'e-files' series in late 2001: I was not aware of any real significance in the library field. That doesn't mean there isn't any, of course." Perhaps my questions to him weren't fair, but I can see all kinds of potential for wikis in libraries, both behind the scenes where they are being used, and in public customer service areas where you could create a librarian-administered, self-serving knowledge bank. For example, what about a My Favorite Web Sites subject guide to the Web wiki, a readers' advisory or book-rating wiki, a suggestion box wiki, an FAQ wiki, a collaborative story created by children, or a guide to using the library wiki by your friends and neighbors? Ben Schmidt, Canadian National Site Licensing Project [http://www.cnslp.ca/], and Professor Anita Coleman, School of Information Resources and Library Science, University of Arizona, both contributed reports by e-mail and via my Searchers' Swiki experiment (see below) about the use of wikis within and outside their projects and institutions. Professor Coleman pointed me to the National Science Digital Library as one of the most high-profile sites in the library community using wikis as part of its Communications Portal (for examples, see http://eval.comm.nsdlib.org/cgi-bin/wiki.pl?WhatIsThis, http://annotations.comm.nsdlib.org/cgi-bin/wiki.pl, and http://sourceforge.comm.nsdlib.org/ cgi-bin/wiki.pl?WikiResources). Some of the common wiki uses are as a hypertext database for research and writing (the wiki as personal information manager [PIM] or organizer), a knowledge management (knowledge bank or knowledge-log), a team collaboration tool for creating and maintaining documents that need frequent updating such as policy and procedure manuals, content for academic instruction, and a more flexible kind of Web log. This last use is already addressed in some wiki or collaborative WCMS implementations such as Scoop [http://scoop.kuro5hin.org/], SnipSnap [http://snipsnap.org/space/start], and Vanilla or VanillaSBX (VanillaSite-out-of-the-Box) [http://www.langreiter.com/space/Vanilla and http://www.langreiter.com/space/VanillaSBX]. These applications describe themselves as allowing collaborative editing, commenting, and threaded discussion, generally by date as with Web logs. Besides serving as "an easy-to-use, hyperlinked text database" (The Wiki Way, 2001, p. 98), some mature wiki clone implementations also fall in the category of Web content management systems (WCMS) and already come designed as collaborative content tools. Wikis are easy to learn and use. There are no complicated syntax or text formatting rules. Some wiki clones permit the inclusion of HTML, but The Wiki Way authors recommend, with some exceptions, against this practice. The lack of a consistent, cross-wiki standard for text formatting is a distinct and severe disadvantage, especially if you visit and contribute to different wikis. Because a basic wiki stores content as plain ASCII text, the original text-formatting rules use start and end pairs of punctuation for markup. Internet URLs are written out in full and automatically recognized. In Ward's WikiWikiWeb, a wiki page is created by running words together with initial capitals for each word to create a WikiWord. In other wiki implementations such as Swiki, wiki pages are created by a paired-punctuation pattern. In the WikiWikiWeb, the WikiWord page name is the last part of the URL; in the Swiki model, pages are numbered, which means you easily rename a page while you're editing it, and once saved, the change is reflected throughout the database. The Wiki Way authors recommend never deleting a wiki page, but deleting the content instead, leaving a note explaining why, and creating another page instead. This practice encompasses the gentle (or brutal) wiki art of RefactoringWikiPages [http://c2.com/cgi/wiki?RefactoringWikiPages]. Except where some implementations allow the use of a JavaScript or some other kind of HTML editor, Wiki page creation or editing is generally done inside an HTML text area box that usually only permits the inclusion of ASCII text. The left edge of the box usually contains certain kinds of visual styles such as bulleted and numbered lists, horizontal rules, headings, or the creation of an Append or Comment field. When I had to copy and paste e-mail messages into a swiki I created, it proved a chore of back and forth correction as certain characters appearing at the left edge of the textarea box kept turning into a bullet or a horizontal rule. Worse, some characters such as a "<" or a ">" would not appear at all unless "escaped" because saving the document in Internet Explorer automatically stripped some HTML markup symbols. Wikis, Web Logs, and RSS "I've toyed around with the idea of using wikis [http://c2.com/cgi-bin/wiki?WikiWikiWeb] for various projects, but in the end, I'm hesitant to use them because it's still stationary information. I want my information coming to me, not waiting around for me to get to it. Yes, you still need the depository, but these days I want it in my news aggregator or my e-mail." ­Jenny Levine, The Shifted Librarian [http://www.theshiftedlibrarian.com/2002/03/19.html#a887] Various experiments are underway on integrating the RSS protocol for both aggregation (subscribing to and reading a news feed) and syndication (exporting of wiki content as RSS content so other sites can subscribe to it). Ward's WikiWikiWeb contains a simplified overview and pointers on WikiStyleRss [http://c2.com/cgi/wiki?WikiStyleRss]; his page on CategoryWikiMetadata covers the limitations faced by wiki sites [http://c2.com/cgi/wiki?CategoryWikiMetadata]. John Abbe's Wiki Weblogs [http://www.ourpla.net/cgi-bin/pikie.cgi?WikiWeblogs] and Wikis with RSS[http://ourpla.net/cgi/pikie?WikisWithRss] demonstrate how some wiki developers integrate wikis with blogs to support RSS aggregation and syndication. While aggregation appears more easily accomplished, syndication is generally handled in a standard wiki through the RecentChanges page. The proposed RSS 1.0 extension for wiki syndication is called ModWiki [http://www.usemod.com/cgi-bin/mb.pl?ModWiki]. One of the goals for ModWiki is to produce a dynamically updated UnifiedRecentChanges page that aggregates external wiki content. Examples of UnifiedRecentChanges pages appear on sites operated by Jeff Dairiki [http://www.dairiki.org/rss1.0/urc.html] and Dave Jacoby [http://csociety.ecn.purdue.edu/~jacoby/UnifiedRecentChanges/]. To see an example of wiki aggregation, visit the Open Wiki WikiSites/Aggregation page [http://openwiki.com/?WikiSites/Aggregation]. Some wiki clones, such as MoinMoin [http://purl.net/wiki/moin/] by Germany's Jürgen Hermann, contain both an XML link on every page that can be "scraped" for RSS syndication, along with a valid RSS URL for his site's RecentChanges page [http://twistedmatrix.com/users/jh.twistd/moin /moin.cgi/RecentChanges?action=rss_rc&unique=1]. Wiki Search and Page Control Tools All wiki implementations contain a few basic search and navigational capabilities, some of which relate to their nature as hypertext databases. The integrated search feature of a wiki at its most primitive is a keyword or text-match tool. Ward's WikiWikiWeb site shows an extension of this feature to include page titles or full text, with the latter searching a separate index updated daily. Some wiki search engines provide case-sensitive and phrase searching, along with Boolean expressions. Every time a page is added or changed, you can select the RecentChanges or Changes query, which displays a real-time update of those page titles [http://www.usemod.com/cgi-bin/mb.pl?RecentChanges]. The History query on some wiki clones provides a list of page versions back to the very first instance [http://prosaic.swiki.net/1.history]. Wikis that implement page-version control may also allow page rollback, usually via the History view; sometimes you will see the word "diffs" used for version display, which means differences, a short form of the software utility of the same name. The Backlinks function may or may not be enabled, depending on what wiki software you use [http://zwiki.org/BackLinks/backlinks]. Backlinks shows you a hyperlinked list of which pages refer to the page you are viewing. The Category feature on Ward's WikiWikiWeb is explained as a "ReverseIndex to related wiki pages" [http://c2.com/cgi/wiki?CategoryCategory]. Some wiki clones have since adopted this wiki structural and search tool. An interlinked site map, the TourBusMap [http://www.usemod.com/cgi-bin/mb.pl?TourBusMap], operates in some wikis. The "grand central" wiki TourBusStop is you-know-where-by now [hyperhint: http://c2.com/cgi/wiki?]. The WikiWikiWeb also features a nice LikePage search that produces a list of page titles matching the one you're on. Each time you select a new page title, a new LikePage list is generated. Slick and quick, it works something like the Related Links in the Alexa Toolbar or "Similar pages" in a Google results list. Ward's WikiWikiWeb also contains a VisualTour [http://c2.com/cgi/tour] link that you'll find on every page. Finally, some wikis show you a hyperlinked, hierarchical trail ("breadcrumbs") back to where you started, or back to the FrontPage. For examples of these, see my Searchers' ZWiki [http://searcher.freezope.org/zwiki/FrontPage], the ZWiki.org site, or any of the public wikis hosted at SeedWiki.com[http://www.seedwiki.com]. Experiments linking wikis togetherfor searching purposes generally fall under the InterWiki concept (or other names) intended to mimic Usenet servers [http://c2.com/cgi/wiki?InterWiki]. In the WikkiTikkiTavi InterWiki implementation, each public or private Tavi wiki controls its own InterWiki linking through a dynamically updated database [http://tavi.sourceforge.net/InterWiki]; you can jump to other wikis or conduct searches of non-wiki Web resources. Canadian Sunhir Shah's MetaWiki inter-wiki keyword search tool [http://sunir.org/apps/meta.pl], based on cached page titles, is found on the Meatball Wiki, which he edits. Jeff Dairiki's experimental,real-time InterWiki Title Search [http://www.dairiki.org/interwiki/search.php] is another example of how wiki developers are enhancing the utility of the technology. You'll find an article summarizing InterWiki in the Wikipedia [http://www.wikipedia.org/wiki/InterWiki], one of the largest single wikis around. Other ideas and leads about wiki data mining appear on the WikiWikiWeb at WikiMines[http://c2.com/cgi/wiki?WikiMines] and via the Meatball Wiki InterWiki page [http://usemod.com/cgi-bin/mb.pl?InterWiki]. Treading the Wiki Software Waters "Potentially, the Web can become a way to structure your workplace. If you have a server and a hypertext editor, you can use the Web to write proposals, status reports, and so on; your colleagues can use the Web to insert their own comments or questions; and so on. It can be used for collaborative authorship: Several people can jointly write a paper or presentation. ... In the future (i.e., after 'simple' hypertext editors are available), special-purpose editors designed for collaborative work may be developed." ­Ed Krol, The Whole Internet (1992, pp. 241-42) Throughout my research and writing of this article over 6 weeks, I downloaded, installed, and tested wiki and wiki-like software, including a few PIM products for comparison such as Infocetera [http://www.infocetera.com] and Treepad [http://www.treepad.com/]. Jeff McWhirter's (WTS Systems, LLC) shareware Infocetera impressed me. Infocetera packs a lot into a compact package, builds on Tcl/Tk, and runs on Windows or Linux. McWhirter describes Infocetera as "a stand-alone Web server/application that provides a rich suite of tools for information management and group collaboration." Among the existing tools are a wiki, selected news feeds from Moreover.com, an outliner, and a text chat/whiteboard. He reports that the Web log tool is not yet implemented. You can also create your own databases, or extend existing ones, as well as import or export text-based content into the databases. Treepad is a more traditional, hierarchical outliner/word-processing tool. While you can embed hyperlinks within each text window, and import/export data in a variety of text formats, something you can't normally do with most wiki implementations, I did not immediately discover a way to see the existing relationships or even find visual aids to know which "nodes" had content. You can use Treepad, like AskSam, to generate a static Web site. Since a wiki is by definition a dynamic, real-time Web site, I didn't see any advantage to this feature. The first wiki product I tried to install myself was the QuickiWiki script that comes on CD-ROM with The Wiki Way. This requires downloading and installing Perl 5. The authors recommend Perl 5.6 from either ActiveState [http://www.activestate.com] or IndigoSTAR [http://www.indigostar.com]; the latter includes an integrated Apache Web server. Because this ensures compatibility between the scripts across different operating systems, they also suggest installing Perl in the filesystem path used on Linux/UNIX installations (rootdrive/usr). I quickly discovered that even on following the book's direction, something was wrong. The scripts that came on the CD-ROM were damaged, but you can find corrected scripts on the book's support site at http://wiki.org. QuickiWiki runs as advertised with or without a server. The script simulates the required server activity through an MS-DOS window, or you can set up a free server such as Apache (not recommended for the non-technical) to run the QuickiWiki. Since I did not want to be bothered with trying out all the useful "hacks" described in part two of The Wiki Way (2001), I moved on to other products. Those working in corporate environments might want to look into TWiki [http://www.twiki.com], "a Web based collaboration platform." Originally developed by Peter Thoeny when he worked for TakeFive, a software development company now owned by Wind River, TWiki is open source and hosted at SourceForge.net. This industrial-strength wiki clone is based on the abandoned JOSWiki (Java Operating System Wiki), not to be mistaken for the JSPWiki software [http://www.ecyrd.com/JSPWiki/Wiki.jsp]. I found TWiki difficult to install on both Windows and Linux (RedHat Linux 8.0 in particular). Corporate user "success stories" listed on the TWiki.org front page include, in addition to its current corporate intranet home at Wind River, the Disney Corporation, Inktomi, Motorola, and SAP. The TWiki software allows developers to create or extend current TWiki Plugins suitable to a corporate setting. Among those available as of January 2003 are the Database Plugin, which appears designed for PHP and MySQL, the Spreadsheet Plugin for adding elementary spreadsheet functions to a TWiki table, and many others [http://twiki.org/cgi-bin/view/Plugins/WebHome]. Bloggers, take note: TWiki also contains a Headlines Plugin for aggregating RSS feeds. Not having had much luck in installing several other wiki clones on a RedHat 8.0 Linux PC, I finally settled on Swiki [http://minnow.cc.gatech.edu/swiki] for my Windows XP PC. Developed at Georgia Tech under the direction of Professor Mark Guzdial (see the "Swiki Words" sidebar interview withMark Guzdial on page 43), Swiki is a wiki clone created with Squeak, an object-oriented programming language variant of Smalltalk. I found Squeak itself quite fascinating, as it runs on just about any microprocessor-equipped platform imaginable, even handling digital cameras! There's even a Squeak plugin for Internet Explorer that provides a lot of Squeak functionality without installing the entire application. Swiki includes its own Web server called Comanche, also known as CoWeb (Comanche Web or Collaborative Web). The major difference between Swiki and other wiki clones is the storage of pages as numbered, plain-text, XML 1.0 files regardless of what you name them, and you can include HTML. I found the Swiki text-formatting rules a little easier to remember, with the flexibility of page renaming a great feature. I quickly discovered, however, that the free Swiki.net service (see the "Swiki Words" sidebar interview withStephen Pair on page 45 used different text- formatting rules, and that page creation did not always work, so some page URLs had to be encoded as HTML rather than the asteriskPage Nameasterisk pattern used by Swiki and Swiki.net. I have yet to experience this problem with my desktop Swiki. ZWiki [http://www.zwiki.org] is a wiki clone designed for use on a Zope Web/application server. If you want a quick overview of how ZWiki differs from the original Wiki, go to DifferencesFromClassicWiki [http://zwiki.org/DifferencesFromClassicWiki]. My initial experience with Zope left me in the BoyDoIFeelStupidCategory. I didn't quite understand how to get ZWiki to work with Zope, but I knew from all I'd read and learned by e-mail over the past few years that Zope itself is an important open source product. The ZWiki product, as internal objects, applications, or services written in Python for Zope are called, contains some features (and flaws) unique to Zope. The most important feature is the ability to mix on a ZWiki page different kinds of structured text formats. Zope itself also implements WebDAV (Web Distributed Authoring and Versioning), but I did not test this feature. The simple secret to getting ZWiki accessible from a Web browser lies in the extensive Zope security permissions. You can test a public version of ZWiki I set up, courtesy of FreeZope.org, at the Searchers' Zwiki [http://searcher.freezope.org/zwiki]; note that "searcher" is singular, not plural. If I haven't implemented security correctly, I'm sure I will learn about my oversight sooner or later. The major Zope flaw widely discussed concerns some kind of memory leakage problem, both within the Zope core program and from products created to run within the Zope environment (source: Chris McDonough, Zope.org post, January 22, 2002, http://www.zope.org//Wikis/DevSite/ Proposals/ToleratingHangsAndLeaks). The Zope Corporation and community are also developing a Content Management Framework (CMF) infrastructure for Zope, which is where Plone comes in. The first and maybe last shot in the Plone Wars was fired on January 21, 2003, through an open letter to the Zope community and the Zope Corporation by Robert Boulanger, CEO and co-founder of BlueDynamics GmbH [http://plone.org/Members/zwark/plone-nzo]. In his long letter he noted that Plone [http://www.plone.org] is the "first downloadable distribution of a Zope which works out of the box, is free, and, most importantly, is absolutely able to earn money in itself. It has a great graphical design and just works. And a very big point for the non-American world: Only Plone cares about localization." There are 24 language translations of Plone, "including the big Asian market." Boulanger also boasted that Plone "kicks most commercial Content Management Systems' collective asses." You'll find some examples of Plone/Zope sites at the corporate level, including the Austrian government, CBS New York, NATO, and the Office of the Governor of Texas at http://plone.org/about/sites. Rob Page, CEO of the Zope Corporation, fired back a reply on January 31, 2003, that laid out a roadmap for the future of Zope [http://www.zope.com/News/ZopeRoadmap]. The response agreed with Boulanger that Plone works out of the box, but pointed out that users still have to configure Zope through the Web browser interface. The reason I call this the Plone Wars is that I believe Boulanger is wrong on that last point. I think Plone's okole is going to get kicked as badly as some others by some other open source Web application/servers. Besides the venerable Apache Web server, probably the only other enterprise-level open source Web application/server against which Zope competes is the AOLserver [http://www.aolserver.com/]. Yes, this is the server that powers the America Online information service, and it is an open source product available without licensing restrictions. There are two exciting open source collaborative projects (dotLRN and dotWRK) underway through the Collaboraid [http://www.collaboraid.biz/] service in Denmark — and other Web entry points — using AOLserver and OpenACS (Open Architecture Community System) [http://www.openacs.org]. Among the first online sources I consulted for wiki software was Ward's WikiWikiWeb page on WikiEngines[http://c2.com/cgi/wiki?WikiEngines]. I found many other outstanding WCMS applications, chiefly open source, with wiki-like features by visiting the active Web sites of just about every entry in the Google Directory for wikis and content management system software [http://directory.google.com/Top/ Computers/Software/Groupware/Wiki and http://directory.google.com/Top/Computers/Software/Internet/Site_Management/Content_Management]. I found the following sites especially useful for current WCMS data: cmsInfo.org [http://www.cmsinfo.org and RSS feed: http://www.cmsinfo.org/backend.php3], CMSWatch [http://www.cmswatch.com/ and RSS feed: http://www.cmswatch.com/RSS/cmswatch.xml], and Transform Magazine [http://www.transformmag.com/], along with SourceForge.net, Slashdot.org, and Tigris.org. Besides the free wiki hosting services I tried (Swiki.net, NetUnify.com, FreeZope.org, and SeedWiki.com), I also looked at various WikiFarms [http://c2.com/cgi-bin/wiki?WikiFarms] and PublicWikiForums [http://c2.com/cgi-bin/wiki?PublicWikiForums]. Unless it gets rescheduled again, the third Open Source CMS Conference [http://www.oscom.org], hosted by this international, nonprofit association, will be held at the end of May 2003 at Harvard University. You can easily find many other academic and vendor conferences geared to e-content and collaborative software, some of them sponsored by Information Today, Inc. Where Will Wikis Go Next? The good news about wiki technology is, that like the Web itself, it's here to stay. Wikis filled a small niche near the time of the Web's birth, but that niche has begun to widen. At its narrowest point, we will continue to find wikis filling the humble role of helping shape people's attitudes and knowledge about Web-based, collaborative content creation and editing. The bad news about wikis is twofold: Unless you implement a wiki within an industry-standard database such as Oracle, MySQL, or PostgreSQL, you may need programming skills to migrate your wiki from one wiki implementation to another. Some wiki implementations store wiki content in database records, while others store content in plain-text files (don't forget, XML is plain text). In both cases, the Web site is dynamically rendered into HTML. This is why wiki sites don't have URLs that end with the ubiquitous ".htm" or ".html." The other major bad news about wiki is that there is no standard way to mark up a wiki. If you do move from one wiki implementation to another, you will need to ensure that your Wiki markup is changed accordingly so it will be understood by the new wiki. I was dismayed to discover that there are important differences, for example, in the way Swiki.net allows Swiki markup and the way markup is handled in a Squeak Swiki or CoWeb. It's the same product more or less, so introducing needless variations in wiki text formatting or markup between the same basic software puzzles me. Wikis are already overshadowed, having never emerged as a must-have technology, by more feature-rich WCMS products that incorporate real-time video and audio. A Squeak Swiki can do this for users with the right kind of programming skills; Squeak itself already contains internal, drag and drop, multimedia support. The future looks promising for collaborative WCMS as shown by some of these developments around the world. For those who take air and computing for granted, MIT's Project Oxygen (also known as the Oxygen Alliance) [http://oxygen.lcs.mit.edu] is worth watching because of its mission to prototype a series of systems for "pervasive, human-centered computing." Among the database- and personal information management-related facets of this $50 million experiment mentioned on the Knowledge Access page are Haystack [http://haystack.lcs.mit.edu/], the World Wide Web Consortium's (W3C) Semantic Web [http://www.w3.org/2001/sw/], and START, a natural-language question-answering system available since December 1993 [http://www.ai.mit.edu/projects/infolab/ailab]. One can see how far removed the ivy-veiled halls of New England academe are from reality, however, by visiting the Collaboration page, where the sole reference to a working collaborative Web-based document annotation system is the W3C's AnnoteaProject [http://www.w3.org/2001/Annotea/]. In the Annotea model, annotations of documents (typically a Web page) are stored on an external server and made accessible to anyone (or authenticated users). The difference between Annotea and wiki is that in an open wiki with no additional extensions, you have no way of knowing who's contributed what. A WebDAV-enabled wiki would likely solve this problem. I expect it would be trivial to request some form of identification as part of the authoring process, if deemed necessary in the wiki deployment, before accepting contributed content. On the other hand, the core idea behind wikis is that a wiki page is always in perpetual edit, so one does not need to know who contributed what. The only two Annotea server implementations available as of January 2003 are the W3C's own server, and the Zope Annotation Server (Zannot) [http://www.zope.org/Members/Crouton/ZAnnot/]. Annotea Web browser clients, plug-ins, and tools listed by the W3C are Amaya (its own editor/browser) [http://www.w3.org/Amaya/), Annozilla [http://annozilla.mozdev.org/], Snufkin[http://jibbering.com/snufkin/], and SWAD-Europe: RDF-based Annotation Systems [http://www.w3.org/2001/sw/Europe/ reports/annotation_demo_server_report/]. You'll find more Web-based annotation software listings at the SemanticWeb.org's site on Annotation & Authoring [http://annotation.semanticweb.org/]. A few academic projects experimenting with collaborative WCMS caught my eye and interest. The Connexions Project [http://cnx.rice.edu/index_html] is happening at Rice University. Brent Hendricks, who wrote the Zope Annotation Server, is listed as Chief Architect. Connexions sounds very much like the University of British Columbia's Public Knowledge Project [http://www.pkp.ubc.ca/], except that Connexions appears geared more towards collaborative course development and publishing, and in that sense is somewhat like the open source Andamooka library [http://www.andamooka.org/]. Daniel Suthers, Laboratory for Interactive Learning Technologies, University of Hawaii, is leading two projects described in one of his co-authored publication as "online workspaces for annotation and discussion of documents." The projects are Kükäkükä[http://lilt.ics.hawaii.edu/lilt/software/kukakuka/], a Hawaiian word meaning discussion, and Pink [http://lilt.ics.hawaii.edu/lilt/software/pink/index.html], not quite ready for prime time as of January 2003, but sounding very much like a wiki. You can try the demonstration version of Kükäkükä. MIT is also leading an open source infrastructure project for computer-mediated (e-learning or online learning) educational activities called the Open Knowledge Initiative [http://web.mit.edu/oki/index.html]. With deep connections to MIT again (Sloan School of Management), and the University of Heidelberg, Germany, dotLRN [http://dotlrn.mit.edu/], "a fully open source eLearning platform project" uses the enterprise-level OpenACS system [http://openacs.org/projects/dotlrn/] "to foster learning and to promote collaboration." Another project using the same client/server combination is dotWRK [http://dotwrk.collaboraid.net and http://openacs.org/projects/dotwrk/]. Among the competing products listed for dotWRK are Groove Workspace [http://www.groove.net/products/workspace/], into which Microsoft invested, and eRoom, which Documentum [http://www.documentum.com/] finalized its purchase of in December 2002. Documentum was named Content Management System of the Year by the Belgian Data News. I think it significant that with this much open source activity in the field of collaborative WCMS, Microsoft is issuing dire warnings about open source software, yet at the same time planning its own collaborative WCMS strategy. On January 21, 2003, Microsoft announced its agreement to purchase PlaceWare, and, more significantly, "the creation of a new business unit — the Real Time Collaboration Group — within the information worker business," of which PlaceWare will become a part. I have a feeling that Microsoft may well be on its way to becoming the IBM PC of collaborative WCMS, unable to compete with more robust, more open, and less expensive products. Opinions expressed in this article are not necessarily shared by the author's employer.   Comparison of Wiki and Blogs • Wikis and blogs are both examples of groupware; each contains design elements for collaborative work. • The first wiki [http://c2.com/cgi-bin/wiki] came online in March 1995, the first recognized blogs came online and were named as such in1997 [http://www.rebeccablood.net/essays/weblog_history.html]. • You can have one without the other: A wiki can be a blog, but a blog does not have to be a wiki (and I think most blogs are not). • While both wikis and blogs are extensible to the point that they become indistinguishable, the general design principles of wikis and blogs remain unchanged: wikis promote content over form, blogs promote form (temporal organization) over content. • All wikis include default, integrated search mechanisms for locating content; not all blog authoring applications and Web hosting services contain internal seach engines. • Wikis are by default open to anyone within the domain served by the wiki, but can be secured against unauthenticated (uninvited) users. • Blogs by default are secured against open collaboration, but can be managed for limited collaboration, usually via appended comments or a threaded discussion forum. The Searchers' SWiki Experiment Early in my research, I set up a wiki as an experiment and a research repository using the free hosting service at Swiki.net. (See the "Swiki Words" sidebar interview with Stephen Pair on page 45.) I prefer Swiki because it allows the use of HTML, making renaming pages easy. I was also a bit nervous about allowing in the Others out there who might delete something. This is the curse of the wiki newbie. I was quickly talked out of locking pages by one user and tried to add comment forms to just about every page so even unregistered users could post — but not modify — content anonymously. The use of frames, however, surprised at least one contributor. If you've visited some of the wiki sites already mentioned, you'll have noticed how minimalist they are compared with other Web sites. Lots of prose and very few graphics. I posted a few e-mails to various lists to see what kind of reaction I would get and whether I would hook anyone to a degree that another individual besides myself would contribute not only content, but also structure. The results of my experiment can be viewed at the Searchers' Swiki [http://searchers.swiki.net]. As I concluded the writing of this article, I decided to provide an alternate source for content, structure, and the wiki experience via the FreeZope.org service [http://www.FreeZope.org] provided by Amaze Internet Services [http://www.zopewizards.com/] in the Netherlands. I encourage you to visit both these sites as they contain more information than I could cram into this article. Your contributions are, of course, always welcomed. What I learned through my little, unscientific experiment reinforced what I read in The Wiki Way and elsewhere: You can lead just about anyone to a wiki, but no one who's not sufficiently bold or has had previous wiki experience will take that first tentative step at changing someone else's creation. So group dynamics in a wiki require a dedicated group to start and keep the wiki alive as long as it's needed. Group or community wikis are first and foremost about collaboration: That's the whole point of the radical (and still controversial), open editing solution devised by Ward Cunningham. It's the same as with open source software development: You're expected, if able, to contribute a part to the whole and to make that part available to the community. You'll find long expostulations on the collaborative, mutable aspect of wiki in Ward's WikiWikiWeb under such WikiWords as PerpetualNow, TheWikiDiscontinuity, WikiIsNoSandCastle, and WikiNature. Elements of mysticism and religion also arise in many WikiWords as some individuals attempt to grapple with the philosophical/metaphysical overtones and existential "meaning" of wiki: for example, NooSphere, WabiSabi, and ZenSlap. Some plain-talking folks just admit their ignorance through a WikiWord — BoyThisStuffMakesMeFeelStupid — and let their wiki neighborhood take over. In describing in a short, final paragraph the experimental nature of wiki, The Wiki Way concludes with these wise words: "People adapt. Wiki adapts." Wiki Words Glossary Some of these terms originate with content management software. Backlinks (reverse links): As defined by Whatis.com, "a backlink is a link back to the page or one of the pages that currently link to the page you're using." Here's an example from http://howto.ipng.be/openMosixWiki/index.php/InterWikiMap For further information on backlinks see http://www.usemod.com/cgi-bin/mb.pl?BackLink and http://www.kuro5hin.org/story/2002/5/16/152614/482. Reverse link functionality is available through the "link:[Web URL]" search protocol in Google and some other search engines. CamelCase: see WikiWord. Citation link: A specially formatted URL allowed in some wiki markups that creates a hyperlink consisting of a number, usually enclosed in square brackets. CMF: Content Management Framework, a Zope Corporation initiative. CMFWiki is a wiki clone implemented within this framework. CMS: Content Management System. See also WCMS. Intertwingular: Memes.net, a wiki, defines this as "many relationships between atoms of data, not just the simple hierarchies that we see in todays [sic] computer interfaces." Examples, besides wikis, that promote intertwingularity are The Brain [http://www.thebrain.com/], Lucid Fried Eggs [example site: http://www.memes.net], and Ted Nelson's ZigZag and Xanadu projects [http://www.xanadu.com/]. Open link: An uncreated wiki page that results from the use of a WikiWord (or whatever text-formatting rule applies to the wiki implementation). Accidental open links are a problem in wikis and result from a wiki writer not checking to see if a page exists before creating a page with the same content, but under a different WikiWord. See also WikiWord and WordJam. RecentChanges: A wiki page that lists the most recent changes to every wiki page. Also called Changes. A proposed wiki extension to the RSS protocol uses the RecentChanges page for syndication content. Refactoring: The process of editing existing wiki pages to create new ones, to enhance existing links, and to reorganize the internal structure. Defined in The Wiki Way (2001, p. 330) as "a technical term for iterative adjustment based on new input"; basically, rewriting, but also restructuring. SlashDot Effect or Slashdotting: According to The Jargon Lexicon [http://catb.org/esr/jargon/html/entry/slashdot-effect.html], "what is said to have happened when a Web site becoming virtually unreachable because too many people are hitting it after the site was mentioned in an interesting article on the popular Slashdot news service." The effect is unintentional, unlike a Denial Of Service (DOS) attack. WabiSabi: Refactoring of content in a Zen-like fashion. WCMS: Web Content Management System. A client-server application category built around the HyperText Transport Protocol (HTTP) that includes site and content management tools. WCMS do not necessarily include collaborative, real-time, Web-based editing of contents by the Web site's end user. WebDAV: Web Distributed Authoring and Versioning. An extension or new version of the HTTP protocol. Zope implements WebDAV. WikiBadge: Zwiki.org [http://zwiki.org/WikiBadge] describes this wiki search feature as "a page which you can add as a link to other pages, usually at the bottom, to mark them in some way. The badge page should describe the purpose of the badge. View the badge page's backlinks to see a list of all pages marked with that badge." Additional discussion about the utility of a WikiBadge is on Ward's WikiWikiWeb [http://www.c2.com/cgi/wiki?WikiBadge]. Wikiblog: A combined wiki and blog application. WikiWord: A text formatting rule from the original wiki Perl script that creates a new wiki page, and, once saved, creates a hyperlink to the page. The WikiWord constitutes the file name, which in turn forms part of the URL. Using a WikiWord again on any other page creates an automatic link to the page, otherwise an open link indicator signals that the page needs to be created. Also known as Camel Case [http://www.ecyrd.com/JSPWiki/Wiki.jsp?page=CamelCase], InterCap, and EmbeddingCapitals. WordJam: A conflict in a new wiki page name and real words, acronyms and abbreviations. See also Open link.   Toward a Collaborative Networked Future The tragic events of September 11, 2001, accelerated an existing trend towards Web-based and peer-to-peer network collaborative work. The Gartner IT research and consulting firm devotes one of its business focus areas to "Collaboration & E-Learning" [http://www.gartner.com]. James Lundy, editor-in-chief, and Debra Logan, contributing editor, of this section, predicted in their 2003 letter from the editor, "Users can't wait for IS organizations to bring them the tools and collaborations that they need to do their jobs." In announcing through a publicly available document the evolution and merger of Lotus products with the IBM WebSphere/DB2 platform, Gartner analyst Simon Hayward admits that "next-generation products have appeared earlier than Gartner had expected." He points out, "The options for enterprises looking for collaboration support have become more plentiful. While Microsoft struggles to turn its assets into a coherent offer for collaboration support, Oracle's entry has opened up the market, and Novell has recommitted to this space." In a presentation justifying its acquisition of eRoom in the fall of 2002, Documentum devoted a page to "The 'Buzz' About Collaboration." Predictions from market research by META Group and Giga Information Group are quoted to support this purchase. Mike Gotta, the META Group analyst, anticipated 85 percent of "knowledge workers" would use "teamware tools" by 2006. Erica Ruguillies, Giga Information Group, anticipated similar strong, yet even more rapid, interest in linking "team collaboration functionality" with content management systems. Transform Magazine named two existing IBM Lotus products that support collaboration, Sametime and Lotus Team Workplace (formerly QuickPlace), among its choices for 2002 products of the year. The magazine's Web site's lead article for February 2003 by Lowell Rapaport is "Team Collaboration Unites the Workforce," and one of the top trends outlined in a January 2003 article by Penny Lunt and others discusses how collaborative technologies are transforming business activities. Microsoft began staking out the territory in 2001 with the introduction of SharePoint Web-based collaborative products that include support for WebDAV. Here is what Microsoft reported on October 29, 2002: SharePoint™ products and technologies have experienced overwhelming adoption by companies implementing portal and collaboration solutions. More than 10 million seats of SharePoint Portal Server have been licensed in its first 17 months of availability, and it has been widely adopted by medium- to enterprise-sized organizations. ... In some cases users need a Web site they can create and contribute to immediately, and SharePoint Team Services meets those information-sharing needs. SharePoint Teams Services is designed for small ad-hoc teams that need a quick and intuitive site to share documents and project-focused work. More important, SharePoint Team Services helps teams create Web sites that are easy to customize and manage. This, of course, is exactly what wiki technology is all about, except that wiki Web server applications, including database components, are for the most part completely free. To its credit, Microsoft bundled SharePoint Team Services with FrontPage 2002 and some other products, but you can only use SharePoint Team Services with Microsoft Web servers equipped with the required Microsoft Data Engine or Microsoft SQL Server 7.0+. You can locate ISPs through the SharePoint Team Services site [http://www.microsoft.com/sharepoint/teamservices/default.asp] that will host a subscription-based SharePoint Team Services site for you.   Wiki Words from Bo Leuf Co-author, The Wiki Way (2001) and Peer to Peer: Collaboration and Sharing over the Internet (2002). Mr. Leuf's biography is on his wiki [http://www.leuf.com/ww/wikicom?WwwBio]; he lives in Sweden. DM: What attracted you to the Wiki concept? BL: Its unique combination of simplicity and leveraging power, plus the fact that it was open source, so anyone could hack customized versions and play around with the concept. I was an early visitor to the original public Wiki at c2.com, and the rapid growth of posted co-authored material and community feeling was quite amazing. DM: Why do you think wikis haven't captured the public imagination the way blogs have? BL: That question is misleading, I feel. "Wiki farms" have in fact spread rapidly, and many more "blogs" than you might suspect are actually built on Wiki or Wiki-like solutions, albeit usually closed for edit to all but the owner. However ... "blogging" or properly Web journaling isn't about any particular technology, it's a form of expression, whether the publishing tool/medium is Movable Type [http://www.movabletype.org/], b2 [http://cafelog.com/], Wiki [http://c2.com/cgi/wiki?WelcomeVisitors], or your average ftp'd HTML site. I rather doubt the average blogger really cares about the underlying technology as such, being more concerned with ease of publishing, the CMS features, layout, and referencing community. And that is perhaps the core of what the question intends. Wiki is primarily about co-authoring, and most implementations tend to downplay layout and styling. Bloggers are mostly writers of personal journals, not likely to be interested in freeform co-authoring. In fact, most would find the very idea of open co-authoring both frightening and unrealistic. The main community interest appears to be cross-linking with other journals and commenting these in one's own postings. Blog software has functionality for this kind of thing, support for calendar organizing postings, and a modicum of styling options. DM: What are some of the features that make a wiki different from other kinds of content management systems? BL: I try to use "a wiki" for specific implementations and "Wiki" for the concept. [The features that make Wikis different are] Minimalistic. Informal. Freeform content. Open source. Open editing (though this can be restricted in various ways). Plain text storage. Hyperlink aware and HTML rendering on the fly. Customization. DM: Can you tell us a little about the Cluster Wiki concept you developed? BL: Experimenting with a clone variant of Ward's original, I soon had several public wikis on a single server [http://leuf.net/ww/wikinet?WikiWebList]. Keeping multiple code bases in sync became tedious and prone to mistakes, so the natural reaction was to move core functionality into a shared library. As I moved towards Wiki as a Web hosting option, and thus even more wiki instances, centralized code bases seemed to be the only reasonable way to go. The defining feature of Cluster Wiki is that each deployed wiki instance is represented by a very short code "stub" with a unique name and a few, largely optional, parameter values. The stub imports the shared library, which then knows which database to look at. DM: What are some of your favorite wikis and why? BL: My own, since that's where I organize my own information. :) Seriously, though, Ward's Wiki at c2.com is always a place I return. It has a large and very active community, highly knowledgeable. A relative newcomer, Wikipedia.org [http://www.wikipedia.org] has rapidly become a valuable Web resource. We may also note that many support and discussion sites, such as the Open Source discussion forums "went Wiki" during 2001. You may now even see a loose "clustering" of HTML site, journal, and open wiki, evidently leveraging the best of each for different aspects of the site. DM: How do you see wikis changing or influencing Web culture? BL: For some, Wiki has meant a return to "content" and "peer" publishing, a return to the original design of the Web, away from the passive content consumer model that became prevalent in the late '90s. In this respect, Wiki shares some characteristics with the peer-to-peer technologies; it's P2P in the person-to-person co-authoring sense. Wiki is in the tradition of simple tools and few user constraints, of community and sharing. DM: What are your thoughts about wikis as hypertext-based information retrieval tools? BL: Wiki is an absurdly simple database tool, very informal. Probably optimal for the kind of ill-defined or shifting needs that an individual has for organizing personal notes or for Web-published meanderings. Less suited to formal database environments where entry format must be specified and access more controlled. That said, wiki implementations have been constructed as front ends for MySQL engines, corporate team tools, and support sites. Wiki has scaled far better than expected. DM: What benefits do wikis offer corporate culture and why should organizations use them? BL: The informal aspect is important, as is the co-authoring aspect. Wiki can be seen as a better group communication/archive tool than e-mail and distribution lists. One of the problems with traditional, more formal knowledgebase solutions is the bottleneck effect, that updates are delayed through centrally managed entry. In, for example, a customer support site, support technicians can search and update on the fly as they deal with customers. Others using the same database know that the information they see is always the most recent version. DM: What are the disadvantages to corporate culture of wikis? BL: There are several reasons wikis might not be sanctioned in corporate contexts. Lack of control. Lack of fixed format. Lack of accountability. "Not on the approved list of applications." DM: Can you connect the dots for us between Wiki, WebDAV, and any other database-driven permutations of collaborative software being rolled out over the next year? BL: Wiki is firmly based on the existing client-server model of the present-day Web. It builds on existing infrastructure and ubiquitous software: Web servers with Perl script capability are legion, any stock forms-capable browser client can participate. No extras, which is why the user interface is by necessity rather primitive, and until the incorporation of CSS, the display totally no-frills. It's also easy to add Apache/Perl support to an MS-Windows PC, which helps the stand-alone or local-network usage of Wiki. Wiki is a simple server-based, node-style application, regardless that you can run it as stand-alone on a desktop (by emulating a Web server with the QuickiWiki script). Some experiments have been done to extend the concept into what is commonly called Wiki Federation [DM: replaced by the InterWikiMap; http://c2.com/cgi/wiki?InterWikiMap], that is a peer network of wiki servers that exchange data so that user requests on one in some way leverage the content of the others. Multisite-spanning search is one example. A very simple enhancement is SisterSite functionality, where page links are validated against lists of page names from sister sites, not just the wiki's own database. Wiki was subsequently extended by some clone derivatives to include more explicit database management (server-side add-on), such as RCS (Revision Control System) [http://www.gnu.org/software/rcs/rcs.html], CVS (Concurrent Versions System) [http://www.cvshome.org/], or ported/integrated into larger CMS systems (Python Zope) [http://www.zope.org]. It was also early ported to the Smalltalk environment (Swiki) [http://minnow.cc.gatech.edu/swiki], where the wiki easily can leverage any of the Smalltalk operating system's native capabilities, or that of other Smalltalk applications. For Mac OS users, Swiki is still probably the easiest well-supported path to go. OS X users have native Perl and server support, so the choice there is less of an OS-issue. WebDAV [http://www.webdav.org] is something different, because though some of the concepts are the same (across-the-Web co-authoring, for example), the implementation is primarily by way of a longer-term change in the infrastructure of the Web — new servers, new applications, new client software, and above all, a new extended HTTP protocol. This is all good and well, and the result will assuredly incorporate many desired features that current Wiki cannot do with its reliance on stock clients and the current HTTP 1.0/1.1 Web protocol. Thus, WebDAV is a future development from the perspective of users and less malleable to individual needs. Wiki is here and now and highly customize-friendly, if very much a hack. You also find a number of usually "enterprise" solutions for Web/distributed collaboration, and these applications are what Wiki is contrasted with on corporate LANs. The big solutions are almost always very client-software specific (and task-oriented), although some of them do have Web interfaces for general use (but perhaps specific for IE with plug-in xyz and support for abc). The big solutions are no doubt relevant for large user bases and the kind of process control (hierarchy, authentication, permissions, audit trails, etc) that some aspects of corporate activities require. Such contexts are not well-suited for Wiki. As noted in the book [The Wiki Way (2001)], corporate use of Wiki tends to be team/department-local and "under the radar" of IT management, for informal discussion, follow-up, and data management before things are ready to be submitted into the formal KB/DMS used. I expect this situation to continue, no matter what software "rolls out" in the immediate future. What I've been following suggests two things, however: 1. Use of small-scale and simple (free, open source) solutions is proliferating rapidly on the Web, and doubtlessly also in the largely invisible corporate networks. Visible adoption of Wiki and Wiki-like applications has been extensive, practically exponential since the book was written. I see no reason for this development to stop; quite the opposite, as more people come into contact with the concept. Some will probably consider Wiki and quasi-Wiki solutions for the Web as just another blog tool. 2. Use of P2P technology (which I wrote about in Peer to Peer [2002]) is also spreading rapidly within certain segments of the corporate world and forming the basis for large scale changes in the way we do business and how individuals will interact with online services. Wiki-like applications find application as part of this new infrastructure, especially in areas such as flexible databases for customer support, discussion forums, and so on. Whether or not .NET [dot NET: http://msdn.microsoft.com/netframework/] becomes the Web services paradigm is irrelevant in this context. The distributed and collaborative functionality will be implemented and deployed in one way or another, and with it some form of greater openness for the individual user, supported by community and trust mechanisms to make it all work. I believe this expansion will happen despite the pervasive repressive movement towards closed systems and centralized content control that is in the news currently. Technological solutions for open systems that cannot be controlled are already deployed on the Web, and in 2003, a broad public backlash against content control could easily become the dominant force as a reaction to efforts at control having gone too far. Collaborative software can only become more important and pervasive over time. Swiki Words from Mark Guzdial Associate Professor, Learning Sciences & Technologies, Collaborative Software Lab, College of Computing, Georgia Institute of Technology, and lead developer of Swiki; http://coweb.cc.gatech.edu/csl or http://www.cc.gatech.edu/~mark.guzdial/. DM: What attracted you to the Wiki concept? MG: We had been doing work with computer-supported collaborative learning for several years before we discovered Wikis and developed Swikis. One of our tools, CaMILE, supported Web-based annotation of other Web documents ("anchors" for discussion). Our studies found that anchoring discussions led to more sustained, on-topic discussion than newsgroup-based forums that were unanchored in things that students cared about. For the most part, though, CaMILE discussions and anchors were created by the teachers. What if students had the power to create their own discussions and anchors? How would it change the dynamic of how students collaborated and used the tool? Those questions are what led us to Wikis. DM: Why do you think wikis haven't captured the public imagination the way blogs have? MG: A blog is a much more structured application. Wikis can do anything. That makes Wikis more powerful, but also more demanding and complex. Why is Word more popular than Photoshop or Painter? Creating within a comfortable, structured space like a typewritten page is easier than being given an empty canvas. DM: What makes a Swiki different from other kinds of content management systems, especially other wikis? MG: Swikis are tuned to the audience we're most aiming at: university teachers and students, and the visitors that they invite. Our users wanted to use the HTML they already knew, and they wanted more control over page titles than most wikis provide. We've realized that we also have a range of users even within this limited audience, and we've tried to cater to those ranges. For example, some classes use the Swiki to create a forum for involving external visitors. These external visitors don't know about Swikis, nor do they want to, so clicking on "Edit" is frightening for them. So, we made it very easy to create "Add to this page" sections at the bottom of pages, to enable ease of visitor input. Jochen Rick, who built our current Swiki software and serves as the open source champion of Swikis, and I wrote a paper for the CSCW conference a few years ago about the user roles we noted and how we tuned the environment to support those users, available at http://coweb.cc.gatech.edu/csl/Papers. DM: What are some of your favorite aspects of and favorite (s)wikis and why? MG: My favorite aspect of the Swikis is how teachers have adopted Swikis and invented terrific uses that never occurred to us developers. The architects do this spectacularly. They've invented wonderful activities in the Swiki, like collaborative pin-ups and galleries, with online debates and critical essay reviews. Irfan Essa in the College of Computing uses Swiki for his annual course on digital video special effects, and those are wonderful Swikis to visit, because his students use the Swiki for storing everything: their storyboards, scripts, code, rough drafts, everything. You can go look at the students' movies, then trace back through the movies' evolution. It's like having an interactive "The making of..." for each of the movies. Our English Composition classes have Swikis where students collaboratively critique poems and essays, and even their own writings. They're not the most exciting Swikis to visit for outsiders, but they're among my favorites because we've found that the collaborative aspect has had an important learning benefit to the students. That's exciting. DM: How do you see wikis (and swikis) changing or influencing Web culture? MG: There isn't a single Web culture. There are many cultures on the Web. We've learned that the same tool, Swiki, can be amazingly successful in one course, and an abysmal failure in another course in the same department, where students don't participate at all. Each course is its own microculture, with its own values and goals. In some settings, the Swiki has had great influence. Our Chemical Engineering School now uses Swikis for every class they teach. But the Web is too vast and diverse for any single Web application to affect all of it. DM: What are your thoughts on wikis as hypertext-based information retrieval tools? MG: That's not really something we've explored much. We're much more interested in the role of Swikis in supporting learning, and then studying how they get used. DM: What benefits do wikis offer the education system and why should they be used as part of the curriculum? MG: We've seen uses of the Swiki where it's had an important role in helping students to collaborate and become more engaged in the course material. Learning scientists refer to this phenomenon as "shifting the agency." In most classrooms, the teacher has the "agency," the control, the driving force — the teacher asks the questions, the students respond. But in the real world, each of us have our own agency. In that sense, the classroom works backwards from the real world. In the real world, if you have a question, you go to an expert who knows the answer, then ask him or her the question. But in the classroom, the teacher typically already knows the answer, but is asking the students the question, and they may not know the answer. The Swiki offers the opportunity to shift the agency into a more realistic state: Students ask questions, make the pages, even create their own activities. One night, while working to meet a deadline, a group of my students decided to create a "Choose your path" adventure game. Someone posted a few pages, and the rest of the class joined in, and soon there were a few dozen pages written by a whole bunch of students. They decided to do that, they took control of the Swiki, and they just made it happen. DM: What are the disadvantages to the education system of wikis? MG: It's scary for teachers to give up control over their students. Today, we increasingly demand our teachers to be more accountable for their students' learning and for their time. In my kids' school, recess was outlawed as unproductive time. However, that's not how learning works. Learning is an individual, purposeful activity, and if you can cajole students into taking charge of their own learning and to inquire about useful and interesting questions, they learn much more than if tightly controlled and lectured at. Our research suggests that students succeed in the more free-form world of Swikis, but only if the teacher and classroom culture supports that freedom. Otherwise, the students stay away and just wait to be told what to do for their A. DM: What does the future hold for Swiki? MG: It's entirely dependent on the open source user community. We're not actively adding features to Swiki now. We've reached a point where we're happy with the interface and performance, and we're focusing on exploring its use. That doesn't mean that Swikis are no longer being improved. As the user community develops fixes or enhancements, these get posted to the mailing list, and Jochen Rick culls the best or most generally useful of them and incorporates them into the next release — in true, open source style. Swiki Words from Stephen Pair Co-founder, Advantive Associates, Inc. [http://www.advantive.com/], Marietta, Georgia, who provide the free NetUnify.com and Swiki.net hosting services. The company introduced both services in 1999 and states that in 2002 the combined total of registered users numbered more than 6,000. The company will release version 2 of Swiki.net this year. DM: Why is your company providing this free service? SP: We are offering Swiki.net as a free service for a couple of reasons: a) it will eventually have features that can be added to an account for a fee; the current service helps us establish ourselves while we work on the site that will (hopefully) generate income; b) the software that powers Swiki.net is a comprehensive Web application development and deployment platform and will serve as the basis for additional offerings that are not related to Swiki.net; it will enable users to design, develop, and deploy Web applications very quickly. DM: Why do you think wikis have not taken off the way blogs have? SP: Blogs provide more structure for content than wikis. A very common form of publishing is the individual or community news item. And, the way that blog entries are organized by date and time fits very nicely with this form of publishing. Blogging capability is something that we would like to add to Swiki.net in the future. DM: What are some of the features that make a swiki different from other kinds of content management systems, including the classic Wiki as initiated by Ward Cunningham? SP: The most obvious difference between Swiki.net and traditional wikis is that there is no software that the user has to install and host. In addition, Swiki.net offers some additional privacy features. Compared with other content management solutions, Swikis (and wikis in general) are more peer to peer in their publishing paradigm and offer greater flexibility (at the expense of more structure) in the organization of content. Wikis also tend to be self organizing. DM: If you have any favorite swikis or wikis, what are they and why? SP: I participate in so many wikis that it's hard to pick a favorite. Some wikis are informational in nature and less participatory. A couple of good ones are echostar.swiki.net and gtw.swiki.net. Others are associated with software development such as eclipsewiki.swiki.net. Still others serve as quasi CRM solutions like ostudio.swiki.net and stx.swiki.net. Many people (myself included) have personal Swikis that they use to organize their personal information. And, a few companies use Swiki.net for their intranet. There are also Swikis for clubs, families, pictures, and neighborhoods. DM: How do you see wikis changing or influencing Web culture? SP: I see wikis helping to decentralize the publishing of information. The Web started as a largely one-way communications medium. In a traditional Web environment, the distinction between publishers and viewers is quite distinct. Wikis simply make it easier to be a publisher of information. DM: Do you have any thoughts about wikis as hypertext-based information retrieval tools? SP: Structurally, wikis are organized just like the Web in general is organized, so any general-purpose Web search engine can index and retrieve content that is wiki-based. But, since most Wiki engines more closely manage their content, they do have potential for enhanced information retrieval capabilities. For example, page links in most wiki engines are bidirectional. This makes it possible to navigate to all referers of a page. DM: What benefits do wikis offer corporate culture and why should organizations use them? SP: Wikis can be very helpful in an organizational setting. Most work within an organization is done in the context of a project. Wikis are very useful in serving as the "home page" of a project and being the place where team members collect and organize their thoughts, work, and research as they relate to their project. In the context of a project, having a place to organize information is critical. In projects where I've used a wiki, it's amazing how much information is collected and organized over time that would ordinarily get lost in the e-mail shuffle. I've often found information in such a wiki and thought, "Wow, I'm glad we didn't lose that." ... Then I'd realize that if we were only using e-mail, the information would have been lost, and I wouldn't even have realized it. DM: What are the disadvantages to corporate culture of wikis? SP: I don't know that there are any disadvantages. Perhaps just the fact that wikis can be new to an organization is a disadvantage. They could also subvert a normal flow of information in an organization. But I'd say that in an agile organization, it's important to encourage informal lines of communication. And, finally, as with anything novel, there can be an overexuberance about it, which can lead people to use it in places where it would be overkill or not a substantial benefit.   Wiki on the Wild and Wholesome Side Many wiki clone software sites contain lists of public wikis using the same software (not the same as an InterWiki list), for example, MoinMoinWikis [http://twistedmatrix.com/users/jh. twistd/moin/moin.cgi/MoinMoinWikis] or [WikkiTikki]TaviSites [http://tavi.sourceforge.net/TaviSites]. And Stuff Wiki: http://andstuff.org/AndStuffWiki binarycloud Wiki: http://binarycloud.com/wiki/ CapitanCook.com: http://www.capitancook.com/ CoForum: http://coforum.de/index.php4? EAD Wiki: http://www.archiveshub.ac.uk/eadwiki/ Easy Topic Maps: http://easytopicmaps.com/ Enciclopedia Libre: Enciclopedia Libre Universal en Español: http://enciclopedia.us.es/ FreeNetworks.org: http://www.freenetworks.org/moin/index.cgi infoAnarchy Wiki: http://www.infoanarchy.org/wiki/wiki.pl?Homepage KmWiki: http://www.voght.com/cgi-bin/pywiki?KmWiki Meatball Wiki: http://www.usemod.com/cgi-bin/mb.pl Memes.net: http://www.memes.net MetaFilter Wiki: http://www.mssv.net/wiki.cgi?Home Min_i_ Sodas: http://www.ms.lt/ NeXus Swiki: http://www.neutron.anl.gov:8080/NeXus/ Nupedia: http://www.nupedia.com OpenIdeaProject's ZWiki: http://www.openideaproject.org/openidea/MAin/ProjectsPage Potlatch Wiki: http://potlatch.net/MoinMoin/moin.cgi RotaryDoctorBank.org: http://www.rotarydoctorbank.org/toc.html State of Alaska, Department of Public Assistance, DPA Wiki: http://soar.hss.state.ak.us/tavi/index.php?page=DPAWiki Susning.nu: http://susning.nu Think Tank: A Sustainable Living Initiative: http://thinktank.rootnode.com/Wiki/FrontPage Tolkien Wiki: http://www.thetolkienwiki.org Wikipedia: http://www.wikipedia.org/ Witionary: http://wiktionary.org/wiki/Main_Page David Mattison's e-mail address is David.Mattison@gems3.gov.bc.ca 4:11:44 PM

新鮮貨／i-show卡拉OK機　電腦影音也能播 2004/04/15 18:20 i-Show交由聲寶銷售，下個月上市。 　記者陳曉藍／台北報導 在家唱卡拉OK，是許多人的休閒活動，經營伴唱帶的啟航國際，也加入卡拉OK機器的生產，15日發表的i-show，除了內建6000首卡拉OK伴唱功能、播放DVD之外，也可以透過乙太網路或無線網路來讀取電腦中影音資料。 啟航國際表示，i-show透過無線網路或乙太網路連接，可讀到多台家用電腦，使用者利用遙控器可選擇欲抓取的電腦，再用遙控器選擇電腦中所儲存的DVD 影片、照片、音樂等資料，但僅限於特定資料夾，並不能讀取所有的檔案，最後利用網路傳輸，在i-show中進行解碼，最後在電視上呈現。 i-show只是可以讀取電腦中的影音資料，並非內建media getway（家庭多媒體閘道器），過去國外也有類似的產品，HP的Digital Enterment Center、AItech的MaxView Cinema Kit等，只能串接音響/電視與電腦之間，市場發展也相當有限。 對於i-show來說主要訴求還是專攻菜籃族的卡拉OK伴唱功能，目前內建6000首，可支援MPEG-4等多種格式，增加曲目可透過伴唱光碟把內容儲存進去，建議售價約為30,000元。 10:02:28 AM

Photoblog Revolution [Slashdot:] 9:26:23 AM

The China Syndrome. The first 18 years of my career, I was with HP. Then I ran a startup where one of my two lead investors was General Electric. In those days, that meant face time with Jack Welch. Jack had coined a word that perfectly applies to China: comcustomer. That's somebody who you compete with and sell to at the same time. That¡¦s China. They are going to emerge as a huge competitor to this country and as... [AlwaysOn Network] 9:21:32 AM

Mac OS X, BSD Unix top security survey. London-based mi2g Intelligence Unit on Tuesday released a report that says Mac OS X and Berkeley Standard Distribution (BSD) Unix are the "world's safest and most secure 24/7 online computing environments." Linux operating systems offer the worst track record, according to mi2g, with Windows coming in second. [MacCentral News] 9:06:47 AM

iPod: No Thanks, Maybe iRiver. iPod users read this: "If you buy into a proprietary platform where the music industry gets a veto, you're screwd. Every time you buy an iPod, you are financing legal and technical countermeasures aimed at taking away legitimate features that... [Robin Good's Latest News] 9:05:01 AM

Learning Objects: A Practical Definition. via elearnspace This is a rather comprehensive review of definition of learning object. Although the author did suggest a definition at the end, I don't think it is any more conclusive than previous attempts. Have a read if you are REALLY interested in the academic discussions about learning object. I still suggest to call useful learning resources learning resources. Why "object" if the By noemail@noemail.org (Albert Ip). [Random Walk in E-Learning] 8:44:16 AM