This page serves to collect proposals for establishing group hierarchies in PmWiki.
Intuition and analogies
This is an important aspect: PmWiki's philosophy mandates that its mechanisms should be intuitive, even to newcomers.
The most important consequence is that group and page names should mimick some well-known hierarchical structure, such as a filesystem hierarchy or the chapters and subchapter numbers of a book. The problem with chapter number syntax is that it doesn't differentiate between absolute and relative paths, i.e. writing "section 3.4.7" doesn't say whether it's chapter 3.4.7 as seen from the table of contents, or if it's subsection 3.4.7 of the current section - this must be established from the context. This leaves us with filesystem naming schemes as the primary analogy for a hierarchy.
Even the filesystem analogy isn't fully powerful enough. In a wiki, any hierarchical name should refer to both a page, as well as to the group of pages that are "below" that page. This is different from filesystems, where a name is either a directory or a file.
To make the problem explicit, let's assume that a name in a filesystem is both a file and a directory. Now if we assume it's a file, we intuitively assume that the current directory is the name's parent. If we assume it's a directory, we assume that itself is the current directory.
In other words, we have conflicting intuitions about what the current directory in such a file system would be. We need to decide for one of these intuitions, and give plenty of examples to counteract the wrong intuition. (It would be interesting to hear how the Reiser people handle the situation. Their file system is in exactly the same situation.)
There would be another way to avoid these conflicting intuitions: stick with filesystem semantics and mandate that a name can be either a directory (group) or a file (page), but not both. However, this is considered against Wiki principles: if something starts life as a page and has to be turned into a group later, this should be easy. In particular, if some other pages had a link to the page, and that page is turned into a group later, the link breaks - i.e. restructuring the wiki suddenly becomes a hard operation.
Relative links are invariant
Moving an entire group of pages from one place to another in the group hierarchy should leave any relative links within the group functional.
Links to sibling pages are the simplest case
The reasons for this are:
This page assumes the following groups and pages:
Kingdom +-Plant | +-Grass +-Animal +-Canine | +-Terrier +-Feline +-Cat
Unless noted otherwise,
Concrete syntax proposals
Any proposals should use the following template.
In the path components section, fill in syntax for the components of a path name. Path names should be constructed by starting with one of the "start" components, followed by an arbitrary number of the other components. In the special rules section, write up any additional rules that may hold for forming a path name.
The examples section is just for establishing how the links would look like in practice. Assume you're on page Canine, and apply the rules from the first sections to get to the listed target pages.
Hint: Try this order when filling out the template:
Here's the template:
Chapter numbering analogy
It's quite likely that syntax for a group hierarchy will be incompatible with PmWiki's current internal link syntax. However, since it's unclear what the incompatibilities will be and whether there's still a way around them, the current stance is to ignore this problem and concentrate on a syntax that's intuitive for the time being.
Quote: The most important consequence is that group and page names should mimick filesystem directory and file names.
I would agree with the analogy so long as you also carry forward the metaphor with hard and soft symlinks, virtual directories and inhertience.
The filesystem analogy serves to give non-geeks a chance to understand hierarchy as such. Properties of objects inside the hierarchy can be handled orthogonally to the way that hierarchy is established, so I don't think that we need to carry the analogy that far on this page. (I don't think that non-geeks even know what a hardlink is, and if they knew, the concrete effects would keep surprising them.)
Actually I think that symlinks already exist (in the form of redirects), that hardlinks are problematic, and that virtual directories and inheritance aren't standard filesystem concepts at all (I don't know a single Linux filesystem that has them).
JoachimDurchholz June 16, 2006, at 03:18 AM
I keep feeling I've missed something. So shoot this comment to dust if I'm covering old ground. I would tackle this as Object Oriented. Files and directories are things. So a thing can be (a) directory and/or (b) file. Unless I misunderstand this is what I'm currently about to download. Now a thing can note it has a nominal parent of an arbitrary other thing including itself. Such self relationships in ERDs have around my way come to be called a "who's ya daddy?" link which simply expresses at it's simplest that the thing needs to know it's parent but does not exclude a "daddy" having an index of it's children.
In this context your group (type A+B thing) is represented by the group home page (the B part) which leaves the A (folder) free to decide if it is root or if it inherits from another group, page or third party thing (yet to be created type C).
At the logic layer now I would have the data layer make an index (like for back links) of known children which can be contextually linked to from the group home (optionally). Further more the path back to root including "UP" to each parent level can be obtained by asking the current thing "who is your daddy" all the way until the answer is "I am". This gives you the "trail" in reverse.
Functionally very little need change and for the user the feel of groups in groups exists. In that way it is like people. Each person has a National Insurance Number in the UK and in the US a similar number is issued to everyone. In the system this "number" is $group.$page now this may be joined to a family, live in a flat (with other families) in a town, under a stack of councils under a government in a country on a planet but it is still $group.$page and it is down to presentational logic as to when you would like things that are not their own parents to be shown. A couple of settings should do it.
In this way groups are a loose coupling (good design pattern) ad do not break easily. Or did I miss something over the course of several pages?
- "Lord" Matt (get hold of me(approve links))
IMHO, I think that maybe one way to deal with this is to always link to pages and never link to groups, so links inside one page will always refer to other pages within the same group/path, just the way it already is with PmWiki.
i.e. a page named "Animals.Canine.Terrier" with a link to "[[bulldog]]" inside it, will always link to "Animals.Canine.Bulldog" where bulldog is a page, it will never link to a group named bulldog inside the current path "Animals.Canine".
So the last argument within a pagename "Animals.Canine.Terrier" is the page itself and the rest is the group/path name "Animals.Canine". If there isn't a page named "Animals.Canine.Terrier" you will see a page saying that that page doesn't exist and inviting you to create one.
You can keep links the way they are now, normally refering to pages in the actual group and if you wanna link to other pages with diferent path/group, just give the fullname (path+pagename) of that page as a link. CarlosAB June 16, 2006, at 01:57 PM
"Always link to pages, never link to groups" seems the right PmWiki thing to do. However, as currently presented, this may cause problems if one restructures the pages or uses an include statement. On Animals.Canine, a link to "[[bulldog]]" refers to Animals.Bulldog whereas on Animals.Canine.Terrier, a link to "[[bulldog]]" refers to Animals.Canine.Bulldog. Furthermore, on Animals.Canine.Terrier, one might want to refer to Animals.Feline. Presumably, one can now no longer write "[[feline]]".
I see two angles of attack on this one, both relying on PmWiki rewriting the links as needed.
For inclusion, the current group that the include directive starts from should always be the location of the include page itself. (If you use the location of the including page, it's very difficult to use inclusion from include files.)
For page restructuring, I think PmWiki can rewrite the links inside the page. This is desirable even in the nonhierarchical case, though less important.
JoachimDurchholz August 19, 2006, at 03:11 AM
In trying to solve this for one level of subgroup, one way that seemed to make sense was to have a subgroup markup character (see Cookbook.SubgroupMarkup).
I don't like that idea. It doesn't scale to sub-sub-groups. What if a former subgroup is turned into a group - you may want to add code that changes the links, but that code would have to handle a lot of borderline cases.
JoachimDurchholz August 19, 2006, at 03:44 AM
This leads to: on Animals.Canine and Animals.Canine.Terrier, a link to "[[,bulldog]]" (note the addition of a comma) refers to Animals.Canine.Bulldog. On the other hand, a link to "[[feline]]" on those pages refers to Animals.Feline. A link on Animals.Feline to "[[canine,bulldog]]" is a reference to Animals.Canine.Bulldog -- a page in the Animals.Canine group; an Animals.Canine page may or may not exist. This could be generalised to any level of hierarchy.
I feel uneasy about leading commas that carry meaning. It's far too easily overlooked, or confused with a full stop.
JoachimDurchholz August 19, 2006, at 03:11 AM
I think this is way over-complicated. Personally, after playing and using PMWiki for about 3 weeks now, the one thing I would love to be able to do is just keep adding the "/"'s. As many as I want.
If I want to do Main/Animals/Mammals/Canines/Dogs/Rottweiler, why not? Main can be a page, as well as Main/Animals, or even Main/Animals/Mammals/Canines/Dogs/Rottweiler. If there's no page for it, the admin can either lock it, or leave it open for creation. No worries.
Take from the UNIX-think of file systems: Everything is an inode to the kernel(PMWiki): Files, Directories, Softlinks, hardlink, devs. It's up to the shell(Admin glue) to decide what to do with different types of inodes.
If I want to move the hierarchy around, so be it. If I want to reference something inside a different "directory" than I'm in, I need to be explicit, or give a bunch of ".." until I get there. And, with Intermaps, we can even do hardlinks. But, to follow KISS, just need to allow as many "/" as the end-user wants. JMO.
Proposals have been spwaned into seperate pages: