Why should any "standards" apply to Wiki Engines?

• make it easier to use different wiki sites (not have to learn different Smart Ascii rules, Wiki Name rules to create new nodes, etc.)

• make it easier to link from one wiki to another (WikiWeb) (e.g. Remote Wiki Links can't work well to link to a wiki which uses [ID] numbers as [URLs] instead of [Wiki Names], or uses punctuation within [Wiki Names], etc.) (see Wiki Name Examples)

• allow for creation of Rich Client apps (maybe to support OffLine use/Data Synch, maybe for visual interface like Touch Graph/Idea Graph) that could work (InterOp) with any engine.

Should this be structured as a Wiki Pattern Language?

Specific potential standards

Inter Wiki - WikiWikiWeb:InterWiki was the original idea to have a single web-wide wiki Name Space, transparently distributed across many servers. That idea is dead/inactive.

Automatic Linking, using Smashed Together Words as Wiki Name/Wiki Word rules. These support other standards below like Inter Wiki Map and Sister Sites.

Inter Wiki Map (Remote Wiki Links, WikiWikiWeb:InterWikiMap, MeatballWiki:InterMap): making it easy to link from wiki to another by simply using HostName:PageName.

• MeatballWiki:InterMapTxt is (?) the definitive list of possible [URLs] to look up; surprising-to-me, the Hostname doesn't have to be Camel Case, just initial-cap (so Hostname:PageName works).

• not surprisingly, this assumes that all servers use the same Wiki Name and page URI conventions (Page Name As Url); so if your wiki assigns some other [ID] as a URI (some use a number, others allow spaces in [Wiki Names] and replace those with underscores in the associated URI), those pages are less likely to get linked to by other wikis.

• UseMod:InterWiki also uses the Meatball Wiki approach.

• TWiki:InterSiteLinkRules seems to use at least the same naming methods, though the actual list management looks different.

• ZWiki, unfortunately, neither uses this list of hostnames, nor even this approach of having the list contained in a single page. Instead, it scatters them through single-wiki pages like ZWiki.

MeatballWiki:InterWikiSearch and MeatballWiki:MetaWiki perform title searches across a number of wikis.

• the former queries those wikis in Real Time, while the latter stores a directory of [Page Names].

• ZWiki doesn't even do title-only searches, I think

• does this belong in the wiki/server, or is in a Rich Client/Universal Inbox?

Sister Sites: a given wiki defines some "sister sites", and caches a list of valid [Wiki Names] for each. Then, for any page it delivers, it checks that list, and if finding matches, shows those links (typically via icon) at the bottom of the page.

MeatballWiki:UnifiedRecentChanges: for a defined set of wikis (the same list used for Sister Sites?), provide a merged Recent Changes view. But note that Recent Changes lists often imply a higher currency (hourly?) than Sister Sites (daily?). Maybe RSS/Universal Inbox is a better approach to this?

[WikiRPC]

ZWiki, being based on ZoPe, gets ZWiki:WikiAcquisition. This can mean that when you nest one Wiki Space inside another, inner references to an existing outer Wiki Name will be recognized/activated. Sometimes this isn't what you want.

A different context/perspective

Imagine you're [CIO] of a BigCo, and there's interest from all over the company in using WiKi. Do you force everyone to use the same Wiki Engine? Or just let bottom-up behavior go its own way?

What's the smallest amount of specification you might demand?

To get some Knowledge Management benefits of people learning from each other, would want to make it easy for people to read multiple sites and link from one to the other. So Wiki Name and Inter Wiki Map features would help.

I could also see insisting on every wiki supporting an RSS format of Recent Changes. But you could probably implement that with some simple scraping from a central spider. (Not unlike an Intra Net Search Engine.)

One would hope that people were working together across dept lines. Which means a given person could end up writing in multiple wiki sites. This would seem to push toward a single Smart Ascii choice.

You'd probably want [Hard Security] (so authorized people could use spaces from outside the Fire Wall). You might not worry about which subset of the company is allowed to use a given space... which might allow Single Sign On validation through something like a central POP/IMAP server.

other?

How do I personally intend to increase adoption of Wiki Standards?

write up something establishing the position. That way people can find it.

• Need to refactor Wiki Standards, WikiWeb, and Wiki Engines - and make specific recommendations

have some running code which support those positions - key for credibility

seek input from Ward Cunningham ("endorsement" of some standards, implementation on [Quicki Wiki] code base)

seek input from authors of key Wiki Engines, try to get congruence toward some of the potential standards

Start pushing it around in Social Software Alliance

• http://www.socialtext.net/ssa/index.cgi?interwiki

• re their engine: http://www.socialtext.net/ssa/index.cgi?feedback

Idea for a better use of human intelligence --2003/09/28 09:18 [GMT]
No doubt the Inter Wiki under a common administration is the basic-anarchic platform for Collective Intelligence to unfold and Open Society and a [World Governement] to be built upon. See http://www.terrahome.net.tc (link discussions for further Info in German and English on different wikis) --Mattis Manzel

2003/12/08 09:49 [GMT]

There is a wiki way to develop wiki standards. The standards you mention above were developed on Meatball Wiki by the collective efforts of all the major wiki developers. [Inter Map Txt], Inter Wiki, Touch Graph link standard, [ModWiki], and soon perhaps a [Wiki Syntax] standard were all done there, and I'm proud of that. Not to disrespect the [JspWiki] guys who made the [Xml Rpc For Wiki] interface. --Sunir Shah

User Options Recent Changes Help Page