authors (intermediate)
Purpose of Categories
Categories are a way to organize and find related pages. Categories are implemented by default in PmWiki 2, and in most wikis they don't require any special code or markup, they're just a useful convention. The idea is that every page that falls into a particular subject area should have a link to a shared page containing links to other pages on that subject. These pages are created in the Category group, and thus these subject areas are called Categories.
Using Categories
Getting Categories to work requires two steps, the first of which is adding links to each Category. A Category named Subject is created by adding a link to Category.Subject on any page. When you add the link to a page, the page can be described as being in the Category. There is a special markup for creating these links which makes Categories work more smoothly: [[!Subject]] will create a link to Category.Subject. The difference between the two types of link will be explained below, but if you plan to use Categories, using the special markup will probably make your life easier.
If you click on the category links on a page, initially you'll just be taken to an empty page named Category.Subject. The second step in setting up Categories is to modify the behavior of pages in the Category group so that they will display a list of all pages containing links to Category.Subject. This is relatively simple to do:
- Open the page Category.GroupFooter? for editing
- Add the line
(:pagelist link=Category.{$Name} list=normal:)
- Save the edits
This will cause the footer on every page in the Category group to display a list of links to pages that reference Category.PageName. However, this list may include a lot of pages that are not actually in the category, but instead link to it. This is where the special [[!Subject]] markup comes in. If you are using that markup, you can replace the pagelist? command in Category.GroupFooter with (:pagelist '!{$Name}' list=normal:), and the list will be restricted to only those pages that have been explicitly added to the category by use of the special markup. For wikis with multi-word category names, like "Technical writing", that do not use WikiWords, use this instead: (:pagelist '!{$Namespaced}' list=normal:). It is worth noting that rather than adding this to Category.GroupFooter, the pagelist code could be added to Category.GroupHeader to similar effect; it just depends on whether you'd prefer to have the list of pages appear before or after any text that you add to the individual category pages (which can be edited just like normal pages).
Recap
So, by adding the link [[!Subject]] to a page, a link to that page will automatically appear on the page Category.Subject, as long as the GroupFooter for the Category group has been tweaked appropriately. Thus, you can create a page that automatically creates an alphabetized list of all movies discussed on your wiki by creating links to [[!Movies]] on each film's page; the resulting automatic list would be on the page Category.Movies.
authors (advanced)
Category Nesting
Categories have the potential for even greater usefulness because Category.* pages can themselves be placed into categories! To follow an excellent example from John Rankin, let's suppose we have the following film pages in the categories listed to the right:
Film.SeanOfTheDead [[!Horror]] [[!Comedy]] [[!2003]]
Film.InMyFathersDen [[!Drama]] [[!2004]]
Film.TheCorporation [[!Documentary]] [[!2003]]
Now then, we can create Category.Horror, Category.Comedy, Category.Drama, and Category.Documentary, and in each one of those pages we put [[!Genre]]. In Category.2003 and Category.2004, we put [[!Year]].
So, what happens when we display Category.Genre ? We see links to "Comedy", "Drama", "Documentary", and "Horror", because they're in the Genre category. When we click on one of those links, we see all of the films listed in one of those categories. Similarly, if we click on Category.Year, we see links to "2003" and "2004", each of which in turn displays the list of films for that year.
Finally, in Category.Genre and Category.Year we can put [[!Category]], which makes them "top-level" categories reachable from the Category.Category page. Voila, we now have an instant "hierarchy":
Category.Category
Category.Genre
Category.Comedy
Film.SeanOfTheDead
Category.Drama
Film.InMyFathersDen
Category.Documentary
Film.TheCorporation
Category.Horror
Film.SeanOfTheDead
Category.Year
Category.2003
Film.SeanOfTheDead
Film.TheCorporation
Category.2004
Film.InMyFathersDen
Note however that this isn't a "strict" hierarchy--i.e., any page or category can appear simultaneously in multiple categories. For example, Category.Documentary could be a member of both the Genre and top-level category listings.
Each category page can have content text before the generated list, e.g., to give a generic description of things in the category. (Or it can be empty, which works fine.) It can also contain associations to related categories ("see also" references). For example, in a tourism wiki, the ''bed and breakfast" category might contain a see-also reference to the "self-catering" category.
administrators (intermediate)
The Guts of the Category Markup
As mentioned, all of the necessary markup features for Categories are enabled by default in current releases of PmWiki 2.0, but here's how they work for those who are interested. The use of the Category group as the repository for all categories is determined by setting the $CategoryGroup variable, and the special [[!Subject]] markup is activated by a call to the Markup() function:
SDV($CategoryGroup,'Category');
Markup('[[!','<links','/\[\[!([^\|\]] ?)\]\]/',
"<span class='category'>[[$CategoryGroup/$1]]</span>");
The advantage of the separate category markup above is that authors can assign pages to categories independently and explicitly. It lets authors distinguish between a category reference and a reference to a page that happens to be a category page.
Coming Up With Good Category Schemes
The hard part about using categories is choosing a good vocabulary. Site content managers may wish to follow the Guidelines for the establishment and development of monolingual thesauri (ISO 2788-1986) and the Guidelines for the establishment and development of multilingual thesauri (ISO 5964-1985). Questions to think about include:
- whether a scheme already exists and can be reused
- number of levels in a multilevel scheme (not too shallow, not too deep -- e.g. 3)
- number of categories per page (not too many, not too few -- e.g. 3)
- consistent use of singular (
[[Mercury]] is a [[!planet]]) or plural ([[Mercury]] is in the [[!planets]] category)
- disambiguation and use of phrases (
[[!musical instruments]] and [[!medical instruments]]) or Cookbook:Subpage Markup ([[!Instruments*Musical]] and [[!Instruments*Medical]])
Or you can just let people use whatever category terms they find meaningful. A vocabulary (or "folksonomy") will emerge over time.
Subject: trial use of Category system of indexes
At the SolaRoof wiki I am looking to explore more dynamic navigation aids and one of the reasons for the 3 column format is to use a dynamic index in the right column in the SolaRoof group, which is a knowledge base group.
Other groups in the SolaRoof wiki are for Teams or Personal space (like SolaRoofGuy personal wiki) and they use the Calendar function on the right column to aid the navigation of a WikiBlog that belongs to that group.
However, the knowledge-base type of group like SolaRoof is strictly for working on content and organizing information for accessible DIY know-how. There is no need for a WikiBlog function in the community wide collaboration space (instead, we do have a community Forum) and therefore the right column is currently empty.
What I would like to have is a navigation aid in that right column that will help a user to go from the current page to the next page, which he can see in the right sidebar, which is a dynamic listing of pages in the same catagory and links to other related catagories. Now that I have read this page I appreciate that what I was developing at GroupName (this is our How To Wiki) where I have talked about Main Index and Sub Index pages should instead be talking about Category and Sub Catagory pages. These links can go on the right sidebar (3rd column) and the left group sidebar will provide the conventional navigation links to useful internal and external links.
Additonally, I would like to bring in further navigation aid that I believe will work well with the wiki groups structure and the Catagory organization since these provide information that is user (human rather than machine) designated that build relationships between pages and sub categories and Categories. It is the relationships that are mapped and structured that make the information so useful. Similar PageNames used in various WikiGroups are not just repetitious, they give depth of knowledge by presenting similar information but in a different context. So the ability to have groups, each with its own name space, will give richness and maintain diversity, avoiding "GroupThink".
The mapping of the context and relationship of any existing page to the other pages in that group and other groups and across categories would make the wiki much more effective and useful. You are not then "surfing blind" but can see the links and threads of connected information. I have recently received a very positive response to working on a "concept map" tool that could be a visual interface for the display of the relationship of Groups and Category and Sub Category structure of the SolaRoof wiki. This technology is available from CMapTools. I would like to explore using this Concept Map interface as further naviagion aid.
In some ways I think that it is not possible to be over engaged in the devlopment of the Wiki Navigation interface - because as the wiki world grows it will be a significant advantage that it grows "intelligently" - that it is a manifestation of "Group Intelligence" - so we would not "surf blind" as we do on the internet - rather we would navigate a structured "Name Space" and have a good idea where we are going as we explore the wiki world.
This is long rambling edit but I hope that it fits here and that I will find some feedback to support the SolaRoof implementation to make it the best of the best.
- SolaRoofGuy
Contributors: Radu, John Rankin, SolaRoofGuy, David A Spitzley
<< Passwords | DocumentationIndex | Installation >>