Category Category

Pages on this wiki may be tagged with one or more categories. This page is the main category page. To get a list of categories on the Tclers' Wiki, select Page / References menu option. Selecting a page title in that list takes you to the category page, then select Page / References to see the list of pages in that category. note that there is a bug currently preventing all references being displayed

How do Wiki Categories work? - there's a page about that. The same page also contains a manually-maintained list of categories. Because it is manually maintained it is necessarily not up-to-date, but it does give a short description of each category it includes. If you create a category page it would be nice to add it to that list.


 Meta Discussion
Meta-meta note
Burying this because it is now so large that anyone looking for categories or something about them needs to know that reading it is optional.

PYK 2013-09-03:

I am dubious of the value of special category pages because existing pages on each topic already exist, and creating separate pages that serve exclusively to earmark a thing as being a category is messy. For example, the page artificial intelligence exists, and is, by its existence and subject matter, already a category. The page Category AI, though, also exists, for no purpose other than as a node in a hierarchy of separate categories. The actual topic pages would work just as well for the purpose of categorizing things, and become category pages precisely when they are used as an argument to the <<categories>> feature. The advantages are that the category hierarchy can grow more naturally as real topics are added, that an almost redundant set of special "category" pages need not be maintained, and it would be more straight-forward to add additional analytical functionality to the system based on the hierarchy that it could infer from the links and category links an a document.

The meta discussion at Tcl 2008 Conference Talks illustrates the mental gymnastics that a separate explicit set of category pages burdens Wiki users with.

I propose that to achieve the best results for this wiki, editors use the <<categories>> function of the wiki with first-class topic pages instead of category pages, and that we carefully curate pages to provide more substantial, organized, and readable content, even if it means duplicating some of the functionality that categories ostensibly provide. For example, I've started editing the Tcl 2008 Conference Talks to contain a set of links to individual conference presentations, even though such a list could arguably be derived by using the "what links here" functionality of the wiki.

Given enough consensus, the time might even come when editors begin to actively dismantle pages named "Category ...".

EMJ 4 Sep 2013 - a few comments:

  • We (FSVO) tend to be distrustful of anything that looks even remotely like a major re-organisation for its own sake.
  • As it says above, there can be, and are, category pages without "Category" in the name. The down-side of that is that there is less to discourage changes that would reduce their suitability as category pages, such as taking a view on the subject which would make the authors of other pages less keen to have them "in" the category.
  • We are also distrustful of enforced hierarchies of subjects, and hence of viewing categories as a hierarchy. Categories are better viewed as a set of disjoint tags, though a few mini-trees of categories exist and may be justified.

2014-03-01: While pages that summarize a topic and provide references to subpages are obviously useful, they are also difficult to maintain as all additions, corrections, and removals have to be manually checked. Hence, we still need the category system, which gives us automatic and accurate references for the much lower maintenance cost of setting category labels on the individual pages correctly. Both systems can be in place and complement each other: they do not disturb or detract from each other in any way. I am in firm opposition to any plan to dismantle the category system.

PYK: The category system is in place, regardless of whether special category pages exist or not, and the current category system already relies on setting category labels on individual pages correctly, and so already incurs this cost. I'm not sure what [name redacted]'s argument is here. I think he may be missing the point. On another note, to be really functional, the category system needs to provide a way to search for pages based on combinations of categories.

EMJ 2014-03-01: The "already incurred" cost of categories is minimal
  • it is easy to add one or two categories to a new page, or to any page you happen to be editing anyway
  • it is almost as easy to edit a page specifically to add a single category

If someone creates a new category and wants to add several pages to it that is a bit more effort. However, since the category system is self-maintaining the total effort is less than creating a list somewhere which has to be manually maintained - if someone who ought to update it actually knows it exists or where it is! That is the point here, along with your reference to "actively dismantling" the Category pages, and I don't think [name redacted] has missed it. Anyway, manually maintained lists remind me (dare I mention it to jog some peoples memories?) of Index Pages.

On another note, given the current sqlite-powered enhanced search , combined queries and all sorts of other complex searches are now quite easy.

Obviously, I also am in firm opposition to any suggestion that the category system might be dismantled.

PYK 2014-03-01: I believe EMJ has somehow also missed the point here. The argument is not to replace the category system with manually-maintained lists, but to use, e.g., object orientation as a category instead of using category Object Orientation. Also, I would love to see an example of finding pages based on some combination of categories, as I've not-yet figured out how to do that. emj there is now a note on the [search] page.

[name redacted]: It seems that it comes very easily to you to dismiss criticism or opposition with the verdict that the people who don't agree with you are "missing the point". I admit that there are many cases where I personally don't see the point of what you're doing, like for instance your odd habit of rewriting perfectly good text by breaking lines at some arbitrary length, making it a major chore to maintain the text without removing those linebreaks again. However, when you talk about it being "messy" to have pages like Category AI side-by-side with pages like artificial intelligence, then I'm afraid that the missing of the point is on your side entirely (and your response to what I wrote also hints that you haven't really thought this issue through). It may be necessary to repeat this: this wiki is not your personal domain, and you are not welcome to rebuild it to suit your preferences. If you want to suggest a change in how pages are organized (as opposed to correcting texts, fixing links, improving the layout of pages, etc) it's absolutely essential that you bring this suggestion up for general discussion before you go ahead and make this change.

EMJ: What he said! And even if I had misinterpreted your viewpoint on categories, I still object to the new version. See firstly my second comment from September 2013. In addition, if you don't label it a category how will anyone know it is a category, unless they happen to see it referred to at the bottom of some other page?.

PYK 2014-03-1: That's precisely how you would know, and that's the only time you really care. Using regular pages as category pages would not affect the current operation of the wiki category system at all. The only difference is that there would be less confusion about where to put information on, e.g., Artificial Intelligence, because there would only be one page on that subject instead of two. Regarding EMJ's 2013-09 response, yes, categories are better used as a set of disjoint tags rather than as a hierarchy, which I see as one more reason that explicit category pages need not exist. However, I do see the point about explicit category pages that have no content being useful as the unencumbered ideal handle for the subject. Maybe that alone is enough to keep them around.

RLE (2014-03-03): I also support [name redacted] and EMJ in that I too am in firm opposition to any plan to dismantle the category system.. I also firmly agree with [name redacted] that "this wiki is not your personal domain, and you are not welcome to rebuild it to suit your preferences." I also often do not agree with a large amount of your edits, but as they (usually) only change the visual presentation I often just leave things alone rather than try to revert them all.

The "category pages" exists because, as a wiki, they are the way to supply the "tags" that are the category names that then get applied to other pages to categorize them. Otherwise the wiki would need two editing interfaces, one for page content, and a separate one for editing the "tags" that can be applied to the pages.

The maintenance effort for a "category" page should be minimal if used properly (and I believe this might be where you have missed the point on the category pages themselves). The "category pages" should be short, simple, and generic. I.e., little more than an "index" entry. Because of this, the effort for a new category page is only expended once, when it is created. After creation, with rare exception, it could (should) be treated as essentially read-only. It should not be "edited" to add links to other pages, or to add commentary or opinion about a topic. Those belong in the topic pages themselves. Because of such, there is no long term editing effort necessary. If the category page contains a "backref" meta-tag then it will contain an automatic, self-maintained, list of links out to all the pages tagged with that category tag. Again, reducing the "maintenance" effort for the category page itself to zero. (And, because of the above, this discussion should probably be moved out to a separate page.)

I.e., an editor does not need to "maintain" the category page. Once created, it is self-maintaining. The effort is in applying the new tag to other relevant pages. But that effort will exist no matter the use of "category pages" or "index tags" or "hierarchical subject matter systems". Someone will have to tell the wiki than random page X on topic Y belongs to "category Z" or "index entry Q" or at point E in the "hierarchical subject matter system".

So, for your example of the [artificial intelligence] page, and the category [AI], they serve two different purposes. The "page" should be where the details, discussions, opinions, debates, etc. should exist. The "category" should be the short, generic, "index" entry value that can locate that page. The value of the category page then comes into its own when another page, under a different title (one not normally recognizable as AI except to AI experts), is found that relates to "artificial intelligence". With the category system, adding that newly found page to the category [AI] involves these steps:

  1. edit that new page to add the "categories" meta-tag, and AI label (or to just add the AI label if there is already a "categories" meta-tag.

With a manually curated set of "related pages" on the [artificial intelligence] page, doing the same involves these steps:

  1. remember the title of the new page
  2. find the [artificial intelligence] page (bookmark, search, etc.)
  3. edit the [artificial intelligence] page
  4. find the "see also" or "related" (or whatever it happens to be called) section
  5. add the new page link, possibly by finding where if the list is sorted in some manner

Using the category tags, adding the new page to the category was a one step operation. Using the main discussion page as its own category/see other reference, it is a multi-page, multi-step process. This is how the categories system reduces maintenance effort, but until one sees this, it is unclear just how it does do so. Much of your effort you've expended in building extensive "see also" link-sets over the last months on topic pages could have been significantly reduced had you let the category tagging system build most of those for you.

PYK 2013-04-03: The "manually-curated set of 'related pages'" thing is a straw man. For the third time, I never proposed that. ...dismantling the category system is also a straw man. I myself use the category system constantly. The proposal was to use, e.g., artificial intelligence within the category system, e.g., as a value to the <<categories>>, meta-tag, rather than using category AI.

RLE (2013-03-03): In which case you should be significantly more careful in your word choices:

dismantle dis-man-tl verb (used with object), dismantled, dismantling.

  1. to deprive or strip of apparatus, furniture, equipment, defenses, etc.: to dismantle a ship; to dismantle a fortress.
  2. to disassemble or pull down; take apart: They dismantled the machine and shipped it in pieces.
  3. to divest of dress, covering, etc.: The wind dismantled the trees of their leaves.

http://dictionary.reference.com/browse/dismantle?s=t&path=/

The very term you choose to use to end your introduction of this discussion means exactly the removal of the category system.

Quoting from your own words
Given enough consensus, the time might even come when editors begin to actively dismantle pages named "Category ...".

So while your intent may not have been to propose that, you certainly set the discussion off in that direction by how you chose to end your initial statement.

While nothing is stopping [artificial intelligence] from being used as a category tag in the categories meta-tag, one item that gets lost is the ability to have a set of backrefs generated by the backref's meta-tag that exist on a page with little content, thereby making the backrefs (equivanently a "what links here" or "see also" set) more visible. I.e., to add a backrefs tag to [artificial intelligence] it has to go somewhere. At the top, and it pushes the useful information of the page down below the fold. At the bottom, and someone has to scroll to find the set. In the middle and it has to interrupt something. On the separate category page, beyond the short, brief, generic introduction, it is the only remaining content. So it can't get lost in the same way. Now, one could also argue that placing that linkset on a separate page makes it more hidden by default. Such would be true. But further lengthening the topic pages also hides something, so that is a loss that simply has to be paid up somewhere.

PYK: It's not the meaning of dismantle that was the issue, but what the object of that verb was. "Dismantle pages named 'Category'...", of course, has an entirely different meaning than "dismantle the category system", particularly when the previous two paragraphs go into depth about how the category system could work without special-purpose "category" pages. One big problem with special-purpose category pages is that once one exists, it becomes impossible to use a non-category page as a category. For example, if I go to the algorithm page and then click on the page header to see the list of backrefs, almost nothing shows up. I have to find my way over to the "category algorithm" page and obtain its backrefs instead. The wiki would be more browseable if simply clicking on the algorithm header gave a useful list of backrefs, and there's an easy fix: remove the category algorithm page. It doesn't have any meaningful content anyway.

EMJ 2014-03-04: Note my trivial change near the top of the page. Where did that spurious "a" come from? Lack of attention to detail when editing, I suspect. Harmless here, but not, I think, everywhere.

PYK 2014-03-09: Just yesterday in the Tcl Chatroom some people who had started using Tcl more recently were complaining about category pages that had no content and the corresponding topic pages that didn't return relevant backlinks. Get rid of category pages and use the actual topic pages directly in the <<categories>> block, and the problem goes away.

EMJ 2014-03-09
"started ... recently" - the wiki maybe, but not Tcl, not for at least two of them. As I read it, you have a couple of people on your side on this issue. Good. But I still don't agree. Part of it is history - the Category system was invented using a facility that was in the wiki software already, it works, it's simple, it's clean. Another thing is that it (along with the whole Wiki) was severely threatened once before, so if anyone tries to make a major change it rings the occasional alarm bell. I think that Category pages should be labelled as such and should stay simple, just a short definition of the category, and a hint to click the title (since people do seem to miss that possibility). I am unsure of the merit of <<backrefs>> since it just gives the page names, whereas using the title gives last-edit dates, which may often be helpful. I have no objection to including a link to the "main" page, if there is an obvious candidate.

Discussion: Major Categories

EMJ 2015-10-15 : So,

  • How is this different from the manually updated list of categories in How do Wiki Categories work?
  • What is a "major category"? (I don't think there is any such thing.)
  • If this was actually a good idea, it should be lower down the page since it breaks the flow here.

PYK 2015-10-15 : I placed this here because I had forgotten about the list at How do Wiki Categories work, which illustrates one problem: Someone browsing the wiki doesn't naturally come across the list. I would say a major category is one like Audio, in contrast with other categories such as Category 3d files, Category Cardgames, or Category Code Style, any of which would just clutter up the main list, and should instead be found by drilling down through the category hierarchy. I placed this list near the top of this page because I think most peope who land on this page are looking for a starting point from which to drill down into sub-categories. I guess there are two other reasons people end up at this page:

  • To find information on how to use the category system. I agree that it would make sense for this information, or at least a prominent link to this information, to appear prior to the list of major categories.
  • To find information and field ideas about the development of the category system. This information could probably appear later.

Given these three different audiences, how about having the category lists (manual and automated) on this page, user help for categories at How do Wiki Categories work, and suggestions about the category feature at Suggestions for Wikit or some similar page?