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.
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 same technologies make it easier to split a topic into a new wiki. See InterWiki for more about seamless integration of various wikis.
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.
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.
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.
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?.
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.
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.
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”.
Are there any other successful applications of a SharedNamespace? ?
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 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.
EditNearLinks: PeerReview XmlRpcToWiki MoniWiki SubPages HijackingRecentChanges MeatBall FacetWiki SubPage EmacsWiki JamesMills SisterSite PmWiki WikiEngine UseMod PageClusters TwikiClone HumaneInterface LinkPattern MeatballWiki