Wiki pages can exist in one or several NameSpaces. On Meatball, for example, all pages exist in the same namespace.

Some WikiEngines allow the creation of new namespaces: A SubWiki. Every page named X can exist in the main namespace as well as in the various subwikis. When linking to the page X, it depends in which namespace the link exists. It will refer to the page X in the same namespace. To refer to page X in another namespace, it has to be qualified. The exact syntax varies: Foo/X, Foo.X, Foo:X.

Implementations: TwikiClone calls these a Webs, PmWiki calls these Page Groups, MoniWiki call these name space.

Each wiki also acts as a namespace in its own right. This is unrelated to a SubWiki. A link to page X always links to page X in the same wiki. To link to page X on another wiki, it has to be qualified. Usually a complete URL works fine, but often wiki engines use an InterMap. This map defines “URL Abbreviations” – each moniker expands to the complete URL of the wiki linked to. The moniker acts as the namespace qualifier. The traditional syntax is Foo:X. See InterWiki for the general idea behind this.

Using a separate wiki per namespace has the drawback that some things are harder to get by, now. Examples:

The missing functionality can be grafted onto a collection of wikis, of course. XmlRpcToWiki and WikiGateway are some of the tools that would allow this.

The same technologies make it easier to split a topic into a new wiki. See InterWiki for more about seamless integration of various wikis.

CategoryNameSpace CategoryWiki

Difference Between Local Links and External Links

The effect of linking from A to B is harder to predict if perfect namespaces are in effect, because the page B may exist in several namespaces.

Depending on the context of A, the link will to different pages If A is in the X namespace, B in the X namespace is linked to. If A is in the Y namespace, B in the Y namespace is linked to. If A is copied from X to Y, the link to B will point to a different page. When copying pages from a wiki X to a wiki Y, all local links have this property.

Note that when wiki Y uses NearLinks to X, then copying page A from X to Y will keep links to B intact, if and only if B does not exist on the new wiki Y.

Example: When you see a link to AlexSchroeder, you have to remember where you are right now before you know whether this links to MeatBall:AlexSchroeder, EmacsWiki:AlexSchroeder, Oddmuse:AlexSchroeder, or Community:AlexSchroeder. This is not a HumaneInterface.

Imperfect Namespaces

Some WikiEngines implement imperfect namespaces. An imperfect namespace implementation does not provide perfect separation of namespaces. PageClusters, SubPages, and NearLinks are examples of imperfect namespaces. They try to get around some of the drawbacks of perfect namespaces.

A solution that implements perfect namespaces would be indistinguishable from an individual wiki for every namespace. If you want perfect namespaces, that’s what you can do: Install a separate wiki for every namespace and use an InterMap to link between them, and write some sort of UnifiedRecentChanges, if such a thing is required. Wikis that are difficult to install multiple times usually have better namespace support because installing them once for every namespace is difficult.

Recent Changes

RecentChanges acts as a bottleneck on attention. Too many changes make PeerReview more difficult. See HijackingRecentChanges. One way to deal with this is to group changes to pages in the same group specially. This does not require separate namespaces. It only has to affect RecentChanges to be effective. This is what PageClusters do.


UseMod allows users to create SubPages to a page. These pages are accessed from outside the group using Foo/X. Within the group, you still need the leading slash: /X. If you just link to X, this will link to the page X in the main namespace. This solution clearly favours one global namespace, since the “default” LinkPattern links to the main namespace only. Since a link X will always point to the same page, the default link pattern is very easy to understand. This is a HumaneInterface. Since the special notation /X will link to different pages depending on context, however, using subpages is not humane.

Using subpages a hierarchical namespace system can be created, much like a directory structure in a filesystem.

Namespaces as Sets

FacetWiki implements SetBasedNamespaces? instead of hierarchical namespaces. This lets you put one page in overlapping namespaces, rather than a strict hierarchy. In a strict tree hierarchy, if page AB is a SubPage of page A, then it can’t also be a SubPage of page B. FacetWiki overcomes this restriction. Another important aspect :) of FacetWiki’s namespace idea is ContextualLinking?.

Near Links

Based upon PeriPeri:NearLinks, near links are links that look like ordinary links but point to a different site. If two wikis A and B act as two different namespaces, and they allow NearLinks to each other, then when you link to page X on wiki A, X may point to page X on A, if it exists, or to page X on B, if it does not exist on A but it does exist on B. Clearly, this requires A and B to exchange information on the pages they have defined. SisterSites requires the same kind of information.

Success Stories

On Campaign Wiki I’ve had a lot of success with using Oddmuse and the Oddmuse Namespaces extension. Essentially this creates a lot of independent wikis, usually used to document campaigns for roleplaying games. There is also an instance of a Warhammer 40k miniatures wargame being documented.

  • Recent Changes for the main site aggregates the changes of all namespaces.
  • Each wiki offers its own Recent Changes page, and its own set of RSS feeds, allowing players to keep up with just their campaigns.
  • Inter links allow people to easily link the various campaigns, but this is hardly ever done. I’ve tried to use these to link to a single name page for myself, but ended up writing simple variations of my standard blurb on each and every namespace I participated in. The setup uses an interlink to link to the same help page in the main namespace from all edit pages.


I’m now feeling that NameSpace is a major tool in the fight for MassCoverageByWiki. PWiki2 has implemented it, and seems to be doing good with it. The RecentChanges for an individual NameSpace is kept seperate and distinct from it’s neighbors. I like it- I like it a whole lot. That way, neighboring topics aren’t constantly bumping up against each other. JamesMills?, the developer of PWiki2, has also expressed interest in making it so you can export a NameSpace, linking this to MobileContent ideas. That means that if you (a wiki owner) started as a NameSpace on someone else’s wiki, but then wanted to move to your own technology and server, you could do so.

I really like that MeatballWiki and CommunityWiki seem to be sharing a NameSpace. I wonder how things would have been if it had been implemented from the start of CommunityWiki - you wouldn’t have any pages in double, except maybe recent changes. Making pages in double would be discouraged - it’d be “the first wiki to talk about a subject gets the page”.

It can make it confusing as to wether MeatBall and CommunityWiki are one or two communities, but I don’t think that’s a problem.

Are there any other successful applications of a SharedNamespace? ?

I use NearLinking a lot – my homepage is near-linked to CommunitWiki? and MeatballWiki, EmacsWiki is also near-linked with CommunityWiki, etc. Don’t know whether people other than me use it, though. :)


Alex, I must be misunderstanding you. Don’t we all use (and love) NearLink?

I mean, LocalNames is based on it, even. My own blog effectively near links to CW, MB, a ton of other wiki.

For Emile: I think the idea is that we don’t necessarily want there to be just one page for every idea. We want ProductiveWikiOverlap. It is very interesting, when there is a page both here and on MeatballWiki, to look at the differences; it gives a good sense (I believe) in how we are different, and how we are similar.

Heh, that’s right. There are more Local Names users than Near Link users… :)

I shall try to put the stuff on this page in a WikiNameSpaceImage

I am not sure if I should use WikiNameSpace or simply use categories. What do people think ?

Use both, depending on what you want to achieve.

Well, I guess I should try to feed my wiki first and do maintenance and organisation when content will grow. Anyway, thank you.

On my own wiki, I used tags to organize things. I will write DatePages for my blogging, tag them, and use JournalPage?s to group them by tag, offering RSS feeds by tag, and so on. Recently I’ve been running into a problem, however: Up to half my pages are now related to games I play. I fear these confuse people that read my main feed. And often my players are only interested in “their” feed. Suddenly my setup feels a bit complicated. My dad would want to see everything except computers and games. Adrian would like to see everything except for the games he’s not involved in. That’s why I have started to move all my game stories to a separate wiki with one namespace per game. Having them all together offers no benefit: These pages do not link to other pages on my wiki. Having them separate simplifies the organization.

Define external redirect: ContextualLinking SetBasedNamespaces JournalPage JamesMills SharedNamespace CommunitWiki

EditNearLinks: MeatballWiki EmacsWiki UseMod SisterSite MoniWiki SubPages FacetWiki SubPage PeerReview WikiEngine MeatBall LinkPattern HumaneInterface PmWiki TwikiClone XmlRpcToWiki HijackingRecentChanges PageClusters


The same page elsewhere: