[pmwiki-users] Motivation for hierachy
Dr Fred C
drfredc at drfredc.com
Thu Jun 1 01:59:10 CDT 2006
John Rankin wrote:
> 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:
> 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
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
More information about the pmwiki-users