Overwriting the commons category system needs large consensus. And i don't think that commons community agree with such a change. So i ask again the wikidata people, please start a RRF on commons or respect our categorization schema. Commons has a own community with active users. It is not okay that a other project is deciding commons stuff whiteout asking commons. I suggest to move this discussion to COM:VP. Date: Sun, 30 Aug 2015 22:51:07 +0800 From: gnangarra(a)gmail.com To: commons-l(a)lists.wikimedia.org CC: wikidata(a)lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours.... What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary On 30 August 2015 at 18:42, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: Luca Martinelli, 30/08/2015 12:03: Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution, It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)». Nemo _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l -- GN. Vice President Wikimedia Australia WMAU: http://www.wikimedia.org.au/wiki/User:Gnangarra Photo Gallery: http://gnangarra.redbubble.com _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

Can you elaborate please? What is replacing commons category system? ... From: gerard.meijssen(a)gmail.com Date: Sun, 30 Aug 2015 20:30:36 +0200 To: commons-l(a)lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons Hoi. The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none. Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice. Thanks, GerardM On 30 August 2015 at 16:51, Gnangarra <gnangarra(a)gmail.com> wrote: the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours.... What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary On 30 August 2015 at 18:42, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: Luca Martinelli, 30/08/2015 12:03: Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution, It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)». Nemo _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l -- GN. Vice President Wikimedia Australia WMAU: http://www.wikimedia.org.au/wiki/User:Gnangarra Photo Gallery: http://gnangarra.redbubble.com _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

Categories are not error prone, it are humans. And this means that as result this applies also to queries. Both depend on the quality of the edits users make, and both are as problematic. I am 100% sure that wikibase technology can be helpful and improve the search for and use of images, but is not a replacement for stable categories and their pages. That it will be available in many languages is nice, but still a stable page system to categorise images is needed. I consider it much more likely that categories are converted in such way that the images in a category are added to an ID, instead of a language depended category name, and yes, that sounds much like a wikibase system, but is not exactly the same. One of the most important usage of categories on Commons is navigation. Looking to the way how Wikidata is, navigation through groups of pages is hopeless. On Commons this type of navigation is essential and Commons can't be without. But still, this subject is irrelevant for this discussion, as the problem situation still remains: from Commons to Wikidata there are two groups of pages to link to: articles and categories. Romaine 2015-08-30 20:52 GMT+02:00 Gerard Meijssen <gerard.meijssen(a)gmail.com>om>:

English. </grin> I do not care for them at all. When functionality opens data for people who do not speak English, then by all means take care of the categories but do understand that it will be no longer for "all of us". grin?? Then just build a i18n system for cats (likely with i18n from wd). Commons has a lot of potential which is not used. Well... Commons does not have own money and own dev's like wikidata. This is explaining a lot. From: gerard.meijssen(a)gmail.com Date: Sun, 13 Sep 2015 21:55:08 +0200 To: commons-l(a)lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons Hoi,<grin> Commons categories are hopeless when you do not speak English. </grin> I do not care for them at all. When functionality opens data for people who do not speak English, then by all means take care of the categories but do understand that it will be no longer for "all of us". When you navigate Wikidata data in "Reasonator", it is really usable and useful in any language. I totally agree about navigating within Wikidata; I do not navigate data in Wikidata. I use Wikidata for editing only.Thanks, GerardM On 13 September 2015 at 21:39, Romaine Wiki &lt;romaine.wiki(a)gmail.com&gt; wrote: Categories are not error prone, it are humans. And this means that as result this applies also to queries. Both depend on the quality of the edits users make, and both are as problematic. I am 100% sure that wikibase technology can be helpful and improve the search for and use of images, but is not a replacement for stable categories and their pages. That it will be available in many languages is nice, but still a stable page system to categorise images is needed. I consider it much more likely that categories are converted in such way that the images in a category are added to an ID, instead of a language depended category name, and yes, that sounds much like a wikibase system, but is not exactly the same. One of the most important usage of categories on Commons is navigation. Looking to the way how Wikidata is, navigation through groups of pages is hopeless. On Commons this type of navigation is essential and Commons can't be without. But still, this subject is irrelevant for this discussion, as the problem situation still remains: from Commons to Wikidata there are two groups of pages to link to: articles and categories. Romaine 2015-08-30 20:52 GMT+02:00 Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt;om>: Hoi,A category includes images that have shared characteristics. The problem with categories is that they are error prone, mistakes are made or they are just not added or understood. A category like "Frisian stallions" has obviously stallions of the Frisian breed in them. When an image is known to have a "Friese stamboekhengst" in Dutch, you do not need to add a text for "Frisian stallion". Because one is the translation of the other. You can search for all the paintings by 文森·梵谷 and tind the same paintings I would when I seek them for Vincent van Gogh. There is nothing wrong with having categories at this time. It is just that once we add statements, the same information will be available in every other language. We cannot do it now. The whole current issue with Wikidata is not that relevant as it will change when development time is put into place and have Wikidata type annotations and queries in a way that is not only but also English.Thanks, GerardM On 30 August 2015 at 20:37, Steinsplitter Wiki &lt;steinsplitter-wiki(a)live.com&gt; wrote: Can you elaborate please? What is replacing commons category system? ... From: gerard.meijssen(a)gmail.com Date: Sun, 30 Aug 2015 20:30:36 +0200 To: commons-l(a)lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons Hoi. The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none. Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice. Thanks, GerardM On 30 August 2015 at 16:51, Gnangarra &lt;gnangarra(a)gmail.com&gt; wrote: the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours.... What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary On 30 August 2015 at 18:42, Federico Leva (Nemo) &lt;nemowiki(a)gmail.com&gt; wrote: Luca Martinelli, 30/08/2015 12:03: Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution, It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)». Nemo _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l -- GN. Vice President Wikimedia Australia WMAU: http://www.wikimedia.org.au/wiki/User:Gnangarra Photo Gallery: http://gnangarra.redbubble.com _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

On Mon, Sep 14, 2015 at 5:31 PM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: Indeed! We are working on the groundwork. Still quite some time away from anything user-visible. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.