[pmwiki-users] Motivation for hierachy

[Dr Fred C]

John Rankin wrote:
SNIP

> Finally, for the sake of completeness, it seems reasonable
>that Joe and Judy might want to work at the same time on
>different parts of their report and Judy decides to break their
>project down into smaller "pages".  A possible (and reasonable)
>structure for this might be something like:
> JudyWren.History,Dueling,Background 
> JoeEagle.History,Dueling,AaronBurr  
> JudyWren.History,Dueling,AlexanderHamilton
> JoeEagle.History,Dueling,Conclusion 
>
> with JudyWren.History,Dueling being the "home page" that
>collates via (:include<page>:) the report into a single place. 
>Presumably, the same collaborative password would work for
>these additional pages without much issue.   


> The above example is the gorilla -- the real world just
> doesn't fit into nice, tidy structures like hierarchies and
> relations. People will want to create all sorts of pages for
> all sorts of reasons, and expecting them to follow a fixed
> and rigorous page naming convention seems somehow anti-wiki. 
> Hence my comment that I'm not convinced this is a good idea.
>
> So you might have a whole lot of supplementary groups outside 
> the formal structure -- Joe and Judy set up a group for their 
> project and links to it from the appropriate points in the 
> relational part of the wiki. Then they can use group security 
> to control access.
>
> The wiki would divide into 2 parts: a structured part that
> implements a relational model of those parts of the problem
> space best represented by relations; and an unstructured
> part that is organic, free-form and ... um ... wiki-like.
>
> The first step would be to create a relational model of the
> data structures you want to represent.
>
> 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.

-- 
Always, Dr Fred Chittenden