Hi all,
I'm involved in a debate about the pseudoscience and pseudoscientists categories, that seems to be at an impasse because of the differences between categories and lists.
One side argues that these two categories are inherently problematic, and that a list would be more appropriate because it allows for annotation of entires and referencing of sources.
The other side insists that a list is not acceptible and that a category is required, for reasons that don't seem particularly clear to me but which they feel strongly about.
Clearly this problem isn't restricted to just those two categories. There are several guidelines that deal with controversial categories, and this debate seems to come up whenever there is a vaguely defined or otherwise "sensitive" category. A more general solution seems to be in order.
Rather than continue the debate (which from the archives on the talk page for the pseudoscience category I can see has been continuing on and off for years) I thought it might be best to simply change how categories work, so that they can support the features of lists that are desired. (Yes, I'm using "simply" in an ironic manner :)
I've tried looking through the mailing list archives and on meta to see if this has been discussed before, but could not find anything relevant. Since there are many other problems with the category implementation (big DB hit for category page loads, inability to cache the results, etc.) I thought I should put together a comprehensive list of features, bugs, suggestions, and so forth before I begin development work.
I'd also like suggestions as to the best place to discuss this topic on either WP or meta.
-Bill Clark
Bill,
I'm not aware of any such discussions but I can tell you that these two categories, and categories like it, are not a local problem. On German Wikipedia, we have these very same discussions over and over again without much of a resolution. If you find anything, let us know because we're looking for solutions too.
Good luck!
sebmol
On 8/10/06, Bill Clark wclarkxoom@gmail.com wrote:
Hi all,
I'm involved in a debate about the pseudoscience and pseudoscientists categories, that seems to be at an impasse because of the differences between categories and lists.
One side argues that these two categories are inherently problematic, and that a list would be more appropriate because it allows for annotation of entires and referencing of sources.
The other side insists that a list is not acceptible and that a category is required, for reasons that don't seem particularly clear to me but which they feel strongly about.
Clearly this problem isn't restricted to just those two categories. There are several guidelines that deal with controversial categories, and this debate seems to come up whenever there is a vaguely defined or otherwise "sensitive" category. A more general solution seems to be in order.
Rather than continue the debate (which from the archives on the talk page for the pseudoscience category I can see has been continuing on and off for years) I thought it might be best to simply change how categories work, so that they can support the features of lists that are desired. (Yes, I'm using "simply" in an ironic manner :)
I've tried looking through the mailing list archives and on meta to see if this has been discussed before, but could not find anything relevant. Since there are many other problems with the category implementation (big DB hit for category page loads, inability to cache the results, etc.) I thought I should put together a comprehensive list of features, bugs, suggestions, and so forth before I begin development work.
I'd also like suggestions as to the best place to discuss this topic on either WP or meta.
-Bill Clark _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 8/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:
This is basically bug 1775: http://bugs.wikimedia.org/show_bug.cgi?id=1775
Yes, exactly. Thanks for finding that.
However, I think the suggestion about how to expand category tags is necessarily the best way to go. I think it would be easier to be able to edit the improved category page (what I'm calling an index page) directly, rather than complicating the tag structure itself. On the other hand, perhaps the ability to keep the information on the article page rather than on a list-style page is precisely why category proponents prefer categories to lists. That's precisely the type of question that I think needs to be discussed in a more general, non-technical forum.
I'd also like to address the problem of load-time efficiency with any change, since my understanding is that the current category implementation puts quite a strain on the servers.
-Bill
On 8/10/06, Bill Clark wclarkxoom@gmail.com wrote:
However, I think the suggestion about how to expand category tags is necessarily the best way to go.
Sorry.. that should read "not necessarily the best way to go."
-Bill
Several months ago, I proposed some extra-informations for categories. The data I proposed was to help making an RSS feed with the last articles added into a category. The data could be a short description put inside the category tag like [[Category:XXXXX | SortTag | The XXXXX is the qsdj o fjqipsdf psqiodf.]] An other idea was to be able to read this tag in a page for last added articles, to avoid manualy updating lots of lists.
I did not have the time to work on sthg like it, but, even if it's not really related to Bill's question, I still think it would be one of the numerous good functionalities to add to mediawiki :)
Plyd
On 8/10/06, Bill Clark wclarkxoom@gmail.com wrote:
However, I think the suggestion about how to expand category tags is [not] necessarily the best way to go.
On second thought, doing it that way would require the fewest code changes and I could probably get it written this weekend. Then, the additional improvements I had in mind could come later.
In order to truly replace lists, we'd eventually need to be able to add these features:
1) Items that don't yet have articles can still be members. 2) Category page can be cached. 3) Arbitrary restructuring of the page.
..and probably more.
I'll look into adding functionality to category tags so that they can take a possibly arbitrary number of key=value pairs, delimited by pipes.
-Bill Clark
On 8/10/06, Sebastian Moleski sebmol@gmail.com wrote:
I'm not aware of any such discussions but I can tell you that these two categories, and categories like it, are not a local problem. On German Wikipedia, we have these very same discussions over and over again without much of a resolution. If you find anything, let us know because we're looking for solutions too.
Well, my initial thought is to replace categories with something along the lines of "edit-time updated lists", by which I mean that adding a category tag to a page would update not just that page but also an "index" page (for lack of a better term) that is essentially a cached version of the category page. This way, loading the index page wouldn't incur any extra database hits, and the index page would be designed such that annotations and references could be added.
Implementation-wise, the code would need to recognize presence of the category tag and update the corresponding index page appropriately. This would complicate page updates slightly, but not overly so. In order to allow for rearranging and annotating the index page itself, code would need to be added that checked for the presence of a link (on the index page) back to the article.
Alternately, the index page could be an entirely different kind of structure than a regular wiki page, and the presence of links could be checked by some more efficient mechanism. This might needlessly complicate the editing of index pages, however.
This would basically combine the features of a list with the features of a category, and improve the load-time efficiency at the expense of a slight decrease in edit-time efficiency (which I think would probably be a big win overall).
These are just my initial thoughts and I'm certainly open to suggestions or objections.
-Bill Clark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Friday 11 August 2006 00:03, Bill Clark wrote:
On 8/10/06, Sebastian Moleski sebmol@gmail.com wrote:
I'm not aware of any such discussions but I can tell you that these two categories, and categories like it, are not a local problem. On German Wikipedia, we have these very same discussions over and over again without much of a resolution. If you find anything, let us know because we're looking for solutions too.
[snip sensible ideas]
These are just my initial thoughts and I'm certainly open to suggestions or objections.
I am way past bedtime, so please take that with a barrel or two of salt. But perhaps these things could be implemented in an extension, to toy around and try them out?
For instance, my own slides extension (shameless plug :D is basically such an "index page". (er its a bit incomplete in the formatting options, but that could of course be possible, its just for presentations the current way made more sense :-D
(Linky: http://bloodgate.com/wiki/Wiki-Presentations_-_About :-)
You have one central template where to store which pages are part of it, and on each page you include that template. That included template then morphs on each page where it is included into a navbar, which is different for each page (thats what categories dont give you, the backlink to the category is always the same. Also I think that mechanism could replace all these huge templates that are used to generate navigation boxes by unifying them - thats on my todo :).
Whats basically missing is the "Index page". I always wanted to add such afunctionality, aka the included template should not only morph according to on which page it was included, but also accoding to what output you want. (e.g.
{{mypresentation}} (generates navbar) {{mypresentation|output=pagenr}} (1, or 2 etc) {{mypresentation|output=pages}} (7 e.g. number) {{mypresentation|output=toc}} (table of contents bascly. your index page)
So what you want is:
* have one template with an extension tag like <list> (whatever) pagename|pagetitle|pagenametosortunder (or whatever format you want) </list> * in each item in the list, include the template, this means each member of the list gets a nice backlink to the list (what you usually do with [[category:foo]]
Since this works with templates, you already got rid of the cache problem. :)
The index page is only updated when one of the member pages, _or_ the list (inside the template) changes. Likewise, whenever you change the master list, all pages that include the template get their navbar updated.
You also can have pages in the list that aren't existing yet.
The only downside I see is that just including the template into a new page doesnt update the list of pages in the main template. (unlike putting a page into a category) But that could be worked around by having the template instead display a big red "thispage is not yetin the lis,t please edit here" button. Heh, thats agood idea for my extension anyway...
Sorry if this ia bit incoherent, but if you want, I look into how to modify/enhance my extension to implement the functionality you want/need.
After sleep, that is :D
Best wishes,
Tels
- -- Signed on Fri Aug 11 02:04:17 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"Spammed if you do, spammed if you don't." - Murphy's Law
On 8/10/06, Bill Clark wclarkxoom@gmail.com wrote:
One side argues that these two categories are inherently problematic, and that a list would be more appropriate because it allows for annotation of entires and referencing of sources.
The other side insists that a list is not acceptible and that a category is required, for reasons that don't seem particularly clear to me but which they feel strongly about.
There's a similar end result problem with a totally different cause at Commons. It's easy to tag images with a category. It's easier to link to a list. End result: half of the images for some topic are in a category with that name, half are on a list.
The easiest solution to me would be to use the text space of a category as the list. You would end up with every entry listed twice: once by some arbitrary sort order (eg, year), and once alphabetically. In the list part at the top, you can put your annotations. The category listing at the bottom basically serves to check that the list part is up to date and that there aren't any stray additions.
Steve
On 8/10/06, Steve Bennett stevage@gmail.com wrote:
The easiest solution to me would be to use the text space of a category as the list. You would end up with every entry listed twice: once by some arbitrary sort order (eg, year), and once alphabetically. In the list part at the top, you can put your annotations. The category listing at the bottom basically serves to check that the list part is up to date and that there aren't any stray additions.
That makes sense. In order to prevent duplication, you could even check if a link to an article has already been displayed in the top list-part, and exclude it from the category-part at the bottom.
I'm poking through the category code right now, and I'll see which approach (category text as list vs. extended attributes for category tags) will work best. I suspect the former, since it won't require any database changes, although the extra parsing step to check for duplicates (which I think is necessary to make this solution palatable) might be too much.
-Bill Clark
wikitech-l@lists.wikimedia.org