Last modified: 2008-04-11 10:30:13 UTC
Some higher-level categories logically have categories as members. It should be possible, when adding one category to another, to specify that it is being added as a member and not as a subcategory. These member categories should then be listed among the member articles, or at least separately from the true subcategories.
That doesn't really fit our category model, in which there is no distinction between subcategory and member category.
Sorry if I didn't make myself clear - this is a request to extend the category model, which would in fact enable such a distinction. (It's a feature request rather than a bug report.) The point is that, logically, there should be a distinction between member cats and subcats (but as you imply, the software doesn't currently support this).
I wouldn't consider this a desirable change at this time.
Reopening again in the hope of extracting a fuller explanation as to why it isn't desirable.
Categories are not primary content pages; they're collections based on tagging. When category pages are themselves categorized (tagged), they too appear in a category collection. But, because categories are something special, we separate these out from the regular pages, and make it easier to navigate down a virtual "tree". These are then called subcategories. Since categories are special collections, not regular pages, they are treated specially. This is by design. Offhand there is little or no benefit to complicating the system to treat them sometimes specially and sometimes not, when in fact they are *always* something special.
I understand, but my point is that they can be "something special" in different ways. For example, "Category:Jesus" and "Category:Politician categories" might both be assigned to "Category:People categories". At present they would both be listed on that page as subcategories. However, logically, only the second one is a subcategory, while the first has a totally different relationship with the parent category - it is *not* a subcategory (in the sense of subset), but a member of the category.
Well, that's just not the way we do categories.
Er... obviously it isn't, otherwise I wouldn't need to be proposing this improvement. You could dismiss any feature request by saying "it's not the way we do it". My point is that it should be the way we do categories, otherwise you get a mess. Admittedly here the mess is only at the top of the category tree, where perhaps few users ever venture, so it isn't a vastly important issue, and I don't mind letting it drop. However I will probably be making a more extensive category proposal soon, which might be of great assistance to tidying up the category system e.g. in Wikipedia, and I hope it will meet with a more open-minded attitude.
In the lack of a strong reason to change the system, the default logical position is *always* to not make the change. The burden of proof lies on the change. There's relatively little justification given for the requested change, and it doesn't seem an appropriate change to me. The reason I see given is based on a reinterpretation of how MediaWiki categories work, from 'practical navigational tagging tool' to 'strict logical semantic hierarchy'. Given that strict logical semantic hierarchies are pretty much impossible to maintain in a world full of non-hierarchical, overlapping, sloppy concepts, and that MediaWiki is designed to run an online encyclopedia under constant construction by multiple authors, and that it is therefore a requirement to handle non-hierarchical, overlapping, sloppy concepts, and that it is *not* a requirement to handle strict logical semantic hierarchies (which do not exist in the real world and cannot be maintained given our environment), I see little benefit to adding complexity to the system to support something which is antithetical to the design and purpose of the system.
Thanks for the fuller explanation. I still think the categorization software needs some additions though. My wish is not for an absolutely strict semantic hierarchy, since this would be unrealistic as you say, but it does seem realistic to strive for a fairly consistent treatment of categories within a given project. And the present state of the software seems not to be conducive to this - it doesn't provide appropriate features for handling all the situations in which people want to use categories. And making categories work sensibly is important, if only because they are part of the content on each and every Wikipedia article page. Anyway, this particular proposal wouldn't make a major difference, so no need to discuss it further, but as promised above, I hope to be making a more useful proposal sometime later.
