Wiki hierarchical table of contents

Presentation edit

The zwiki implementation of wiki has a nice structuring feature (see the discussion of this feature at the zwiki site [1] ([2] doesn't work) and an example at the Zope site [3]). This structuring feature allows parent and child relationships to be modified on the backlinks page. Each reference to a page are listed with checkboxes. A checked checkbox indicates the page is actually a parent. The page from which another page is created is by default a parent. This default can be overridden by toggling the checkboxes on the backlinks page

Here is a simple version of this concept for Wikit where all the references to a page treated as a parent and the parentage cannot be changed. The following code uses the graph struct from tcllib:

 # Returns a graph containing the wiki page ids as nodes with
 # arcs connecting parent nodes to child nodes
 proc wikiRefsToGraph {} {
    set graph [graph]

    # Add each nonempty page to the graph (empty pages have date of 0)
    foreach pageId [mk::select doc.pages -min date 1] {
       if {![$graph node exists $pageId]} {
           $graph node insert $pageId
           }
       set refs [mk::get doc.pages!$pageId refs]
       foreach ref $refs {
           if {![$graph node exists $ref]} {
               $graph node insert $ref
               }
           $graph arc insert $ref $pageId
           }
       }
    return $graph
    }

 # Returns an html tree form of the given graph beginning with 
 # the optionally given node id as the root.  A node's children
 # are only displayed the first time the node is encountered.
 # After that "..." is appended to the node name
 proc getHtmlTreeFromGraph {graph {node 0}} {
    global visitedNodes
    puts -nonewline "<li>[Wiki - $node.html]"
    if {[lsearch $visitedNodes $node] < 0} {
       if {[$graph node degree -out $node] > 0} {
            puts <ul>
            }
        puts ""
        lappend visitedNodes $node
        foreach child [$graph nodes -out $node] {
            getHtmlTreeFromGraph $graph $child
            }
       if {[$graph node degree -out $node] > 0} {
            puts </ul>
            }
       } elseif {[$graph node degree -out $node] > 0} {
       puts "..."
       } else {
       puts ""
       }
    }

Here is an example use of this code:

 package require graph
 namespace import ::struct::graph::*
 set visitedNodes ""
 getHtmlTreeFromGraph [wikiRefsToGraph]

Comments edit

RA2 I agree with you 200%, Brian. ZWiki is in my view the best wiki of them all, for it creates hierarchical contents we are all used to. Without a hierarchy of some kind, a wiki ends up being well.. let's not be afraid of words...: a mess.

Zwiki is a more or less a wiki outliner.

I never thought the backlinks concept (invented by Stan Silver at C2.com) was a hot invention. Of course the backlinks concept is far-out when there is nothing else around! It is better than nothing so we settle for it, the same way we'd settle for an ugly girl until a gorgeous one shows up. All in all, outlines make much more sense! And this is what Zwiki does: it is a wiki outline.

I believe that when an information is structured, it adds value to itself. To the opposite, when an information is not structured, it is worthless. In this regard, your tkoutline is marvellous because it is very structured!

I'd love to try your code if only it could be inserted in a script of some kind.

RA2 I have a good idea for you. Take tkoutline, modify the code and make it a wiki. And you'll have a winner. If you need details, put the questions on my homepage and I'll explain! [unperson]

DDG May be my nwikit clone would be a good choice although it currently only makes simple hierarchies (all wiki links on the home page wich are in a list are used). Adding one level more would be an easy task. See: http://goblet.molgen.mpg.de/nwikit

[unperson] Very interesting, Detlev!

It would be interesting if you could have a look at Zope Wiki in action somewhere. You enter a site, you have a quick look at the outline and right away you know what the site is about, you see the articulations, the structure.

I was very interested in wiki's hierarchical table of contents and I have studied Wiki's hierarchies inside out and outside in for a long time a few years ago. To my knowledge, there are four types of hierarchies in all wikis:

* The Zope outline (well described by Brian above)

* The slash concept in Usemod; when you create a link with a /, the page where the link is created becomes the father link and the pages created its children. Ex: In a page called Animals, you create a new link: /Ostriches. Another page: /Lions. Your pages will be shown this way in Recent changes. Animals/Ostriches; Animals/Lions. Very useful feature!

* The father/child concept in Yet Another wiki; pretty complex

* Dave Parker's strange concept of compound words: AnimalsBirdOstriches will make the 2 links (Animals and Birds) appear on top of the Ostriches page. Not a bad idea! I was suggesting something else to Dave and this is what he understood! Great concepts have been invented this way, through misinterpretations! :-)

* The Austrian's guy (I forgot his name) concept of key pages. Links are written on a key page. Ex: A key page called Animals would contain the Ostrich, Lion, etc. links. He has a list of key pages. I'll try to get the address of his wiki.

I don't consider the Category System (invented at C2.com) a hierarchical table of contents. It is a sort of indication at the bottom of a card indicating where the card belongs.

Of course no one minds the lack of hierarchy in wikis (since we all more or less spend our time peeping Recent Changes) but for serious contents, one needs an outline, a structure.

If you could put your wiki online, we could test the hierarchy.

DDG http://goblet.molgen.mpg.de/cgi-bin/wiki/public/eurotcl2006-test.cgi/0

you can edit this to test the outline. Currently nested outlines are missing but they should be easy to implement. Please read the nwikit-article for the supported markup as well. I would see, with an true hierarchical outline a wiki becomes a true website.

CMcC thinks there's just one small problem with this: a Wiki is a directed graph of pages, and general digraphs aren't hierarchies. Of course, you can always put a spanning tree over a digraph by deleting some links (ie: destroying information.) In view of the nature of destroying information on a Wiki in order to make it more navigable, I would like to suggest a name for the links so formed: goosesteps.

[JF] Actually, destroying information to make it more useful is exactly the goal of Wiki. All of the information on Wiki already existed. It was just disorganized and distributed. Wiki eschews the less imortant information so that what remains can be ingested.

[unperson] Digraph? What is that?

Colin, a real manageable content management systems is not made of hundreds and hundreds of independent pages linked together with a vague category system; to the contrary, it is made of pages linked together in a hierarchical structure called an outline.

Say what you will about the non-necessity of outlines, but I can tell you from my own experience that organization is key. Disorganized people end up being complete failures and their projects end up in the garbage. I have yet to see one successful (and happy) disorganized person.

I have spent hours and hours working on the organization of just about every project I have worked on and I have never regretted wasting one hour of my time on this task. Each hour used on organization saves 100 hours of mess, headaches, heartaches, crying, conflicts afterwards.

At 23 I spent 3-4 months literally searching for a simple way to write addresses so that I didn't have to carry ten boxes of index cards. I persisted and I found the solution. The system that ensued has saved me time and effort.

I have always thought that wikis are in fact collections of simple electronic index cards. It works well that way; the system fits the purpose. Surely! But I fail to see how 10, 20 writers writing a book together could produce some serious work working this way with a wiki.

I was never able to write with index cards much less with electronic index cards.

Outlines are a great tool used by serious writers.

Detlef, I'll be testing your outline wiki in a second. I have. Indeed the outline could simply be put on Home page or on start page; all links would have to stem from that page et voila! There is your outline!

A nice possible enhancement: start page occupies the left of the screen. We click on a file and it appears on the right of the screen.

No need to create an outline automatically. We could simply type in the numbers: 1, 2 and the letters a), b) etc.

DDG You fink of something like a `outline´ node where we write down the hierarchy like nested list ?

DDG In fact a wiki per se is a digraph - one child can have many parents - a tcl documentation page can be the child of a tcl parent and a documentation parent, but you can use a hierarchy as well on it if you restrict yourself to a certain degree or level of hierarchy. So if you use a wiki more like a content managment system with a limited amount of confidential writers, you can use a hierarchy of information on it. This Wiki here is certainly a digraph, but you could generate a very large hierarchy on it, where each child might appear several times in the tree. I have this same phenomen of "gene ontology" terms http://www.geneontology.org

. To avoid endless loops however you must restrict the hierarchy level to a certain degrees, becomes child-parent relationships might be reversed on a page.

Category Wikit

Category Package