Wikidata

Wikidata:Requests for comment/Creating new Wikidata items for all Commons categories

< Wikidata:Requests for comment
An editor has requested the community to provide input on "Creating new Wikidata items for all Commons categories" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!

All Wikimedia Commons categories should have a Wikidata item

Wikimedia Commons is one of the main users of information from Wikidata. Media files use Structured Data on Commons, and categories use the Wikidata Infobox to provide multilingual context for the categorised media files. There are now over 3.6 million categories using Wikidata information via the infobox, which is about half of the circa 7 million Commons categories. This is due to a huge effort over the last few years to add Commons sitelinks, which has included bot work via Pi bot, a Wikidata game, and work by many other editors. The deployment of the infobox has been a huge success on Commons and for the use of Wikidata information within the Wikimedia projects.

The ideal situation would be that all Commons categories are linked with Wikidata and use the multilingual Wikidata Infobox - and this RfC proposes creating new items so that all Commons categories have Wikidata items. This is equivalent to the way that Wikipedias already get Wikidata items by default - but it would expand the scope to include all Commons categories. The remaining unlinked categories are a mix of 'topic' and 'category' items - so the simplest approach is that new items are created without instance of (P31) values, so that editors can later decide whether they are instance of (P31)=Wikimedia category (Q4167836) or are individual places. This will include a huge number of notable items that aren't otherwise covered by existing Wikipedia articles. The creation of the new items would be implemented by Pi bot (and there will naturally be an additional check of community consensus with the bot request approval process).

The new Wikidata items can subsequently be populated with information imported from Commons (such as coordinates and authority control IDs), as well as being open for expansion by the normal processes. It would also provide a new avenue to create new Wikidata editors by contributors wanting to expand the information displayed by the infoboxes on Commons. It will also reduce the need for new items to be created for Wikipedia articles, where they can be matched to an existing Commons category.

Duplicate items will be minimized by the bot searching for potential matches, which would then be added to the Commons category matching game - and a new item would only be created after all possible matches have been cleared. This will need an update to Wikidata:Notability to recognise that these items are important for Wikidata - but this is long overdue. Thanks. Mike Peel (talk) 23:06, 18 December 2021 (UTC)[reply]

For all categories I am not sure, but at least for all people, places, and objects who have a category on Commons, certainly. Yann (talk) 23:30, 18 December 2021 (UTC)[reply]
I'm coming across a lot of Commons categories in Sweden, Norway and Germany (countries near me) which really just need to be linked up to existing wikidata items, so I'm not convinced that at this point it's a really good idea. Hjart (talk) 23:52, 18 December 2021 (UTC)[reply]
@Hjart: Yes, there are a lot that can still be matched up - see the game I linked to above for example. The plan would be to only create new items if Wikidata search doesn't find any potential existing matches. Thanks. Mike Peel (talk) 13:07, 19 December 2021 (UTC)[reply]
I (a Commons volunteer) agree that there should be at least Wikidata items for all locations (not just places, but for all locations with geo coordinates, for instance: countries, provinces, regions, streets, nature reserves and bodies of water) and objects, no matter whether there is a Commons category or not. But not for all people, only for those with notability, see Wikidata talk:Notability#Item 4 is confusing. And please, let there be only one Wikidata item about a subject, not one for the subject with all the links and an image, and another one specially for the category about the same subject with no possibility for a photo (odd/weird rule) nor for links to Wikipedias (because they are already in the subject item). Too often I quarrel with such constructions. I think the latter ones are redundant. JopkeB (talk) 06:43, 24 September 2022 (UTC)[reply]
I think that at this point a diluted / watered down version of this proposal could be made where we could request for every Commonswiki category to have a Wikidata item but specifically excluding persons and organisations that don't already have an existing item on another Wikimedia project unless their notability can be established. This way we can keep the biggest incentive for "spamming" (self-promotion / promotions of charities and causes people like) off of Wikidata while still connecting most Commonswiki pages to Wikidata. This could greatly help with the Structured Data on Wikimedia Commons (SDC) project. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 09:00, 24 September 2022 (UTC)[reply]
@User:Donald Trung For people and organizations: OK. But there are more exceptions, see below the discussion about categories of "view of building X from street y" or "black and white photographs of men with a mustache", and (my addition) about internal affairs like the subcategories of c:Category:Commons maintenance content and perhaps more. JopkeB (talk) 05:11, 25 September 2022 (UTC)[reply]
I hope we are not forced to connect Commons categories to Wikipedia categories because of that, which has been a nasty side effect of connecting things through Wikidata, due to misunderstanding the Gallery namespace in Commons and taking it for some kind of equivalent to articles, which it is not in the least. What makes sense in Commons, with few exceptions, is to connect Categories with Wikipedia articles, not with the generally useless (for us) Wikipedia categories.
But a huge lot of Commons categories probably should never have any Wikidata item (ex: "Eiffel Tower taken from the west corner of the Trocadero terrace" (don't know if this one exists, but that's the kind of stuff we usually create there to classify views), so I'm not especially confident that should be done. Darwin Ahoy! 23:58, 18 December 2021 (UTC)[reply]
 Support: "a huge lot of Commons categories probably should never have any Wikidata item" and the example is very well chosen.
But I doubt whether links should refer to Commons categories or to Commons gallery pages. For me personally, as a Commons volunteer, links to categories would be easier. But I don't know about end users, people who are searching for images for Wikipedia pages and the like, or for their own presentations and papers. They might be better off with gallery pages, but only when the gallery is good, with a lot of well selected images of (at least) the most important subcategories (and their links) and with the Wikidata item. In my opinion end users are the people we collect all the stuff for and their interests should be given precedence. JopkeB (talk) 08:06, 24 September 2022 (UTC)[reply]
On Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links a solution for this dilemma has been presented. --JopkeB (talk) 10:35, 25 September 2022 (UTC)[reply]
There is still a lot of issues in structured data that need addressing I'm still finding a lot of data points that dont describe the files, I'm not sure all are just nuances of the Australian English I speak nor the differences in spelling. With that there are a lot of subcategories which are there for convenience of scale. I think its an ideal goal but not yet something thats worthy of the effort at any significant scale. Gnangarra (talk) 06:31, 19 December 2021 (UTC)[reply]
  • Support any idea to sync Commons with Wikidata I would like to see some conversation about the best way to accomplish this proposal, but if no one has better ideas or objections, then I support going forward as proposed.
I want to know when it will be timely and useful to deconstruct the Commons categories. In the 2013 New York Times article Wikipedia’s Sexism Toward Female Novelists (Q110191200) a writer criticized that Wikipedia had a category for "American Women Novelists", noting that there was no comparable category for male novelists. This sort of observation recurs regularly, and one possible way to deliver the same information to users while also preventing the misuse or misunderstanding in that article would be to separate the categories for place, demographic, and occupation. That is, directly labeling "American Women Novelists" can be unethical and problematic, but providing a list of "Americans" who are "Women" and whose occupation is "Novelist" does not have those ethical problems, and would not have triggered the complaint in that article. If we imported categories as described here, then get the benefit of fast and easy access to existing data. A risk or drawback is that possibly we strengthen the old system which needs to be updated anyway. The same category intersection problem as exists on Wikipedia exists in Commons, and if we are going to move this system into Wikidata, then I wish that could happen after an inventory of its shortcomings and some discussion about when and how we could address them. Blue Rasberry (talk) 00:02, 19 December 2021 (UTC)[reply]
I fully agree, @Bluerasberry! We need some way to link to the intersection of multiple categories. Instead of https://commons.wikimedia.org/wiki/Category:American_women_novelists, something like https://commons.wikimedia.org/wiki/Special:Categories/Americans/women/novelists (Not saying that Special: namespace is necessarily the best way to implement that, but you get the idea.) ⁓ Pelagic ( messages ) 04:22, 28 January 2022 (UTC)[reply]
Dang, Special:Categories already exists. ⁓ Pelagic ( messages ) 04:24, 28 January 2022 (UTC)[reply]
  • I don't support nor oppose this since I haven't thought about this enough. I just want to mention that there are categories with very long name in Commons. You can list the 1000 categories with the longest name with this query at Quarry. I will list some of those categories here
Rdrg109 (talk) 01:58, 19 December 2021 (UTC)[reply]
@Rdrg109: For the first item, please comment on the open discussion at Commons:Categories for discussion/2020/02/Category:Demographic maps of Australia - I agree that this whole category tree is bad and should probably be deleted (I first saw this tree through previous discussions about this topic). For the 2nd and 3rd items, I can't tell from the categories if they are actually relevant or not - could you elaborate on your comment here? But I think you're making a great point for me: these are all internal Wikimedia links, and we'll only discover these issues if we work collaboratively on them. And if you really want, I could put a character limit on a script that creates new Wikidata items for unconnected categories, but I'm not convinced from these examples that this would help. Thanks. Mike Peel (talk) 19:44, 20 December 2021 (UTC)[reply]

 Oppose, for several reasons:

  • All metadata at Commons, including categorization, is still mainly unsourced and there is a ton of it. It does not seem reasonable to import this mess to Wikidata.
  • There is way too much non-notable and promotional stuff at Commons, and the community does not even remotely seem to be able to handle the situation appropriately. Even without category items, some users are exploiting the chaos at Commons to gain Wikidata notability. It does not seem wise to make this even easier.
  • The Commons community does not seem to be particularly friendly.
  • Categories are old tech, better get rid of them at Commons as well. No need to make a detour via Wikidata.
  • There is still the phenomenon that Commons uses intersection categories a lot, often with more than two facets per category. This is completely at odds with the approach at Wikidata.

So, please just don’t do this. —MisterSynergy (talk) 00:17, 19 December 2021 (UTC)[reply]

    • @MisterSynergy: please dont get personal with comments like The Commons community does not seem to be particularly friendly whether you have aggrievances with individuals or have been blocked this is no reason to exclude connecting the data. Wikidata already has a extensive connections to information on Commons likewise Commons already draws extensively from Wikidata this proposal is just about closing the gap between what Commons holds and what Wikidata presents. Gnangarra (talk) 06:14, 19 December 2021 (UTC)[reply]
      • @MisterSynergy: I don't know your history here, but regardless:
      • Sure, there is a ton of unsourced information. It's the same as we already have with Wikipedias. It needs to improve, but it won't happen unless something changes - like synchronising with Wikidata.
      • I've not seen this chaos, but if it exists, surely integrating with Wikidata will help with this - you grow the community that can deal with this by involving new people, which Wikidata helps bring in. See my other comments here about how you tackle those looking for Wikidata notability (i.e., tackle it on Commons first).
      • The Commons community has been as friendly to me as Wikidata has - and much more than, say, the English Wikipedia. Is this where you're going personal?
      • Categories may well be old tech, but the path to new tech is by improving on the old tech. Synchronising categories with Wikidata really helps with this - it provides a starting point to identify the locations and subjects of the photographs in the category. We can deprecate categories at some point in the future - but only when we've migrated their information to Wikidata, which this proposal works towards.
      • Intersection categories are really complicated - but they are still a step towards providing structured data, and they aren't easily replaceable just yet as Commons is handling these issues. Let's use them as a stepping board - sure, we may need to delete the items about them in the future, but we gain a lot of information from them through that transition process.
      • Please bear in mind that we need to have migration approaches to get to the point where Wikidata is fully integrated with the rest of the Wikimedia projects. This proposal is an important step in that process for Commons.
      • "please just don’t do this" - I have to do this to try to bring my two favourite projects closer together. Please, help to do this, don't oppose it. Thanks. Mike Peel (talk) 20:19, 20 December 2021 (UTC)[reply]
Okay, “please just don’t do this *now*” would be more appropriate. I would appreciate more integration, but I think the current condition of Wikimedia Commons makes this endeavor a burden for Wikidata for reasons mentioned in my earlier comment, while the potential improvements for Commons seem much less clear to me. Mind that we do already have quite a bunch of problems here as well, and we have a community way too small for all the content. Besides this, here are two things I want to clarify:
  • The unfriendly nature of the Commons community is a perception that grew over time, and it is not related to individual incidences. I’ve simply seen too many cases where users (including myself) unsuccessfully went to Commons to report a problem with the content over there that had surfaced here. We meanwhile have quite often the situation that problems simply remain untouched (both here and at Commons) since nobody wants to involve themselves in cleaning up on Commons side, which is the reason why I consider this a blocker for deeper integration. Enwiki is maybe not the best benchmark for comparison, btw.
  • To welcome more integration, I think Commons would have to change a lot; in particular, it would need to be more restrictive in terms of application of the project scope (it accepts way too much content), and it would restrict itself to the bare minimum that is required to make hosted files accessible. Right now, it tries to be a full grown content project beyond hosting the files themselves by collecting all sorts of auxiliary information that should not really live in Wikimedia Commons. SDC and Wikidata integration are indeed key factors here, but as long as the old workflows including categorization prevail with no exit scenarios, I do not see that Commons is ready to migrate. Categories might have been the best tech for content organization when Commons was set up, but the limitations of it are so obvious that they should be phased out in most situations as quickly as possible. I don’t think it is worth to add more category items to Wikidata, or to add more Wikidata infoboxes to categories at Commons (particularly since many of them would be empty at the beginning).
—MisterSynergy (talk) 21:13, 20 December 2021 (UTC)[reply]
@MisterSynergy: Thanks for replying, I appreciate it, and I'm doing my best to listen to what you're saying.
  • "please just don’t do this *now*" asks for *when* should this happen? I think it's really important that we sync the various Wikimedia projects, but I'm not convinced that this will happen any time soon because of the reactions we've been seeing here (not just yours).
  • I've been finding the editors on Commons to be generally very friendly - but not as much as those on Wikidata. And they are much nicer than those on enwp. I don't know how we get better at this across the Wikimedia projects - but raising barriers between integrating projects doesn't help.
  • I think we need to change in sync - you can't expect Commons to change to match Wikidata, without Wikidata accepting contributions from Commons. Categories work well - and they need to be replaced by something that works better, which needs to be demonstrated - please could you do that? Thanks. Mike Peel (talk) 21:34, 20 December 2021 (UTC)[reply]
  • I think it is mainly Commons which needs to be fixed, so the onus is on them to show most commitment. The proposal here seems more like an attempt to offload some work on to the Wikidata community, but it is not clear how this should help Commons in the long run. One might even argue that more Wikidata infoboxes on category pages make these even more indispensable.
  • Categories do *not* work well as a technology to organize content (this applies to Wikipedias as well). They were the only option available for a long time so the communities familiarized themselves with them; however, with the experiences that we have with structured data meanwhile, it is obvious that categories are inferior and should better go quickly. Unfortunately, plenty of editors have invested heavily into them and are now difficult to migrate to something else.
  • I can see outlasting need for categories in terms of a maintenance tool—but not to organize content. As a reference, I would point to the situation here at Wikidata where we fortunately never used them for content. This also implies that category pages would no longer be places where content users browse files and navigate through the project. Instead, querying is the way to go, including or course a robust interface that makes it unnecessary to write actual query code.
—MisterSynergy (talk) 22:12, 20 December 2021 (UTC)[reply]
@MisterSynergy: Commons is now one of the major users of Wikidata information after extensive work involving millions of edits over the last few years. This RfC is aimed at encouraging Wikidata to provide more support - and to get back the same support in terms of content contribution. It's been a huge amount of work to make such progress already - you can't realistically say that "the onus is on them to show most commitment" without also giving a commitment from Wikidata to support Commons growth. If you can see an improvement over categories that can be implemented now, then please do so. Mike Peel (talk) 22:50, 20 December 2021 (UTC)[reply]


  •  Oppose I do not see a benefit in connecting all Commons categories with Wikidata. Commons has many very specific categories like Photos taken on XXXX-YY-ZZ in ABC. These are categories that will likely never exist in any other project, so we will never need an item to connect the sitelinks. --Ameisenigel (talk) 07:37, 19 December 2021 (UTC)[reply]
  •  Oppose except if you don't create WD items, just link to existing items. --SCIdude (talk) 08:24, 19 December 2021 (UTC)[reply]
  •  Comment. I would support this if Wikimedia categories were not dealt with through Qxxx items but through new Wxxx items dedicated to all statements that relate to Wikimedia projects and are just meta stuff we need for technical reasons. Regular Qxxx items would have statements connecting them to Wxxx items in a dedicated section at the bottom of the page. Until then, I am a bit skeptical. Thierry Caro (talk) 08:29, 19 December 2021 (UTC)[reply]
  •  Comment items without any statements are already not terribly useful, but the proposal seems to be to create items without any fixed label either .. we already have many items for Commons categories that shouldn't have been created. Maybe cleaning out those and finding a solution for gallery namespace would be a more interesting course of action. --- Jura 10:49, 19 December 2021 (UTC)[reply]
@Jura1: They would have the label from the Commons category name, and I'd also import coordinates and other things wherever possible - the same as I'm already doing for e.g., enwiki. Gallery namespace problem is already solved - where the gallery exists, link to that from the topic item, and have a category item linking to the Commons category. Thanks. Mike Peel (talk) 13:10, 19 December 2021 (UTC)[reply]
If it's a category item, the label would include "Category:", if not, it wouldn't. Here without a P31, there it's not clear. I'm aware of the current approach to Gallery namespace, but I don't think that solves it. Maybe opting for the same approach as for Creator namespace is preferable.
If coordinates can be found on Commons, why not create items just for these? At least, if they don't match coordinates of parent categories. --- Jura 23:18, 19 December 2021 (UTC)[reply]
@MisterSynergy: What do you mean by "non-notable and promotional stuff", what kind of images or subjects should not be on Commons and are there now? JopkeB (talk) 08:52, 24 September 2022 (UTC)[reply]

 Strong oppose per Yann, Darwin, MisterSynergy and Ameisenigel. We already have way to much unsourced (per Wikipedia-mass-imports and other bad imports) and vandalized content here and we're not good (and don't improve much) at providing better quality and fighting vandalism. To import the even bigger mess of Commons (where we're creating an even bigger mess every day without even daring to start preventing new messy imports ...) here is absurd. Commons seems lost - until we're able (or at least willing) to change that, we should not mass-export from there. --Mirer (talk) 11:55, 19 December 2021 (UTC)[reply]

  • Thierry Caro's proposal is interesting. I like the idea of getting meta-wiki-stuff out of the Q space. Gallery pages should be deprecated as sitelinks, in the other hand. Anyway, if "Categories are old tech" and "better get rid of them at Commons as well" (spoiler: not happening anytime soon), then I guess notability standards should be lowered here, to use Structured Data there, instead of categories (?). strakhov (talk) 12:58, 19 December 2021 (UTC)[reply]
i agree with Yann. there should be items for categories of unique and individual people, locations, organisations and objects (like books/films). but there shouldnt be items for cats like c:Category:Videos of 2019 from Lenina Street (Tyumen) c:Category:Files from Foreign, Commonwealth and Development Office Flickr stream (to check), and certainly not the maintenance cats. RZuo (talk) 13:47, 19 December 2021 (UTC)[reply]

First of all, this topic is useful. I think I should share also my opinion. The progressive integration Wikidata-Wikicommons is a good thing, no doubt about it. However, the Commons architecture was not created having Wikidata in mind, quite the opposite; I still remember the useless insult we could receive talking about metadata on Commons by expert users who did not get it at all.

We will have some integration but it would not be this way. On the long term, some integration could happen also this way, with a brutal import to be "fixed" later, but the best pathway here is a slower one.

Namely, we still have to fix:

  • the status of the galleries, that I agree we should deprecate here as links, Wikidata Infobox are for categories, that's where they work IMHO... let Commons users understand with their pace that the gallery namespace needs to be thought from scratch probably. I support some automated process with "most-used files on platforms" or "most-downloaded files", but that's me and in any case it's "their problem", not ours.
  • the improvement of the flies metadata on Commons. Once the metadata coverage will be completed we will finally understand what to do with very specific categories such as "view of building X from street y" or "black and white photographs of men with a mustache"... the role of most of these categories can probably be replaced with efficient search tools once related metadata are accurate (and I don't think it is so precise at the moment)
  • the quality of items here. I see the huge difference of statements and references depending on the areas. using wikidata metadata to order the category systems of another platform is feasible for certain fields, not all of them. The outreach effort we do in many countries is still embryonic. I'd like Wikidata to be used as a catalysts for order, not to increase gaps even further.--Alexmar983 (talk) 15:04, 19 December 2021 (UTC)[reply]
    • @Alexmar983: Thanks for recognising that Wikidata-Wikicommons is a good thing! With galleries, while I don't like them myself, TBH, the Wikidata Infobox doesn't care - it will work equally well with galleries and categories. I'd love to see automated solutions here to create galleries, but I think what you're suggesting is a few steps beyond this (and I think the solution would involve Wikidata). BTW, see commons:Template:Wikidata_Gallery for a fun example of how we can create Commons galleries form Wikidata!
    • I don't think we have a good solution right now for how to tackle cases like "black and white photographs of men with a mustache". Sure, search may be able to cope with this in the future, but that's multiple years away. In the meantime, let's make it easier for non-English speakers to at least be able to find/understand a category like this - which is what Wikidata enables using category combines topics (P971).
    • I think it's more important that we import and then improve on internal Wikimedia datasets like Commons, which cover important topics for countries that we're not already covering yet on Wikidata, than to exclude them. Sure, references need to be improved - but that's the case across most of the Wikimedia projects. With Wikidata, we get to improve them together. Thanks. Mike Peel (talk) 19:29, 20 December 2021 (UTC)[reply]
  •  Comment In any case, a lot of work must be done first to reconcile categories to existing items. I've just played the distributed game for a while and saw huge gaps in our efforts to map those together. For example, has someone paired Commons disambiguation categories to Wikidata disambiguation items? That should be relatively easy (based on title). Another relatively simple task would be to try to reconcile taxonomic Commons categories to taxons in Wikidata - there, a text string in the category's name is also fairly unambiguous.Vojtěch Dostál (talk) 17:10, 19 December 2021 (UTC)[reply]
Oh yes tons of crap... we never addressed the problem systemically (I suspect, mostly because Commons does not help in that directions) and the system is chaotic. In "my" "main" areas (Tuscany and scientific researchers) I think I do a good job with other wiki-friends, but outside that comfort zone it can get really messy. I performed few tests in the area of epigraphs and it was quite bad. Every years I fix the pictures of Wiki Loves Classics as a "good deed" and I spot really a lot of gaps in other Mediterranean countries.--Alexmar983 (talk) 19:46, 19 December 2021 (UTC)[reply]
@Vojtěch Dostál, Alexmar983: This request for comment is linked to a huge effort to link Commons categories with existing Wikidata items. It links in with the Wikidata Infobox deployment there, and the mass adding of Commons sitelinks over the last few years (particularly by Pi bot). The creation of new items would be fully integrated with the distributed game you were playing - if there's a possible match in the game, then no new item would be created until the possible match had been decided upon. I'm also open to writing new bot scripts to do the matches - but I'd need some help with this, since there are potential issues with auto-matching disambig categories (see commons:Category:Uses of Wikidata Infobox for disambig pages for a tracking category of existing uses on disambig categories, which already need some cleanup), and also with taxons (these are particularly messy since there are different taxon trees on Wikipedias/Wikidata/Commons that don't always match with each other). And sure, there is a lot of crap - but then, that also applies to various Wikipedias, which we already support, and Wikidata itself. Syncing Wikidata and Commons by the creation of new items will benefit both projects - missing Wikidata topics, bad Commons data, it all comes together and gets resolved collaboratively. Thanks. Mike Peel (talk) 18:38, 20 December 2021 (UTC)[reply]
Or in other words, you're just piling more misery on top of the chaos we already have imported from Commons. Wikidata should be the leading system on what it thinks is an actual category, not Commons. Braveheart (talk) 01:53, 21 December 2021 (UTC)[reply]
P.S.: The misery would probably also include categories of people who didn't consent to the Commons categories being created in the first place? And does Commons:Category:People pointing by name actually have any value for Wikidata? Braveheart (talk) 01:58, 21 December 2021 (UTC)[reply]
@Braveheart Value for Wikidata (and for all our projects) is in the integration between Commons and Wikidata. This integration would be greatly simplified if we could put aside all categories that clearly do not have ny counterpart in Wikidata. I understand this "putting aside" is what Mike has been suggesting and I  Support that - if the algorithm for this decision-making is good enough. Vojtěch Dostál (talk) 09:56, 21 December 2021 (UTC)[reply]
@Vojtěch Dostál If there's a tool that can match and discard categories as required that would indeed be helpful (probably similar to Mix'n'match?). But it's different from the initial statement of all Wikimedia categories having a Wikidata item. Braveheart (talk) 12:00, 21 December 2021 (UTC)[reply]
@Braveheart The title of this RFC is indeed a little unfortunate but the proposal states that "a new item would only be created after all possible matches have been cleared", which seems to be in line with my interpretation of the proposal. Vojtěch Dostál (talk) 12:36, 21 December 2021 (UTC)[reply]
@Braveheart you're spot on. As someone who has had to see a Wikidata item created on herself because there is a category on Commons, I can only nod vigorously at the idea that matching Commons categories will indeed add more chaos on top of the chaos. I am at a loss how one can think this is a good idea given the many points made above showing how impossible Commons categories sometimes are. I think that linking categories that make sense is a good idea, but importing without any bias all Commons categories can only further the category nightmare that our projects suffer from. notafish }<';> 12:15, 21 December 2021 (UTC)[reply]
  •  Strong oppose – I cannot understand why such a vote is taking place right now. There is currently an increasing opinion in the Wikidata community that one should reconsider whether Wikicommons categories really lead to the relevance of a data object. From my point of view, this should first be discussed before starting such a discussion here. --Gymnicus (talk) 20:04, 19 December 2021 (UTC)[reply]
    • @Gymnicus: It's happening now since we're reaching the transition point between matching categories with existing items and needing new items to cover all articles. I have no idea what you mean by "an increasing opinion" - can you elaborate? And have we had that same discussion about relevance of sitelinks with any other project? Thanks. Mike Peel (talk) 18:24, 20 December 2021 (UTC)[reply]
  • Will this actually make it easier to find useful media from Commons? Will it in any way reduce the amount of undercategorisation, overcategorisation and miscategorisation? Please ping with reply if answer is yes as I would like to know how. Pbsouthwood (talk) 07:21, 20 December 2021 (UTC)[reply]
    • @Pbsouthwood: Yes. Specifically: it will mean that categories can be described multilingually. This is by having multiple language labels, having multilingual information about the topic, and, in the case of intersection categories, by linking to the topics covered by the category. This would be a huge step forward for editors who don't know English, and should have a direct impact on the under/over/miscategorisation that you mention, by non-English speakers. Thanks. Mike Peel (talk) 18:24, 20 December 2021 (UTC)[reply]
      • Multilingual accessibility is in principle a good thing. However it means that the chaos of Commons categories will be shared among other language users. This could lead to more eyes on the problem and more people trying to fix it, or more people without a clue contributing to the mess, who knows? Good categorisation is hard, and requires some topic knowledge and and understanding of how the categories can and should be used, not a free-for all of enthusiastic noobs with a superficial comprehension and more enthusiasm than skill. I don't actually understand how this proposal would be implemented, but I hope there will be some way of filtering out the worst of the truly facile categories. If that is the case then I don't really see a big downside. Call me cautiously optimistic. (disclaimer: I am basically a Wikipedian and Wikivoyager. I use Commons as a store and where I can, as a source, and am often frustrated, not so much by things not being there, but by not being able to find things that are ther), Cheers, Pbsouthwood (talk) 06:15, 21 December 2021 (UTC)[reply]
  • I agree with broadenig the notability of Commons categoreries, but there are exceptions mentioned above. And there should be problem with notability - Now when somebody creates item about himself, this can be easy deleted because of notability and no sitelinks. With this proposal anybody can create category on commons., upload one photo created by myself and then create item on WD. But the idea about the new namespace specially for Commons categorie - which can be redirected to normally Q items sounds good.... JAn Dudík (talk) 13:47, 20 December 2021 (UTC)[reply]
    • @JAn Dudík: It's a problem that already exists (I've encountered this several times already). The solution is to get the photo(s) and category deleted on Commons first, and then delete the Wikidata item - the exact same approach as we use when people create spam Wikipedia articles.
  •  Neutral I think the template is really good and it helps, but i think for all categories. (Example: when you have a "Category:Germany" and untercategories by year like "Category:Germany 2021", i don't think we need there own categories. Thats why neutral. @Pbsouthwood: The infobox helps immensely because it sets the male and female categories and the year of birth, if known. If we now think further, we could do even more with just a few tricks. For example, the affiliation to clubs or public offices, or which awards one has received. But that all has to be discussed. @all: I think the template is good, you can develop it further and it has already done a lot for Commons. But for really all categories, I'm not sure as in the example. Therefore neutral. Regards --Crazy1880 (talk) 18:18, 20 December 2021 (UTC)[reply]
    I get your point. Pbsouthwood (talk) 06:16, 21 December 2021 (UTC)[reply]
    @User:Crazy1880: Yes, I agree: The infobox helps immensely because it sets the male and female categories and the year of birth, if known. Addition: This also applies for names (given names and family names). JopkeB (talk) 06:45, 25 September 2022 (UTC)[reply]
  •  Support In theory, adding Wikidata-powered IBs to relevant Commons categories would definitely increase knowledge equity and efficiency. Today, Commons category system is exclusively managed in English, which is an obvious exclusionary mechanism for non-English speakers (the vast majority of the world!), and to power categories with multilingual IBs increases knowledge equity. Today, we have no good system to visualize the Commons category system knowledge graph, and the link to Wikidata would allow for efficient querying, establishing constraint mechanisms and so on, when the category tree is modeled on Wikidata. In practical terms, the excellent work Mike Peel has done already with the Commons categories is a powerful example of the potentialities of integrating Commons and Wikidata and a convincing demonstration of the technical pathway to run this two-project integration, so I think we are not going through much risk here. The only convincing caveat about this proposal --from what I read from other contributors of the RfC-- is that there are irrelevant categories on Commons, that might get increased end-user visibility if we power them. Well, this is a fair point, but IMO a more efficient Wikidata-Commons integration would actually help our community locate and curate these irrelevant categories. BTW, the examples shown are really awesome; good job and thank you for all you do for the movement! Cheers. --Joalpe (talk) 15:11, 21 December 2021 (UTC)[reply]
    The categories you mention are irrelevant to Wikidata (and all other WMF projects), but not necessarily to Commons. --- Jura 15:25, 21 December 2021 (UTC)[reply]
    If the category is relevant to Commons, then it makes sense to add it to Wikidata, IMO. Joalpe (talk) 15:32, 21 December 2021 (UTC)[reply]
    @User:Joalpe Why does this makes sense? If we assume that every Commons category has a purpose on Commons, does that automatically mean that every Commons category serves the purposes of Wikidata to have it on Wikidata as well, even if there are no links to Wikipedia or other databases? I agree with you that the multi-language problem might then be solved, but it requires a lot of effort to make WD items and translate all those category names into other languages. Another solution for this problem might be to add translations in category descriptions: Commons does not need necessarily wikidata infoboxes for translations (though they are handsome for that purpose). (I find it easier and less time consuming to make category descriptions with translations, compared to making new WD items.) This might especially be true for the many subcategories by countries, which will have fewer visits by "foreigners". My advise: weigh effort and time against expected yield (= expected number of "foreign" visitors who profit from a infobox because they struggle with English as well as with the language(s) in the category description). JopkeB (talk) 07:26, 25 September 2022 (UTC)[reply]
    The Wikimedia Commons' issue when it comes to other languages is based on the fact that the default language is English and it doesn't properly integrate redirects well. Imagine if every category had redirects based on its name in a different language and these redirects would be displayed as the title when those languages are set by default. Unfortunately, there is no such software and the MediaWiki Upload Wizard doesn't properly integrate with redirects either (a good model here would be HotCat, which does). Wikidata could easily be used to solve this problem by simply generating multi-lingual redirects and then one could theoretically upload files to the Wikimedia Commons without ever having to encounter any English. Unfortunately, nobody at either the Wikimedia Foundation (WMF) or Wikimedia Germany (WMDE) is investing in this or other obvious improvements that make the Commonswiki friendlier for novice users, it has a steep learning curve in every aspect, but it should be as easy to use as possible and give possible warnings of copyright wherever possible (such as if someone uploads an image in subset of "Buildings in France" that it says "France does not have Freedom of Panorama (FOP), please make sure that your image does not include the works of an author who died less than 70 (seventy) years ago"), but that's a different discussion. Wikidata could easily be used to improve language integration if the software was there and integration could make this transition easier. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 07:38, 25 September 2022 (UTC)[reply]
    I cannot see all consequences yet, but on first sight it seems to me a solution that can work. But again, it would require a lot of effort to make and translate all those redirects. Did you ever propose this on a Community Wishlist Survey at Meta.wikimedia.org/? JopkeB (talk) 10:48, 25 September 2022 (UTC)[reply]
    I'm not allowed to. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 10:49, 25 September 2022 (UTC)[reply]
  •  Strong support, the Wikimedia Commons is supposed to be a multilingual project and Wikidata could be used as a base to introduce more translations for category names into other languages. Regarding the concerns of notability and the "Spampocalypse" Commonswiki categories would cause to Wikidata, well we could noindex all items that exclusively link to Commonswiki categories and then index them only once external notability is established. There are many advantages to being able to add more information to Commonswiki categories through Wikidata and using the old infrastructure will improve Structured Data on Wikimedia Commons (SDC), the largest concerns are those raised against notability and that can easily be solved by making these items invisible for external search engines making the Commonswiki category items at Wikidata exclusively for the Wikimedia Commons to utilise and improve itself with until notability is established outside of it. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 21:37, 21 December 2021 (UTC)[reply]
  • Regarding the linguistic element of my comment, imagine that a category is called "Statues in Berlin" then someone could add the Dutch translation "Standbeelden in Berlijn" and if someone's display language at the Wikimedia Commons is Dutch then they will see "Categorie:Standbeelden in Berlijn", it would even be better if redirects would automatically be locally created after a fortnight or something (enough time to fight vandals and tricksters). It wouldn't make much sense to have this feature be exclusive for categories Wikidata deems "notable". -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 21:42, 21 December 2021 (UTC)[reply]
  •  Oppose Multilingual infoboxes for single-topic categories linked to single-topic Wikidata items are great, and Mike's work in this area has been excellent. But I very strongly oppose the creation of new Wikidata items for categories that combine topics, like "Photographs by Harry Pot in the Tweede Kamer (1962)". Creation of such items and corresponding infoboxes will create a lot of work for volunteers in translating and maintaining these, while IMO the Wikimedia movement's actual development effort should be targeted towards (1) introduction of Structured Data on Commons based multilingual navigation that actually replaces the flawed category system on Commons, and (2) faceted multilingual search on Wikimedia Commons. Items in the example category I mentioned above should be made discoverable by helping users multilingually browse and search for files that combine the (single-topic) characteristics 'is a photograph' / 'photographer is Harry Pot' / 'made in the Tweede Kamer' / 'made in 1962'. This is ultimately why we are doing structured data efforts on Commons, and I'm very afraid and worried that a detour via multi-topic categories will only send the message that we're actually not so interested in that, and that such development efforts are not a priority. Spinster 💬 09:56, 22 December 2021 (UTC)[reply]
    Hey, Spinster. My impression is that the development of SDC is paused, isn't it? I have not seen anything going on for several months now. Without a clear development path and schedule for SDC, Mike's proposal is a functional alternative. Joalpe (talk) 16:06, 22 December 2021 (UTC)[reply]
    No, there is active development on SDC. At this moment, work is being done on references in SDC. Spinster 💬 19:04, 22 December 2021 (UTC)[reply]
    Let's just try to fix aspects of Commons with SDC instead of flooding another project with their problems. Braveheart (talk) 09:38, 23 December 2021 (UTC)[reply]
    @Spinster: Do you actually have a roadmap to replacing the Commons category system (by which I mean actually deleting Commons categories, not just trying to bypass them)? Because I can't see that happening any time soon, and think it's really important to have multilingual support for them using existing tools like the Infobox. Since all data is structured, it should be simple to migrate information into SDC as needed anyway (which was a major reason why I invested my time in setting up the infobox and sitelinking so many Commons categories thus far). Thanks. Mike Peel (talk) 10:25, 23 December 2021 (UTC)[reply]
  •  Oppose Like other users already said above, many of the Commons categories that combine several topics are very specific for Commons. I see no point in creating items for them in order to give them labels in different languages. As the categories are only used on Commons, I think the translations are better done there. --Dipsacus fullonum (talk) 12:28, 24 December 2021 (UTC)[reply]
    • @Dipsacus fullonum: There are a lot of topics that aren't specific for Commons - many buildings etc. with Commons categories but no Wikipedia articles yet. Translations can be based off the structured data (category combines topics (P971)) and labels, which only Wikidata enables. – The preceding unsigned comment was added by Mike Peel (talk • contribs).
      • @Mike Peel: First: The RFC says all Wikimedia Commons categories, and that is what I oppose, not e.g. new items for buildings. Second: There is nothing that says that an infobox cannot fetch labels from several items, so you can specify the combined topics in the infobox template at Commons. I see no need for new Wikidata items to do that. --Dipsacus fullonum (talk) 23:52, 24 December 2021 (UTC)[reply]
        • @Dipsacus fullonum: It's the same approach that we take with Wikipedias, nothing special for Commons. The Infobox is designed to work entirely from Wikidata information, since a structured database is the best place to store this information, trying to replicate Wikidata via template inclusions on Commons doesn't scale well (if items are merged/redirected/otherwise modified on Wikidata, then this wouldn't automatically update them on Commons). Thanks. Mike Peel (talk) 23:59, 24 December 2021 (UTC)[reply]
  •  Neutral While I don't necessarily have something against the proposal, I think there are far more urgent matches to be made with Commons, such as the valued image scopes. That would allow better image choosing algorithms. Strainu (talk) 19:27, 24 December 2021 (UTC)[reply]
    @Strainu: It's not one or the other, multiple things can be done in parallel. Thanks. Mike Peel (talk) 20:00, 24 December 2021 (UTC)[reply]
  • I'm fundamentally disappointed with the negativism here. I was hoping that ~3 million edits so far to match up existing items, and the general enthusiasm for linking up Commons items with Wikidata and subsequently using Wikidata information through the Infobox would help. But that's clearly not the case. I understand the arguments against the borderline combination categories, but I was hoping that this would be counterbalanced by the importance of multilingual information that only Wikidata can provide, and also by the huge numbers of Commons categories about specific notable structures. I'll continue matching up existing items regardless, and hope that you change your mind after another million edits or so. Thanks. Mike Peel (talk) 23:49, 24 December 2021 (UTC)[reply]
    Mike Peel I share your disappointment but a lot of work can be done nevertheless. For example, have you considered creating "category items" for items that have Commons category (P373) but do not link to the category via sitelink because a gallery page is already linked from there? I think such automated process would be very useful and help clean up some Commons categories as well. Vojtěch Dostál (talk) 19:28, 30 December 2021 (UTC)[reply]
    @Vojtěch Dostál: I think @Jheald: was doing that a while back, perhaps he could re-run it? The problem is that there are still quite a few bad P373 values, but there's probably ways around that. Thanks. Mike Peel (talk) 19:41, 30 December 2021 (UTC)[reply]
    @Mike Peel @Jheald That would be very useful :) Vojtěch Dostál (talk) 16:23, 6 January 2022 (UTC)[reply]
  •  Neutral or  Weak support. Benefit for this would that structured data of categories could be used as proxy for structured data of files. ( = read as suggestion if you want) and it would actually solve the issue how to create multilingual search in example. It would be also useful when we are populating SDC to files. However, in SPARQL query terms it would be more usable when system would be directly inside SDC aso it would be queried more easily and fully automatic (based on category structures, wikidata, lexemes and machine translations) so it would be not require separate updating. The reason to do this inside wikidata is because the wikidata is already there and there is already working solutions/practices for it and it helps that there is data from other realms than commons too. --Zache (talk) 13:37, 25 December 2021 (UTC)[reply]
  •  Support for 'topic' items,  Oppose for 'category' items. Creating items for 'topic' times would be beneficial for wikidata. However, I'm not a friend of transferring Commons/Wikipedia internal stuff to wikidata. 'Category' items are clear examples of internal stuff. In some cases, the need for interwiki may be a valid user case, but swaths of 'category' items will never need interwiki (for example from one random picture categories like Category:Photographs taken on 2006-02-11, Category:Industrial buildings in the London Borough of Southwark, Category:Geograph images in the London Borough of Southwark etc.). --Jklamo (talk) 10:29, 3 January 2022 (UTC)[reply]
  •  Oppose Category = class = concept (= Q item). The category system was an attempt to allow taxonomy creation with the technology available at the time. We now have better technology available: Wikidata. Wikimedia category (Q4167836) and related Q and P items merely serve to embed an alternate, less usable taxonomy based on categories into Wikidata, which is completely backwards. People are generally resistant to change, and I understand that there will be resistance in Commons and elsewhere to get rid of categories and replace them with Wikidata concepts (and combinations of concepts, which are also concepts), but this change has to happen. In my opinion, implementing this RFC would merely solidify the category system further, instead of serving as a bridge to the eventual elimination of categories. Silver hr (talk) 17:48, 2 February 2022 (UTC)[reply]
  •  Oppose It will likely create to much problems with spam given that commons has relatively lose notability criteria. ChristianKl ❪✉❫ 21:10, 20 July 2022 (UTC)[reply]
@User:Alexmar983 I use Wikidata infoboxes not only in Common categories but also in Gallery pages. I find them useful there because in a nutshell they give a lot of basic information about a subject. And then I can focus on the files to include.
I guess Commons categories like "view of building X from street y" or "black and white photographs of men with a mustache" are mostly made because the parent categories were overcrowded (my criterium is 200 files or more). In such cases you look for groups of files who share common characteristics and make subcategories for them, to remove them from the parent category. In Commons a big number of files is a reasons to make new subcategories. So, these subcategories might not be interesting/appropriate for Wikidata.
@User: Mike Peel I think making proper Commons gallery pages is human work. It is about setting up a page, what would you like to tell (just give an impression of a village, make a sign post to a main category, or something else), selecting good images for that goal, placing them in a good order and giving them captions and/or links to subcategories. "some automated process with most-used files on platforms or most-downloaded files", could be another kind of process, for instance an option in a free search, but I think the order of search result is already on relevanc and I guess "most used" is already part of this syntax.
@User: Pbsouthwood I agree that unfortunately there is a lot of undercategorisation, overcategorisation and miscategorisation on Commons. How does that affect Wikidata? I know that there are Commons volunteers who do what they can to solve this problem (like me) and others, including bots, who add meta information (based on Wikidata items) to files to make them better findable.
About deleting files from Commons: you cannot ask for a deletion request for a Commons file if it is still in use in a Wikidata item. This problem is being discussed on Wikidata talk:Notability#Item 4 is confusing. JopkeB (talk) 10:38, 24 September 2022 (UTC)[reply]

Alternatives ? edit

@MisterSynergy, Ameisenigel, SCIdude, Mirer, Multichill, Gymnicus: Most of your opposes seem to be based on what would be valuable to Wikidata, without considering what would be useful to Commons. So what alternative do you propose instead of items here, that would have the same value for Commons? As I see it, there are two key things that enabling Wikidata items here would assist for Commons. The first is enabling multi-lingual infoboxes, to set out in the user's own language what the category represents. For this purpose one could to some extent work around the lack of a Wikidata item with a template like c:Template:Main subject, hard-coding the identities of the relevant Q-items the category combines into the wikitext of the category page -- though it's significantly less attractive, being non-standard, more awkward to edit, less transparent, not updating if items get merged, and not showing up in "what links here" or "what statements reference this item" on wikidata; and it doesn't give the same slot to internationalise the name of the category.

But where it seems to me that a workaround like that really fails is machine accessibility. What I would like to be able to do, eg for a group of files in a category for a particular GLAM upload, is to be able to ask things like: "what information is currently represented by categories on files in this group, that is not represented in SDC statements?" -- and then to get a list of potential SDC statements to add for particular files, that I could then go through and manually approve or reject. To be able to answer a question like the above, a tool needs to be able to discover what the categories on a file represent. If categories have Q-items with statements explaining what they contain, this becomes relatively possible. (And it also becomes much easier to ask the same question for categories, too, to systematically run sweeps to check whether their inheritances are fully represented in statements). Having items for the categories seems to me the essential pre-requisite, if one wants to be able to make this possible. The comparison is with how wikidata makes WDQS queries possible, whereas nobody would consider such queries if every time they involved scraping wikitext of multiple multiple wikipages to extract values from templates there.

So that is why, to all the people who 'opposed' above, I would like to ask: what is the alternative you would propose to make the above do-able, which would seem to be possible with wikidata items, but very difficult without them? Jheald (talk) 11:56, 18 January 2022 (UTC)[reply]

Additional pings: @Spinster, Dipsacus fullonum, Jklamo, Mike Peel: -- Jheald (talk) 11:59, 18 January 2022 (UTC) [reply]

I'm not more a Wikidata guy, than I'm a Commons guy, so it has nothing to do with thinking about just what is good for Wikidata. I oppose an automatic creation for all Commmons categories. And that is in my opinion good for Commons too. Anything else would cement stuff over there ("but it has an Infobox!"), which should be solved otherwise and/or cleaned up before more automatic mass-edits are made. They are the reason Commons is the mess it is and Wikidata is as unreliable as it sadly is). Nobody cares about cleaning up the stuff, just more bad mass-edits everyday ...
You're thinking about stuff like people or existing objects?! I think no one objects creating (even automated) items for those in 99% of the possible cases. But there is a difference with Categories like "Black and White photographs from an unknown location with or without people where some may be smiling or wearing hats". As well with other cases mentioned and discussed above. Almost all of them not only import problems here, we don't need here. They don't improve Commons either. Mirer (talk) 15:30, 18 January 2022 (UTC)[reply]
@Mirer: Thanks. I'm not a great fan of hyper-categorisation either. In fact, there's a current Commons discussion at the moment where I've been arguing as strongly as I can precisely against some hyper-narrow categorisation in the context of old maps, and would like to see it undone. But, for what I've written about above, it's specifically not just categories for people or concrete actual objects that IMO it would be useful to be able to have items for here. It specifically is intersection categories such as "Category:Industrial buildings in the London Borough of Southwark" that I think we now need Q-items for, to make it possible to record and make accessible exactly what information is intended to be implied by the categorisation into a category like that -- ie the information that the category combines "industrial buildings" as a class of subjects depicted, and "London Borough of Southwark" as location. That is the information that I think it would be useful to record somehow in wikidata terms, and that it would be useful to have accessible as likely wikidata properties and statements for any file in the category. A wikidata item with wikidata statements seems by far the best means we have to record that that is what the categorisation represents, if it is to be readily accessible. Maybe some workable alternative exists that might serve pretty much as well -- but I can't see it. So that was the purpose of my post, to ask people opposing such items, what alternatives can they suggest instead, that would be as straightforward to write such information to, and as easy to access? Jheald (talk) 17:32, 18 January 2022 (UTC)[reply]
I don't wanna go to deep into detail, but in my opinion even an item for a cat "Industrial buildings in the London Borough of Southwark" wouldn't be smart and would not help Commons in the "long run". That are two very different things, which should be 'marked or mapped' (I'm not sure about the english terms here ...) with structural data and not categories. Every item or picture of items in this cat is only an intersection of "Industrial buildings" and objects located in the "London Borough of Southwark". Cementing cats (which have Infoboxes!) in Commons for such filtering cases is not smart. That's technology of the 80s which we shouldn't prolong. We should only do this, if it is useful for a transformation to structured data and a cleanup of that respective 'area' in commons. --Mirer (talk) 04:12, 19 January 2022 (UTC)[reply]

How to move forward while avoiding intersection categories edit

I would really like to see this RfC end with a practical outcome that at least significantly increases the number of Commons categories that are linked with Wikidata. From what's been posted here so far, the main concern seems to be the intersection categories. So, let's try to focus on the non-intersection categories if we can. I think this can roughly be done by applying these constraints:

  1. Maximum length of category name: must be under 100 characters (or maybe a lower limit?)
  2. Category name should not include " in ", "taken on" - and we could add other exceptions as needed as we start the tcreattion of the items
  3. Also, the categories should not have potential matches in the Wikidata game

Would this approach work? Thanks. Mike Peel (talk) 20:30, 22 January 2022 (UTC)[reply]

BTW, I've rebooted the discussion about the bot to create items about humans that have Commons categories. Thanks. Mike Peel (talk) 21:02, 22 January 2022 (UTC)[reply]

I agree that the scope of Wikidata's notability policy should be expanded to include more Commonswiki categories. In the previous discussion ("my" proposal) there were some users that wanted to expand Wikidata's notability to specific types of categories. I   reluctantly support the above proposal as I don't see the full adoption of Commonswiki categories being realised anytime soon and this more narrow scope addresses most of the concerns made above, well excluding those of the people that simply view the Commonswiki and general MediaWiki categorisation system as "archaic". I think that the Wikimedia Commons' category system is awesome and should be improved rather than completely abolished. Wikidata's current concept system is "less customisable" than the Wikimedia Commons' category system which can be fitted for the Commonswiki's unique needs and more complicated subjects within media files. I don't see how getting rid of them will help people unfamiliar with its organisational infrastructure find items more easily. Wikidata integration will help Structured Data on Wikimedia Commons (SDC) and its search engine so I support any expansion that allows more categories to be linked to Wikidata items. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 22:39, 2 February 2022 (UTC)[reply]

Summary and conclusions edit

Just a very short overview, does not at all do justice to all input, details and nuances, for who is new and wants to know what this discussion is about and what has been achieved so far.

  1. There is no agreement upon "Creating new Wikidata items for all Commons categories". A lot of the participants in this discussion would indeed like to have more integration between Wikidata and Commons; others are against the whole idea, for verious reasons, perhaps later. There is no one who would like to have an automatic creation for all Commmons categories.
  2. Partial proponents say:
    1. It would be useful to have Wikidata items for a lot of subjects, like locations, objects and notable people, organisations and buildings.
    2. Excluded should be:
      1. Commons categories for which already Wikidata items exist, but there is not yet made a match between them (there is a Wikidata item about the subject, but there is not yet made a link between the Wikidata item and the Commons category).
      2. Persons and organisations that don't have an existing item on another Wikimedia project (outside Commons) unless their notability can be established.
      3. Categories which were created solely because the parent category was overcrowded with files, like "Eiffel Tower taken from the west corner of the Trocadero terrace" and "Black and white photographs of men with a mustache".
      4. Subcategories of Category:Photographs by day (Photos taken on XXXX-YY-ZZ in ABC).
      5. Other categories on Commons that are irrelevant for Wikidata, like those for internal affairs in Commons, such as the subcategories of Category:Commons maintenance content.
  3. Other discussion subjects were about:
    1. Galleries - status.
    2. Multilingual accessibility of Commons: Wikidata items are perhaps the best solution, at least for single-topic categories, but there might be alternatives.
  4. No discussion about:
    1. Wikidata Infobox - genereal agreement about its success, they are handy and useful.
  5. Still open: How to move forward?

Please add important missing points. --JopkeB (talk) 02:25, 26 September 2022 (UTC)[reply]

One could start by making a list of missing WD items corresponding to Commons categories for people, places, objects, etc., and see if there is a consensus for mass creating these. Yann (talk) 08:48, 13 December 2022 (UTC)[reply]
It would be wise if a Bot would start mass-indexing all Commonswiki categories and pages that don't have an equivalent on Wikidata and then come up with a new proposal of what should and shouldn't be acceptable here, that way we can visualise what we want and what we don't want. This is actually more easily to debate than an abstract blanket acceptance of all Commonswiki categories. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 09:05, 13 December 2022 (UTC)[reply]
That's quite a task. There are more than 8 million category pages at Wikimedia Commons which are not yet connected to a Wikidata item. —MisterSynergy (talk) 09:52, 13 December 2022 (UTC)[reply]
That is too many to oversee, impracticable. Perhaps we should first agree about the criteria to make new Wikidata items for Commons categories, which subject is in no other Wikimedia project, and make that a policy (so the criteria on Wikidata:Notability should be changed). And then act pragmatically: make a new Wikidata item whenever you see a Commons category that meets the criteria and has no Wikidata item. JopkeB (talk) 15:28, 13 December 2022 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Creating_new_Wikidata_items_for_all_Commons_categories&oldid=1789580663"