[pmwiki-users] Motivation for hierachy

[John Rankin]

On Tuesday, 30 May 2006 6:24 AM, Dr Fred C <drfredc at drfredc.com> wrote:
> John Rankin wrote:
><snip> 
>
>I'd like to note an additional workaround: subpages.
>This has the wholly pragmatic benefit that it can be
>added to pmwiki in about 10 lines of php and nothing 
>breaks. It defines [[,subpage]] markup.
>
>*It is not a hierarchy, but in some cases it may be 
>all that's needed.*
>
>On page LocalElementary.TeacherJones the markup 
>[[,StudentBobbySmith]] generates a link to the page
>LocalElementary.TeacherJones,StudentBobbySmith
>
>This page becomes a subpage of LocalElementary.TeacherJones
>
>On the subpage, a reference to [[,StudentJaneGrey]]
>generates a link to the page
>LocalElementary.TeacherJones,StudentJaneGrey
>
><snip>
>
>Or schools
>
>LocalElementary/TeacherJones/StudentBobbySmith  
>
>Exactly how many more examples do you need? 
>    
>
>
>Wouldn't subpages help in all the examples given and be
>sufficient in 4 of the 5? 
>  
> Subpages might work fine for many applications with some
>savings in code and parsing.  Perhaps it's a good place to
>start.
>
> That being said, I'm not entirely sure from an enduser
>perspective how subpages differs from having a hierarchy. 
>
> For example, would StudentBobby's subpage be able to have its
>own set of private subsubpages that might comprise Bobby's
>various projects, quizes, and homework over the year? 
>
>LocalElementary.TeacherJones,StudentBobbySmith,ReportCard
>LocalElementary.TeacherJones,StudentBobbySmith,Homework,Widgets 
>LocalElementary.TeacherJones,StudentBobbySmith,Homework,DoFunnys 
>LocalElementary.TeacherJones,StudentBobbySmith,Quiz,Widgets 
>
>Hmmm...  would something like this structure work better?
>
>LocalElementary,TeacherJones,StudentBobbySmith.Quiz,Widgets 

As I understand the way other wikis have implemented subpages,
they are a special case of hierarchical pages with one level
of nesting. That is, most wikis that support subpages let you
have pages of the form (syntax varies from wiki to wiki):

    Group.Page,Subpage

But not

    Group.Page,Subpage,Subsubpage

I am not at all clear when one would use subgroups versus
when one would use subpages. That is:

    Group,Subgroup.Page implies 1 wiki page

    Group.Page,Subpage implies 2 wiki pages

As I understand it, the primary motivation for introducing
subpages is to "disambiguate" page names. There are 2 cases:
1. association -- the subpage is associated with its parent
   in some semantically meaningful way (BobbySmith,Hobbies
   and JennyJones,Hobbies)
2. same name, different meaning -- Mercury,Planet and
   Mercury,Element and Mercury,God

For example, in the Cookbook group, one might allow every
page to have a [[,WikiSandbox]] -- a separate sandbox for
each recipe.

If you like, subpages are the simplest possible form of
/page/ hierarchy one can introduce. 

There is probably a complementary option of "subgroups" 
being the simplest form of /group/ hierarchy one can 
introduce, yielding pages of the form Group,Subgroup.Page. 
I am not at all clear how this might work from a user 
perspective, however. For example, what markup extensions 
are implied? What is the subgroup equivalent of [[,subpage]] 
markup and how does it behave?


>
>It would seem upon reflection, the second option might work
>better as it would seem to get Bobby his own private "group" to
>work with.  I'm not sure how such a change would be for
>TeacherJones to organize and manage her students, but I suppose
>it could be done easily enough with a search of some sort. 

I suspect that both TeacherJones and StudentSmith will need
their own private groups! 
>
>Which points out how this sort of end-user stuff tends to
>evolve from simple to more robust applications.  There would
>seem to be a need for good documentation of how to properly
>organize utilize these new data structures and powers plus
>developing some sort of file management utilities to sort out
>the inevitable messes endusers and admins will make of things
>as they get started on using these new found powers.  
>
>Many users (and admins) may quickly find their wiki getting all
>mucking up with a need to rename files to keep the proper data
>structures.  As part of this, there would also be a need to
>(attempt) track down and fix lost links created by any file
>name changes. 
>
>Then there's this sort of problem -- suppose TeacherJones gets
>replaced by TeacherMacDonald halfway thru the year?). 
>
>LocalElementary,TeacherJones,StudentBobbySmith.Quiz,Widgets
>somehow needs to get seamlessly changed to
>LocalElementary,TeacherMacDonald,StudentBobbySmith.Quiz,Widgets
> 
>
>Perhaps upon further reflection, the organization might better
>be 
>
>LocalElementary,StudentBobbySmith.TeacherJones,Quiz,Widgets? 
>LocalElementary,StudentBobbySmith.TeacherMacDonald,Quiz,Dofunnys?
>
>
>It would be nice, but unrealistic, to think that all data
>(group, subgroup, etc) structures will be created properly the
>first implementation.  I'd like to retire next week, but that
>ain't happening either...  

The problem here, I think, is that the data structures lend
themselves more naturally to a set of relations, rather than
to a hierarchy. One perhaps needs a group for each distinct
entity, plus groups for each association between entities.
For example:

Schools
Teachers
Students
Enrolments (student at school)
Classes (teacher of student)

and so on. Once the structure of the data is clarified,
how to represent it in a wiki (or indeed whether a wiki is
the most appropriate tool) should also become clearer.
I think it's fair to say that one of the reasons relational
databases took over from hierarchical and network databases
is that they are inherently more flexible in the sorts of
data they can represent.

In this example, it's not obvious to me that the data fit 
either the wiki's group.page structure or a hierarchy.
But a starting point using a wiki might be: establish a
group for each "real world" object, like Student, Teacher,
Course. Then establish a group for each association
between these real world objects.

This seems to have wandered a long way from hierarchies...

><snip>

-- 
JR
--
John Rankin