|[Tcl Commands%|%previous : Tcl Commands]| Pages on this wiki are tagged with one or more categories. This page is the main category page. To get a list of major categories on the Tclers' Wiki, click on the title "Category Category" at the top of this page. To get a list of any subcategories on any category page, navigate to that page and click on the title of the page. ** Summary ** The is the key page for the '''category''' functionality of this Wiki. A page is a '''category page''' if it contains a link to this page. ** Major Categories ** In addition to the list automatically generated major categories when one clicks on the title of this page, the following is a manually-curated list of majore categories. [Category Audio%|%Audio]: Recording, processing, and playback, of audio signals. ** Description ** One feature of this Wiki is that clicking on the title link at the top of any page displays a list of all other pages which contain links to the current page. The Wiki's '''category''' functionality is built on this mechanism. Links to '''category pages''' are intended to be placed on all Wiki pages. Users may then navigate to some category page, click on the title link for that page, and get a list of all pages "belonging" to that category. To create a new category, create a new page representing the category, and place a link to the '''this''' page on the new page. Look at a few other category pages to see what is usually done. There is a convention to name all category pages starting with the word "Category" (e.g. "Category Topic"), but this is not required, and there are some category pages that do not do this. One reason is that such a page serves a dual purpose, both as a '''category page''' and as the primary content page for some topic. Category links are traditionally placed at the bottom of a page (order is not critical) using the `<>` wiki macro: ======none <> Topic | Other Topic ====== Which will be rendered similar to: ======none !!!!!! | [Category Topic] | [Category Other Topic] | !!!!!! ====== If necessary, the `<>` macro will prepend the word, "Category" to a page link to resolve it. A category link on a page should answer the question, "What is this page about?". Links to related pages which do not belong in any of the same categories should either be placed under a "See Also" heading or simply referenced in context in the text. ** Tips ** The page [How do Wiki Categories work] contains a description of available categories. When adding a new category, please also add a description there. However, because it is manually maintained the authoritative source of information about each category is the '''category page''' itself. ---- <>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 `<>` 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 `<>` 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. [PL] 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 [PL]'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 [PL] 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 [http://www.sqlite.org/fts3.html%|%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. [PL]: 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 [PL] and [EMJ] in that I too am '''in firm opposition to any plan to dismantle the category system.'''. I also firmly agree with [PL] 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 '''<>''', 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 `<>` 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 <> 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. <> <> Category