biologydaily.com:Categorization policy

This is a discussion, not a vote

Please add opinions and discussion to the talk page , and add well-formulated amendments or additional suggestions below.

Please bring this page to the attention of others by linking to it from whatever relevant discussion pages you can think of.

Description

Wikipedia strives to be the sum of all human knowledge. However, for knowledge to be useful, it must also be accessible. The obvious way of making the Wikipedian articles more accessible is categorization.

Some Wikipedians feel that the category system has become overly complex. They have concerns about inconsistent naming, partial redundancy with other categories and/or lists, and what they feel is overspecialization to near-empty categories (e.g. Finnish botanists). The category renaming and deletion page has a backlog of two months.

It is suggested by these users that it would be better to impose a standardised categorization system in Wikipedia. They argue that for individual articles, the process of letting every user write about whatever he wants works great - but for the overlying structure, it is better to develop a consensual system that is internally consistent.

Proposed policy

Locking categories

The category system should be decided upon by the community consensus, rather than by any random user on an individual basis.

1. Any user can make suggestions to Wikipedia:New category requests. After five days, the category will be created unless there is serious consensual objection, using existing categorization guidelines.
2. To ensure no wrong categories are created, only admins can create or rename categories.
3. Only admins can move categories into (or out of) other categories.
4. Any user can move articles into (or out of) categories.
5. New category requests will ensure that new categories comply with category standardization (e.g. German cities vs. Cities in Germany), as well as proper capitalization and spelling.
6. This is supposed to obviate the excesses of WP:CFD, and New Category Requests are expected to quickly die down into a couple per week.

Note that the Stub Sorters already use a similar system for creating new stub categories and related templates.

This is open for discussion on the talk page . It is not presently being voted on.

Withdrawn policy suggestions

The suggested policies on lists and nav.templates have been withdrawn, because of a variety of good reasons and comments to oppose them. See the talk page for details.

Redundant lists

To improve consistent categorization, all lists that are a mere series of links (e.g. List of computer viruses) should be converted to categories. Any list that is redundant with an existing category should be a redirect to the category, after merging its links and redlinks into there. See also Category:Lists_that_should_be_categories.

One advantage of lists over categories, is that a list can contain redlinks of articles that haven't been written yet, and categories cannot. However, since a category main page can contain text (e.g. Category:Songs), the redlinks should instead be put there. It would be preferable if any user can add new redlinks.

If this is technically problematic, or a (potentially long) list of redlinks at the top of a category is considered ugly, the redlinks can instead be kept on the category talk page.

The major technical problem with categories compared to lists is that categories are horrendously inefficient, requiring hundreds or thousands of times the resources per page view. This extreme cost disparity arises because the contents of category pages isn't cached. Instead, it's generated anew, using a new datbase query and page build with every page view. A normal list page is simply loaded from the Squid cache server closest to the viewer, a very inexpensive operation. At present, 6 or so Squid cache servers handle about 80% of all hits to the sites, with some 40 other machines needed to handle the rest.

Lists that contain information in addition to links (e.g. Fictional chemical substance) should, of course, be kept.

The description of lists gives three purposes for lists: information, navigation and development. It may be the case that navigational lists are obviated by categories, and developmental lists could be placed inside category text as specified above. That leaves informational lists, which tend to be very encyclopedic in nature.

• You also have to remember that lists can be ordered in other ways than alphabetic (like categories). Also, putting redlinked articles somewhere in cats will look odd because they won't be listed like other articles. So I think some navigational lists have become obsolete because of cats, but I don't see a reason why we can't have both. It's always easier if you can find info in multiple different ways. Mgm|^(talk) 13:42, Mar 19, 2005 (UTC)

Redundant templates

Certain groups of articles use templates for inter-navigation, that are partially redundant with categories. While many of them are useful (e.g. Polish history), others are arguably less so (e.g. Orcs , which is nominated for deletion (update:deleted) and Buddhism which recently managed to survive a vote for deletion).

The problem with having a template for a category is that they can easily become divergent. A solution would be to implement software that displays a category as a navigational template, or a bot that automatically updates a template from a given category.

A consensus might be achieved on for which categories a navigational template would be useful. A criterion might be whether the template adds a meaningful ordering (other than alphabetical) to the topics in the category.

Technical solutions

Technical solutions may make a policy change unnecessary and provide additional benefits.

Combining categories

From a reader's perspective, a straightforward solution would be: Allowing the reader to combine existing categories. Categories such as the aforementioned Finnish botanists would be dissolved; any article would instead have two entries like Category:Botany and Category:Finnish people or three like Category:Botany, Category:Finland and Category:People. (The latter case might include a foreigner working about Finnish botany, but we may decide to live with this imprecision.)

Scenario: Heikki wants to find a Finnish botanist whose name he forgot. On the main page, he clicks on a link to Wikipedia:Find by category. That page presents him links to all categories (possibly sorted alphabetically or hierarchically). Next to each of these, there is (instead of the bullet) a checkbox. Heikki checks "Botany" and "Finnish people". When Heikki clicks "Submit" he gets a list of all articles that pertain to both categories.

This will be a big improvement for Heikki over the current situation: Currently, he has to read half a page of Wikipedia:Category schemes before he finds Lists of people (called "Biographies") and then he has continue on a cumbersome and detour-prone search till he finds Finnish botanists. And that assumes that he even knows that such a category exists in the first place! (Implementation detail: The link to Wikipedia:Find by category should be in a prominent place. It could replace the link to Wikipedia:Category schemes.)

It will also be an improvement for editors: We only need to remember a fraction of the current number of categories (- was that "Category:List_of_Libertarian_Economists_and_Business_Leaders" or "Category:List_of_Libertarian_Business_Leaders_and_Economists"?).

The same principle would be applied to stubs. Instead of {{bio-stub}} we would simply use {{stub}} and Category:People. In addition to the above advantages it would give us:

• The categorization work won't have to be done twice.
• Articles will be categorized correctly early on, which means among other things that anyone who looks up a category combination will automatically see all applicable stubs. We might even consider tagging stubs in category lists (e.g. with an icon) so that people are enticed into expanding them.

17:14, 2005 Apr 17 (UTC) 

There is a bugzilla entry requesting boolean searches for categories, which would partially implement this suggestion. -- Beland 00:01, 18 Apr 2005 (UTC)

Cool - thanks for the link! The bug seems more general and more demanding to implement and to use, though. — Sebastian (T) 06:50, 2005 Apr 18 (UTC)

Related proposals

• Wikipedia:Merge lists to categories