A proposal about how to replace categories

[David Cuenca]

I suggest using the approach: "search, don't sort". That involves the use of tags.

For instance, following the Monet example. If Monet were tagged as "people" "painter" "french" "impressionist" "paris", that gives a lot of flexibility.
One might look for:
- people paris
- painter french
- painter impressionist
- french impressionist
- painter

And Monet always would appear in the results. Additionaly I suggest to include in the search results (maybe on top), a list of the most used tags in the results (for instance, 10), removing those which are common to all the articles. A click on one of those tags would perform a new search of the previously typed tags plus the new one.

[tkjazzer]

again, I think recent changes within health science workgroup would be VERY useful.  I get so frustrated when I go to wikipedia and want to see what articles are being worked on and I can't just look at recent changes because the list is too long.  You try to go to related changes from an article and it doesn't link very well.  If you go to a portal...

just find a way to tag all the health science articles and then check the recent changes please.

[Larry Sanger]

The main problem with a category system is that if it is not perfect it is of very little use. It is also of very little use even when perfect.

That depends on what you think their purpose is.  If their purpose is supposed to be a source of data for search, then I think I'd agree.  But if their purpose is to provide information to the user about what subtopics and related topics there are, then they are an essential part of a general introduction to a topic.

[tkjazzer]

We need to educate new writers on which categories too add to articles or have workgroups assigned to figure this out.

For "related changes" within a category to work, we need to have general categories on every article.

For example, go to WP biology category and click related changes.

The only changes you see are biology, ecology, etc

This is because all of the subgroups are not listed in the related changes.

[tkjazzer]

Ok, I think we revolutionized how to use categories since now we have workgroup related changes.  Check out:

http://forum.citizendium.org/index.php/topic,539.0.html

[MarkusBaumeister]

Despite this thread being hijacked for the "Recent Changes" issue let me state my opinion concerning categories.

First I consider it useful to be able to add a "category" entry to an article itself and have the system automatically create the downlink to it. Why do by hand what can be done by a computer. This is in contrast to what Larry proposed about hand-editing all the (hierarchic) downlinks into the top article.
Second I think the thread shows that we have actually two uses of categories:

• The (somewhat) hierarchical backlink (often within several disjunct hierarchies). This is what Larry's proposal addresses
• The list creation (i.e. the songs of Beatles, railway stations of Britain, railway stations of Wales, .... kind of examples). Here one typically does not want to write anything into what I would call the "collecting" article as that would have gone into e.g. the "Beatles" article or the "British railway" article. And you definitely do not want to edit these lists by hand. This is not addressed by Larrry's proposal.

Yet I think the idea that a category must always also be an article is useful. It unifies the namespace and somewhat prevents proliferation of categories. What I could thus imagine is the following:

• The title of any article approved as category by an editor can be used as category.
• The category markup is then added to the daughter article as it is in WP.
• Creation of the downlinks is done automatically by the system from the article (e.g. under the proposed "subtopics" heading).

As a result hierarchical categories somehow follow the idea of Larry (only use as category what is also an article) but avoid the problem of having to change the category article for each new member of a category (which could be quite some work for article contained in several hierarchical categories). There could be some rules already proposed (e.g. no explicit transitive category links) for this, too.

For list categories one has to create an empty collecting article (maybe even write a sentence or two into it) and get an editor to approve it as category. If later on that list category is considered useless, simply delete the collecting article and the list is gone.

Too ease tool use of the categories one might want to use different markup for hierarchical categories and list categories. Yet tools is much easier this way than if a tool would have to parse the article text for all links under the "Subtopics" heading.

Only problem of course: Probably not doable with current wikimedia code.

[Larry Sanger]

Some replies:

Despite this thread being hijacked for the "Recent Changes" issue let me state my opinion concerning categories.

First I consider it useful to be able to add a "category" entry to an article itself and have the system automatically create the downlink to it. Why do by hand what can be done by a computer. This is in contrast to what Larry proposed about hand-editing all the (hierarchic) downlinks into the top article.

Well, as long as we're dreaming about ways to change the code, one could automatically create downlinks and uplinks based on the contents of specially titled article sections.

Anyway, I'm not sure I see the advantage that you do.  What exactly is the advantage?  You place a tag on an article, and then a list is automatically created.  How is that easier, for either contributors or readers, than simply maintaining a list on the article?

Each act of placing [[Category:X]] on article Y, and saving, directly replaces act of placing link Y on article X under "Sub-articles," and saving; but you can place as many links Y1...Yn under "Sub-articles" on article X and save once, and that one act directly replaces n separate page edits.

Of course, my way, it is conversely more difficult to edit parent categories--there one has to edit each of the parents for a given (multi-parented) child.  But since there are almost always many more children than parents, my way is still more efficient.

Second I think the thread shows that we have actually two uses of categories:

• The (somewhat) hierarchical backlink (often within several disjunct hierarchies). This is what Larry's proposal addresses
• The list creation (i.e. the songs of Beatles, railway stations of Britain, railway stations of Wales, .... kind of examples). Here one typically does not want to write anything into what I would call the "collecting" article as that would have gone into e.g. the "Beatles" article or the "British railway" article. And you definitely do not want to edit these lists by hand. This is not addressed by Larrry's proposal.

I don't know whether or not I said anything about it, but I have always thought that it is necessary to have some "List of X" articles.  I was actually the person who started that convention on Wikipedia, if I remember right.  And this is far superior to Wikipedia's current clumsy solution, which requires that you edit 100 pages to create a 100-item list, rather than simply make 100 lines in a single page.

Yet I think the idea that a category must always also be an article is useful. It unifies the namespace and somewhat prevents proliferation of categories. What I could thus imagine is the following:

• The title of any article approved as category by an editor can be used as category.
• The category markup is then added to the daughter article as it is in WP.
• Creation of the downlinks is done automatically by the system from the article (e.g. under the proposed "subtopics" heading).

As I said above, assuming that we always use the same section title for the subarticles, isn't this isomorphic to my proposal--couldn't we easily do what you propose, and with fewer keystrokes, if one simply codes the software to parse out what the subarticles are?

As a result hierarchical categories somehow follow the idea of Larry (only use as category what is also an article) but avoid the problem of having to change the category article for each new member of a category (which could be quite some work for article contained in several hierarchical categories).

...but not nearly as much work as having to include a bunch of articles in one category (as I said above).

Too ease tool use of the categories one might want to use different markup for hierarchical categories and list categories. Yet tools is much easier this way than if a tool would have to parse the article text for all links under the "Subtopics" heading.

Hard to say what would be harder, quite frankly...

[Chris Day]

First I consider it useful to be able to add a "category" entry to an article itself and have the system automatically create the downlink to it. Why do by hand what can be done by a computer. This is in contrast to what Larry proposed about hand-editing all the (hierarchic) downlinks into the top article.

Anyway, I'm not sure I see the advantage that you do.  What exactly is the advantage?  You place a tag on an article, and then a list is automatically created.  How is that easier, for either contributors or readers, than simply maintaining a list on the article?

Second I think the thread shows that we have actually two uses of categories:

• The (somewhat) hierarchical backlink (often within several disjunct hierarchies). This is what Larry's proposal addresses
• The list creation (i.e. the songs of Beatles, railway stations of Britain, railway stations of Wales, .... kind of examples). Here one typically does not want to write anything into what I would call the "collecting" article as that would have gone into e.g. the "Beatles" article or the "British railway" article. And you definitely do not want to edit these lists by hand. This is not addressed by Larrry's proposal.

I don't know whether or not I said anything about it, but I have always thought that it is necessary to have some "List of X" articles. 

I have bolded what i consider to be the take home points above.

How about going through a case study? I'd like to see how this will work in practice. I have started a new thread (so as not to hijack this further):
http://forum.citizendium.org/index.php/topic,593.0.html

[MarkusBaumeister]

Anyway, I'm not sure I see the advantage that you do.  What exactly is the advantage?  You place a tag on an article, and then a list is automatically created.  How is that easier, for either contributors or readers, than simply maintaining a list on the article?

I think what we have here is ...... a difference in envisioned use cases ;-)

Lets call the two approaches the "parent list" approach and the "child tag" approach (to avoid speaking of "yours" and "mine" which they are not since they are simple general approaches). The Parent List approach fits well if the standard use case is that someone sees/searches for a lot of articles and then decides he wants to create a category for them. With Parent List he has to create only one article and somehow copy the list he has on his screen anyway into that article.
The Child Tag approach on the other hand works smoothly if someone creates (or edited) an article and notices it should be in one (or several) categories. Simply add the category tags to the article in edit and be done.

IMHO the second use case is more prevalent and is actually the one we should strive for as it will spread work more. With Parent List we will probably end up with people (editors?) generating and regenerating (after new articles were added) downlink list. With Child Tag we could ask everyone to take care of the categories for new articles himself. We could even add a "Are categories present" check field to the article checklist (No Sir, I honestly didn't mention Larry's pet project to gain his approval for Child tag ;-). And since categories have to be articles in the hierarchy anyway, I would assume that most often the category will already be there once an article is written (assuming we will mostly work down the hierarchy once a minimum set of articles is in).

 (Note that probably both approaches are self-fulfilling prophecies, i.e. if one is implemented the use case better supported by it will be the one we will see most often).

But there are more advantages to Child tag than just which use case is better supported:

• With Parent List the sorting and arranging in columns of the downlinks has to be done by hand by the one adding the list, possibly including rearrangements/formattings if the list becomes too long. With Child Tag it will be done automatically.
• Parent List has problems with the concept of "approved" articles. To add a topic into a category with Parent List, the Category article has to be reapproved (as it is edited). That is IMHO counter-intuitive. The fact whether an article belongs to a category is an attribute of the article and should thus be protected by the "access control rights" of that article. This is the case with Child Tag, whereas Parent List will probably lead to annoyed editors.
• If I understand the Parent List proposal correctly, category downlinks will be all the normal links following the ==Subtopics== headline until the next headline. In contrast with Child Tag, categories are created with adding a [[Category:foobar]] "tag" anywhere in the article. Parsing the second is easier as it is just one regular expression to find all categories. For Parent Link you either have to construct a complicated RegEx to find all links between ==Subtopic== and the next headline (better hope no one uses "==" within a link)

[Joe Quick]

Here is what I imagine.  Forgive me if it has already been covered and I missed it.

Back before the unfork, I rewrote the category Maya Peoples.  It only has one article so far, but I hope to gradually fill it up over the next few months. This process will also include an article about the Maya macroculture which the ethnic groups in that category share. 

Ideally, I would like to write the "Maya Peoples" article in the page that is currently just a category. The reason is that any new articles that are tagged "Category:Maya Peoples" will automatically show up as relevant links at the bottom of the parent page.

In order for this type of tagging to work properly, we need to very clearly define what belongs in each category.  For my example, only Maya ethnic groups would properly be included in the category. Links to articles about religious syncretization or globalization would be best included in the text of the article. And links in a "See Also" section would be limited to sibling pages like [[Olmec]] or [[Aztec]], which also fall under the category of Mesoamerican cultures.

[Larry Sanger]

IMHO the second use case is more prevalent and is actually the one we should strive for as it will spread work more.

In other words, you think that people more often will want to link from a given article to its various parents, than they will want to link from a parent article to its children articles.  Well, I don't know why you say that.  I will make the contrary claim.  In fact, I think the contrary claim is pretty obvious; this is how I saw Wikipedia being built, in fact.  Somebody would link from A to nonexistent articles B, C, and D, and someone would make article B; and then someone would link from B to nonexistent article E, F, and G, and so on.

You say this will "spread work [around]" more, but this doesn't make any sense to me.  I think it's plain that the "child tag" approach as you call it will require a lot more work, but I don't see how it will make work any less concentrated or more collaborative.  Besides, this is hardly a significant advantage anyway.

Anyway, there is another argument that really destroys the child tag approach as an option, namely, that the parent list approach encourages more clear thinking about what the contents of categories should be.  The child tag approach has the contributor ask, "What sort of thing is this?"  This encourages the formulation of all sorts of ridiculous ad hoc categories and categories that are woefully incomplete and arbitrary as to their contents.  The parent list approach, by contrast, has us think carefully about what the subtopics, and the related topics, of a particular topic are, all on one page, which means that the list thus constructed will be far more coherent--and hence useful to the end-user as opposed to the contributor--than a list constructed in bits and pieces by random guesses, the way things are far too often on Wikipedia.

With Parent List we will probably end up with people (editors?) generating and regenerating (after new articles were added) downlink list.

You mean that we will inefficiently regenerate the same lists?  Why think so?  For topic T, there will be a need only for a list of the subcategories of T, and topics related to T.  If some related topics are always the same for a set of articles (e.g., monarchs of England), we can use a template.

• With Parent List the sorting and arranging in columns of the downlinks has to be done by hand by the one adding the list, possibly including rearrangements/formattings if the list becomes too long. With Child Tag it will be done automatically.

This isn't necessarily an advantage; sometimes (maybe usually) we'll want to organize links to subarticles in a different way than an alphabetical list.

• Parent List has problems with the concept of "approved" articles. To add a topic into a category with Parent List, the Category article has to be reapproved (as it is edited). That is IMHO counter-intuitive. The fact whether an article belongs to a category is an attribute of the article and should thus be protected by the "access control rights" of that article. This is the case with Child Tag, whereas Parent List will probably lead to annoyed editors.

Well, after an article is approved, one can immediately change the "draft" version of the article.  If you want to see the latest list of subarticles, simply go to the draft page.

• If I understand the Parent List proposal correctly, category downlinks will be all the normal links following the ==Subtopics== headline until the next headline. In contrast with Child Tag, categories are created with adding a [[Category:foobar]] "tag" anywhere in the article. Parsing the second is easier as it is just one regular expression to find all categories. For Parent Link you either have to construct a complicated RegEx to find all links between ==Subtopic== and the next headline (better hope no one uses "==" within a link)

True enough, but who cares?  One of the fantastic things about the parent list proposal is precisely that article lists don't have to be generated automatically.  They're part of the articles themselves.

Pretty uncompelling arguments there, Markus, although I appreciate the effort!

[MarkusBaumeister]

I will make the contrary claim.  In fact, I think the contrary claim is pretty obvious; this is how I saw Wikipedia being built, in fact.  Somebody would link from A to nonexistent articles B, C, and D, and someone would make article B; and then someone would link from B to nonexistent article E, F, and G, and so on.

Yes, but those links to nonexistent articles will typically not point to subtopics. Take e.g. the "computers" article. I didn't count but outside the "Digital circuits" part there are probably not much links going to subtopics of "Computer". Especially not if the at most 25(?) entries in a category you proposed holds.

So most of the time you are creating an article it will be not from a subtopic link.

but I don't see how it will make work any less concentrated or more collaborative.  Besides, this is hardly a significant advantage anyway.

It spreads work around because it will animate people that are editing/creating an article to add the category tag there as well. More user-friendly than having to edit another article and search there for the correct position to insert a link in.

It is significant, because I think people complained here about too few editors (although in the Computers group it seems to be more too few authors) and I fear the parent list approach will leave it to them to collect articles into a subtopic list.

Anyway, there is another argument that really destroys the child tag approach as an option, namely, that the parent list approach encourages more clear thinking about what the contents of categories should be.  The child tag approach has the contributor ask, "What sort of thing is this?"  This encourages the formulation of all sorts of ridiculous ad hoc categories and categories that are woefully incomplete and arbitrary as to their contents.  The parent list approach, by contrast, has us think carefully about what the subtopics, and the related topics, of a particular topic are, all on one page, which means that the list thus constructed will be far more coherent--and hence useful to the end-user as opposed to the contributor--than a list constructed in bits and pieces by random guesses, the way things are far too often on Wikipedia.

Now the only problem with this destructive argument is that the nice new world of top-down constructing the topic-subtopic relationship is - based on my admittedly limited knowledge - not the way human thought processes work.You find classes based on examples. And the "ridiculous ad hoc categories" is (more or less) solved by the fact that a category has to be an article with a "category" blessing from an editor. I agree with you on that one (see the 20th Feb post).

You mean that we will inefficiently regenerate the same lists?  Why think so?  For topic T, there will be a need only for a list of the subcategories of T, and topics related to T.

Except that you will not generate complete lists. Thus, each time a new example is found, the list will have to be changed (find the right position in the list, add the link, if the list is too long now, convert it into two columns, whatever).

Lets take Joe's Maya people as an example. You seem to assume that Joe will create the "Maya people" article including a complete list of all people relevant. The articles on them are then created by other writers or by Joe by clicking on the list created by Joe. Those articles will be automatically backlinked to "Maya people" and everybody is happy.

I assume that Joe will write his "Maya people" article plus a few articles on the people he knows about, likes best, ... whatever. Someone else will follow a link from an article on some Mayan monument written by someone completely else, where it says e.g. "the monument is assumed to be created by  [[foo bar]]" and create an article on the "foo bar" people. Now either that writer will look around for a category, find Joe's article which is blessed as a category and add "[[Category:Maya people]]" to his newly created article. Or maybe Joe will at some time stumble upon the article, read it, maybe correct a few things and in the process also add the category tag of "his" category. Neither one has to change the "Maya people" article and neither intended to.

Which of the scenarios is more probable?

Well, after an article is approved, one can immediately change the "draft" version of the article.  If you want to see the latest list of subarticles, simply go to the draft page.

Except that, if i understand the "approve" idea correctly, we don't want the random reader to always go to the draft page (why then approve articles?). So the real question is: Is, in your opinion, the addition of a new instance, example, subtopic to a category article an action which requires re-approval. If yes, everything is fine. If no, you shouldn't say, ah, but we can fix that problem with this functionality-degrading hack.

• If I understand the Parent List proposal correctly, category downlinks will be all the normal links following the ==Subtopics== headline until the next headline. In contrast with Child Tag, categories are created with adding a [[Category:foobar]] "tag" anywhere in the article. Parsing the second is easier as it is just one regular expression to find all categories. For Parent Link you either have to construct a complicated RegEx to find all links between ==Subtopic== and the next headline (better hope no one uses "==" within a link)

True enough, but who cares?  One of the fantastic things about the parent list proposal is precisely that article lists don't have to be generated automatically.  They're part of the articles themselves.

Yes, that is correct for the parent article. But somehow you need links from the child to the parent (the actual category links). Now I assumed that the relationship is explicitly specified only on one side. For child tag it is specified in the childs, for parent list it is specified in the parent. Each time the 'backlinks' (in the parent resp. in the child) are created automatically. Thus you need to parse the primary links to generate the backlinks.

If you now say, no, no parsing is necessary since the relationship will be explicitly specified on both side, I would like to point out that

• that strengthens my argument about used-friendlyness of the child tag approach
• leaves the database with redundant information which will quickly out-date and become a problem and require even more parsing from the automatic cleanup routines.

Pretty uncompelling arguments there, Markus, although I appreciate the effort!

We become a little bit patronizing lately, aren't we?

Anyway. This discussion leads to nothing. Just do what you think is best and we will talk again about this topic in one year. I will just not maintain "parent list"-type category list (like what for mysterious reasons Robert Tito tries to do on the Computers Workgroup homepage).

[Bidouleroux]

This being a problem of taxonomy, I do not think a top-down approach is wise in practice nor in theory, although in practice it is always workable if you are lenient enough.  Markus hit the core of this argument when he essentially said that you cannot predict from the top down every possible thing that exists in a category.  Obviously, in practice you would only have to insert a link to your child article in the parent category after you have created it and thought of a category where it can fit.  But there is a problem when no category yet exist that truly fits with your article, or even when you want to create a category with a lot of disparate articles that you need to hunt down.  In that last case, how do you get the word out that you have created a new category?  This is a solvable problem of course, but no solution will be simpler than letting categories create themselves as they are needed (especially lists).

In fact, I would make an analogy here: an architect might design a building from the top-down if he so wishes, but he will always have to build it (or assemble it) from the bottom-up.  In a immaterial world where what is being built is an intangible structure, you can build it both ways of course, and a choice has to be made: do you put faith in you or a figure of authority to think of every possible thing that can be put under a category (as an architect does before building) or do you let the child article dictate it's own categories (as really good architect do, by planning ways to "upgrade" a building, like at Habitat 69)?

Of course, there should be a limited number of categories otherwise every last thing becomes its own category, but here we are asking if we want to restraint the number of articles in a category or the number of categories in an article? The former puts you in a "I must exhaust all possibilities of this category" mindset, the latter a "I must categorize this article" one.  The first is a work of memory and knowledge of the topic of the category: good for people with photographic memory or who exercises their memory a very big lot, not so for most modern people who have always relied on writing.  The second simply uses our human ability to abstract and categorize things, and although this is also a skill that is distributed unequally, I think it is more common than a photographic memory or encyclopedic taxonomic knowledge.  Also, with the second you can always write an article even if you cannot decide in which category it should go, whereas you would be forced (theoretically) to decide before even starting with the first method.  This, I think, is one of the reasons why the engineers at Google thought and still think that tags are more efficient than folders although they ultimately play the same exact role (replace categories with labels and articles with emails). 

Maybe a closer analogy would be the Google tagging system versus symbolic links: in the latter you work with folders but you can make as many links to a file as you want in as many folders as you want.  A tagging system will be cleaner and faster, as long as you can navigate by tags and not simply by folders.  If you wish to put a copy of every file with a certain combination of tags in a folder, you can do so.  But putting a combination of tags on every file in a folder requires that you go folder by folder.  Of course, when automated this becomes moot and we come back to: do you want a top-down approach or a bottom-up approach.  Since there is already a lot of top-down authority in this project with the editors, I cannot but think that a top-down approach would ultimately lead to a kind of dictatorship over time or at least invite totalitarian personalities into the project (those that want power are in most cases those that don't deserve it).

Feel free to chop this post down, it's only a kind of essay on the subject and not a firm proposal.

[Larry Sanger]

This being a problem of taxonomy, I do not think a top-down approach is wise in practice nor in theory, although in practice it is always workable if you are lenient enough.  Markus hit the core of this argument when he essentially said that you cannot predict from the top down every possible thing that exists in a category.

I, and no one using the system I propose, would be pretending that one can predict "every possible thing that exists in a category."

It is actually greatly misleading to view the problem I am trying to solve as a difficult formal problem of taxonomy or as a programming problem.  The function of the system I propose is not to assist computer processing.  I do not care about computer processing nearly as much as I care about comprehensibility and usefulness by human beings reading articles.  Ultimately, I think, if we pay attention to the needs of human beings, processability will take care of itself.

Obviously, in practice you would only have to insert a link to your child article in the parent category after you have created it and thought of a category where it can fit.  But there is a problem when no category yet exist that truly fits with your article, or even when you want to create a category with a lot of disparate articles that you need to hunt down.  In that last case, how do you get the word out that you have created a new category?  This is a solvable problem of course, but no solution will be simpler than letting categories create themselves as they are needed (especially lists).

Indeed, we can create ad hoc article list pages in order to find "homes" for orphans; or, we can live with orphans for a while.  I couldn't disagree more vehemently with the approach of "letting categories create themselves as they are needed."  It is the Wikipedia approach and it is what has led to the utter and complete mess that its category system is.  It's completely worthless--I never use Wikipedia categories to navigate, find, or anything else.  The whole purpose of linking up articles in the way I propose is to make it easier for human beings to find articles highly relevant to a given article.  The best way to compile a list of such articles is for people to construct the list as they work on the article.  For example, when I work on "Philosophy," after having worked long and hard on it, and knowing the topic as I intimately do, I have an excellent idea of what related topics to list, and what not to list, that will help readers of the article.  If, instead, I simply wait for people to put "Category:Philosophy" tags on their articles, all that results is the aggregation of individual, and completely unsystematic and often inconsistent, views about what should go in the "Philosophy" category.  If the list is constructed in one place, however, it is easy to maintain, and relatively easy to make coherent.

In fact, I would make an analogy here: an architect might design a building from the top-down if he so wishes, but he will always have to build it (or assemble it) from the bottom-up.

The great system-builders of the world, indeed, compare their system-building to constructing a building, beginning with the foundations.  But, you'll notice, they tend to begin with the general and subsume the more particular under the general.  That, presumably, you're calling "top-down," but they would describe it as "bottom-up."  So would I.

There is, I concede, always going to be some adjustment between levels of a conceptual structure.  But that does not diminish one of the grand things about the subtopic system I propose: that each article is its own node in the "hierarchy," and hence that we focus particularly on the needs of the user of that particular article.  We cannot (as easily) have such a focus if we create uplinks with Wikipedia-style tags from subtopics to supertopics.

In a immaterial world where what is being built is an intangible structure, you can build it both ways of course, and a choice has to be made: do you put faith in you or a figure of authority to think of every possible thing that can be put under a category (as an architect does before building) or do you let the child article dictate it's own categories (as really good architect do, by planning ways to "upgrade" a building, like at Habitat 69)?

The suggestion here, to take an example, is that if I make a list of Philosophy subtopics, I am acting as "a figure of authority" with respect to whether "the children" "want" to be included in the main topic.  This is a weak argument by analogy, at best.  One could just as easily say that the supertopic is under the thumb of dozens of independent taskmasters, which are not working together, and which are making a hash of everything.  Surely it is far easier to "upgrade" a list of categories when the list is maintained in one place, than when the list of n items is spread out and editable only by editing each of the n articles in the list!

Anyway, that's all I have time to respond to here.  I'm afraid none of the arguments here are doing anything other than confirming me in my own opinion.

[Joshua David Williams]

...

I love the idea of using Related Topics and Subtopics instead of See Also. I don't see any problems with anything you said. I think we should go for it (and avoid upgrading to the tagging in MediaWiki.. ugh!).