What we could do with hierarchical Wiki pages and why we should do - or why not.
See also(?): InterWiki, PagesHierarchy, FacetedClassificationInMoin
URLs, UI and subpages by subdir
If we do subpages by subdir (see StorageRefactoring/PagesAsBundles), we can change between subwikis by just changing the rootpage.
This change should be triggered by URL, e.g.:
http://wikiwikiweb.de/FrontPage gives FrontPage with rootpage="" (== using data_dir virtual root)
http://wikiwikiweb.de/SubWiki/FrontPage gives SubWiki's FrontPage with rootpage="SubWiki" (== using data_dir/pages/SubWiki as root)
Still unclear:
difference of SubWiki and SubPage when using subpage by subdir. Is there any, should there be any?
- Implications on link pattern?
- how should user interface reflect new possibilities?
Perhaps the original authour had a different problem in mind, but for me it´s mostly
- having subnetworks with easy to configure, subnetwide ACL
- having easy access to subnetworkwide search functionality
- the possibility to for some to work (and search) in many subnetworks at the same time (wiki farms do not help here)
A possibile implementation would be use SubPage functionality for this, but add the following:
- an option so that relative links are prefered:
SisterPage on ParentPage/SubPage would match ParentPage/SisterPage if it exists, otherwise it would be SisterPage under root. (I patched moinmoin for it and will probably submit the patch if someone is interested -- TobiasPolzin 2006-02-13 11:22:23)
Usage scenario
I think we should develop a complete usage scenario to see if it is good or bad.
TODO
Company Website with Different Usergroups
Suppose there are different usergroups (DeveloperGroup1, 2, 3, CustomerGroup1, 2 3) and subtopics (Customer Public Pages for Product 1, 2, 3, Internal Pages for Product 1, 2, 3). Suppose that the access of the usergroups to the subtopics is not 1:1, some teams have access to different products, internal and external pages. This could be achieved with ACL for each page but this is horrible to maintain. -- TobiasPolzin 2006-01-31 12:05:34
IRC logs
(16:26) < Fabi> I think subwikis are a bad idea
(16:29) < ThomasWal> because?
(16:33) < Fabi> It is confusing
(16:33) < Fabi> make seperated wikis if you need to
(16:33) < Fabi> or use one
(16:34) < ThomasWal> subwikis are separated almost the same way as separated ones
(16:37) < Fabi> so this is only yet another wikifarm implementation
(16:37) < Fabi> we already have this
(16:37) < Fabi> even with one process
(16:37) < ThomasWal> i am still thinking what we can get out of this as we get this for cheap
(16:38) < Fabi> have a look at twiki
(16:38) < ThomasWal> already did. they call it webs.
(16:38) < ThomasWal> one level.
(16:39) < ThomasWal> didnt see if multi levels are possible.
(16:41) < Fabi> one level already is too much IMHO
(16:41) < Fabi> creating new wiki should not be too easy
(16:42) < ThomasWal> yes, i know
(16:42) < Fabi> more levels don't make any sense, because you ahve only one root page per wiki
(16:43) < ThomasWal> ?
(16:43) < Fabi> you have to decide there the normal links point to
(16:44) < Fabi> links are absolute (relative to root page)
(16:46) < ThomasWal> the rootpage gets set early by looking at url
(16:46) < ThomasWal> so wikinames are within that wiki
(16:51) < ThomasWal> from an upperlevel wiki, referring to a subpage would maybe not change rootpage, while referring to
SameLevel:SubPage could chroot to SameLevel
(16:53) < ThomasWal> we also could use those "webs" for users and system pages, even for multilang
(16:55) < ThomasWal> one thing that annoyed me a bit on moinmoin wiki is that if you want to globally clean up, you have tons of
user homepages to look over (or skip)
(16:55) < Fabi> I would strongly vote agaist webs in the default configuration
(16:56) < Fabi> and multilang has to be network transparent or it is more or less useless
(16:57) < ThomasWal> i thought about having webs addressed like interwiki, but with precedence, so this would be maybe no problem
(16:58) < Fabi> ok, so where is the difference between subwikis and a multiconfig setup
(16:58) < ThomasWal> i think we have to make a complete usage scenario to get this clear
(16:59) < ThomasWal> currently it would be only configuration
(16:59) < Fabi> I don't like that the webs are so obvious in twiki
(16:59) < ThomasWal> subwikis would share same configuration
(17:00) < Fabi> I don't want to think about different name spaces if i enter a new wiki
(17:01) < ThomasWal> hmm, doing the same stuff without could only be some weird hack
(17:01) < ThomasWal> like, "if we dont find it here, look also in user: and systempages:"
(17:02) < ThomasWal> sort of underlay_dir stuff
(17:03) < ThomasWal> or we define subwikis as overlaying (specializing) the more general upperlevel wikis
(17:04) < ThomasWal> so we could have user accounts and system pages in main web (/) and more concrete topics in some topic: web
Discussion
I do not think that a hierarchical wiki i a good idea. It counteracts all concepts of an advanced content management. (I do not like the current subpage concept too.) What we actually should strive for instead of antique hierarchical classification schemes is sort of a FacetedClassificationInMoin; a deeply nested URL may be used then to indicate narrow the set of relevant pages.
Suppose you have the following othogonal classification system:
- group: myGroup, yourGroup
- task: taskOne, taskTwo
- level: basic, advanced, expert
Then we can narrow the set of pages we are interested in with the URL http:my.wiki.net/myGroup/expert/ we'd get an index page which list us all tasks within myGroup on expert level. This would be a generic approach to "separate" pages for different groups. -- jbusse
Okay, facets would be another possible approach. But they have to include ACL (a main aim here is to have a protected subnetwork). But as facets are not about to come soon, I will use the two patches mentioned above. -- TobiasPolzin 2006-02-13 11:52:37
It might well be that hierarchies are antique and whatever, but they have uses. I ended up using TWiki instead of moinmoin for this reason alone. Even though I find TWiki rather baroque. -- randomuser.