Nathan wrote: For ease of use (adding and removing), I think most wikis have HotCat (<https://commons.wikimedia.org/wiki/HotCat>). Is that insufficient? Regarding hierarchy, there's absolutely no technical reason, as far as I'm aware, that categories must be hierarchal. It's certainly an intended feature that categories have subcategories and the capability to be hierarchal (i.e., you can have subcategories), but you can concurrently use categories with a flat structure. Right? It's a common term, sure. It's been suggested that this may simply be a user interface labeling problem, though. If we renamed "Categories" at the bottom of the page to "Tags", what else needs doing? MZMcBride

MZMcBride - Categories are hierarchical and people worry about them overlapping. Tags have no hierarchy.

The major problem is that labor is wasted because there is no easy way to search intersections of categories. Instead of having a category for 18th century French painters, it would be ideal to just have tags for "people in the 18th century" "French people" and "painters" and let the users remix those tags instead of being forced to look in only that branch.

A proposal is at <https://meta.wikimedia.org/wiki/Beyond_categories> The problem has two parts - WMF cannot coordinate this kind of search with existing categories, and there is no need to reform categories unless there is a commitment to make this search capacity. I see this as a serious problem.

I think intersection is the most significant cause of the current categorisation system. My understanding of the current reasoning behind categorisation as seen on Commons and elsewhere is that: 1) the lack of category intersection causes the very specific categories, which are essentially saved category intersections. and 2) the category list at the bottom of the page being very literally the category names as listed in the page wikitext is why pages are only included in non-overlapping leaf node categories. On en.wp there are many useful specific categories which are deleted because they would only 'clutter' the category section of the page content footer. E.g. Spanish Paralympic competitors at the 2012 Summer Games. Most other multisport cohorts/intersections can have a category, but 'by country; by games' cohort is currently not permitted. Fair enough. I've seen stubs on en.wp where the category section of the page is larger than the page prose. IMO the 'future' of categories in wikimedia projects would be to replace the very specific 'intersection categories' with saved queries in wikidata, with the category list at the bottom of the page dynamically including the list of saved wikidata search query results that the page is a member of, if the local project has more than <d> pages that are members of the query. -- John _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

The search engine (new, as well as old) supports category intersection. So actually, searching intersections of categories is very easy.

On Tue, May 20, 2014 at 3:06 AM, Jan Ainali &lt;jan.ainali(a)wikimedia.se&gt; wrote: for awesome. I think of most the syntax that Special:Search supports as for experts/power users. Pretty much everything beyond quoting phrases is non-intuitive. I'd describe it as useful but not discoverable. I remember seeing on a draft backlog a mention of writing some kind of more discoverable interface for complex category queries. I don't remember which backlog (so no link, sorry) but I recall it being scheduled reasonably high on the list. I don't know what that means for when work starts, much less when a first copy is released. I don't even know how well it'd work with categories being "leaves" rather than tags or declarations of facts like I imagine you'd get with an ontology based solution. And I don't know how you'd get from the categories we have now to something more like tags or facts. I don't know lots of things.... It might be worth it to jump over category queries and implement it directly against wikidata. I'll be sure to talk about this with the wikidata team when I see them later this week One advantage that categories do have is that they are built in so whatever more intuitive intersection mechanism we make would be useful to all mediawiki installs willing to install the search backend. If it is hitched directly to wikidata the installation burden goes up considerably. Not to mention it'd be easier for me to test locally with categories then with wikidata. On the other hand having some mechanism where facts in wikidata are reflected into the local wiki sounds a bit jangly and breakable. On the other other hand reflecting the facts into the local wiki would translate them into that wiki's language which would delay the need for some kind of translation integration (probably with wikidata as well). On the other other other hand that doesn't help commons be multilingual. Or do anything about toothbrush. I'm going to stop rambling now and go work on something else and let my subconscious filter through this. Nik _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

On 20 May 2014 02:16, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: We've been talking about this for years ... picking the precise subsubsubcategory is a pain in the backside. Most or all would also fall out as Boolean queries on tags. I've been here since 2004 and I still go to Commons and have trouble finding the subsubsubcategory I'm actually looking for in the search. Expecting users to know our category tree is user-obnoxious. Tags are common. As Gerard notes, they would also solve the problem that everything is categorised in English. I vaguely recall a proof-of-concept was coded and working in Postgres several years ago, but the same thing had unusable performance in MySQL so the idea was shelved. - d. _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>