Hi all!
I finally got to implement the often-demanded categories in the PHP script (http://wikipedia.sourceforge.net/fpw/wiki.phtml).
It works like this: - Add "{{CATEGORY A category,Another category}}" to the text of an article. Separate the categories by ",". - Everything between {{ and }} will *not* be displayed within the text, but as a category list at the bottom of the page, as well as in the sidebar, if you have turned it on. - In an article that *is* a category, write "{{THISCATEGORY}}" somewhere. This will be replaced with a list of all articles which *at that very moment* have a "{{CATEGORY xyz}}" for that category.
See it for yourself at the above site. I put "Gene" and "DNA" into both "Biology" and "Genetics" category. "Genetics" itself is in the "Biology" Category. On the "Genetics" and "Biology" pages, at the bottom, you'll find a grey box, listing all the pages that are within that category.
OK, I know this screams "problems" all over, but it's just the "hooray, it's running!" version. There's much more to be done, starting with a sorted article output to limiting "Search" and "Recent Changes" to certain categories, and so on. But hey, it's a start...
A more technical note: I also put all the "fixed" text displayed on the 'pedia into variables and collected them in one single file. So, for international versions, only one file has to be changed, the other files can get "technical" updates without having to translate/merge the whole thing again.
That's all for now, Magnus
Magnus, can you give me an example of a post or just some point that someone has made, that constituted a feature requirement such that this feature in particular is supposed to fulfill it? There's so much that has been said on the topic of categories that I can't remember. I mean, I'd like to see the feature requirements at the same time we see the feature, so that we can compare the two.
I do remember one feature that I asked for, along with Jimbo (in at least one form--the feature, not Jimbo), and perhaps some other people, that this might help with. Namely, "Recent Changes" has gotten perhaps so large as to have too much noise and not enough signal for someone who is interested only in a few topics. In that case, my suggestion was that we categorize edits (not articles) in one of the front-page categories, by selecting them from a multiple selection box. (Future edits could be automatically categorized the same way, or changed by the user as they become relevant to different areas.) This is a specific, delimited solution to a specific, delimited problem, and it would make Wikipedia more attractive to specialists, which is important.
The category feature you've created could be used in all sorts of ways, and (sorry!) I'm not sure I like all of those ways. First of all, it appears to be a way to get the notion of subpages in through the back door, by distinguishing a "category" category of articles and an "articles in this category" category. So, if used indiscriminately, I'd largely be opposed to this new feature on much the same grounds that I was opposed to subpages in the first place.
If, on the other hand, we as a community were to decide that only a *limited, pre-designated* set of pages could be "category" pages, then this would be, obviously, different from the old main page-subpage scheme. In that case, though, I should think it would be better to select the category for any given page from a drop-down box, so people couldn't mess up the spelling, attempt to add categories that shouldn't be categories, etc. Moreover, while my misgivings with subpages would not apply, for the most part, I'd still wonder--just because I like to be clear about this sort of thing--what the feature, used this way, would accomplish. I imagine that after the philosophy of language article, we'd have the "philosophy" and "language" (and/or "linguistics") categories listed. In doing this, we would *highlight* the fact that the article belongs to a number of traditional academic categories. And we would invite the reader to begin their exploration of Wikipedia with those traditional academic categories. And you know, I agree with the interdisciplinary advocates: I just don't think the traditional academic categories are *important enough*, per se, for us to take this trouble to *highlight* them for the reader. The reader can easily and will naturally deduce the general subjects, at many different levels (not just the broadest-traditional- academic-category level), just by reading the article and following the links in the text. The beauty of a well-written, complete, well-linked article is that one can specifically place its location in the web of knowledge by reading the article itself.
Of course, I could be just failing to remember or realize some other clear benefit of having articles sorted into a limited number of various official categories.
Now, if we *simply* wanted to use this as a standard "see also" section, some modified version of this might work well. But it does too much for just tha right nowt...
Awaiting further enlightenment!
Larry
On Thu, 3 Jan 2002, Magnus Manske wrote:
Hi all!
I finally got to implement the often-demanded categories in the PHP script (http://wikipedia.sourceforge.net/fpw/wiki.phtml).
It works like this:
- Add "{{CATEGORY A category,Another category}}" to the text of an article.
Separate the categories by ",".
- Everything between {{ and }} will *not* be displayed within the text, but
as a category list at the bottom of the page, as well as in the sidebar, if you have turned it on.
- In an article that *is* a category, write "{{THISCATEGORY}}" somewhere.
This will be replaced with a list of all articles which *at that very moment* have a "{{CATEGORY xyz}}" for that category.
See it for yourself at the above site. I put "Gene" and "DNA" into both "Biology" and "Genetics" category. "Genetics" itself is in the "Biology" Category. On the "Genetics" and "Biology" pages, at the bottom, you'll find a grey box, listing all the pages that are within that category.
OK, I know this screams "problems" all over, but it's just the "hooray, it's running!" version. There's much more to be done, starting with a sorted article output to limiting "Search" and "Recent Changes" to certain categories, and so on. But hey, it's a start...
A more technical note: I also put all the "fixed" text displayed on the 'pedia into variables and collected them in one single file. So, for international versions, only one file has to be changed, the other files can get "technical" updates without having to translate/merge the whole thing again.
That's all for now, Magnus
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
Larry, I was just working my way through a "feature request" list I keep for myself, and "categories" was one of them. So, I'm sure it was in discussion somewhere. The only mention of it I can find right now is at
http://wikipedia.com/wiki/Feature_requests/Really_ambitious_and_fanciful_fea ture_requests
where you already "answered" that request, as I see now. Anyway, the feature isn't meant to *reduce* anything - it is just for making certain things easier. As I said, it is only implemented as a "minimal" version right now. There's no pressure to use it. Yes, it has some drive into the "old-fashioned" categories. But, even in the "web structure" of wikipedia, noone would put a "DNA" article under "fiddle traditions"...
I just thought it would make things easier, so *later*, you could restrict your "Recent Changes" to display only articles * without any category information (=not categorized at all) and * those with Biology as a category There's no point in choosing a category at every edit, right?
Also, this could be a way to use categories for the "approval" mechanism we didn't decide on yet...
As for the categories, I suggest we use all "HomePage" categories, and, additionally, more specific ones, like "Biochemistry".
Of course, most of that *could* be done with simple [[links]] (treat a link to [[Biology]] as a category, for example), this is just more - well, visible.
If you don't want it, just say so, it'll be gone in a minute... (Remember, I just implement the stuff, I don't think about what it is good for;)
Magnus
-----Original Message----- From: wikipedia-l-admin@nupedia.com [mailto:wikipedia-l-admin@nupedia.com]On Behalf Of Larry Sanger Sent: Thursday, January 03, 2002 8:10 PM To: Wikipedia-L@Nupedia. Com Subject: Re: [Wikipedia-l] Categories in the PHP script
Magnus, can you give me an example of a post or just some point that someone has made, that constituted a feature requirement such that this feature in particular is supposed to fulfill it? There's so much that has been said on the topic of categories that I can't remember. I mean, I'd like to see the feature requirements at the same time we see the feature, so that we can compare the two.
I do remember one feature that I asked for, along with Jimbo (in at least one form--the feature, not Jimbo), and perhaps some other people, that this might help with. Namely, "Recent Changes" has gotten perhaps so large as to have too much noise and not enough signal for someone who is interested only in a few topics. In that case, my suggestion was that we categorize edits (not articles) in one of the front-page categories, by selecting them from a multiple selection box. (Future edits could be automatically categorized the same way, or changed by the user as they become relevant to different areas.) This is a specific, delimited solution to a specific, delimited problem, and it would make Wikipedia more attractive to specialists, which is important.
The category feature you've created could be used in all sorts of ways, and (sorry!) I'm not sure I like all of those ways. First of all, it appears to be a way to get the notion of subpages in through the back door, by distinguishing a "category" category of articles and an "articles in this category" category. So, if used indiscriminately, I'd largely be opposed to this new feature on much the same grounds that I was opposed to subpages in the first place.
If, on the other hand, we as a community were to decide that only a *limited, pre-designated* set of pages could be "category" pages, then this would be, obviously, different from the old main page-subpage scheme. In that case, though, I should think it would be better to select the category for any given page from a drop-down box, so people couldn't mess up the spelling, attempt to add categories that shouldn't be categories, etc. Moreover, while my misgivings with subpages would not apply, for the most part, I'd still wonder--just because I like to be clear about this sort of thing--what the feature, used this way, would accomplish. I imagine that after the philosophy of language article, we'd have the "philosophy" and "language" (and/or "linguistics") categories listed. In doing this, we would *highlight* the fact that the article belongs to a number of traditional academic categories. And we would invite the reader to begin their exploration of Wikipedia with those traditional academic categories. And you know, I agree with the interdisciplinary advocates: I just don't think the traditional academic categories are *important enough*, per se, for us to take this trouble to *highlight* them for the reader. The reader can easily and will naturally deduce the general subjects, at many different levels (not just the broadest-traditional- academic-category level), just by reading the article and following the links in the text. The beauty of a well-written, complete, well-linked article is that one can specifically place its location in the web of knowledge by reading the article itself.
Of course, I could be just failing to remember or realize some other clear benefit of having articles sorted into a limited number of various official categories.
Now, if we *simply* wanted to use this as a standard "see also" section, some modified version of this might work well. But it does too much for just tha right nowt...
Awaiting further enlightenment!
Larry
On Thu, 3 Jan 2002, Magnus Manske wrote:
Hi all!
I finally got to implement the often-demanded categories in the
PHP script
(http://wikipedia.sourceforge.net/fpw/wiki.phtml).
It works like this:
- Add "{{CATEGORY A category,Another category}}" to the text of
an article.
Separate the categories by ",".
- Everything between {{ and }} will *not* be displayed within
the text, but
as a category list at the bottom of the page, as well as in the
sidebar, if
you have turned it on.
- In an article that *is* a category, write "{{THISCATEGORY}}"
somewhere.
This will be replaced with a list of all articles which *at that very moment* have a "{{CATEGORY xyz}}" for that category.
See it for yourself at the above site. I put "Gene" and "DNA" into both "Biology" and "Genetics" category. "Genetics" itself is in the "Biology" Category. On the "Genetics" and "Biology" pages, at the bottom,
you'll find
a grey box, listing all the pages that are within that category.
OK, I know this screams "problems" all over, but it's just the
"hooray, it's
running!" version. There's much more to be done, starting with a sorted article output to limiting "Search" and "Recent Changes" to certain categories, and so on. But hey, it's a start...
A more technical note: I also put all the "fixed" text displayed on the 'pedia into variables and collected them in one single file. So, for international versions, only one file has to be changed, the
other files can
get "technical" updates without having to translate/merge the
whole thing
again.
That's all for now, Magnus
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
On Thu, 3 Jan 2002, Magnus Manske wrote:
Larry, I was just working my way through a "feature request" list I keep for myself, and "categories" was one of them. So, I'm sure it was in discussion somewhere. The only mention of it I can find right now is at
http://wikipedia.com/wiki/Feature_requests/Really_ambitious_and_fanciful_fea ture_requests
where you already "answered" that request, as I see now.
OK. :-)
Anyway, the feature isn't meant to *reduce* anything - it is just for making certain things easier.
Of course!
As I said, it is only implemented as a "minimal" version right now.
That's interesting--I'm wondering what the full version would do!
There's no pressure to use it.
Right, but there was no pressure to use subpages either; it was just a feature that happened to be included in the wiki software that we happened to adopt, and people thought it was nifty and started using it anyway.
Yes, it has some drive into the "old-fashioned" categories. But, even in the "web structure" of wikipedia, noone would put a "DNA" article under "fiddle traditions"...
Of course not; that's not what I'm concerned about. I'm mainly concerned about adding unnecessary complications, and imposing useless category schemes--when the content *is* the category scheme--when the information in articles (if well done) provides its own structure in as detailed and precise a way as one could possibly hope for.
I just thought it would make things easier, so *later*, you could restrict your "Recent Changes" to display only articles * without any category information (=not categorized at all) and * those with Biology as a category There's no point in choosing a category at every edit, right?
Well, in fact, there is. Rather than categorizing articles--which, I think, opens up a huge can of worms that is best left in the depths of the pantry--we categorize edits. The *edit* category information for each article is saved with each article, and can be changed by each user (a philosophical addition to [[God]] is filed under the philosophy category, whereas one that gives details about the Muslim conception of God wouldn't be). And that info is used *just* to solve one clear problem, viz., that edits in all sorts of different fields are jumbled together in the present Recent Changes page. (Some people would like that, and they could just choose to view all edits. I'd probably view things that way myself, but I'd like the option of just looking at the philosophy edits too.)
Also, this could be a way to use categories for the "approval" mechanism we didn't decide on yet...
I'm not sure I understand...?
Anyway, I thought I made it pretty clear that you've got a dilemma, and I'm curious what you think about it. On the one hand, you might want the categories to proliferate freely. Then you've just recreated subpages with all their problems. On the other hand, you might want the categories to be of a limited set. In that case, we should have a drop-down box that lists the categories we (somehow) decide on (to prevent misspelling and the proliferation of new categories). Also in that case, it's still just not clear what the *purpose* of the feature is. So far, I can see only *one* purpose that is important enough to warrant all the trouble, namely, categorizing edits (or articles) for purposes of the overgrown [[Recent Changes]] page. If that's the purpose of the feature, the feature, in my opinion, should probably be redesigned so as to include a drop-down box rather than in-the-text data; the data in any case should probably be used just for [[Recent Changes]] categorization, not to inform readers of what category an article belongs to.
If designed with enough flexibility, then, *if* we found some clear advantage or use for categorizing articles (i.e., if we spelled out what article categorization would be used for, such that that would be a clear advantage over the presents system), we could use the same data to categorize articles.
As for the categories, I suggest we use all "HomePage" categories, and, additionally, more specific ones, like "Biochemistry".
Well, I don't know. That would be something that is up to all of us to opine about and hash out. It depends, again, entirely on what the purpose of the feature is! If the purpose is *just* to sort [[Recent Changes]] neatly, I imagine it might depend on how narrowly we can expect people's interests in Wikipedia article edits to be delineated.
Of course, most of that *could* be done with simple [[links]] (treat a link to [[Biology]] as a category, for example), this is just more - well, visible.
If you don't want it, just say so, it'll be gone in a minute... (Remember, I just implement the stuff, I don't think about what it is good for;)
In the interests of simplicity and general lack of headaches, I'd say at least scrap *this* version of it; but save the code, of course, since we might think of a very good use for it.
Larry
-----Original Message----- From: wikipedia-l-admin@nupedia.com [mailto:wikipedia-l-admin@nupedia.com]On Behalf Of Larry Sanger Sent: Thursday, January 03, 2002 8:10 PM To: Wikipedia-L@Nupedia. Com Subject: Re: [Wikipedia-l] Categories in the PHP script
Magnus, can you give me an example of a post or just some point that someone has made, that constituted a feature requirement such that this feature in particular is supposed to fulfill it? There's so much that has been said on the topic of categories that I can't remember. I mean, I'd like to see the feature requirements at the same time we see the feature, so that we can compare the two.
I do remember one feature that I asked for, along with Jimbo (in at least one form--the feature, not Jimbo), and perhaps some other people, that this might help with. Namely, "Recent Changes" has gotten perhaps so large as to have too much noise and not enough signal for someone who is interested only in a few topics. In that case, my suggestion was that we categorize edits (not articles) in one of the front-page categories, by selecting them from a multiple selection box. (Future edits could be automatically categorized the same way, or changed by the user as they become relevant to different areas.) This is a specific, delimited solution to a specific, delimited problem, and it would make Wikipedia more attractive to specialists, which is important.
The category feature you've created could be used in all sorts of ways, and (sorry!) I'm not sure I like all of those ways. First of all, it appears to be a way to get the notion of subpages in through the back door, by distinguishing a "category" category of articles and an "articles in this category" category. So, if used indiscriminately, I'd largely be opposed to this new feature on much the same grounds that I was opposed to subpages in the first place.
If, on the other hand, we as a community were to decide that only a *limited, pre-designated* set of pages could be "category" pages, then this would be, obviously, different from the old main page-subpage scheme. In that case, though, I should think it would be better to select the category for any given page from a drop-down box, so people couldn't mess up the spelling, attempt to add categories that shouldn't be categories, etc. Moreover, while my misgivings with subpages would not apply, for the most part, I'd still wonder--just because I like to be clear about this sort of thing--what the feature, used this way, would accomplish. I imagine that after the philosophy of language article, we'd have the "philosophy" and "language" (and/or "linguistics") categories listed. In doing this, we would *highlight* the fact that the article belongs to a number of traditional academic categories. And we would invite the reader to begin their exploration of Wikipedia with those traditional academic categories. And you know, I agree with the interdisciplinary advocates: I just don't think the traditional academic categories are *important enough*, per se, for us to take this trouble to *highlight* them for the reader. The reader can easily and will naturally deduce the general subjects, at many different levels (not just the broadest-traditional- academic-category level), just by reading the article and following the links in the text. The beauty of a well-written, complete, well-linked article is that one can specifically place its location in the web of knowledge by reading the article itself.
Of course, I could be just failing to remember or realize some other clear benefit of having articles sorted into a limited number of various official categories.
Now, if we *simply* wanted to use this as a standard "see also" section, some modified version of this might work well. But it does too much for just tha right nowt...
Awaiting further enlightenment!
Larry
On Thu, 3 Jan 2002, Magnus Manske wrote:
Hi all!
I finally got to implement the often-demanded categories in the
PHP script
(http://wikipedia.sourceforge.net/fpw/wiki.phtml).
It works like this:
- Add "{{CATEGORY A category,Another category}}" to the text of
an article.
Separate the categories by ",".
- Everything between {{ and }} will *not* be displayed within
the text, but
as a category list at the bottom of the page, as well as in the
sidebar, if
you have turned it on.
- In an article that *is* a category, write "{{THISCATEGORY}}"
somewhere.
This will be replaced with a list of all articles which *at that very moment* have a "{{CATEGORY xyz}}" for that category.
See it for yourself at the above site. I put "Gene" and "DNA" into both "Biology" and "Genetics" category. "Genetics" itself is in the "Biology" Category. On the "Genetics" and "Biology" pages, at the bottom,
you'll find
a grey box, listing all the pages that are within that category.
OK, I know this screams "problems" all over, but it's just the
"hooray, it's
running!" version. There's much more to be done, starting with a sorted article output to limiting "Search" and "Recent Changes" to certain categories, and so on. But hey, it's a start...
A more technical note: I also put all the "fixed" text displayed on the 'pedia into variables and collected them in one single file. So, for international versions, only one file has to be changed, the
other files can
get "technical" updates without having to translate/merge the
whole thing
again.
That's all for now, Magnus
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
I like Magnus' idea a lot. Yes, we could just use ordinary old links. But I like this better for a couple of reasons: 1. Software can understand the {{CATEGORY ...}} notation much better than it can understand plain old links. What if I want to extract all the articles on linguistics from Wikipedia? With categories like this, I could have a script that could do it easily. But with just plain old links, writing a script to do it would be difficult. 2. We can easily find "loose" pages, that don't belong to a category. (On the other hand, we could mark the category pages as category pages, and then search for pages aren't linked from a page marked as a category page.)
Larry suggested having a drop-down box, to limit the categories the users could choose from. I think Wikipedia should support multiple category schemes, and should allow anyone to add their own categories. That way we can experiment, and see what works best. People with alternative views of how to categorise things can create their own category schemes (and categorising things is one area where there are often as many views as there are people, probably because there is no one right answer.)
I think it would be nice if we could have different "category namespaces", to support multiple category schemes. There should also be a way to lock cateogy namespaces: so I can have my own category namespace, and only I am allowed to assign pages to categories within it; or so (like Larry seems to be suggesting) people can't create their own categories, but they can assign pages to pre-existing ones.
I also think that information on "what pages this category belongs to" belongs in the category, not in the page (although I don't know how you were actually installing this.)
Finally, even if we don't want this sort of feature for Wikipedia, why not keep the code, but make it an administrator configurable option? So if Larry & Jimbo don't want to use it on the Wikipedia.com server, they can switch it off, but if other people want to take PHP Wikipedia's code to use for some other purpose they can turn it on if they want to?
Simon Kissane
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
First, let me say that, despite all appearances, I'm not trying to criticize Magnus (surely no one should be criticized for doing work for Wikipedia ;-) ). Or Simon! I just think we need to think harder about all of these issues.
Maybe Simon can answer the question Magnus couldn't (or, not very well as far as I could tell): what is the *purpose* of this feature? What is it supposed to accomplish?
On Sun, 6 Jan 2002, Simon Kissane wrote:
I like Magnus' idea a lot. Yes, we could just use ordinary old links. But I like this better for a couple of reasons:
- Software can understand the {{CATEGORY ...}}
notation much better than it can understand plain old links. What if I want to extract all the articles on linguistics from Wikipedia? With categories like this, I could have a script that could do it easily. But with just plain old links, writing a script to do it would be difficult.
OK, this is helpful: categories could be used to sort articles into broad compilations (associated with academic fields like linguistics) that, for whatever reason (and who can predict what reasons they would be?), people might like to have.
I can see a use for that, but I think it needs to be clarified further: is the claim that it would be useful to have articles sorted only at the top-level categories (those on the HomePage, just for example) or at some expanded level? If at some expanded level, depending on *how* expanded, the purpose(s) of the feature might change considerably.
Moreover, it is *not* at all clear to me (particularly given, as Simon says, we might want to support multiple category schemes--though this too I might doubt, as I'll have to explain) that this particular implementation is the best. What *would* be the best way to sort articles into broad categories? Why not, for example, have special pages that simply list article titles, so that, e.g., [[linguistics category]] would contain nothing but links to articles that someone asserts belong to the category of linguistics? We could just as easily autogenerate lists of uncategorized pages, and for each article page we could have the script look at the category: pages to see whether the article is in a category. I'm not saying that this is a better idea; I'm just saying that there are multiple ways of going about doing something, and it would be a mistake not to consider them.
- We can easily find "loose" pages, that don't belong
to a category. (On the other hand, we could mark the category pages as category pages, and then search for pages aren't linked from a page marked as a category page.)
Larry suggested having a drop-down box, to limit the categories the users could choose from. I think Wikipedia should support multiple category schemes, and should allow anyone to add their own categories.
Well, we could have multiple drop-down boxes, eh? How else would we individuate our multiple category schemes? The whole point of a drop-down box is to disallow a category scheme from metastasizing for frivolous reasons (such as that somebody didn't know that an article that goes under XYZ really belongs under XYZ, and so creates its own category--just an example).
That way we can experiment, and see what works best.
How exactly would we experiment? What would we be seeing "works best"?
I think at this point we need to be very clear on what we mean by "category scheme." On the one hand, there are schemes of the sort we have on the Home Page, or the Library of Congress catalog scheme. Those schemes (1) list subjects, (2) arrange those subjects under larger headings ("supercategories"), and even (3) provide an ordering of some sort within the "supercategories." So when you say we can experiment and see what works best, which of these (or what combination) do you mean? We already do experiment with multiple category schemes in the sense of a combination of (1) and (2). But this doesn't list all articles, of course.
But when Magnus proposes to allow us to list the category, or categories, of a particular article on an article's page itself (even within the body of the article itself), he provides us no particular category scheme in *any* of the senses in (1), (2), or (3) (which is fine). What Simon asserts now is that Magnus' feature allows is "multiple category schemes." I don't see this, though. What it allows us, rather, is multiple *categories*, at the whim of the user: so we could expand the list mentioned in (1) at will. That's the only sense in which I can see how Magnus's feature allows us "multiple category schemes."
By contrast, there's nothing about Magnus' feature that allows us to produce multiple category schemes in the sense in which we've *usually* talked about them on Wikipedia (and Nupedia), viz., the *combination* of (1) (a specific, delimited set of subject categories) and (2) (an arrangement of that delimited set into supercategories). As far as I can tell, Magnus' feature at present would give us *a single* infinitely expandable set of categories.
People with alternative views of how to categorise things can create their own category schemes (and categorising things is one area where there are often as many views as there are people, probably because there is no one right answer.)
Wouldn't that make categorization particularly pointless? No one person is going to categorize all our articles, I imagine--no one person is competent to do so, probably. That means we have to work together on this. Now, I can see multiple competing category schemes (maybe--but I'd like to know what the purpose of *that* would be). Say, two or three. More than that, and, again, we've got a veritable babel; in that case, I doubt any one scheme would succeed in categorizing all the articles. Even two or three is a little confusing: won't "philosophy" be a category in any plausible scheme? Similar with other traditional subjects. So how will the competing category lists (not schemes, really) be distinguished?
On the other hand, if we can agree in advance on one set of categories, then, *for the purpose of sorting articles into broad academic fields* (which, as I said, seems like a clear, reasonably useful purpose), we can *work together* on sorting all the articles. That would be a good thing: it could be a useful, accurate piece of metadata.
I think it would be nice if we could have different "category namespaces", to support multiple category schemes. There should also be a way to lock cateogy namespaces: so I can have my own category namespace, and only I am allowed to assign pages to categories within it; or so (like Larry seems to be suggesting) people can't create their own categories, but they can assign pages to pre-existing ones.
I'm not sure I understand, exactly, but is the idea here somewhat like the one I suggested above? Viz., we put the metainformation about categories not on article pages but on special categorization pages?
I also think that information on "what pages this category belongs to" belongs in the category, not in the page (although I don't know how you were actually installing this.)
Aha, yes. Might be better, yes.
Finally, even if we don't want this sort of feature for Wikipedia, why not keep the code, but make it an administrator configurable option? So if Larry & Jimbo don't want to use it on the Wikipedia.com server, they can switch it off, but if other people want to take PHP Wikipedia's code to use for some other purpose they can turn it on if they want to?
I'd be 100% in favor of something like that.
I really don't like to sound contrary (really, I don't!), but I think that whenever we propose new features that could potentially complicate the process of building Wikipedia, and that could be abused or misused (resulting in confusion if nothing else), we should think more carefully about what we are doing and why we're doing it, exactly.
So far, along these lines, there are *two* actual reasons that I have spotted for why we might want to do *one specific* thing, viz., list (somewhere) the metadata about what *general categories* articles are classed under. To wit:
(1) It would help sort the Recent Changes page nicely, so that specialists can, if they want, focus just on articles in their areas. (Others could view all categories at once.) If this were all we needed to accomplish, then we might as well sort *edits* into categories, not *articles*.
(2) It would allow us to produce a list of all the articles in one broad area of study, which would no doubt be useful for a variety of purposes. For this, of course, we need to sort articles, not edits.
Now, there are a variety of ways we could accomplish both of these purposes. The best I think we've heard so far would work like this:
On each article page, there is a multiple-selection box that allows us to place articles into one or more categories from among a set of categories that is previously decided upon by Wikipedia members and probably Nupedia as well (it would be nice if the categories corresponded to Nupedia review groups). This particular datum is editable like anything else in the article. There is *also* a set of pages sorting existing articles into these categories based on the metadata found on the articles; these might or might not be editable. There is, as well, a page or several of unsorted articles; from that page one could visit different pages and sort them quickly.
The latter proposal would accomplish purposes (1) and (2) as follows: the metadata would allow us to sort the Recent Changes page so we can view only those categories of articles we're interested in; it would also allow us to generate (and further organize, perhaps) broad categories of articles. One can see an autogenerated Wikipedia Encyclopedia of Mathematics, for example!
Larry
--- Larry Sanger lsanger@nupedia.com wrote:
First, let me say that, despite all appearances, I'm not trying to criticize Magnus (surely no one should be criticized for doing work for Wikipedia ;-) ). Or Simon! I just think we need to think harder about all of these issues.
Maybe Simon can answer the question Magnus couldn't (or, not very well as far as I could tell): what is the *purpose* of this feature? What is it supposed to accomplish?
Well, as I see it, the purpose is to make the administration of lists of pages easier -- these lists could be categories (such as Philosophy, or Mathematics, or so on) -- but I also think other lists such as Biographies, Mathematics, U.S. Presidents, International Intergovernmental Organizations, and so on.
Consider for example if I was to put the article on Bill Clinton in the Biography listing, and the U.S. Presidents listing. At the moment I have to edit two or three pages -- the Biography and the U.S. Presidents listing to add a link to the article, and the article to add a backlink to the lists (if so desired). With Magnus proposal, as I understand it, I'd just have to insert "{{{CATEGORY Biography, US_Presidents}}}" into the article and I'd be done.
Also, with these categories, its easier to automatically extract the articles in Wikipedia on that category, since software can parse "{{{CATEGORY ...}}}" more easily than links on a category page (since it can't tell which links point to pages within the category, and which links point elsewhere -- unless it has AI, of course).
And supposing we want to divide articles up by traditional academic discipline, using this lets us easily see which articles have not yet been assigned. (We'd simply have to do a query to see which articles are not in one of the categories which make up our category scheme.)
[snip]
OK, this is helpful: categories could be used to sort articles into broad compilations (associated with academic fields like linguistics) that, for whatever reason (and who can predict what reasons they would be?), people might like to have.
I can see a use for that, but I think it needs to be clarified further: is the claim that it would be useful to have articles sorted only at the top-level categories (those on the HomePage, just for example) or at some expanded level? If at some expanded level, depending on *how* expanded, the purpose(s) of the feature might change considerably.
Well, I see two uses for this. Firstly, putting articles into broad categorisations, such as those used on the home page. Second, is maintaining lists like U.S. President, and so on.
I'm not proposing we try to design a complex hierarchial classification scheme. For starters, we can put all the Maths pages into a "Mathematics" category. But, if someone wants to go to the trouble of creating additional categories, "Mathematics--Analysis" and "Mathematics--Topology" and "Mathematics--Geometry" and so on, why not let them? Lets create a basic category scheme to start with, and let it grow finer over time as (and if) people see the need.
We should also allow people to create low-level categories without fitting them into a hierarchy -- I should be able to go ahead and create the category U.S. Presidents, without having to decide whether it belongs under History or Politics or what, or where it should belong in some finer subclassification of those topics. Later on, if we feel the need, and once the category system is sufficently evolved, we can worry about how to fit these standalone low-level categories into broader ones.
Moreover, it is *not* at all clear to me (particularly given, as Simon says, we might want to
support multiple category schemes--though this too I might doubt, as I'll have to explain) that this particular implementation is the best. What *would*
be the best way to sort articles into broad categories? Why not, for example, have special pages that simply list article titles, so that,
e.g.,
[[linguistics category]] would contain nothing but links to articles that someone asserts belong to the category of linguistics? We could just as easily autogenerate lists of uncategorized pages, and for each article page we could have the script look at the category: pages to see whether the article is in
a category. I'm not saying that this is a better idea; I'm just saying that there are multiple ways of going about doing something, and it would be a mistake not to consider them.
I think the approach you suggest would be inferior to Magnus' for a number of reasons. Firstly, when looking at an article, you would not be able to see which categories it belonged to, unless someone added a backlink to that category. Secondly, if I want to add an article to three different categories, I have three different pages I have to edit -- four if I want to include a backlink in the article. Thirdly, by using the "{{{CATEGORY ...}}}" notation, we can store the categories directly in the database, if we want, as a CATEGORY table -- which will mean faster access.
[snip]
Larry suggested having a drop-down box, to limit the categories the users could choose from. I
think
Wikipedia should support multiple category
schemes,
and should allow anyone to add their own categories.
Well, we could have multiple drop-down boxes, eh? How else would we individuate our multiple category schemes? The whole point of a drop-down box is to disallow a category scheme from metastasizing for frivolous reasons (such as that somebody didn't know
that an article that goes under XYZ really belongs under XYZ, and so creates its own category--just an example).
I agree that we need to find a way to stop frivolous or accidental creation of categories. But at the same time, I think we should create tools that can be used for a wide variety of purposes, rather than putting things in a straightjacket.
The main point behind having multiple category schemes is that I can ask the software the question "Does this page belong to any category in this scheme?" Suppose we decide we want to place every Wikipedia article in certain broad categories (Mathematics, Physics, Chemistry, Biology, Philosophy, History, etc.), then we want a list of all articles which do not currently belong to one of those categories. Suppose "Bill Clinton" belongs to the category "U.S. Presidents" -- that article should still come up in our list, since although it belongs to a category, it does not belong to the broad category scheme. So at the least, we'd want a way of distinguishing subject categories (such as History, Philosophy, etc.) from other categories (like U.S. Presidents, Treaties, Roman Emperors, Popes, etc.).
Secondly, suppose someone wants to create a subclassification of a pre-existing category. Say create categories "History--Ancient", "History--Medieveal" and "History--Modern", or "History--Europe", "History--North America", "History--Asia" and so on. Then they'd want to ask "show me all the articles in category History which haven't been assigned to categories History--Ancient, History--Modern or History--Europe". This would involve some way of marking categories as subcategories of a larger category. However, these aren't just simple subcategories within the same category scheme -- these are two orthogonal categorisations. We want to be able to generate separate "not yet assigned" lists for each.
To stop people accidentally or frivolousy creating categories, we could make it so that people have to execute some special procedure (e.g. a create_category action on the script) to create a category (so they don't accidentally automatically create one, by mispelling it say.) That procedure should show them what categories already exist, warn them against creating them needlessly, explain Wikipedia policy on categories, and so on.
We should also enable for categories to be deleted if they are created in error. Only admins should do that after consultation -- but we could permit anyone to delete them, if we had an "undelete" feature (i.e. the category disappears from the list of categories, but its data is retained, so it can be undeleted.)
As to drop down boxes, they have their advantages and disadvantages. The advantage is that they are easier to use than {{{CATEGORY ...}}}. The disadvantage is that if we ended up with a lot of categories, they'd become unwieldly. They should be multiple selection combo-boxes, not drop-down boxes, if we are going to allow the one article to belong to multiple categories. Finally, the problem with combo boxes is that its easy to accidentally add or remove an article from a category -- one misplaced click is all it takes. At least with "{{{CATEGORY ...}}}", they have to type or delete something.
But whatever user interface we choose, we can still provide the same backend implementation.
That way we can experiment, and see what works best.
How exactly would we experiment? What would we be seeing "works best"?
Well, as I said, create little categories for things like "U.S. Presidents", "Kings of France", "Bible"... and if someone wants to subcategorize a broader category (i.e. create "History--Asia" and "History--United States"), let them. Let the system evolve (just like how we let Wikipedia articles evolve). Remove categories that are unneccesary or stupid. Every now and then, look back over what is there, and try to move things into a more coherent system.
I think at this point we need to be very clear on what we mean by "category scheme." On the one hand,
there are schemes of the sort we have on the Home Page, or the Library of Congress catalog scheme. Those schemes (1) list subjects, (2) arrange those subjects under large headings ("supercategories"), and even (3) provide an ordering of some sort within the "supercategories." So when you say we can experiment and see what works best, which of these (or what combination) do you mean?
Well, now I thought about it more, what I'm really talking about is groups of categories which fit together -- e.g. all different subdivisions of the one broader subject along one aspect. (Kind of like a faceted library classification, ala the Colon Classification of S. R. Ranganathan.) So we'd really only have one category scheme, it would just be, in part, hierarchial and faceted.
We already do experiment with multiple category schemes in the sense of a combination of (1) and (2). But this doesn't list all articles, of course.
But when Magnus proposes to allow us to list the category, or categories, of a particular article on an article's page itself (even within the body of the article itself), he provides us no particular category scheme in *any* of the senses in (1), (2), or (3) (which is fine). What Simon asserts now is that Magnus' feature allows is "multiple category schemes."
Well, it doesn't at the moment allow that, but it could be extended to do so, which is I suppose what I am proposing.
[snip]
People with alternative views of how to categorise things can create their own category schemes (and categorising things is one area where there are often as many views as there are people, probably because there is no one right answer.)
Wouldn't that make categorization particularly pointless? No one person is going to categorize all
our articles, I imagine--no one person is competent to do so, probably. That means we have to work together on this. Now, I can see multiple competing category schemes (maybe--but I'd like to know what the purpose of *that* would be). Say, two or three. More than that, and, again, we've got a veritable babel; in that case, I doubt any one scheme would succeed in categorizing all the articles. Even two or three is a little confusing: won't "philosophy" be a category in any plausible scheme?
Similar with other traditional subjects. So how will the competing category lists (not schemes, really) be distinguished?
Now I think about it, I agree with you, so I withdraw that aspect of what I'm proposing.
On the other hand, if we can agree in advance on one set of categories, then, *for the purpose of sorting
articles into broad academic fields* (which, as I said, seems like a clear, reasonably useful purpose), we can *work together* on sorting all the articles. That would be a good thing: it could be a useful, accurate piece of metadata.
I think that would be useful also. But I also think we should permit the creation of many finer categories, such as U.S. Presidents, or Kings of England, or Treaties, or Thailand, or 12th century... and also subdivisions of subjects, so we can have "Philosophy--Philosophy of Religion" and "Mathematics--Analysis" and "Law--criminal law"... I'm not suggesting we design a whole detailed category scheme from the top-down, but rather let one grow from the bottom up...
I think it would be nice if we could have different "category namespaces", to support multiple category schemes. There should also be a way to lock category namespaces: so I can have my own category namespace, and only I am allowed to assign pages to categories within it; or so (like Larry seems to be suggesting) people can't create their own categories, but they can assign pages to
pre-existing ones.
I'm not sure I understand, exactly, but is the idea here somewhat like the one I suggested above? Viz.,
we put the metainformation about categories not on article pages but on special categorization pages?
It was a badly thought out suggestion, so I withdraw it.
[snip]
I really don't like to sound contrary (really, I don't!), but I think that whenever we propose new features that could potentially complicate the process of building Wikipedia, and that could be abused or misused (resulting in confusion if nothing
else), we should think more carefully about what we are doing and why we're doing it, exactly.
My attitude is different -- build versatile tools, that can be used for many things, and then see what useful things people can do with them. I agree though we should be careful to avoid abuse or misuse, or having some wizzy new software feature get in the way of the primary purpose of Wikipedia, which is writing articles (categorising them is only secondary).
[snip]
(1) It would help sort the Recent Changes page nicely, so that specialists can, if they want, focus
just on articles in their areas. (Others could view all categories at once.) If this were all we needed to accomplish, then we might as well sort *edits* into categories, not *articles*.
(2) It would allow us to produce a list of all the articles in one broad area of study, which would no doubt be useful for a variety of purposes. For this,
of course, we need to sort articles, not edits.
Let me add: (3) We need a heap of categories to make it easier to maintain and manipulate lists of Presidents, Philosophers, Mathematicians, Countries, International Organizations, and so on. (One category per a list.)
(4) We need categories to group articles on some broad topic, such as all the articles on the Bible, or articles on Hinduism, or all articles on the U.S. Government, or so on. When dealing with a broad topic like these, it would be nice to see a list of all the articles on the topic, to help improve the coherency between the different articles on the topic. However, although these are broad topics, they are a lot narrower than the disciplines you suggest.
(5) We need categories to help progressively develop a more structured category scheme for Wikipedia. (The bigger we get, the more essential organizing is going to be, or else everything will just turn into a mess...)
Now, there are a variety of ways we could accomplish both of these purposes. The best I think we've heard so far would work like this:
On each article page, there is a multiple-selection box that allows us to place articles into one or more categories from among a set of categories that is previously decided upon by Wikipedia members and probably Nupedia as well (it would be nice if the categories corresponded to Nupedia review groups). This particular datum is editable like anything else in the article. There is *also* a set
of pages sorting existing articles into these categories based on the metadata found on the articles; these might or might not be editable. There is, as well, a page or several of unsorted articles; from that page one could visit different pages and sort them quickly.
The latter proposal would accomplish purposes (1) and (2) as follows: the metadata would allow us to sort the Recent Changes page so we can view only those categories of articles we're interested in; it would also allow us to generate (and further organize, perhaps) broad categories of articles. One can see an autogenerated Wikipedia Encyclopedia of Mathematics, for example!
We could have both your proposal and mine. We have a fixed set of broad categories for your purposes (1) and (2). And we have an expandable list of independent categories or subcategories for my purposes (3)-(5).
Larry
Simon.
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
"Umgekehrt wird ein Stiefel d'raus"
I'll propose somewhat the reverse of what Magnus envisoned. In detail:
Categorised pages contain no special markup. Contrariwise, the category pages contain special links (syntactically different from normal ones) to pages considered in that category.
* Why is this scheme better than we do now (plain old links from a category to categorised pages)?
Scripts can tell that e.g. {{Compilers}} is in category [[Computer science]] but [[Mathematics]] or [[1950s]] is not. It's possible to automatically show (e.g. on the article bottom) links to the categories a page is in, to restrict searches to pages in category X, etc.
* Why is this scheme better than Magnus's (noting on a page itself that it belongs to categories X, Y, Z)?
Almost no good category list is just a random jumble of links. For example [[Prime ministers of Great Britain]] should probably be sorted in chronological order. "Proper" categories like [[Computer science]] are best represented by dividing the listing into subfields (as done in the current page). Magnus's scheme could support this via more complicated syntax (e.g. {{{CATEGORY P.M. of Great Britain;1985}}}, or {{{CATEGORY Comuter science;Algorithms}}}), but that reeks a bit of overengineering. Plus writers would have to coordinate their efforts (choose the same subcategorisation, and/or sort order) -- coordination is easier done on a single page (the category) than across a number of pages.
So the promise of "just editing one page instead of two or more" is a fallacy IMO. Even with the extended synatx above, you'd first have to check out the category page(s) to see the existing layout before you could sensibly write the correct category link(s).
If one doesn't want to put too much work into categorisation, and really wants to only let the link show up on the category page in a random location, my scheme could support this as well. Imagine a "put this page into this categories" box separate from the normal text edit box. Putting one or more categories there will add special links back to this topic onto the end of these pages. They'd be put into a distinct section, e.g. named "unsorted links". People tending to the category page can take and move these to a more proper position. I'm not sure whether we /want/ to support this kind of laziness by the original authors, though.
Concerns were raised that links from a categorised page to a category are more easily processed automatically than the other way around. My response is that this is an implementation detail -- one can always keep a seperate "backlink" index seperate from the main page texts for optimisation.
Robert Bilhmeyer wrote:
"Proper" categories like [[Computer science]] are best represented by dividing the listing into subfields (as done in the current page). Magnus's scheme could support this via more complicated syntax (e.g. {{{CATEGORY P.M. of Great Britain;1985}}}, or {{{CATEGORY Comuter science;Algorithms}}}), but that reeks a bit of overengineering.
My experience from various wiki shorthand notations is that they should be easy-to-write. The major difference between an old style website and a wiki is that the wiki is written by all, and that this broadening of the authorship must be met by a simplification in format. For example, the choice between plural and singular in article headings is guided by which is easier to use as a link from another text, and that most often turns out to be a singular, thus [[Car]] rather than [[Cars]].
The indicated sort of overengineering should be avoided, not because I say so, but because it will not be used. You can try to introduce it, and then collect statistics on its use, and draw conclusions from the numbers. Keep it simple, make it successful. Even the use of special {{}} braces seems overly complicated to me. This is not a programming language designed for programmers, but a text format intended for someone who is specializing in entomology or woodcarving.
For a real simple category system, see http://www.c2.com/cgi/wiki?CategoryCategory
--- Lars Aronsson lars@aronsson.se wrote: [snip]
My experience from various wiki shorthand notations is that they should be easy-to-write. The major difference between an old style website and a wiki is that the wiki is written by all, and that this broadening of the authorship must be met by a simplification in format. For example, the choice between plural and singular in article headings is guided by which is easier to use as a link from another text, and that most often turns out to be a singular, thus [[Car]] rather than [[Cars]].
The indicated sort of overengineering should be avoided, not because I say so, but because it will not be used. You can try to introduce it, and then collect statistics on its use, and draw conclusions from the numbers. Keep it simple, make it successful. Even the use of special {{}} braces seems overly complicated to me. This is not a programming language designed for programmers,
but a text format intended for someone who is specializing in entomology or woodcarving.
I don't think its that big a problem if the category syntax is a tad bit complicated. Its not content-creation, its metadata. The entomologist or woodcarver who can't understand the category system can just write their article anyway, and let other people worry about the category system.
And, how is "{{{CATEGORY ...}}}" any more complicated than "#REDIRECT"? Not much. Maybe, if we want to make the syntax more coherent, we could use syntax "#CATEGORY" instead?
So instead of writing (Bill Clinton article): {{{CATEGORY Biography, US_Presidents}} We could write, on a line by itself anywhere in the article: #CATEGORY [[Biography]], [[US Presidents]] In fact, this syntax is probably easier to write than Magnus', so maybe we could use this one instead?
For a real simple category system, see http://www.c2.com/cgi/wiki?CategoryCategory
When I read this, I had what seemed like a good idea at first. Why not just adopt Categories as in the original WikiWiki?
I would suggest though that rather than use CamelCase to mark categories, lets use a namespace "category:" or "cat:". Then, a page containing a link to a category page is in that category.
There is one problem here: what if I want to link to category X page from page Y, without thereby adding page Y to category X? We'd need to introduce two different syntaxes -- one for adding the page to the category, and one for referring to it. For example, we could have "[[cat:Dog Breeds]]" to put the current page in the category "Dog Breeds", and "[[catref:Dog Breeds]]" to link to the "Dog Breeds" category without putting the page in it. But how is that any simpler than Magnus' proposed syntax? If anything it seems harder, and unless you know the difference between cat: and catref: one might get them confused, and accidentally add an article to a category, or just link to the category when you meant to add to it.
If you look at http://www.c2.com/cgi/wiki?DiscussionOfCategories, you'll find that this problem has been discussed already on WikiWiki. They suggest three solutions: a link prefix, a separate linking syntax, and do nothing. A link prefix is what I suggested above, cat: and catref:. A different linking syntax is basically the {{{CATEGORY}} syntax Magnus proposed, or the #CATEGORY syntax I propose above. Doing nothing is not making a distinction, and including pages which link to a category in the category. The last is what WikiWiki does at present. While that might be acceptable for WikiWiki, I don't think it is acceptable for Wikipedia.
[snip] Simon J Kissane
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
--- Robert Bihlmeyer robbe+wiki@orcus.priv.at wrote: [snip]
- Why is this scheme better than Magnus's (noting on
a page itself that it belongs to categories X, Y,
Z)?
Almost no good category list is just a random jumble of links.
I both agree and disagree. An organized collection of links can be useful. But an alphabetical list of articles in the category can still be quite useful.
I know it might sound like a bit of an overkill, but we could have both -- we could have organized and unorganized category pages, the unorganized ones automatically generated, the organized ones made by hand. Since we'd only have to maintain one (the organized one), its really no more work than we have at the moment.
I think generating category pages to display to the user is only one use for categories -- there are uses for software-understood categories as well, like siome of the uses I and Larry have mentioned in our respective posts. So a categorisation that doesn't automatically feed into the category page might still be useful.
For example [[Prime ministers of Great Britain]] should probably be sorted in chronological order.
Ideally, I'd like to have the software understand objects like "Incumbent", with little fields of data like "Office, Name, Start Date, End Date"... That way we could produce little databases of office holders, etc... They could be used to generate a category, sorted whichever way you wish. And, since they'd be databases, the information in them would be easily available to dumb software (exactly what you'd do with it though, I don't know.) I've been thinking about doing this, although its not really a priority at the moment.
"Proper" categories like [[Computer science]] are best represented by dividing the listing into subfields (as done in the current page).
Well, my suggestion was that they would be subcategories, or independent categories in their own life... so an algorithm could go in the category [[Computer Science/Algorithms]], or alternatively in both the [[Computer Science]] category and the [[Algorithms]] category. Using a modification of Magnus' proposal you could display the contents of multiple categories on the one page.
Magnus's scheme could support this via more complicated syntax (e.g. {{{CATEGORY P.M. of Great Britain;1985}}}, or {{{CATEGORY Computer science;Algorithms}}}), but
that
reeks a bit of overengineering.
I think in the case of Algorithms, it makes sense. Most category systems permit subcategories, so why not have a "Computer Science/Algorithms" category?
As to the P.M, well, I agree with you that seems a bit overengineered.
Plus writers would have to coordinate their efforts (choose the same subcategorisation, and/or sort order) -- coordination is easier done on a single page (the category) than across a number of pages.
I don't envision the primary responsibility for categorisation necessarily being with the writer of the page. Writing articles, and categorising them, are different tasks, and don't need to be done by the same people. (One is like an author, the other like a librarian.)
So the promise of "just editing one page instead of two or more" is a fallacy IMO. Even with the extended synatx above, you'd first have to check out the category page(s) to see the existing layout before you could sensibly write the correct category link(s).
Well, it depends on how well you know the category, and how it is organized. If you are thinking of just assigning things to major categories, like "Physics", or "Philosophy" and "History", and we are in the process of assigning 20,000 articles to these major categories, then just being able to click "Edit this page", add "{{CATEGORY}}}" and save is a lot simpler.
Simon J Kissane
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
I'd like to mention two simple technical solutions that came to my mind reading the last posts:
1. The cat: namespace is a nice idea. Maybe [[cat:foobar]] could point to the same page as does [[foobar]], so the script could tell apart when you mean "link" and when you mean "category".
2. Another way would be to have no {{}} or [[cat:]] or the like at all, but use the "pages that link here" function I already implemented. Instead of a seperate page, it could be included by a variable on every page that (supposedly) is a category. The advantage would be that we'd only have to add "see also" links or the like on all the pages to have them listed. The disadvantage would be having pages listed that we don't want to have (e.g., "HomePage" would be listed on the "Biology" page, because it links there).
But currently, I don't think the problem is a technological one. IMHO the question is "have category functionality or not?". I'll leave that one to the rest of the community and to the "higher powers";)
Magnus
Simon Kissane sj_kissane@yahoo.com writes:
I both agree and disagree. An organized collection of links can be useful. But an alphabetical list of articles in the category can still be quite useful.
[later:]
I don't envision the primary responsibility for categorisation necessarily being with the writer of the page.
[and, on the topic of "just edit one page":]
Well, it depends on how well you know the category, and how it is organized. If you are thinking of just assigning things to major categories, like "Physics", or "Philosophy" and "History", and we are in the process of assigning 20,000 articles to these major categories, then just being able to click "Edit this page", add "{{CATEGORY}}}" and save is a lot simpler.
I think my suggestion to add a "put this page in the following categories" box (in addition to the normal "edit page text" box) can achieve all that:
* Page authors not interested in elaborate categorisation have a quick way to stuff a topic into the right categories.
* These categories end up with an unsorted (or alphabetically sorted) list of topics.
* "Categorisers" can use this unsorted lists and gradually move topics from there into a proper order.
* Topics which are afterwards put in a category the same way again end up in an unsorted section, ready to be moved into the existing order.
I know it might sound like a bit of an overkill, but we could have both -- we could have organized and unorganized category pages, the unorganized ones automatically generated, the organized ones made by hand. Since we'd only have to maintain one (the organized one), its really no more work than we have at the moment.
My scheme keeps both parts (manual and automatic) of a category on one page so that they can be kept in sync more easily. Otherwise "categorisers" always have to scan the automatic page for changes.
Well, my suggestion was that they would be subcategories, or independent categories in their own life... so an algorithm could go in the category [[Computer Science/Algorithms]], or alternatively in both the [[Computer Science]] category and the [[Algorithms]] category. Using a modification of Magnus' proposal you could display the contents of multiple categories on the one page.
This would work, although it would blur the one-article-one-page concept. What would you be editing if you select "edit" on such an [[Computer Science]] page automatically built from a number of subpages?
wikipedia-l@lists.wikimedia.org