LinkingBetweenNamespaces

MeatballWiki | RecentChanges | Random Page | Indices | Categories

On some wikis like FoxWiki and UseModWiki, there exists a concept of namespaces. On FoxWiki, the namespaces are merely sections of the wiki. On UseModWiki, they are implemented through SubPages. Compare this to the flat namespace of most wikis like WikiWiki and MeatballWiki--that is, all the names are at the same "level"; there is no hierarchy.

On the other hand, each separate wiki is its own namespace. Ultimately, the InterWiki scheme is just a namespace qualifier with a bit of magic. Really, you could easily add to the InterMap the line

: SubPage https://www.usemod.org/cgi-bin/wiki.pl?SubPage/

and then refer to SubPage:RecentChanges [1].

But this just isn't clean considering that the InterWiki namespace itself is flat and the current SubPage syntax leads to long names. So, the question arises, how can we link between separate namespaces (wikis, subpages, "namespaces" or otherwise) elegantly?

Contributors: JohnAbbe, CliffordAdams, DaveHarris, anonymous

Another nice fallout of a generic, scalable, elegant namespace system could be implementing a simple way to mirror pages on wikis with something like the InterMap file. That is, if the inter-namespace links are seamless, it is possible to move pages from one server to another. Eventually it could be done dynamically -- a wiki could offer to mirror a page (who would decide how?) and even (maybe?) offer a way to merge conflicting changes together.

Contributors: JohnAbbe, anonymous

That is an approach I'd considered, and it's one reason I don't like the InterWiki colon suffixes. I never came up with a design I liked, though. If the full path of the current page is /root/project/mainpage/subpage (in DOS/Unix directory terms), we want a nice syntax for at least:

: /root/project/mainpage/subpage/subsubpage.
: /root/project/mainpage/subpage2.
: /root/project/mainpage2/subpage.
: /root2.

which is quite a load. (In this system, each "page" would be an object that controlled the namespace below it. Some pages would be proxies for remote systems, acting like symbolic links.)

A related issue is the notion of WikiCharter?, which is the set of rules and expectations that hold sway over a particular wiki. Different wikis have different Charters (eg one may allow swearing and the other not), and you really need to be told when a link will take you into a different charter's territory. That is one reason to use colons. Although perhaps they should be inserted by the system automatically, after it has compared the reified charters of the two wikis for compatibility.

I stopped thinking about it, although I still feel this is quite an important area if Wikis are to grow and specialise seamlessly. -- DaveHarris

: ZWiki (ZWiki:RecentChanges) seems to be doing some work with hierarchical wikis. I've explicitly decided not to support hierarchies at this time. --CliffordAdams

Thank god. Simplicity is--in my humble opinion--key to WikiNature?. SubPages are complicated enough for now. ZWiki's ~infinite extensibility is too much for my brain yet.

Maybe this is just reaching for the OneBigWiki...

Technology - hierarchies - help by factoring out common context. Eg since almost every link on this wiki is to another part of the same wiki, we can get shorter names by leaving that implicit. -- DaveHarris

With hierarchies, I think you are encouraged to make a top-down organization of the graph. However, if we had written SoftSecurity as a hierarchy: SoftSecurity/CommunityExpectation, then we'd end up colouring CommunityExpectation forever with the tag "SoftSecurity." Moreover, it makes it more difficult to link directly to it. I think when you segregate the namespace like this you break the feel of interconnectedness simply because it's harder to connect pages together. That's why I asked Cliff not to turn on SubPages initially. I don't think it would be appropriate here.

As I understand it, the argument here is wholly about SubPages. The problem is "Where does the discussion go?" I suppose. I think the problem really is, "Why isn't it clear that it doesn't matter where the discussion goes, because it is linkable from anywhere?" Well, because it does matter with SubPages, because you are spatially situating it in the PageDatabase. A flat namespace doesn't force you to make spatial decisions (merely suggestions). -- SunirShah

A little bit later... Not to say that organizing content spatially is a bad thing. It's the same with choosing your LinkPattern appropriately: choose one that best fits the problem at hand. I could easily see a FaqWiki being hierarchical. A pattern/concept wiki would not. And I think the CommentingChallenge could have been better factored, personally. -- SunirShah

A flat namespace does force spatial decisions, as CommentingChallengeResponsePartTwo shows. We just have to manage the namespaces manually, with unique prefixes. That works up to a point, but there's a reason why DOS and Unix file systems have directory structures. They can be overused, but any situation where you find yourself using unique prefixes is a candidate for a namespace. CommunityExpectation doesn't fit that pattern.

The original question was about allowing refactoring; the intent is to make the system more fluid. Possibly we should be linking to something like inodes rather than page names. Whatever, a poorly-thought-out heirarchy doesn't have to be forever. At worst we can rename it and update all the links to it manually. If we have symbolic links, document inclusion etc a single subpage could be found under several root pages and be a root itself. (JargonFile:CreepingFeaturitis again.) -- DaveHarris

... if we had written SoftSecurity as a hierarchy: SoftSecurity/CommunityExpectation, then we'd end up colouring CommunityExpectation forever with the tag "SoftSecurity."

Only if the software would only allow linking to fully qualified page names. See PeriPeri (which is also mentioned further down this page) for an implementation, which doesn't need fully qualified references. Other possibilities with less complexity are sketched in AutoLinkingStrategies?.

Okay, this is bending my brain. Here's the first nibble of whatever clarity I have. SimpleDynamicMirroring? (wherever this already exists if I'm just repeating others). ComplexDynamicMirroring?, which includes linking between and within name spaces will come by text as time allows, or by phone (see CreationMatters:JohnAbbe):

What we have is in the moment transferred data. I contact you, we agree to exchange or copy (just a special case of exhange) or merge two pages. I'll call this StaticInterWiki?. What I am here exploring is what I'll call SimpleDynamicMirroring?, or just DynamicMirroring?.

With DynamicMirroring?, a wiki's owner can negotiate on an ad hoc basis to mirror a particular page (typically with the same name) with another owner. Or, set a page to be "offered" universally or to any selected list of other wikis. Any wiki (on the list for selective offerings) is then free to accept the offer and the two wikis begin mirroring that page.

When two pages are mirrored for the first time, if they both have content it is concatenated with something like two lines between them. Over time they will presumably get refactored.

At any time, either wiki-owner can end the relationship on that page.

Dynamic means for allowing the users to collectively set pages to be offered universally or selectively.

There might be a large pool of sites sharing all the pages about WikiNature? (and a small pool of the same aimed at those for hom English is a second language), and several smaller groups (each for a different computer-experience level) sharing a set of how-to wiki pages.

We can each have a personal, secure wiki, full of private notes, and "offer" individual pages of it to the family wiki, the organization wiki, the OriginalWiki, the TrainCollectingWiki, etc.

You could also mirror an entire wiki into the SubPages of a single page on another wiki.

Or host a set of SubPages on another machine on the Net. --JohnAbbe

No, I haven't solved EditConflicts yet. I don't think there can be a complete solution, so it may just be a matter of finding better and better hacks. (I'm tempted to say that I have an answer but it won't fit in the margin of this wiki to write it here :-)

But the short-term hack is just to implement redirection between wikis (already possible, right?). This requires more trust between wikis than the InterMap, of course. Mirroring seems preferable as a security feature, in my humble opinion, as many wikis will keep histories.

: The UseModWiki redirection is only local. Redirecting outside the site exposes all readers to arbitrary-HTML attacks (by redirecting to a hostile-HTML site).

Readers may think that LinkingBetweenNamespaces is just about links between two wikis. How about LinkingBetweenWikiNamespaces?. Hmm, kinda long. --JohnAbbe, scratching head...

: It sounds like an interesting idea. When will we get to see the reference implementation? :-) Seriously, a lot of people have come up with wiki-cooperation ideas, but almost none of them have happened. Even the minimal current InterWiki took some effort to come to a standard formatting convention. The issues of mirroring and redirection between wikis seem difficult, and it is hard to see the significant benefit. The wiki authors (including me) are busy with features they know they want to write, so they don't want to write features with unknown benefits.

: In a way, your idea sounds like TransClusion between wikis, possibly with a cache for efficiency. I'm rather skeptical about TransClusion, but I'm willing to be proven wrong. --CliffordAdams

That's a fine way of putting it. The coming 0.5 release of PikiePikie will have within-wiki TransClusion (using an IncludePage? command), and JSPWiki has some kind of XmlRpc thing going but i haven't checked to see if they're actually sharing content between wikis yet. --JohnAbbe

I'm relatively new to the world of Wikis, so I'm just starting to think about these problems and I may be wrong. But: I don't think that current interwiki-linking, namespaces or subpages do solve the problems (as I see them).

First: Lets assume the Wiki idea gains popularity and the overall Wiki space (# of Wiki pages) grows by a factor of 10-100. Some Wikis will grow in size and will need some partitioning. Many more Wikis will come into existance. How many homepages will a user have to create, how many RecentChanges pages will a user have to check daily. Different user interfaces and text formatting rules won't make life easier. Information will be redundant in different Wikis (e.g. book descriptions).

Second: I come from Austria. This country is relatively small (8 million) and has a good public school system. It would be a nice thing to create one single Austrian SchoolWiki? for all teachers and pupils (on the other hand to have a Wiki for each and every school would be an inefficient nightmare). One could build helpful features (e.g. automatic multiple choice tests) into the system. But: one must be able to support 1E4-1E6 pages, a flat namespace partitioning system (Geography, English, Chemistry, ...), a general global namespace (for books, homepages, general information), and a system to qualify the level (or difficulty) of pages. A teacher should be able to restrict his focus to certain parts of the pagespace (Geography+English, level 5-8) to see only those RecentChanges or those pages he is interested in. If the same page exists in multiple namespaces, link resolution ("see also:") should be automatic. So, it seems there might be a need for a title index ("title+subspace"). Full title search, full text search should still work efficiently (need of inverse index). Might look a bit complicated, but could be a guiding vision, where we are heading to.

Just a few thoughts.

--HelmutLeitner

: Thank you for an interesting vision of future Wiki features. I intend for UseModWiki to handle about 20,000 to 30,000 page wikis in its current form (plus some improvements for full-text search). With a mod_perl (persistent script) implementation and a simple relational-database backend it might handle up to 100,000 pages. Beyond that level I expect that a full redesign will be needed. My initial goals are to make UseModWiki very simple to use for small to medium-scale wikis.

: Many of the scaling and inter-site problems are not new ones--they are also problems for existing WWW systems. Wikis don't solve all problems--they make some things easy (like updating or fixing pages), but they also introduce new problems.

: I want to avoid the "Curse of Xanadu" (XanaduProject), of trying to design the "perfect" system but never deploying even a workable prototype. My code is unlikely to be perfect, but it has the distinct advantage of being usable. My inspirations are the gradual evolutions of many successful Internet systems like UseNet and the HTTP servers. In these cases people often extended the prior software as much as possible before doing a full redesign and reimplementation. Often the new implementation greatly benefits from the lessons learned by the prior implementation.

: For me personally, ViewPoint is my guiding vision. (Wikis are simply a good way of building a community until it is large enough for a ViewPoint system. :-) To make that goal reachable I have decided to simplify many aspects of the design, by choices like not implementing transclusion, authorship tracking, or complex inter-site behavior. Even with that simplification, I don't expect to have a usable ViewPoint prototype before late 2001. (I hope to finish UseModWiki 1.0 before starting ViewPoint as a separate project.)

: On the other hand, I'm very willing to work with people who have other goals for wikis. I'm especially open to adding simple options (as long as they don't greatly affect people who don't use them). For major changes I'm willing to give advice, but I think that large changes would be better as a separate wiki project. --CliffordAdams

I think, even if everything works out perfectly, it will take us 2-3 years to outgrow the current UseMod framework. I feel commited to simplicity. German users need simplicity even more, because they usually lack the usenet background (and they happen to think more complicated). I still have to read more about your ViewPoint project, but at first sight it doesn't have the "communication and cooperation" appeal of the WikiWikiWeb.

Another means of providing arbitrary namespaces is set facets (see UbikWiki). Whether this design is good or bad has yet to be discussed in any great detail: check it out and decide for yourself! A quick set of features: it allows arbitrary depths of namespaces, does not require the "/" notation of SubPages, and avoids hierarchy. OTOH, it still lacks a completely general way of crossing namespaces, and has by no means been tested on a real live Wiki (just a prototype).

A less strict way is provided by Shatter facets (see PeriPeri). This algorithm is flexible enough to be added onto pretty much anything - see for example UseMod:WikiPatches/PeriPerify.

: Can you explain how this works from a user perspective? I've read the math-oriented explanations, but I can't imagine the benefits. -- AlexSchroeder

: Suppose you want FarmTools to mean different things in the WikiWebFarming category than the PigFarming one. Create a FarmTools stream (subpage) called WikiWebFarming and the Shatter algorithm will link things up properly for you.

: Most of the math is actually for if you have lots of such streams: it totally disambiguates which one to pick.

: -- ChrisPurcell

Sounds interesting -- carrying the SubPages idea a significant step further, perhaps even allowing a ViewPoint-like system to be built. From a usability perspective, how would a user know what to expect? Or does the system assume that the user does not know how many alternate versions of the page exist? If the choice was always clear to the system, how would the user experience differ from a set of different wikis, perhaps interlinked via inter-wiki links? Is it possible to produce a list of recent changes for such a wiki such that the output makes sense? -- AlexSchroeder

The effect is something like InterWiki, actually - you are carried seamlessly between categories unless the category you are in has Shattered the page you're linking to, in which case you will be seamlessly kept within the category. Since the recent changes format is exactly what is used for UseMod, eg FarmTools/WikiWebFarming, yes, the recent changes makes sense.

Possibly the strangest thing about the patch's implementation of the Shatter algorithm is that FarmTools/WikiWebFarming seems backwards, but that's because the Shatter algorithm is definitively not hierarchic, and hierarchy is what subpages suggest -- ChrisPurcell

LinkingBetweenNamespaces

Discussion