Filters only work if articles are assigned to categories. Setting aside wether we should use categories in wikipedia itself or only in some sifter project, categories have to be implemented in the software either way. So I hacked a barebone implementation at the test site. A list of current categories can be found at
http://test.wikipedia.org/wiki/Special%3ACategories
Currently, anyone can add and delete categories. I suggest that this will be restricted to sysops later, as it will prevent a "category inflation", as well as malicious deletion of a whole category.
Anyone can assign any article to any category, and remove that assignment as well. Wiki, right? :-)
Currently, categories are *not* shown on the article page, although I have written that code (keep getting some weird effect, though, so I turned it off).
To be done: * Personal category filters * Search for a category combination (in the example online, "Biology" and "Germany" should list "Anton de Bary")
Thoughts? Comments? Bullets? ;-)
Magnus
Magnus Manske wrote:
Filters only work if articles are assigned to categories. Setting aside wether we should use categories in wikipedia itself or only in some sifter project, categories have to be implemented in the software either way. So I hacked a barebone implementation at the test site. A list of current categories can be found at
...
Thoughts? Comments? Bullets? ;-)
Magnus
At the moment, a sort of "category" function is being performed by the lists on the en wiki called "List of XXX topics", for various values of XXX. These are just "dumb" pages, with no special software support, maintained by hand.
Your category suggestion, so far, just automates these lists. I agree that a proper category/scoring framework would be great, but it needs to be more general than this. Category membership is a special case of scoring, a much more powerful concept. For example, I'd like to be able to cast a vote for the completeness or authoritativeness of an article.
Two comments: * An old suggestion is magic non-displaying "[[Category:XXX]]" links that could be put in articles to put them in a category. * One nice thing that can be done with the dumb lists is to link to not-yet-created articles, effectively creating category-based to-do lists.
Regards,
Neil
Magnus-
Currently, anyone can add and delete categories. I suggest that this will be restricted to sysops later, as it will prevent a "category inflation",
Please, let's not have another ability that is restricted to sysops. Wikipedia is supposed to be open.
Anyone can assign any article to any category,
How? I see no information on how to do this.
All in all, I obviously like my [[Category:Foo]] proposal more. I'm not too worried about separating this kind of meta information from articles, IMHO it belongs there. This makes all changes to the categorization - listed in recent changes - diffable - easy to revert It would also be trivial to use the existing links tables for category management under that scheme.
The reason interlanguage links are so annoying is not that they are mixed with articles, but that they are needlessly redundant. I think someone proposed an interesting solution to that problem a few months ago (hint, hint).
Regards,
Erik
Erik Moeller wrote:
Currently, anyone can add and delete categories. I suggest that this will be restricted to sysops later, as it will prevent a "category inflation",
Please, let's not have another ability that is restricted to sysops. Wikipedia is supposed to be open.
Well, let's say we have carefully searched and tagged each and every "sexually explicit" article in the 'pedia as such. Then user:Michael (lacking a better example) comes along and deletes the category. All work for nothing. All tags are gone. Yes, in a perfect world we'd have undelete here as well, but limiting access to sysops seems an acceptable intermediate solution as well.
Anyone can assign any article to any category,
How? I see no information on how to do this.
Next to "printable version", there's a link "Categories". Try that one.
All in all, I obviously like my [[Category:Foo]] proposal more.
Been there, had it implemented. Long time ago (Phase II, IIRC). No want, no need, too complicated. Gone now. Really, I'm trying to get rid of the language links in the future, why add another obstacle? It's a mess as it is ;-)
I'm not too worried about separating this kind of meta information from articles, IMHO it belongs there. This makes all changes to the categorization
- listed in recent changes
- diffable
- easy to revert
It would also be trivial to use the existing links tables for category management under that scheme.
Most of this only shows that we need to improve Recent Changes... Seriously: diffable is no argument, if the article text is not changed (as in my implementation). It should show on RC, but that's a problem with RC, IMHO. Reverting is easy with my solution as well (try it).
The reason interlanguage links are so annoying is not that they are mixed with articles, but that they are needlessly redundant. I think someone proposed an interesting solution to that problem a few months ago (hint, hint).
I don't recall... I still have the code of *my* implementation in the test wiki, if that's what you mean. I just can't find the database structure anymore :-(
Magnus
--- Magnus Manske magnus.manske@web.de wrote:
Erik Moeller wrote:
Currently, anyone can add and delete categories. I
suggest that this will be
restricted to sysops later, as it will prevent a
"category inflation",
I suggest that we also limit article creation to sysops as well to avoid articles inflation :-)
And non sysops can quietly go on creating lists as they are currently doing. We don't really need categories anyway. Lists are fine.
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Anthere wrote:
--- Magnus Manske magnus.manske@web.de wrote:
Erik Moeller wrote:
Currently, anyone can add and delete categories. I
suggest that this will be
restricted to sysops later, as it will prevent a
"category inflation",
I suggest that we also limit article creation to sysops as well to avoid articles inflation :-)
So funny.
"Category inflation" will be counter-productive. The whole *point* of categories is to group large number of articles into them. If we had 130000 categories for 130000 articles, it would not really do any good, would it?
And how should filtering be done if we have categories "adult", "sex", "sexual content", "sexually explicit", etc. all for the same thing? If we want to make it an option to block "sex stuff", it has to be one option (maybe two at max), not a dozen or more.
And non sysops can quietly go on creating lists as they are currently doing. We don't really need categories anyway. Lists are fine.
Today, someone talked on one of the mailing lists about one of your lists that took five minutes to save and slowed down the whole 'pedia significantly.
Categories are my implementation of the filtering issue, something that would be quite difficult with lists. It could also work to tag images as "GFDL", "public domain" or "fair use". It can also replace the lists. So, if we implement a filtering option anyway, why not use the opportunity?
Magnus
Magnus Manske wrote:
Categories are my implementation of the filtering issue, something that would be quite difficult with lists. It could also work to tag images as "GFDL", "public domain" or "fair use". It can also replace the lists. So, if we implement a filtering option anyway, why not use the opportunity?
Magnus
Magnus,
My comments were not meant to criticise categories, or your attempts to make an implementation. I'm a proponent of categories: I think they can serve useful purposes. I'm also grateful you are actually exploring the problem space, instead of just talking about it like the rest of us.
I think the [[List of XXX topics]] categories are very useful, and having a pointer from the category list to the article is the natural way to do it: it also handles the case of making a category for a non-existent article.
But it would also be nice to flag an article for membership in a category list by adding a back-link.
The huge maths topics article shows that the "flat article" approach does not scale well for very large lists: there are two possible routes to making this better: either
i: fixing the scaling problem for articles with very large lists of links, or ii: a special implementation for category lists
Neil
Neil Harris wrote:
I think the [[List of XXX topics]] categories are very useful, and having a pointer from the category list to the article is the natural way to do it: it also handles the case of making a category for a non-existent article.
But it would also be nice to flag an article for membership in a category list by adding a back-link.
My implementation makes it easy to show backlinks to the (then automated) category pages. Source is already written and in place, just not turned on.
Suggestion: We could easily import the existing lists into my implementation.
Magnus
Neil Harris wrote:
Magnus,
My comments were not meant to criticise categories, or your attempts to make an implementation. I'm a proponent of categories: I think they can serve useful purposes. I'm also grateful you are actually exploring the problem space, instead of just talking about it like the rest of us.
Ditto! But I can plead technical incompetence :-)
I think the [[List of XXX topics]] categories are very useful, and having a pointer from the category list to the article is the natural way to do it: it also handles the case of making a category for a non-existent article.
Categories can be assigned to lists as well. I also see no way that we will ever do away with lists completely. They still serve a useful function for highlighting what articles are still wanted.
Ec
--- Magnus Manske magnus.manske@web.de wrote:
Anthere wrote:
--- Magnus Manske magnus.manske@web.de wrote:
Erik Moeller wrote:
Currently, anyone can add and delete categories.
I
suggest that this will be
restricted to sysops later, as it will prevent a
"category inflation",
I suggest that we also limit article creation to sysops as well to avoid articles inflation :-)
So funny.
:-)
"Category inflation" will be counter-productive. The whole *point* of categories is to group large number of articles into them. If we had 130000 categories for 130000 articles, it would not really do any good, would it?
Not, it would not.
Just as it would not be good to have 10 articles on gmo (say). But the creation of list could work exactly how the creation of articles exist right now. With a quantitative and qualitative community driven control process. Anyone can create a list, and add or remove articles in the list. Quick and easy. And discuss if there is disagreement.
Similarly, anyone could create a new category. And anyone could contest that creation. And perhaps a sysop delete it after common agreement that the category is not necessary.
The current process is that everyone has an equal right of creation and edition of articles.
You just suggest that we give up some of wikipedia openness and very concept, just for the fear of an event that could very well be handled through peer pressure and votes for deletion.
And how should filtering be done if we have categories "adult", "sex", "sexual content", "sexually explicit", etc. all for the same thing? If we want to make it an option to block "sex stuff", it has to be one option (maybe two at max), not a dozen or more.
Depends. If we only provide the tool, and end users (such as a school) decide what is to put on the "censored list", only one category is necessary. If Wikipedia itself set the content of the "sexually explicit" list, I think we will need dozens of lists. Because clearly not everyone here will agree on what has to be on the list, and what has not to be.
And non sysops can quietly go on creating lists as they are currently doing. We don't really need categories anyway. Lists are fine.
Today, someone talked on one of the mailing lists about one of your lists that took five minutes to save and slowed down the whole 'pedia significantly.
Yes. That is a big problem. But just as it is wrong that a non-sysop user has to go begging and waiting for the good will of a sysop to put a link on the main page (*this* is counter productive), I think it wrong that regular users have to go begging a sysop to create a category for them. If I want to have a category about sustainable agriculture articles, and there is no sysop caring about the topic, would I really have to spent hours trying to find one cooperative enough to make it for me ? I don't think so. Again, this is counter productive. I predict lists will go on existing if categories are sysops restricted only.
Categories are my implementation of the filtering issue, something that would be quite difficult with lists. It could also work to tag images as "GFDL", "public domain" or "fair use". It can also replace the lists. So, if we implement a filtering option anyway, why not use the opportunity?
Magnus
I agree tagging images as gfdl, public domain or fair use, or tagging text as copyrighted is very interesting. But a sysop restricted categories to replace open-to-any-editor lists is bad.
And I did not understand the filtering option had been decided really.
Cheers. Ant
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Anthere wrote:
Yes. That is a big problem. But just as it is wrong that a non-sysop user has to go begging and waiting for the good will of a sysop to put a link on the main page (*this* is counter productive), I think it wrong that regular users have to go begging a sysop to create a category for them. If I want to have a category about sustainable agriculture articles, and there is no sysop caring about the topic, would I really have to spent hours trying to find one cooperative enough to make it for me ? I don't think so. Again, this is counter productive. I predict lists will go on existing if categories are sysops restricted only.
Is it realy necessary to _beg_ a sysop? I think there are enought sysops to make such things happen fast. The problem I have, is mainly to find the requests of the users, but if there is a discussion page or faster, the mailing list is used for emergency cases, I will find the requests in less than ''hours''. And as developer of course the time to code as fast as the users invent new ideas is a problem -- but for adding a category, including use of some brain time*, I need 2 or 3 minutes (slow brain;).
My experiences with sysop's (on germen wiki) go more the other way. The users complain that they are to fast ;) But of course, I think it is possible for Magnus to implement, that only deletion is restricted.
*) Like CPU time, only its build in ;)
Anthere wrote:
Anthere wrote:
You just suggest that we give up some of wikipedia openness and very concept, just for the fear of an event that could very well be handled through peer pressure and votes for deletion.
Not at all, as (almost) anyone can become sysop. I did not suggest "sysop only" to take some rights from the unwashed masses, merely as a practical measure. I don't insist on that.
Suggestion: Limit creating categories to sysops for, say, two month after installing the category system. After that, anyone can create categories. The idea is that once we have some category scheme that works, people will rather stick to the existing system than trying to invent a new one, e.g. by adding a "people from Novosibirsk that made U.S. president" ;-)
IMHO deleting categories should be resrticted, until there's an "undelete" option. No doubt, my implementation needs work; renaming and merging categories will be important. Easy to implement, and I volunteer, but not until I get a "go" ;-)
Depends. If we only provide the tool, and end users (such as a school) decide what is to put on the "censored list", only one category is necessary. If Wikipedia itself set the content of the "sexually explicit" list, I think we will need dozens of lists. Because clearly not everyone here will agree on what has to be on the list, and what has not to be.
There could also be categories for large groups, like U.S. schools. "Not suitable for U.S. schools"? Or rather "Not Republican approved"? ;-]
And I did not understand the filtering option had been decided really.
It wasn't. I just remember a few mails where Jimbo seemed to embrace the idea of a filtering option for wikipedia.
Magnus
--- Magnus Manske magnus.manske@web.de wrote:
Anthere wrote: Suggestion: Limit creating categories to sysops for, say, two month after installing the category system.
The time to set things clear. Yes. That is an option. But the names and types of categories should be decided together.
IMHO deleting categories should be resrticted, until there's an "undelete" option.
Agreed. But imho, no deletion should be possible without an undeletion
And I did not understand the filtering option had
been
decided really.
It wasn't. I just remember a few mails where Jimbo seemed to embrace the idea of a filtering option for wikipedia.
Magnus
Yes. Jimbo.
But I think there are two things quite different that could be set with your proposition. Better management of lists and filtering. These are conceptually very different.
Best
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Anthere wrote:
--- Magnus Manske magnus.manske@web.de wrote:
Suggestion: Limit creating categories to sysops for, say, two month after installing the category system.
The time to set things clear. Yes. That is an option. But the names and types of categories should be decided together.
The decision for the (initial) categories should be made by all wikipedians. Limiting the actual creation to sysops is only to prevent someone from enforcing his POV by just going ahead and implementing it. (Uhh... bad trap ;-)
But imho, no deletion should be possible without an undeletion
Deleting is for test purposes at the moment. No problem turning it off.
But I think there are two things quite different that could be set with your proposition. Better management of lists and filtering. These are conceptually very different.
They are. All I propose is to use the same technical system for making them possible.
A future sifter system (which will come, I have no doubt) will be based on the wikipedia software, and it will have categories and filters as a standard, that I have no doubt. How we use it at wikipedia (completely, not at all, filters but no categories etc.) is another decision.
Magnus
Magnus Manske wrote:
"Category inflation" will be counter-productive. The whole *point* of categories is to group large number of articles into them. If we had 130000 categories for 130000 articles, it would not really do any good, would it?
This may not be as much of a problem as it at first appears. Categories will be subdivided or split off as the need arises. Developing a nice bell curve in a statistical analysis can depend on choosing the right group sizes.
And how should filtering be done if we have categories "adult", "sex", "sexual content", "sexually explicit", etc. all for the same thing? If we want to make it an option to block "sex stuff", it has to be one option (maybe two at max), not a dozen or more.
Using some kind of codification helps here. A single code could incorporate all the items listed above. I'd be inclined to have a range of possible categories for this.
And non sysops can quietly go on creating lists as they are currently doing. We don't really need categories anyway. Lists are fine.
Today, someone talked on one of the mailing lists about one of your lists that took five minutes to save and slowed down the whole 'pedia significantly.
Whether something gets put onto a list is pretty hit and miss, and completely uncontrolable. If we look at any list on Wikipedia we can never be certain that it in fact includes avery relevant article.
Categories are my implementation of the filtering issue, something that would be quite difficult with lists. It could also work to tag images as "GFDL", "public domain" or "fair use". It can also replace the lists. So, if we implement a filtering option anyway, why not use the opportunity?
It can be used to flag a very wide range of "impaired" articles.
Ec
Magnus-
Well, let's say we have carefully searched and tagged each and every "sexually explicit" article in the 'pedia as such. Then user:Michael (lacking a better example) comes along and deletes the category. All work for nothing. All tags are gone.
Let's say user:Michael comes along and blanks all our articles. All work for nothing. All text is gone.
;-)
See, because we have to make the wiki principles (reversion, watchlists, rc, diffs, attribution, protection, deletion, undeletion ...) work for any solution that is outside the article space, I prefer one that is simply part of the article space.
All in all, I obviously like my [[Category:Foo]] proposal more.
Been there, had it implemented. Long time ago (Phase II, IIRC). No want, no need, too complicated.
Then your implementation was obviously in need of improvement ;->.
Most of this only shows that we need to improve Recent Changes... Seriously: diffable is no argument, if the article text is not changed (as in my implementation).
Wikipedians have certain workflows. They write articles, revert to prior revisions, do comparions over 10 past revisions and so forth. By creating a completely separate scheme, you require them to add another workflow to their routine. The system becomes more complex and the user is increasingly confused. This should be avoided when implementing the same feature within the existing workflows is reasonably possible. I believe this to be the case with categories (but not necessarily with interlanguage links).
I don't recall... I still have the code of *my* implementation in the test wiki, if that's what you mean. I just can't find the database structure anymore :-(
Hm, that's why it's a good idea to use CVS branches for that kind of ideas. Then they don't get lost. Test.wiki code is overwritten every couple of weeks.
Regards,
Erik
Erik Moeller wrote:
See, because we have to make the wiki principles (reversion, watchlists, rc, diffs, attribution, protection, deletion, undeletion ...) work for any solution that is outside the article space, I prefer one that is simply part of the article space.
You have removed the part of my answer where I talked about undeleting...
All in all, I obviously like my [[Category:Foo]] proposal more.
Been there, had it implemented. Long time ago (Phase II, IIRC). No want, no need, too complicated.
Then your implementation was obviously in need of improvement ;->.
At that time, it was the mere concept of categories that was "under attack", and the fact that I put the stuff into the articles. Well, I guess that's my fate, being ahead of my time ;-)
Seriously: diffable is no argument, if the article text is not changed (as in my implementation).
Wikipedians have certain workflows. They write articles, revert to prior revisions, do comparions over 10 past revisions and so forth. By creating a completely separate scheme, you require them to add another workflow to their routine. The system becomes more complex and the user is increasingly confused. This should be avoided when implementing the same feature within the existing workflows is reasonably possible. I believe this to be the case with categories (but not necessarily with interlanguage links).
IMHO categories don't change the way articles do. An article about a city will be about a city as long as the article exists. I could add a date field to the connection category-article to make a diff, but I don't see the point.
I still have the code of *my* implementation in the test wiki, if that's what you mean. I just can't find the database structure anymore :-(
Hm, that's why it's a good idea to use CVS branches for that kind of ideas. Then they don't get lost. Test.wiki code is overwritten every couple of weeks.
No, the *code* is still there (SpecialInterwiki.php, IIRC). The test database was wiped, and that wouldn't have been in the CVS, unless I had explicitely put a copy of the database structure there.
Magnus
Magnus-
Erik Moeller wrote:
See, because we have to make the wiki principles (reversion, watchlists, rc, diffs, attribution, protection, deletion, undeletion ...) work for any solution that is outside the article space, I prefer one that is simply part of the article space.
You have removed the part of my answer where I talked about undeleting...
True, because we can always add such functionality later. That's not the point. The point is that we should avoid reinventing the wiki whenever possible.
IMHO categories don't change the way articles do. An article about a city will be about a city as long as the article exists.
Certainly, but that is a very limited view of categories. In my scheme, you would also have
[[Category:City with population under 10]] [[Category:Large city]] - which could each be child categories of [[Category:City]], so if you specify one, you do not have to specify the other. You create a child category simply by putting [[Category:City]] on [[Category:Large city]]. [[Category:Cultural heritage site]] [[Category:Capital]] ...
and so on, which would be used to generate the respective list articles that are currently manually maintained. Within such a more comprehensive metadata framework, constant changes, debates about categorization etc. are inevitable. It makes sense to use articles/talk pages in the traditional sense.
I'm not sure how I feel about a meta namespace. I don't really see the need for it yet, but if this kind of metadata becomes too much, we might go for it. Note that if we do it, we need to do it for each of the existing namespaces.
No, the *code* is still there (SpecialInterwiki.php, IIRC). The test database was wiped, and that wouldn't have been in the CVS, unless I had explicitely put a copy of the database structure there.
That's why it's a good idea to create patch-files (see maintenance/ archive) whenever you change the database structure. It's a bit annoying, but prevents accidents like this.
Regards,
Erik
Erik Moeller wrote:
Magnus-
Erik Moeller wrote:
See, because we have to make the wiki principles (reversion, watchlists, rc, diffs, attribution, protection, deletion, undeletion ...) work for any solution that is outside the article space, I prefer one that is simply part of the article space.
You have removed the part of my answer where I talked about undeleting...
True, because we can always add such functionality later. That's not the point. The point is that we should avoid reinventing the wiki whenever possible.
Idon't see the issue as about reinventing wikis. Becoming the largest wiki puts this project into a unique position of confronting scaling issues that have been meaningless on a smaller project.
Ec.
Magnus Manske wrote:
Wikipedians have certain workflows. They write articles, revert to prior revisions, do comparions over 10 past revisions and so forth. By creating a completely separate scheme, you require them to add another workflow to their routine. The system becomes more complex and the user is increasingly confused. This should be avoided when implementing the same feature within the existing workflows is reasonably possible. I believe this to be the case with categories (but not necessarily with interlanguage links).
IMHO categories don't change the way articles do. An article about a city will be about a city as long as the article exists. I could add a date field to the connection category-article to make a diff, but I don't see the point.
Most articles are probably very stable. Only a small minority become the subject of wild edit wars. I tend to agree that once a particular category is established it will not change very much.
People can adapt their personal workflows if the change is not too complicated. The ability to add a simple code of a few letters to a page without needing to chase to another page should not significantly affect work flow. Compare this to going to a list on a separate page to make sure that the item is on that list.
Ec
Erik Moeller wrote:
Magnus Manske wrote:
Erik Moeller wrote:
All in all, I obviously like my [[Category:Foo]] proposal more.
Been there, had it implemented. Long time ago (Phase II, IIRC). No want, no need, too complicated.
Then your implementation was obviously in need of improvement ;->.
I'm pretty sure that the objection to Magnus' implementation was more "No want, no need" than "too complicated".
You could code your version up to, Erik, and we'll try them both out on [[test:]]! ^_^
-- Toby
Magnus-
Magnus Manske wrote:
Oh, there it is. Stupid me. Thanks to whoever made this (wasn't me, unless Alzheimer's coming sooner than expected...)
It did. I ran the thing and it blew access to all non-en databases :-(
Trying to fix it now...
Take your time. En: is damn fast right now, it's almost fun to use ;->
Regards,
Erik
Erik Moeller schrieb:
The reason interlanguage links are so annoying is not that they are mixed with articles, but that they are needlessly redundant.
And that they are on top of the articles (often followed by html stuff for images or tables).
If no developer is motivated to create a "interlanguage:" or "meta:" namespace for them let's mount a "put all interlanguage links below article text" campaign. Or is this something the bots could hunt?
Kurt
Kurt Jansson wrote:
If no developer is motivated to create a "interlanguage:" or "meta:" namespace for them let's mount a "put all interlanguage links below article text" campaign. Or is this something the bots could hunt?
I do this already.
I also put a comment before tables:
<!-- To edit the main text of the article, skip past this table. -->
-- Toby
Magnus Manske wrote:
Filters only work if articles are assigned to categories. Setting aside wether we should use categories in wikipedia itself or only in some sifter project, categories have to be implemented in the software either way. So I hacked a barebone implementation at the test site. A list of current categories can be found at
For a variety of reasons, I've been waiting a few days to jump in on this one. Like Erik I have been arguing for some kind of category system, and have been dismayed when this important initiative gets lost in a straw man argument over censorship or copyrights. Yes, a category system can be used as a tool for such purposes, but it's value for Wikipedia goes well beyond such narrow confines.
Currently, anyone can add and delete categories. I suggest that this will be restricted to sysops later, as it will prevent a "category inflation", as well as malicious deletion of a whole category.
This aspect has already had a lot of response, particularly from those concerned about the openness of Wikipedia. I don't see "category inflation" as a serious problem. Of course if the category list were to remain in its current draft unordered state, its uselessness would increase with its size. In applying restricted access of any kind, system vulnerability, either to malice or to accident, becomes the primary criterion. Even the most trustworthy among us can sometimes fall prey to an "oops" moment. I can see a distinction between integrated and non-integrated categories with only the former being subject to restricted editing, and even integrated categories could have their descriptions fully editable. Altering integrated categories could have unforseen and often far-reaching consequences that may not easily be apparent.
Anyone can assign any article to any category, and remove that assignment as well. Wiki, right? :-)
Of course!
Currently, categories are *not* shown on the article page, although I have written that code (keep getting some weird effect, though, so I turned it off).
To be done:
- Personal category filters
- Search for a category combination (in the example online, "Biology" and "Germany" should list "Anton de Bary")
All in good time.
Thoughts? Comments? Bullets? ;-)
Seeing the jumbled nature of a category list that is only 19 items long has only added to my conviction that we should have a codified hierarchical system.
For a Wikipedia (I have very different approaches for a Wiktionary) I would argue for a system that '''starts''' with Library of Congress Classification System. Before I get back a lot of comments about why it's not a good system, let it be known that I am perfectly aware of its shortcomings, notably its American slant on subject classification, and the fact that its century old structure may not be appropriate to many modern subjects. In its favour is the simple fact that it is there and in the public domain; it is hierarchical and easily subdivided when we require it; it is well known and accessible at its most fundamental structure and that gives us a coherent starting point. An alternative system would be just as good, but it should have these characteristics if we want to avoid a reinventing-the-wheel kind of situation. We need to rember too that whatever system we choose will be modified as we progress.
Some people complained before that they don't like the idea of having to have to learn a long list of different codes. That's fair enough, but it's important to remember that most contributors will work within a limited range of subject areas, and that in itself will limit the codes that they need to remember. Of course coding and classification is an optional task. If a person feels comfortable writing text, but feels lost with codification he can leave that to somebody else even as we aim to make codification as easy as possible.
Any article should be classifiable in several categories. Thus the Anton de Bary article can appear in CT for biography, DD for Germany and QH for biology plus whatever else Wikipedians consider appropriate. Unlike printed books there is no need to limit ourselves to a single classification to enable us to find the book on a shelf somewhere in a library
A category would have three elements: a code, a title, and a description. The codes would be brief and hierarchical; they would also be sufficient as broad search elements. The titles would function in a manner similar to the present article titles. They could appear after a code as a dumb descriptor for that code and linked directly only to the third element. Like most articles these descriptions would be fully editable, and if any edit wars were to arise out of the classification system this is where they would happen.
Magnus's idea of using drop down boxes for putting things into categories should work well with a hierarchical scheme. This could be expanded into a series of nested drop down boxes as required. For the most part LC uses only 2 letters in its classifications, and even then there are many unused classes. Only 3 letters would give us the capacity for 17,576 codes. In the LC system the "E" category is about the United States, and is not normally further developed into lettered sub-classes (though it does have numerical subdivision). We could choose to use "EL" for United States localities, and that would be one of our second level drop down choices. A third level choice might divide these localities by state, but since the drop down list of all states is taller than most people's screens it might be limited to states beginning with each letter, and we could wait until the fourth level to sort out California, Colorado and Connecticut. Georgia, as the only "G" state would have been sufficiently identified at the third level. There you have it -- all the RamBot articles have been classified. :-) There's a great deal of flexibility there.
Eclecticology
Eclecticology wrote:
A category would have three elements: a code, a title, and a description. The codes would be brief and hierarchical; they would also be sufficient as broad search elements. The titles would function in a manner similar to the present article titles. They could appear after a code as a dumb descriptor for that code and linked directly only to the third element. Like most articles these descriptions would be fully editable, and if any edit wars were to arise out of the classification system this is where they would happen.
I don't understand the motivation for including the code at all. If it's to allow for hierarchical classification, then this can also be done by placing, say, "[[Category:Mathematics]]" in the text of [[Category:Topology]], just as you'd place, say, "[[Category:Topology]]" in the text of [[Hausdorff space]]. If it's to standardise the name of the category, then we can just use the name of the article on the subject: say, [[Category:Mathematics]], following [[Mathematics]], not [[Category:Maths]] or [[Category:Math]], much less [[Category:QA]]. Of course, we could always redirect the abbreviations to [[Category:Mathematics]].
I agree that the LC could well give us an initial set of categories to use. But we don't need their codes.
-- Toby
wikipedia-l@lists.wikimedia.org