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: * Pages with lots of information on are typically unwieldy * Often words have different meanings in different domains Current solutions available: * Use long names - for instance, to distinguish by domain, could have ComputerTrees and BiologyTrees. : Advantage: No new technology needed. : Disadvantages: Very long names often result; decreases the chance of happy coincidences. * Hierarchical subpages - for instance, place all pages about BiologyScience inside that page : 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?). * Footnotes (see CocoaDev SisterSite) to make large pages easier to navigate. : 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 WikiPage''''''s, each with a WikiWord for a name, think of it as a collection of WikiWord''''''s, 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. * Firstly, what is a context? To avoid complicating the situation, a '''''context''''' is just a collection of WikiWord''''''s, equivalent to categories now. * How can we tell what context we are in when we make a link? Simple: just put every page into contexts. For example, AppleComputer could be in the contexts {OperatingSystemsManufacturer, ComputerHardwareManufacturer, MacOperatingSystem}. This is exactly as putting things in a category now. * How do we distinguish one definition of a WikiWord from another? Associate each with a unique (to that WikiWord) context that it is defined in; call this the '''''defining context''''' of the '''''specialized definition'''''. For example, we could specialize "tree" to the context {biology, mathematics} (to break with WikiName conventions momentarily); my notation for this is {biology, mathematics}"tree". '''There is currently no equivalent to this in Wiki.''' * How closely should specialized definitions be related to each other? Answer: very. Every one should list at least enough of the others to be able to traverse them all (perhaps just immediate neighbours in a poset-fashion). 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 WikiName''''''s it contains; on CocoaDev, that would be all WikiWord''''''s 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: * Problem: Discussions on WhyWikiWorks are nearing resolution, and a refactoring is proposed, but the refactorer wants to keep his work separate from the discussions while he crafts it, but still leave it open for comments in the discussions area. : Solution: Create {DocumentMode}"WhyWikiWorks" and refactor there. * Problem: MaintainingFarms has different meanings for WikiWebFarming and WikiCowFarming. : 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. * Problem: A developer has produced his own library implementing the C++ STL specifications. He wishes to add his documentation to the standard pages, since much of it will otherwise be reiteration, but he does not wish to invade the actual main pages more than necessary. : 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: * Include me with all my ancestors. Never displays any ancestor of the specialized definition without it being appended. (An ancestor is another definition whose defining context is a subset of the original's.) * Include me with all my direct ancestors. (A direct ancestor is an ancestor of a page that is not the ancestor of any other ancestor of the page.) * Include me with a specific ancestor. * Include all my children with me. Never displays a page without all its children. (A child of a page just has the page as an ancestor.) * Include all my direct children with me. How does this help us? For example: * Problem: ThreadMode and DocumentMode are too closely intertwined for the liking of many. : 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! * Problem: Someone wants to set up a fungus database with many fungi and many characteristics of each (appearance, texture, toxicity, whatever), but keep each section separate in a key-value type system (true example!) : 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 WikiLink''''''s, 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 WikiWord''''''s 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 WikiWord''''''s at all!) This would be a non-trivial extension to most current engines, because WikiWord''''''s 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