Hello,
Here is another perspective on this same issue and an actionable remedy for a lot of the problems we are discussing here. http://lists.wikimedia.org/pipermail/gendergap/2014-May/004287.html
That email describes a game in which people use a game on Wikidata to tag biographies with a gender.
MzMcbride identified the major problem in the old system - "The general rule is always place an image in the most specific categories, and not in the levels above those." Because of this, we had infrastructure which precluded the development of finding all kinds of intersections. It did not have to be that way, but that is how we used categories.
Read the above email in the link to see an example of how this new system will prevent problems, make things simpler, and be more fair to people by not defining them so discreetly.
Also, play the Wikidata game.
yours,
On Tue, May 20, 2014 at 8:56 AM, Nikolas Everett neverett@wikimedia.orgwrote:
On Tue, May 20, 2014 at 3:06 AM, Jan Ainali jan.ainali@wikimedia.se wrote:
2014-05-20 8:41 GMT+02:00 Chad Horohoe chorohoe@wikimedia.org:
The search engine (new, as well as old) supports category intersection.
So
actually, searching intersections of categories is very easy.
Our definitiions of "very easy" are not intersecting :)
It is possible yes, but to qualify for very easy I would suggest a GUI
for
modifying a search and a hotcat like functionality for selecting interescting categories. Such addition to Special:Search would be
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe