[pmwiki-users] Motivation for hierachy

[John Rankin]

On Thursday, 1 June 2006 5:56 AM, Dr Fred C <drfredc at drfredc.com> wrote:
> John Rankin wrote:
><snip>

> While, you've displayed a reasonable means to visualize and
>structure a pmwiki solution to this real world (non-wiki)
>application, it also seems that much of the solution is
>somewhat a "work around" to avoid adding at least one more
>hierarchical dimension to pmwiki's structure.

I'm more questioning whether a wiki is the right tool to use
for this particular problem, with or without the addition of
a hierarchy. The problem you describe lends itself most
naturally, I think, to an underlying relational data model,
not a hierarchical data model. One may well then choose to
provide various hierarchical navigation paths to the data.

With a relational structure underneath, you can serve
up whatever views of the data may be needed.

Could this be implemented using a wiki? I'm not sure; let's
think about it...

1. assume a normalised relational model of the data exists

2. every relational table becomes a wiki group

3. every page gets named after the table's primary key
   values

4. where the primary key is multi-column, we need a method 
   to take apart the page name into its constituent parts
   and link the parts back to their referring pages

   this could be done using a comma separator, eg

   Student.James (page James in the Student group)

   Course.Fencing (page Fencing in the Course group)

   Student,Course.James,Fencing (page James,Fencing in
                   the Student,Course group)

   We interpret this to mean the relation that ties
   Student.James to Course.Fencing

5. notice that we use the structure of the page name to
   show a relation, not to represent a hierarchy

6. a piece of code might automatically display links on
   the Student,Course.James,Fencing page to the
   Student.James and Course.Fencing pages

You know, I think this could be made to work; I'm not
sure that it's a good idea, but it might work.

Perhaps the thread ought to be renamed to

   "motivation for a relational model"
>
> If there were even just one more pmwiki
>level<group><subgroup><subgroup,subpage>   things would seem to
>get easier to handle.  For example,
>
><School>.<student>.<class>.<classpages> might be handled by
> School wikiFarm/<student>.<class>.<classsubpages>
> Or put into application -- JudysSchool (a wikiFarm) there
>would be JudyWren.History.Dueling
>
> In other words, one uses wiki Farms as the top hierarchical
>layer as Judy only attends (is associated with) one school at a
>time. In the above example, Judy has History as an additional
>hierarchical group under her name.
>
> However, if I understand your subgroup concept, an optional
>structure to the above example using subgroups might be -
> JudyWren.History,Dueling?

No, I'm saying forget hierarchies *for this example*; instead
treat pages of the form A,B,C.X1,Y2,Z3 as implying links to
pages A.X1, B.Y2, C.Z3 -- you don't need a farm, you just need
a group for every table in your relational model and a convention
for how to interpret compound page names.

But there is an ugly gorilla in the corner of this nice tidy room...
>
> Am I correct in assuming that Judy could assign (and share) a
>password to her History,Dueling report so that her classmate
>Joe Eagle could collaborate on a Dueling paper stored under her
>name without giving Joe access to anything more than the
>Dueling report?  Or is creating nested passwords for this sort
>of individual page part of the issue you allude to below? 

It depends on whether you want to model reports inside the
relational structure or not. If there is a 
Course,Report,Student.History,Duelling,Judy page then yes,
Judy would assign a password to that page. On the other hand,
you could choose to exclude these from the structue and let
Judy create and control a JudyDuellingPaper group and link to
it from Course,Student.History,Judy -- either way would work.
>
><John Rankin wrote> "Implementatiuon details, such as password
>control on a per-student
>
>basis (my page and its sub pages) are non-trivial, but could, I
>think, be resolved. You would need to load Group.Page.php (with a
>student password) for all subpages of Group.Page -- that could be
>done. An exercise for the reader  :-) "
>
> BTW, one would assume that Joe might put something like
>(:include JudyWren.History.Dueling:) in his
>JoeEagle.History,Dueling page to allow for a relatively
>seemless connection to their collaborative report, at least
>from a (parent) reader's perspective.  It would seem Joe would
>need have to have an alternate path of some sort to actually
>open the JudyWren.History,Dueling for editing. 
>
> 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.
-- 
JR
--
John Rankin