On 8 May 2013 18:26, Sumana Harihareswara <sumanah(a)wikimedia.org> wrote: To put a nice clear stake in the ground, a magic-world-of-loveliness sparkly proposal for 2015* might be:

* Categories are implemented in Wikidata * -> They're in whatever language the user wants (so fr:Chat and en:Cat

nl:kat and zh-han-t:貓 …)

* -> They're properly queryable

* -> They're shared between wikis (pooled expertise)

* Pages are implicitly in the parent categories of their explicit

* -> Pages in <Politicians from the Netherlands> are in <People from the Netherlands by profession> (its first parent) and <People from the Netherlands> (its first parent's parent) and <Politicians> (its second parent) and <People> (its second parent's parent) and … * -> Yes, this poses issues given the sometimes cyclic nature of categories' hierarchies, but this is relatively trivial to code around

* Readers can search, querying across categories regardless of whether they're implicit or explicit * -> A search for the intersection of <People from the Netherlands> with <Politicians> will effectively return results for <Politicians from the Netherlands> (and the user doesn't need to know or care that this is an extant or non-extant category)

* -> Searches might be more than just intersections, e.g. "<Painters from the United Kingdom> AND <Living people> NOT <Members of the Royal

or whatever. * -> Such queries might be cached (and, indeed, the intersections that people search for might be used to suggest new categorisation schemata

wikis had previously not considered - e.g. <British politicians> & <People with pet cats> & <People who died in hot-ballooning accidents)

* Editors can tag articles with leaf or branch categories, potentially over-lapping and the system will rationalise the categories on save to the minimally-spanning subset (or whatever is most useful for users, the database, and/or both)

* -> Editors don't need to know the hierarchy of categories *a priori*

adding pages to them (yay, less difficulty) * -> Power editors don't need to type in loads of different categories if they have a very specific one in mind (yay, still flexible) * -> Categories shown to readers aren't necessarily the categories saved

the database, at editorial judgement (otherwise, would a page not be in just a single category, namely the intersection of all its tagged categories?) ​Apart from the time and resources needed to make this happen and operational, does this sound like something we'd want to do? It feels like this, or something like it, would serve our editors and readers the best from their perspective, if not our sysadmins. :-) [Snip] ​ > I think the best place to pursue this topic is probably in > https://meta.wikimedia.org/wiki/Talk:Beyond_categories . It's unlikely > Wikimedia Foundation will be able to make engineers available to work on > this anytime soon, but I would not be surprised if the Wikidata > developer community or volunteers found this interesting enough to work

​I guess I should post this there too, maybe once someone's told me if

mad-cap. ;-)​

From what I hear wikidata phase 3 is going to basically be support for

From what I hear wikidata phase 3 is going to basically be support for inline queries. Details are vauge but if they support the typical types of queries you associate with semantic networks - there is category intersection right there.

If any of the wikidata folk could comment on what sort of queries are planned for phase 3, performance/scaling considerations, technologies being considered (triple store?) Id be very interested in hearing. (I recognize that future plans may not exist yet)

more generally it would be interesting to know the performance characteristics of SPARQL type query systems, since people seem to be talking about them. Are they a non starter or could they be feasible?

Semantic and efficient are not words I associate with each other, but that is due to rumour not actual data. (Although my brief googling doesnt exactly look promising)

-bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Wed, May 8, 2013 at 10:47 PM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: categories Category cycles are the least of it. The fact that the existing category hierarchy isn't based on any sensible-for-inference ontology is a bigger problem. Let's consider what would happen to one of my favorite examples on enwiki: * The article for Romania is in <Black Sea countries>. Ok. * And that category is in <Black Sea>, so Romania is in that too. Which is a little strange, but not too bad. * And <Black Sea> is in <Seas of Russia> and <Landforms of Ukraine>. Huh? Romania doesn't belong in either of those, despite that being equivalent to your example where pages in <Politicians from the Netherlands> also end up in <People> via <Politicians>. And it gets worse the further up you go. You would have Romania in <Liquids> a few more levels up. For this to work, each wiki would have to redo its category hierarchy as a real ontology based on is-a relationships, rather than the current is-somehow-related-to. Or we would have to introduce some magic word or something to tell MediaWiki that <Politicians> is-a <People> is a valid inference while <Black Sea countries> is-a <Black Sea> isn't. In other words, code-wise adding "tags" to an article is the same as categories with inference and querying. But trying to use the existing category setup as it exists on something like enwiki as "tags" for inference (or querying, to a lesser extent) seems like GIGO.

A person who is originally from the Netherlands but moved to Germany and became a politician there would be in <People from the Netherlands> and <Politicians>, but maybe should not be in <Politicians from the Netherlands> depending on how exactly you define that category.

Without deliberately making it an even longer term plan, as I think it is

great idea, another long goal solution to the same problem would be (as Flow gets Wikipedians into the idea of tagging) that categories get

replaced by tags. That way they lose much of their absoluteness and therefore some of their controversy. Categories are hard for Wikipedia because compromise is not possible. Consensus can be reached on a subtly different compromise version of the wording of a sentence or paragraph, but there is no compromise on categories. A category either exists or does not. A page either goes in

does not. With tags, a biography could relatively uncontroversially be tagged as "Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy

even if nearly everybody agrees that half the tags while true are entirely unimportant and not relevant to the subject's area of notability. Whether some tags like race and appearance should exist at all may still generate debate, but if they are only ever available modifiers and not hard categories their offense would be softened. For some subjects, entirely uncontroversial tags could be extracted from Wikidata. It would be content shakeup and therefore perhaps politically difficult, but it would take a lot of the technical challenge out of joins, even permitting joins (automatically or manually) with tags translated into equivalent versions in other languages. All possible combinations of tag derived categories would then "exist",

it would just be a matter of debate as to whether there is a justification to add a link from a page to "Biography+Novelist+Enjoys Spicy Food" or if that is a meaningless category. If reverted, the one person interested in that exact category could still always visit it, it's just that other

would not be directed to it unless they probe talk page debates. Luke Welling

On 9 May 2013 12:07, Brian Wolff &lt;bawolff(a)gmail.com&gt; wrote: > Nobody has ever been able to explain to me the technical difference

> tag and category. (Other than being able to query intersections, which

The theory is that tags are non-hierarchical, casually-applied and well-supported in software (from intersections to more). You can see how people feel what we have is somewhat different from this world vision. :-) J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

With tags, a biography could relatively uncontroversially be tagged as "Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy Food" even if nearly everybody agrees that half the tags while true are entirely unimportant and not relevant to the subject's area of notability. Whether some tags like race and appearance should exist at all may still generate debate, but if they are only ever available modifiers and not hard categories their offense would be softened.

On 9 May 2013 12:40, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: Well, to me that's a​n even more compelling reason create such a system (Categories as-is don't have them): "WikiTags let you cite the source of why the subject is tagged that way".

On 8 May 2013 18:26, Sumana Harihareswara &lt;sumanah(a)wikimedia.org&gt; wrote: To put a nice clear stake in the ground, a magic-world-of-loveliness sparkly proposal for 2015* might be: * Categories are implemented in Wikidata * -> They're in whatever language the user wants (so fr:Chat and en:Cat and nl:kat and zh-han-t:貓 …) * -> They're properly queryable * -> They're shared between wikis (pooled expertise) * Pages are implicitly in the parent categories of their explicit categories * -> Pages in <Politicians from the Netherlands> are in <People from the Netherlands by profession> (its first parent) and <People from the Netherlands> (its first parent's parent) and <Politicians> (its second parent) and <People> (its second parent's parent) and … * -> Yes, this poses issues given the sometimes cyclic nature of categories' hierarchies, but this is relatively trivial to code around * Readers can search, querying across categories regardless of whether they're implicit or explicit * -> A search for the intersection of <People from the Netherlands> with <Politicians> will effectively return results for <Politicians from the Netherlands> (and the user doesn't need to know or care that this is an extant or non-extant category) * -> Searches might be more than just intersections, e.g. "<Painters from the United Kingdom> AND <Living people> NOT <Members of the Royal Academy>" or whatever. * -> Such queries might be cached (and, indeed, the intersections that people search for might be used to suggest new categorisation schemata that wikis had previously not considered - e.g. <British politicians> & <People with pet cats> & <People who died in hot-ballooning accidents) * Editors can tag articles with leaf or branch categories, potentially over-lapping and the system will rationalise the categories on save to the minimally-spanning subset (or whatever is most useful for users, the database, and/or both) * -> Editors don't need to know the hierarchy of categories *a priori* when adding pages to them (yay, less difficulty) * -> Power editors don't need to type in loads of different categories if they have a very specific one in mind (yay, still flexible) * -> Categories shown to readers aren't necessarily the categories saved in the database, at editorial judgement (otherwise, would a page not be in just a single category, namely the intersection of all its tagged categories?) ​Apart from the time and resources needed to make this happen and operational, does this sound like something we'd want to do? It feels like this, or something like it, would serve our editors and readers the best from their perspective, if not our sysadmins. :-) [Snip] ​ on. ​I guess I should post this there too, maybe once someone's told me if it's mad-cap. ;-)​ J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l