Categorization/Archive 3

==Describing the relations==

I hit much the same problem as Morwen a week or so ago, and backed off from categorization while waiting for the dust to settle. I saw with both as supercategories I decided against it, because a footballer is a sportsperson, but is not a sport. I ve come to the conclusion that Categories are currently broken in one serious (but fixable) way: we ve got a fantastic set of directed graphs, but none of the arrows is labelled . In other words, we re saying X is related to Y, but if you ask how, I m going to have to kill you . This makes any kind of semantic inference across those relations impossible (apologies if I m abusing terminology here but you get my point): we can t say Anyone in a subcategory of People (recursively) is also implicitly a member of People because that s making a huge semantic assumption about the relations, and one that just isn t true in the current state of the wiki.

The fix is to label the arrows: describe the relations. This is, in my limited understanding, what Resource Description Framework does. That uses the terms subject , predicate , and object . The subject is the thing you re categorizing. The object is the category you re adding it to. And the predicate describes the relation. Predicates allow you to make semantic inferences programmatically. So far in the wiki I ve seen two predicates, which I would summarise as Is an example of (John Lennon is an example of a vocalist) and Is, er, related in some way to (Musical groups are, er, related in some way to Music; 251 Menlove Avenue is, er, related in some way to John Lennon). Unless we encode this distinction in the categorization system, we can t make any inferences over the relations. And once we start encoding this distinction a whole new world of possibilities (and problems!) springs up: arbitrary relations.

I want to relate footballers to football. I should be able to use a more specific relation than is, er, related in some way to , something like is a participant in . It s the same relation you d use between basketball players and basketball, but not the same as you d use between Musical groups and Music, and especially not between 251 Menlove Avenue and John Lennon. In I want to be able to put something like:

You can see the idea. Wikipedia then encodes much more information programmatically. Incidentally, this could also be used with the tricky problem of who belongs in - you could use different relations, such as Alleged to be (for example!). It also, of course, means that we have a whole new Relation namespace to deal with - with RfD, etc, etc.

IMHO without an idea like this we can t make any meaningful semantic inferences whatsoever within the category hierarchies, and categories overall become much less useful.

(Oh, in case someone asks: yes, relations should also be related to other relations

-- 10:05, 9 Jun 2004 (UTC)

:I follow your argument, but I disagree with your solution. I believe that Categories should only be hierarchical, and the title of the category is already enough to tell the reader what kinds of articles it contains. A category that is a discipline, like Sports Sport (i.e. the discipline; Sports would be a listable subcategory of this) or Music, will contain subcategories and unclassifiable articles, while a category that is a concrete noun, like football players or musicians, obviously contains a list of them. Trying to link categories to each other in every way with a relationship code of some kind would not only be too complicated for most editors and almost all readers, it s unnecessary since the links in the articles themselves do this so well in plain English (or whatever language they re in.) Instead of trying to force square pegs into round holes making Categories do everything that Articles and Lists do and more, let Categories be a quick way to reach large, simply defined, alphabetical lists of things. 00:27, 10 Jun 2004 (UTC)

::You said earlier that everything under 08:32, 10 Jun 2004 (UTC)

:::People are creating categories from the bottom up because that s the easiest way for editors to work -- they put the four Beatles together in a category then lump them together into larger categories, because few people want to attempt to create a list of hundreds, or thousands, of articles. But however it s done, we have to make it easy for encyclopedia users to navigate from the top downward. Vegetarianism is fine within the discipline of Food and drink, as long as it isn t within a subcategory that s a list of foods or a list of drinks. If someone is looking for a famous mineralogist, they wouldn t look in a category called Minerals. Both the list of 19:34, 10 Jun 2004 (UTC)

::::I think we have a philosophical difference here. You rightly talk of the importance of top-down, and of a properly understood and maintained hierarchy. I agree completely. Where we disagree is that I think the wiki can encode much more than that (without breaking the behaviour you would like). It s clear that this is what people are trying to do, but only by breaking the hierarchy in the process. I also take the view that people are more likely to start in the middle of the hierarchy than at the top: they ll google their way to a Wikipedia article, spot the categories, and jump into the tree. Where do they go from there From a user s perspective, categories are primarily a navigational tool. Frankly it would annoy me intensely if I surfed from a footballer to , I m afraid, and throws away what could be meaningful data.

:::I think the approach to take here is to add the ability to have relations in the category. It doesn t remove anything from the system that we have now and may add something. In the first implementation off this, all that should change is that the category page would have multiple lists, one for each relationship, rather than the single list it has now. This shouldn;t be too hard to code up and add extra possibilities without any downside (apart from the implementation time). 07:40, 11 Jun 2004 (UTC)

:Yes, Wikipedia categories effort is the same than the 14:36, 2004 Jun 30 (UTC)

= Categorization of countries =

I am really confused by 20:41, Jun 4, 2004 (UTC)

:Hi. That s exactly the same issue as above. Sometimes the categories are an is a relationship, sometimes they mean is related to . 21:30, 4 Jun 2004 (UTC)

:Oh... you re right. This is why I was bad at analogies on the SATs. :( - 21:31, Jun 4, 2004 (UTC)

::As I observed above, the characteristic which seems to determine which relationship applies is the pluralization of the category s title. Otherwise 05:28, 6 Jun 2004 (UTC)

=More on nontree structure of categories=

(moved from main page)

I m not sure that I can diagram this, so I m not going to try. I m thinking about some of the dog topics. For example, dog is a member of pets ; dog is also a member of mammals ; both mammals and pets are members of animals but neither is a subcategory of the other. Now, how about 02:51, 4 Jun 2004 (UTC) ::This is very clear, and it is not disputed that some articles belong in multiple categories. (Actually, I d dispute putting pets under animals as I know people who have pet rocks and pet plants.) Anyway, your example pales in comparison to some of the existing category structure, which includes not merely 03:47, 4 Jun 2004 (UTC) :::Speaking as a public librarian, I hope you appreciate the reason why librarians need to earn a Masters degree in Library Science, or the reason why such a degree is still needed when there s Google and other miraculous computer tools. Many people think that all knowledge is hierarchical, since they see all the library books on the shelf in Dewey Decimal order, but a librarian knows that books about even a simple subject such as dogs may be found in several places. I m learning a lot about the public s view of knowledge by reading this page as everyone here tries to reinvent the wheel . Maybe, just maybe, the consensus of a thousand people will come up with a system of rules that the great Doctors of Library Science didn t. 16:31, 5 Jun 2004 (UTC) ::::More likely (or hopefully) a few Doctors of Library Science will lend a hand here when we start going astray. -- 22:13, 5 Jun 2004 (UTC)

:::Interesting stuff Gullman. Am I right in thinking that, even though a book can only be in one location various index cards are rather cheap Is that what index cards were used for To provide a proxy book in the filing system -- 02:09, Jun 12, 2004 (UTC) ::::First, many libraries are now computerized, and it is trivial to put a book in multiple categories in the computer. Second, why do you think a book can only be in one location Most libraries have multiple copies of popular books anyway, and it is not unusual to file them in different locations if they cover diverse topics. That way, people browsing the shelf find them in either place, and someone who knows about the book can check the other location if the first try is checked out. -- 16:38, 12 Jun 2004 (UTC)

= Archive of discussion on placement of category tags in articles. =

At the beginning or at the end of articles (with interlanguage links)

:Category tags should, in all cases, be the very first thing listed on the article. 17:27, 30 May 2004 (UTC)

: Strictly against this. Categories should be listed last in the article. Why We had the same discussion with interlanguage links: it s just not pretty for a new user when he clicks edit to see a bunch of categories. Put them at the end, please. -- 20:50, May 30, 2004 (UTC)

::They should be above the interlanguage links at the bottom in my opinion. 21:46, 30 May 2004 (UTC)

::: Agree. -- 21:52, May 30, 2004 (UTC)

::: Agree. 21:56, 30 May 2004 (UTC)

::: Agree (at the end of articles). -- User:Docu

::: Agree, end is the place. 01:25, 1 Jun 2004 (UTC)

::: Yep. 05:28, Jun 1, 2004 (UTC)

::: Another vote for the bottom, either before or after the w:xx s. 18:40, 1 Jun 2004 (UTC)

::: Agree, just the position where I choosed to put them myself before coming here. 20:18, 1 Jun 2004 (UTC)

::: Disagree. Category seems more natural at the top, IMHO. 17:53, Jun 1, 2004 (UTC)

::: First. Interlanguage links make more sense at the bottom because they re numerous and intimidating and not going to be edited (or understood) by newer users. Categories are the opposite: not numerous, not intimidating and all users should be able to easily understand and add categories, so they shouldn t be hidden at the bottom. 00:22, 2 Jun 2004 (UTC)

:::They should go at the bottom, after the inter-language links. IMHO, nothing, not a table or an image, should go before the first line(s) of text in the article, just to keep from intimidating a new user. 00:37, 2 Jun 2004 (UTC)

:::IMO, they belong at the bottom, before the inter-language links (which, IMO, should only be at the bottom, not both at the top and the bottom). But best would be a user preference. 09:12, 2 Jun 2004 (UTC)

::: Agree — at the end, before interlanguage links. 01:01, 4 Jun 2004 (UTC)

::: We seem to have a strong majority opinion, so refactoring to reflect it. -- 07:15, 5 Jun 2004 (UTC)

:: Just seeing that a (semi) concensus has been formed I thought I might add a differing oppinion. How about we have the software decide where to put them. That way it could be a preference value whether it go at the top or bottom. Additionally, everyone can argue^H^H^H^H^H discuss what the default should be. 07:54, 11 Jun 2004 (UTC)

:::There are two issues here. 1) Where to put the tags on the displayed page (which could be a preference, and can even now be changed in your css ). 2) where to put them in the RAW unparsed article text in the editor. The above discussion ONLY talks about this second item, and it would not really make sense to have a preference for that. -- 17:04, 12 Jun 2004 (UTC) ::::I assumed the discussion was about the first issue. If the software was configurable with respect to the first, the second seems a mute point, as the software will display it at the right stop regardless of where it was placed. 02:05, 13 Jun 2004 (UTC)

=Renaming Catgeories=

It is apparently impossible to rename a Category article once it has been created. I am for example unable to move Catgeory:Australian MHRs (which is an incorrect form) to the correct Category:Australian federal MPs, so now I am going to have to delete them all. (This is

:Yes, you did tell me that, so I did some time researching, found the terms are close to equivalent (and if not, MHR is less ambiguous), and yesterday I added some articles into the category. Today I find that you had deleted the references from all the articles. Interesting, if you were willing to go to the effort of deleting them, why did you not just change them, which would have been a lot less effort (for both you, and for whoever adds the articles to whichever group it is decided is appropriate) 05:06, 6 Jun 2004 (UTC)

This problem must be urgently fixed or it will cause endless fights. 15:43, 5 Jun 2004 (UTC) :There s no way to change an article s categorical affiliation without directly editing the article itself (at least, not yet). Even if it were possible to move a category, doing so wouldn t list the articles in that category into the new one. Right now the only solution is to manually change every article linking to the old category to the new one, then put the old category (now an orphan) into 17:26, 5 Jun 2004 (UTC) ::It s possible to move an article, and that doesn t magically fix any links in other articles. That issue is solved by making the old page a redirect to the new page in case of a move. Now, if redirects for categories would work (I ve found to my surprise they didn t), moving a category wouldn t be a problem. 22:15, 5 Jun 2004 (UTC)

A most unsatifactory state of affairs. This whole scheme will cause as many problems as it solves, maybe more. 17:52, 5 Jun 2004 (UTC)

::Oh sh**. I ve wasted half a day cos I misnamed a category and added fifty people to it before someone pointed out my error. groan . Now, I am probably diligent enough to sort out my own mess. I wouldn t assume the same of others. -- 02:13, Jun 12, 2004 (UTC)

=Minor Categories=

Might it be possible to have a minor category (or organizational category or invisible category or whatever you want to call it) Perhaps put a small [see more categories] link in the current Category box, with the link either revealing a hidden box below the current one, or taking you to separate subpage of the article with the full category list.... This way categories that are important to the reader would be visible in the current box, while those that are useful but redundant (or more useful to the editors/organizers than the readers) could be hidden from casual view, but easily reachable by those who are interested.

Even if the the minor category idea is unworkable, I suspect a [see more] functionality will be needed eventually, if certain articles end up placed in more than a small handful of categories.

What do you think -- 22:21, 5 Jun 2004 (UTC)

: I m confused as to what you re suggesting. Could you provide an example 08:06, 6 Jun 2004 (UTC)

::I can t tell whether this will be helpful until we see how Categories are going to shake out in general, but I just thought I d throw the idea out, in case it helped influence the evolution of the discussion.

::Say you have an article on Nile Rodgers (just picking it because it s one I did research on and expanded recently). He s American -- African-American, to be precise. He s a record producer. He s a guitarist. He was a member of the band Chic. He has organized a charity foundation. He owns a prominent African-American-run business. There are a couple of different ways you could do this, but I guess I was picturing the main category box like so: :::Categories: African-Americans | Chic members | Guitarists | Record Producers (etc)

::And a separate, hidden-by-default Minor Categories box like so: :::Minor Categories: African-American record producers | African-American guitarists | Biographies of people whose name starts with R | People who have worked with David Bowie (etc)

::Which categories went where would be a whole nother level of editorial judgment (and potential editorial disagreements), but primarily the idea is as above: hide things that are useful but redundant or organizational (i.e., more useful from the category list page than from the article page). And it s always just a click away from someone who s interested in more detail.

::Obviously some of the redundancy I thought of at first is taken care of by including articles in only the most specific category; I am sure there are other cases which will not be so clean, however. The other main advantage I see is that it allows the construction of more interesting but obscure or very specific lists without cluttering the main Category display. (Of course that might be a disadvantage, as well....) As I said, just a thought I wanted feedback on. Thanks! 03:58, 10 Jun 2004 (UTC)

Ah, I understand. I agree - this would be really nice if we could do that. Any developers about 04:06, 10 Jun 2004 (UTC)

=Rendering on Category Pages=

I ve seen several complaints about the free-form structure of the list of articles belonging to a category. Take a look at , for instance. The top half is the neat tree found in the old-style list. Below in the box is an automatically generated unsorted jumble of articles that belong in the category. These are the solutions I see:

1.) Merge lists of articles into category pages, but manually maintain structured copies in the editable sections. This requires more work, but at least there s only one page (to help maintain consistency between the manual and automatic lists).

2.) Put some tags in the editable section of the category page that tell the system how to create a properly sorted nested list. This is possibly easier for editors, since all the changes they need to make are on a single page, but when new articles are added to the category, they will also need to be put into the sort order by futzing with the category page, or else end up in an unsorted section. This option also makes it really easy to re-factor.

3.) Put tags in the article themselves that allow the system to sort them in a nice way. A bit of syntax that might help might be to stick sort strings after the category name with a / as a separator. So for example:

:

The sort order would have to be defined somehow - it could be automatic, or specified in the category page. But it would be especially annoying to distribute the sort order among the article pages - that would make renumbering really annoying.

(Note from later on - / would be a bad choice of character, since this conflicts with the literal / in URLs.)

4.) A hybrid method, in which editors have a list-making interface similar to what is envisioned in option 2, but when the information is stored, the system goes back and writes tags as in option 3. Easily editable, easily renumbered, but all the category information is kept in one place. Harder to implement in code, though, and more resource-intensive.

-- 10:12, 5 Jun 2004 (UTC)

5) For really long lists of stuff, it would be nice to simply break it up into alphabetized sections with letter headers. The software could be told to do this with a TOC tag of some sort, or it could do this automatically whenever a certain size threshold is reached. Another simple formatting option could include telling the software to put the links in a bulleted list instead of a comma-delimited string. 02:04, 6 Jun 2004 (UTC)

:Layout of the article lists could use some improvement, even where they easily fit on one page, the layout from may be of help. -- User:Docu

:I agree with Bryan on every point. To make good use of the Category system its implementation should be improved. For example, if I where to have a list with the names of a few people it would be nice if the year of birth/death could be mentioned next to it. The way it s done on the biography pages so the year of birth should not become a link to the person. Possible way of implementing 19:16, 12 Jun 2004 (UTC)

The rendering on category pages has changed to make subcategory and article listings multi-column. That s nice. But it has also added big, bold letters at the start of each letter in the alphabetical listings. This is a big waste of space and looks quite ugly when there is a small number of items. See for instance: or [[:Category:Wikipedia]. I think it should be obvious when a list is alphabetical, and navigation in an alphabetical list is fairly trivial - you just go up or down as appropriate (even if it s wrapped into multiple columns).

I would urge disabling the letters, at least for lists with a small number of items (perhaps less than 30 or so), if not all auto-generated lists.

I like the idea of generic metadata tags. Embedding a character into Category tags is a big kludge (and / is a bad choice of special character, too) and capability would be very useful in many other ways, as described. It also makes creating multiple structured lists inside categories a lot easier.

Given metadata in biography articles that specified birth year, name, and subfield, you could automatically create three different lists (perhaps in different subcategories) that were sorted in three different ways.

I wonder if embedded XML would be a good choice for this. There are WWW-wide XML standards being developed for just this sort of situation, and perhaps it would be good to interoperate with them. If that s too complicated, we could do something like:

...and make a list of valid key names and what they should be used for.

We would also need metatags for Show an auto-generated list of articles/categories with the following matches in their metadata and the following sort order .-- 02:14, 13 Jun 2004 (UTC)

The rendering should say 1 article/subcategory in this category not articles/subcategories.-- 04:59, 13 Jun 2004 (UTC)

:XML would certainly a good option for creating metadata, the only problem I have with it is that we now have Wikitax, and I like Wikitax :) I do think metadata would prove to be a valuable addition to Wikipedia, not only in terms of categorisation but on other fields as well. Some aspects of Wikipedia are very structured: the albums, countries, biographies etc. These aspects all contain more or less the same information. An biography will always have the name of a person, his year of birth, place of birth, if we would incorporate this information that is always present into metadata we can create a highly flexible system. For example the metadata for an album would look something like this.

:With this method of metadata you can get rid of those ugly tables in each album/country entry and instead you can build a template that is filled in by Mediawiki with the given metadata. This allows that at once all album entries can change colour or can even become part of a skin. Of course this would also be very helpful in the perspective of categorisation. With these four tags I mentioned you can already make a list of all albums, albums by the Beatles, all albums in 1968, etc. -- 10:47, 13 Jun 2004 (UTC)

= Contents of Categories =

What kind of things should be in 13:32, Jun 8, 2004 (UTC) :The way bands should go, from what I can work out: : , etc) : , etc) : : : (Now here s where I mess up...) - . :The reason for this is that if it was, all the articles under and get only the articles that are groups, albums, or people. Unfortunately it s not that easy to read it, go oh yes, that makes sense , and do it. I ve stuffed it up a couple of times. :In the same way, 14:04, 8 Jun 2004 (UTC) ::I think you re being too pedantic about the categories. It isn t a tree. Putting category John Lennon under The Beatles members does not put the stuff in that category under The Beatles mebmers . If that were the case, then it would almost never make any sense to put a category into two other categories. I don t think you can carry the relationship beyond one link all the time. -- 04:26, 9 Jun 2004 (UTC)

:::Well, I m just following the pattern set by ScudLee s example diagram at the top of this page. Everything under People should be a person. Everything under Musical group should be a musical group. Everything under Albums should be an album. The category system is designed to allow this to work, so it would be pointless not to take advantage of it. -- 06:32, 9 Jun 2004 (UTC)

04:38, 9 Jun 2004 (UTC) :Well we could just as easily put each member in 06:32, 9 Jun 2004 (UTC)

Actually, I wasn t referring to the article/category 08:00, 9 Jun 2004 (UTC) :(John, The is part of this particular band s official name -- see

=Piped category tags=

I had an idea and attempted to configure the 20:16, Jun 8, 2004 (UTC)

:I think that piping categories is used to change how the page is sorted on the category page, not how the text appears. 22:18, 8 Jun 2004 (UTC) ::Drat! Foiled again! 23:02, Jun 8, 2004 (UTC) :::You re not the only one that thinks it s a good idea. -- 23:17, 8 Jun 2004 (UTC)

:I think the piped link should be used to change the way it appears (as it would for normal piped links) and as a secondary effect, also be the sort key when listed in their respective categories. 03:11, Jun 11, 2004 (UTC)

:I think pipe links in categories are fine as is -- changing sort order, not changing headings. However, it would be very interesting if categories had an alternate view that showed the piped name ( sort keys ) instead. In some categories, both would be useful. -- 16:41, 12 Jun 2004 (UTC)

=Questions about categories=

My main question is about changing a category. What I ve noticed is that if you edit an article and rename the category ie if the category was incorrect or too general, it will create a link in the new category page, but the link remains also in the previous category page, even though that link does not show on the subject article page. For example Jack Nicholson was originally categorised as Category:Actors . I d read on the categorisation talk page that Paul McCartney should be British musician, but not musician, because British musician would be a subcategory of musician, so I applied the same logic and changed Jack to Category:U.S. actors and actresses where he now appears. But in the Category:Actors page he still appears even though there should be nothing to link him there, and in the Jack Nicholson article page, the only category now visible is Category:U.S. actors and actresses . Does anyone know why that would be Am I doing something wrong or is there a problem with the database or what :No, it s nothing you ve done wrong - unless someone else has changed it in the meantime, its just a caching issue - your machine still has the old versions of the page. I ve found even forcing a full refresh doesn t help, you just need to wait a while. BTW, I noticed there are a lot of names under 13:15, 9 Jun 2004 (UTC)

thanks for the info, and I will wait and see. Although some of the ones that I changed were about 4 days ago and the change still doesn t show. Not a problem though. Yes I agree there s a lot needing to be recategorised, and a lot that haven t been categorised at all. I m sure it will all happen soon. 13:58, 9 Jun 2004 (UTC)

Also another question which is less important but I m trying to get my head around categories and subcategories. So .. Category:Vocalists and Category:Pop singers . To me, all pop singers are by definition vocalists, so along that line of thinking every person categorised as a pop singer should also be categorised as a vocalist. But is that the intention Should vocalist just be for a band s vocalist ie Robert Plant vocalist, but not pop singer. Along the same line I would categorise Belinda Carlisle vocalist (Go Gos) and pop singers, (solo). Britney Spears pop singer, but not vocalist Would be interested to hear how anyone would interpret this. Thanks

:I would think Vocalists==Singers, therefore Pop singers is a sub-category of Vocalists. Then you have the Britney thing. It doesn t matter how NPOV you want to get, or what you think of her, she can t sing live and shouldn t be classified as a vocalist. 13:15, 9 Jun 2004 (UTC)

That s exactly the point I think - categorising is sure to create examples that are POV. As for Britney, I d call her a vocalist only insofar as the sounds she makes, do seem to be coming from her mouth, which is not to say that I don t like her or think she s without value, just without talent. Will be looking forward to reading your 13:58, 9 Jun 2004 (UTC)

And now I ve just discovered that the category pages can t be linked from here. Which is why I ve italicised them instead. As if I wasn t confused enough! 10:20, 9 Jun 2004 (UTC)

:Just type [:Category:Category name]] (note the extra colon before Category ). 13:15, 9 Jun 2004 (UTC)

Would Hilton be 23:50, 9 Jun 2004 (UTC)

:I ve occasionally mused that 05:21, 10 Jun 2004 (UTC)

: 01:37, 10 Jun 2004 (UTC)

=Categories that are list of versus categories that are articles about =

There s been a lot of discussion about what it means for an article to be in a category or in the subcategory of a category, such as whether articles in subcategories inherit the parent categories as well. I ve been running into this problem myself as I try to figure out what should go where. Perhaps to try bringing a little order to the chaos we could work out some sort of standardized way of indicating that a category s children should or should not inherit it A set of templates, perhaps, giving guidelines to editors about how the category is to be treated that could be inserted on category pages. 03:14, 10 Jun 2004 (UTC)

:That would be wonderful. Right now, we have no clear direction, and different people are implementing competing (and incompatible) systems. 19:58, Jun 10, 2004 (UTC)

::Okay, in the spirit of boldness then, I give you 00:59, 11 Jun 2004 (UTC)

Here s the text that s currently in them:

Subcategories inherit:

Subcategories don t inherit:

:::This problem would be solved™ by describing the relation in the categorization system: see the Describing the relations discussion above. This is very definitely not a binary inherit/not inherit problem: there are many different ways we might want to relate/are already relating things in a formal way, so that the underlying system can make semantic judgments programmatically (including that 09:33, 11 Jun 2004 (UTC)

::::Yes, but unfortunately I m not a developer so I m limited to the tools which are currently available. These templates wouldn t work in all situations, but they will work in some situations so I think they can still be a useful stopgap until support is added for giving subcategories meaning. I ve experimentally placed one of these templates on 23:27, 11 Jun 2004 (UTC)

=Simplest categories=

My understanding is that the purpose of the category system is to allow automatic cross-checking of lists. Wouldn t the best way to do this be to make each category give one fact 05:14, Jun 10, 2004 (UTC)

:Or one could do it by having Category:Musicians and Category:American people both inherit the contents of Category:American musicians. I suspect it ll be hard to reach a consensus on which of the two approaches is the One True Best Way; I can see the appeal of both of them. 05:18, 10 Jun 2004 (UTC)

::It would be neat to search by category like that. But first, all people must be put in their nationality category, and I notice a lot of people editing category stuff don t bother to look for nationality, etc... Has anyone done a bot to partially automate any of this -- 02:39, 11 Jun 2004 (UTC)

=More piped link fun=

So, having discovered, much to my dismay, that piped links can not be used to change an article s display on the category page (merely its alphabetic classification for ordering purposes), I decided to do so to organize 22:35, Jun 11, 2004 (UTC) :: Yes I m guessing it is a bug in the sub category listing code only, using the pipe on an articles worked for me on 01:19, 12 Jun 2004 (UTC)

=What a mess!=

This talk page s 22:41, 11 Jun 2004 (UTC) :That s because there s not really any agreement on how to use, start or suggest categories... Things should settle down soon, I think (hope...). (BTW, I m archiving this talk page because it s huge -- I don t mean to step on anyone s toes by removing discussions) 22:48, Jun 11, 2004 (UTC)

:There is a user guide, which was at 22:50, 21 Jun 2004 (UTC)

= Putting articles into the smallest category only is wrong =

I think that trying to use the category functionality for precise classification, searches like Poets AND German and whatnot is futile. It was neither designed or is suitable for it. It didn t work with the old subpage system and it won t work with something as simple as ParentCategory=X . To do that in a useful way, we would at least need name-value pairs, if not something even more sophisticated. I don t think that our hardware and software will be up to that any time soon.

OTOH, categories are perfectly useful for bottom-up constrution of TOCs: just add , and Luxembourg appears in the list of European countries. Except, the way we do it now, it doesn t, because we put it into EU Countries , which is a subcategory of European Countries . So, if I want to find something, I more or less have to know where it is.

The way it really should work, is that an article should be a member of all categories where we want it to show up in the list. So, London should be a member of Cities of England and Cities of the UK and Cities of Europe and Cities of the World , while Leibnitz should be just a member of Cities of Austria . Accordingly, Johann Wolfgang Goethe should be a member of German Poets , European Poets , Poets and German Scientists .

This leads to every article being put into several categories: the more important the article, the more categories it will belong to.

If and when a full classification and search system is implemented, more categories per article will provide more data to be pumped. 13:46, 12 Jun 2004 (UTC)

:I m not sure how I feel about that. I agree that splitting Europe into EU and otherwise is probably silly, and there are few enough countries they could all go into Europe. However, would be worse. I think those should be split as is, and leave the top category for people who we haven t figured out how to categorize.

::I think that whether something should go into a larger category should be based on it s overall relevance to the category. For example in 09:57, 8 Jul 2004 (UTC)

:But some categories are definately too deep, even within the People heirarchy. More of a concern to me is that when editors put people in the categories. they are not being thorough. They don t put them into enough categories, and they are not putting the sort tag in, and worse, they might add two categories with the sort tag, but leave the adjacent three or four without a sort tag! Anyway, this will all be sorted out eventually. -- 16:31, 12 Jun 2004 (UTC)

What I would like to see is something automatic, where if you go to the page on Category A, you see a list of all articles, not only in A, but in all its subcategories, subcategories of subcategories, etc. Is anyone working on this -- 15:47, Jun 18, 2004 (UTC)

:[http://sourceforge.net/tracker/index.phpfunc=detail&aid=964667&group_id=34373&atid=411195 RfE 964667] is probably the closest task in sourceforge and is currently unassigned. -- 17:20, 2004 Jun 18 (UTC)

::The other problem with only using smallest categories is you end up with examples like the novel 11:14, 8 Jul 2004 (UTC)

:::And, furthermore, it s ridiculous that if you want to get from 11:23, 8 Jul 2004 (UTC)

::::I d also add that I ve noticed a sudden rash of classification of tv series into categories solely by which network broadcsat them (originally). This is both *very* US-centric, and useless for those who don t know that WB, CBS, whoever were involved. It may be useful for some people, but not to the vast majority. I would go around removing unusable categories like this but I have seen people then break them down even further so stand clear instead. -- 11:47, 8 Jul 2004 (UTC)

= Functional versus taxonomic categories =

Moved this here from the main page (but left a summary behind). -- 09:40, 13 Jun 2004 (UTC)

I recently built Category:Commercial item transport and distribution (CITD), which culls articles related to all aspects of this particular field. Another user was concerned that it might be too scattershot and non-specific, and proposed breaking it up. I think, however, that this new category points up an emerging difference in how categories may be used. Although I didnt explicitly set out to do so, I created in CITD an example of what could be called a functional category, as opposed to many of the examples used on this page, which set forth a fairly straightforward taxonomy approach to pulling articles together.

In categorizing these categories as taxonomies, I mean that it takes very little external context to pull together the articles in the category, just common, low-context knowledge like the alphabet and geography. You could probably send in a bot to check keywords and pull together categories like Companies that begin with the letter H or Companies in Germany.

By contrast, the CITD category itself contains substantial pieces of contextual information within it, namely, that there is such a thing as the commercial transportation and distribution industry and which particular things pertain to it. You wouldnt pull together disparate articles such as on the companies FedEx and Hapag-Lloyd, the items pier and containerlift, and the concepts materiel and logistics, unless you already knew that they all happen to be pertinent to this particular industry. In other words, the very category itself informs the user somewhat. It would be much harder to use a bot to build a category like this, or at least its search algorithm would have to be more complex, containing a dose of contextual knowledge about what it was looking for.

A functional category like CITD is well-suited to the user who is drilling down from the main page in generalized exploration. It answers the challenge of supplying information to the user who may not even know what they are looking for. By contrast, a user more knowledgeable on a topic, say, ornithology, might be more likely to go straight to a taxonomic category like All bird names that begin with the letter G .

I see a great use for functional categories for big human nexus events, like Category:World War II. That category (though big enough that it s through subcategories) can eclectically collect everything from the brownshirts and the Holocaust to the Norden bombsight to Glenn Miller and Rosie the Riveter.

There is a limit to everything, of course, so I can see a functional category could be taken too far, or even used as a form of disguised original research: If you hold the hypothesis that parrots are controlling the minds of chiropractors, you might build a category that includes everything about parrots, mind control, and chiropractors. That would be an abuse of the encyclopedic genre. By contrast, I have been defending CITD on the ground that it is indeed a real and natural grouping. While it is not as clear-cut as Companies that begin with the letter H , it is sufficiently cohesive, unitary, and real in the world that grouping its elements together is not an abuse of the encyclopedic genre. Im not defending CITD here, and whether CITD itself happens to be a good functional category isnt really the point here, but rather that functional categories do have a place beside taxonomic categories in Wikipedia.

If there were only one categorization possible for each article and thus we were working on the One Table of Contents, the dispute between functional and taxonomic categories might be more pitched, but fortunately we are not so constrained. The two types of categories may exist side by side, and users will benefit from both; users who are more focused on specific information retrieval might find 23:05, 9 Jun 2004 (UTC)

:Some time ago, I pulled together a few things into

:: If those other items would be useful to someone wanting to understand RF propagation who was browsing in the category tree, I would include them. I don t think their inclusion in other categories affects their usefulness in this category. -- 19:18, 13 Jun 2004 (UTC)

Hmm...I think there s something to be said for the idea that categories are not the most logical way to deal with what you call functional categories. List pages, the actual article on commercial item transport and distribution, and so forth, seem to me to be a better way of dealing with these kind of things. Otherwise, categories will quickly become completely out of control. I support restricting categories to what you call taxonomic. 16:06, 13 Jun 2004 (UTC)

:My justification for functional categories is that they tie together a concept or field of endeavor immediately for someone who is browsing in the category tree, and they locate it within the hierarchical context of all categorized subjects. We could do a similar tie-together with a massive list on an article page, but the user won t get there unless he chooses that article. If the grouping isn t within the tree, the user may miss it if he doesn t apprehend the significance of the one collecting entry, like commercial item transport and distribution. But this other way, he can t miss it. Still, I may be missing important downsides to this; what is your concern with putting functional categories in the category tree -- 19:18, 13 Jun 2004 (UTC)

::One thing that categories do that lists or overarching articles do not do is provide an easy way for someone to find their way from a small article (like an article on the United Parcel Service, for instance) to a bunch of related articles (say in the CITD field). With lists and articles, you can only go from main concept to supporting concepts, not the other way around. Unless you do lots of linkbacks and cross-references, which is exactly what categories are, except the maintenance is easier. -- 04:01, 14 Jun 2004 (UTC)

:::Might be possible to utilize the best of both by including links and explanatory text to guide readers to selected high-level lists and articles in the introduction for appropriate categories. However, whether or not maintenance is actually easier for categories over lists is debatable, IMO. Renaming a list is easy, while renaming a category would involve replacing the category everywhere it occurs. Adding an article to a category is somewhat easier, provided one remembers to do it while creating or editing the article--otherwise you have to go into the article for the sole purpose of adding a category, which is not much easier than adding the item to a list (though if adding multiple categories at one time, then cats have the edge). For backlinking, yes, categories do have the advantage. IMO, the main disadvantage to categories are that they convey less contextual information than a well-structured list or overview article. They are nice for browsing, if you are simply curious or if you already have a basic familiarity with the terms used, but if you don t already know how the elements in a category are related to one another, it is not very helpful. 17:42, 14 Jun 2004 (UTC) ::::All extremely good points! I rarely edit an article just to add one category--I try to add several at once. -- 03:16, 17 Jun 2004 (UTC)

=Expand usefulness of categories and lists=

I m not sure I have an opinion on the issue directly at hand, but I have a suggestion.

List pages of various kinds and the growing number of categories all attempt to organize information in an easy-to-use-and-edit fashion that provides relevant links with appropriate context to articles. I think there s pretty widespread agreement that whether categories or lists, or both, are used, the goal should be as above. Both list pages and category pages could be better at achieving this goal. Let s brainstorm what we need and want in such a system, then pester the developers until it happens.

What kind of information should be categorizable. The fact that a person is a musician, a Canadian, a trumpeter and a jazz musician are clearly relevant. Should our system be able to accomodate less relevant tidbits (that he s left-handed, male, more than 6.5 feet tall and a 1986 Grammy Award winner for Best Jazz Album) Should it be possible to combine categories using the MediaWiki software in a way that could create a list of Jamaican-British MPs What about Jamaican-British MPs who voted against joining the EU If albums are classified by both year and genre, could we automatically see what the earliest hip hop album with an article is Could we tag more information, and see what the earliest hip hop album by a white man to go gold in Australia is What about list-ordering Do we have to classify something like Popes in either alphabetical or chronological order, or could we tag info to generate a list in either way, or by nationality or some other criterion Could we take tagging a bit farther and automatically generate something like )

Anyway, these are just some questions to get started... Seems to me that a very simple system was put into place, and nobody s really satisfied with it, but since the software is constantly evolving, we have the ability to make the category system even more useful than anybody reading this discussion now is likely imagining. 19:32, Jun 14, 2004 (UTC)

:I think that if a category includes only one or two items, it is probably unnecessary. (However, if there is only one article now, but we anticipate more, that s a different story: I created a category of Shorthand systems which has only 2 articles, but more ought to be written on other systems.) - 14:52, Jun 21, 2004 (UTC)

---

Interesting questions.

So it appears that categories are currently being used for both semantic/taxonomic classification (A is a type of B) and navigational/functional linkages (article C is related to topic D; subcategory E is a subset of topic D, etc.).

This means that direct and indirect membership may not carry a clean semantic meaning. For instance, the articles that are members of Category:Units_of_measure or its subcategories are mostly actual units of measure (foot, volt, kilogram, etc.). But other articles include a list (Scientific units named after people), general articles (Historical weights and measures), and related articles (Dimensional analysis). This messes up queries like show me all units of measure that begin with the letter H . It may also cause the following query to include unwanted results: show me all article-descendants of Category:Units_of_measure that share at least one word in their titles as a title of an article-descendants of Category:Scientists .

Even worse, navigational linkages make the recursive lists of subcategories potentially uselessly large. For example, consider the following chains:

Systems of Government -> Monarchy -> Royalty -> Royals People -> Royals -> Royalty of England -> Queen Elizabeth II

This unfortunately may lead an automated search to conclude that (among other things) the concept Royals and the person Queen Elizabeth II are examples of governmental systems.

To solve this problem, linkages could be assigned types. For example (using an XML syntax):