[pmwiki-users] Motivation for hierachy

John Rankin john.rankin at affinity.co.nz
Thu Jun 1 18:56:41 CDT 2006


On Thursday, 1 June 2006 6:59 PM, Dr Fred C <drfredc at drfredc.com> wrote:
>John Rankin wrote:
>SNIP
>> Phew! My brain hurts.
>>   
> I think you got it write with the comment that, with a proper 
>organizational foundation, there are lots of free form solutions to this 
>sort of application that would be very 'wiki-like'. Sure, there are all 
>sorts of other more elegant ways one might solve this sort of issue, but 
>most would require constant programmer tweaking to fill everyone's needs 
>-- which is very unwiki-like.  
>
>  It also seems that it would be much easier to logically as well as 
>creatively tackle (or wander into) many of these sorts of real world 
>applications if there were a notch more hierarchy to pmwiki than 
>currently exists.
>
>  It's like there are workarounds to describe most everything that one 
>might imagine existing in the three dimensional real world via some sort 
>of two dimensional pmwiki like structure.  Ditto for doing things in 
>pmwiki's limited file structure.    The workarounds are fine for those 
>familiar with how to make these things work. 
>
>The very fact that the topic of hierarchy occasionally pops up is 
>indicative that even those familiar with the workarounds realize there's 
>something missing...  Does there need to be a full blown limitless 
>hierarchy? Probably not.  However,  adding a notch or two more 
>file/group structure of some sort than currently exists in pmwiki would 
>help clarify solutions to a fair number of real world problems for a 
>wide spectrum of users.

I almost agree, but not quite... The word "workaround" is not quite
right. There are many different types of data structure in the real
world; some are best represented in a hierarchy (a bill of materials,
a chart of accounts, a book); others are best represented using
relations (consultant billing, student management, event booking).
Some are best represented using a free-form, unstructured wiki.

The excellent example you describe would, I think, be better served
using a relational model than trying to fit it into a hierarchy.
Although you may well choose to provide hierarchical navigation paths 
to the data.

The first design decision for a developer is which data structures
are appropriate for the problem. A good example is the online Oxford
English Dictionary, where they started by trying to define a relational
data model and eventually changed to a complex hierarchical data model
using SGML. Whenever one chooses an inappropriate representation,
one ends up having to create work-arounds. You are right: introducing
a work-around is a sign that one may be using the wrong representation.

Christian's question is spot on: what problems does hierarchical
groups or hierarchical pages solve? I think what we are seeing is a
range of problems which pmwiki in its current form does not
support well. This is by design. For some, a hierarchy is the 
solution; for others, a relational model; and for still others a 
page/subpage extension is all that's required. For example, the 
thread on -Talk suffix pages is an example of subpages in action.

So I come back to Christian's challenge. I think it would be
helpful to describe in detail a use case for which we assert
that the current pmwiki data model is inappropriate. The second
question becomes what data structures are appropriate for this
use case. I would not assume a priori that adding a hierarchy 
is the answer, although it may be. 

For example, a way to manage cross-references between pages
could be a small and useful recipe. Instead of saying on
page A that it's related to page B and on page B that it's
related to page A, we create a page that connects them.
Actually, this can be done with no changes to PmWiki, but
some small customisations would make it more usable.
However, that's a whole other thread...

Cheers
-- 
JR
--
John Rankin






More information about the pmwiki-users mailing list