<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
John Rankin wrote:
<blockquote cite="mid1084436564john.rankin@affinity.co.nz" type="cite">
<pre wrap="">On Wednesday, 31 May 2006 5:17 AM, Dr Fred C <a class="moz-txt-link-rfc2396E" href="mailto:drfredc@verizon.net"><drfredc@verizon.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">John Rankin wrote:
<snip, snip, snip> 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...
You've done a reasonable job of explaining some of the ins and
outs of various data structures that wikis might and might not
use.
As a point of reference, after a bit of checking, our local
schools use the following internet file structure :
<School>/<Student>/<Class>/ReportCard
</pre>
</blockquote>
<pre wrap=""><!---->
Ah. They are using a hierarchy as a *presentation* method, not
necessarily as a *structural* method. This suggests the following
possible approach:
- set up "natural" wiki groups for entities like Student with
pages like Student.JennyWren with a way to resolve duplicate
names -- eg an ID number rather than a name, with the name as
(:title:)
- perhaps use subpages for Student.JennyWren,Spanish
- or a StudentCourses group, with pages (relational data model)
StudentCourses.JennyWrenSpanish
</pre>
</blockquote>
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. <br>
<br>
If there were even just one more pmwiki level
<group><subgroup><subgroup,subpage> things would
seem to get easier to handle. For example, <br>
<br>
<School>.<student>.<class>.<classpages> might
be handled by<br>
School wikiFarm/<student>.<class>.<classsubpages><br>
Or put into application -- JudysSchool (a wikiFarm) there would be
JudyWren.History.Dueling<br>
<br>
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. <br>
<br>
However, if I understand your subgroup concept, an optional structure
to the above example using subgroups might be - <br>
JudyWren.History,Dueling?<br>
<br>
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? <br>
<br>
<John Rankin wrote> "Implementatiuon details, such as password
control on a per-student<br>
<pre wrap="">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 <span class="moz-smiley-s1"><span> :-) </span></span>"</pre>
<br>
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. <br>
<br>
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: <br>
<br>
JudyWren.History,Dueling,Background <br>
JoeEagle.History,Dueling,AaronBurr <br>
JudyWren.History,Dueling,AlexanderHamilton<br>
JoeEagle.History,Dueling,Conclusion <br>
<br>
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.
<pre class="moz-signature" cols="72">--
Always, Dr Fred Chittenden
</pre>
</body>
</html>