Wiki Multiple Definitions

The following has developed into the FacetWiki project; I have left it here for now because it contains ideas not yet spiked. -- Chris Purcell (KritTer)

I have been working on an extension to the Wiki concept to solve issues arising from the single flat namespace, and other issues:

Current solutions available:
Advantage: No new technology needed.
Disadvantages: Very long names often result; decreases the chance of happy coincidences.
Advantages: clear relationship between pages; no pollution of global namespace; short reference forms.
Disadvantages: must be very organized to use correctly (where would I put a page about computers *and* biology?).
Disadvantages: can get very big pages that are hard to maintain.

Let us approach the problem by temporarily looking at WikiWiki in a different light from the norm. Instead of thinking of a Wiki as a collection of WikiPages, each with a WikiWord for a name, think of it as a collection of WikiWords, each with a definition (which consists of both a WikiPage and an EditPage). What might help is a way of having multiple definitions of the same WikiWord in different contexts, so pages can link to the definition most appropriate to their content.

Determining which page a link should point to is just a simple application of set theory. [To be specific, if A is the context the starting page is in, B the set of contexts the target is specialized in, then the page targeted is N{C in B | C contains An(UB)} whenever that is a member of B, where n is intersection, N is intersection of members, and U is union of members. Do excuse the poor ASCII set notation!]

This fits very easily into different Wiki formats. On sites that already have categories in use, the context of a page is just the categories it is in: on this site, that would just be all the WikiNames it contains; on CocoaDev, that would be all WikiWords following a %%BEGINENTRY%% directive. (The former is much more Wiki-like, but more susceptible to accident.) With a little help, it can also provide very neat solutions to both the problems I gave above, but first here are a couple of scenarios and how the above can be used in them:

Solution: Create {DocumentMode}"WhyWikiWorks" and refactor there.
Solution: Create {WikiWebFarming?}"MaintainingFarms?" and {WikiCowFarming?}"MaintainingFarms?". Users browsing from WikiWebFarming? pages will find the former, WikiCowFarming? users the latter, with conflicts resolved by priority.
Solution: Create a main page for the library, and define specializations of all the STL pages in its related category. Each of these pages will correctly link to each other, but the standard pages will be unaffected except for a mention of the new specialization in their headers.

Specialized definitions fit very neatly with inclusions, because a small bunch of inclusions between specialized definitions of the same page cover a lot of scenarios. A definition can be included in another definition of the same word (displayed with it) by the following:

How does this help us? For example:

Solution: When someone wants to comment on a page, they can just specialize to the context {ThreadMode} and direct that page to include itself in the original page, now an ancestor of it. The original page is not touched, it just sprouts a comments section. When someone wants to refactor a long discussion, they can set up a similar situation, by moving the original page to the defining context {ThreadMode} and creating a new one for the refactoring. Bingo!
Solution: On the main page for each fungus, tell it to include all its (direct) children with it, and create specialized definitions for each characteristic. The main page will now provide a neatly-sectioned description of the fungus.

Whether or not one can explicitly link to specialized definitions that a page would otherwise be in the wrong context to join to is up to the Wiki developer, as is exactly how contexts are defined (plain WikiLinks, explicit formatting tags, metadata, or whatever) and what to do when the link is not well-defined (list all available definitions, or just the ones 'closest' to the originating context, however that is interpreted). Since the WikiLink notation can be entirely unaffected by the addition of specialization, existing sites can be extended without fear of breaking existing content, unlike subpages which may affect fragments like /Page.

A sufficiently well-formed approach to implementing this functionality can also be used as an alternative to redirections. One simply allows two definitions of two different WikiWords to be identified, such that only one definition is actually used. Page misnamed? Just rename it. Want to use a word in both singular and plural forms? Use the same definition for both. (Optionally: want to delete a page? Just stop it being a definition of any WikiWords at all!)

This would be a non-trivial extension to most current engines, because WikiWords and definitions would need to be totally decoupled, but it might prove useful, too.

One goal with these extensions is to make implementing a dictionary with the Wiki paradigm seamless, and I feel they manage that. How would one define "jumped"? Perhaps simultaneously as "jumped" and {past perfect}"to jump" (to abuse the WikiWord format), with a forced inclusion of all direct children in "to jump" making a seamless entry for that word of all its various forms. Or perhaps a single entry, identifying "to jump", "jumped", "jumping", and all other forms of the word.

Comments about previous revision of this page

To make sure I'm understanding: this would (potentially) work by looking at the referring WikiPage for the desired context? This would have the advantage over hierarchical namespaces of not having to type (in Java package-style syntax, begging forgiveness) page.biology.tree or page.mathematics.tree, but the user would still end up at the appropriate page (with links to the others so the Wiki's apparent ad-hockery doesn't end up biting the user). Am I getting this right?

How would this work for those of us who are used to typing http://www.myfavouritewiki.com/index.pl?DesiredPage in our browser's address bar?

This (of course) doesn't address the (also frequent?) problem of multiple declarations and one definition; e.g. pages like WikiWord which merely point to the plural. It might be beneficial to look at abstracting traditional wiki just a bit further. The disadvantage to doing so being that you're probably going to lose the beauty and simplicity of the system as it currently exists. (Perhaps this paragraph should be refactored to a WikiMultipleDeclarations? page.)

-- RobRix

Yes, that is the correct notion. The address you gave would still work, at least in my current theoretical implementation, and would link to the general page rather than a redefinition. Finally, multiple names for one definition has been pretty much solved by other means that do seem to mesh reasonably well with Wikis - like creating a redirection.

-- Chris Purcell (KritTer)

The idea of inclusions fits very naturally, as has RobRix's suggestion, despite my initial disinclination. I have updated this page accordingly.

-- Chris Purcell (KritTer)

CategoryWiki | WikiOnWiki

EditText of this page (last edited November 15, 2004) or FindPage with title or text search