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
and then refer to SubPage:RecentChanges .
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:
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
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.
Readers may think that LinkingBetweenNamespaces is just about links between two wikis. How about LinkingBetweenWikiNamespaces?. Hmm, kinda long. --JohnAbbe, scratching head...
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.
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.
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