Wikidata:Properties for deletion/P373

Commons category (P373)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

I thank the more than 60 users who have participated in this nomination for deletion over almost three years, with special mentions to Nomen ad hoc for opening it, and to Mike Peel and Liuxinyu970226 for their activity. The discussion has helped the community to reflect and compile enough arguments for and against the deletion of Property P373 ("Commons category"). Still, it has not been enough to identify the community's preferred outcome. There is a need for a final decision-making process (e.g. a vote under Wikidata:Requests for comment) for finding the community's preferred way of linking Wikidata Items to Wikimedia Commons categories. In such a process, each editor, informed by a balanced summary of pros and cons from this and many other discussions (e.g. previous nominations for deleting the Property: 1, 2, 3, 4; RfCs: 5, 6, 7, 8, 9), should be able to choose one of a small number of predefined options without further justification. The process should have start and end dates agreed upon before its opening, with a duration of more than 30 days, and its results should be conclusive and binding. Until those results are available, I resolve to extend the status quo and keep the Property, and that no more nominations for deleting the Property be opened. --abián 12:05, 6 August 2022 (UTC)

---

Commons category (P373): (delete | history | links | entity usage | logs | discussion)

Seems redundant with "Other sites" field. And we have no equivalents for other wikiprojects... —Nomen ad hoc (talk) 19:55, 8 September 2019 (UTC)

• @Nomen ad hoc: Please read archives listed in its talk page carefully: 1, 2, 3, 4 (if links can't work properly, use Ctrl+F type P373), this was PFDed for 4 times and their results were all keep. --Liuxinyu970226 (talk) 22:03, 8 September 2019 (UTC)

  @Liuxinyu970226: The links 2 and 3 don't seem to work. The RedBurn (ϕ) 20:30, 2 May 2020 (UTC)

  @Nomen ad hoc, Liuxinyu970226, The RedBurn: The links are : 1, 2, 3, 4. —Eihel (talk) 11:04, 30 May 2020 (UTC)

• Unless if @GZWDer, Lavallen, Ivan A. Krestinin, Izno, Doostdar:@Jakec, Cycn, Esquilo, Multichill, Paperoastro:@GautierPoupeau, Tamawashi, Micru, ערן, Closeapple:@TomT0m, JAn Dudík, Pasleim, Jklamo, Hanay:@Rippitippi, Sannita, Jianhui67, ŠJů, Jmabel:@Discasto, Marsupium, Mike Peel, Kaldari, Ghouston:@Strakhov, Jheald, Jura1, Slowking4, DarwIn:@Jarekt, Deryck Chan, PKM, Derzno, Ksc~ruwiki:@Krenair, Amire80, Jon Harald Søby, Tgr, Tpt: those guys said something against their previous keep, I would love to non-admin close this discussion. --Liuxinyu970226 (talk) 04:05, 9 September 2019 (UTC)
•  Keep - needed when the Commons site link is connected to a Gallery page. - PKM (talk) 05:03, 9 September 2019 (UTC)

  @PKM: In those cases, just create an item with instance of (P31)=Wikimedia category (Q4167836), and use topic's main category (P910)/category's main topic (P301) to link to the topic item, e.g. Category:Isaac Newton (Q7215722) vs. Isaac Newton (Q935). Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)

  @Mike Peel: you make a compelling case below. But I'd prefer that we standardize on linking to Commons categories not Galleries. - PKM (talk) 06:41, 9 September 2019 (UTC)

  @PKM: So would I! But others seem to disagree. Although, that wouldn't change things in the example I gave, since en:Category:Isaac Newton also uses the Commons sitelink via Category:Isaac Newton (Q7215722). Thanks. Mike Peel (talk) 06:46, 9 September 2019 (UTC)

•  Keep The "other site"-link is a one-to-one mapping from Commons to a Wikidata object (and its interwiki links). Commons category (P373) is a many-to-many mapping to Commons. /ℇsquilo 06:04, 9 September 2019 (UTC)

  @Esquilo: We may consider to break such glitch, see reasons at phab:T54971. --2409:8902:9021:3DF1:579C:FBA1:7BB1:D3E0 00:30, 21 September 2019 (UTC)

  I consider that to be a bad thing. There are numberous cases when multiple Wikipedia articles uses images from the same Commons category. Wikidata structure should reflect this usage. /ℇsquilo 09:17, 21 September 2019 (UTC)

•  Delete - or in the immediate future, deprecate until the remaining cases that don't match the sitelinks are resolved (while bot-removing matching cases to unearth the mismatches). This property served its purpose as a temporary work-around, but nowadays the Commons sitelinks are used, both to link to Wikidata from Commons (using commons:Template:Wikidata Infobox), and also to link from Wikipedias (using en:Template:Commonscat/en:Module:WikidataIB's getCommonsLink function). Keeping P373 around just adds to the maintenance burden, as it needs to be kept in sync with the sitelinks (the sitelinks automatically update when a category is moved/deleted, P373 has to be manually/bot-updated), and that's particularly difficult here since things like Wikidata:Database reports/Constraint violations/P373 are continuously broken/outdated. There is a lot of work still to do to get rid of this property - in particular, uses on various wikis need to be changed to use the sitelink instead - but I'm not sure that will start unless the property is clearly marked as deprecated/on its way out, in favour of the better solution of the sitelinks. Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)
•  Keep Per previous threads. Apparently nothing changed. I may add keeping Commons gallery (P935) and deleting P373 while allowing gallery-sitelinks doesn't make much sense. Galleries should be deprecated as Commons sitelinks. strakhov (talk) 06:27, 9 September 2019 (UTC)

  @strakhov: See #Part 3 below for an alternative solution for your matters. Liuxinyu970226 (talk) 04:16, 15 January 2022 (UTC)

  @Liuxinyu970226: Honestly, letting alone querying performance issues, granularity issues, and the potential creation of endless "category items" only for storing a commons category, I don't see how #Part 3 (you meant this?) is a solution for solving the severe inconsistency of deleting P373 because "only one way to link", "kill redundancy", "use the links that's what are they for" & "blablabla" while keeping at the same time Commons gallery (P935). One way or the another:

  1. Wikidata permanently deprecates the use of galleries as sitelinks, using this Commons gallery (P935) property instead.
  2. Wikidata dictates galleries should be linked as sitelinks in the main topic item, making then Commons gallery (P935) useless and "redundant".

  The current proposal (killing P373, keeping P935 and allowing gallery sitelinking) does not make sense IMHO. strakhov (talk) 08:58, 15 January 2022 (UTC)

•  Keep: P373 is still the least-bad kludge for dealing with Wikidata's original sin of insisting on 1:1 item correspondence between projects, despite being founded long after Commons. As Liuxinyu970226 mentioned, this is at least the 4th nomination to delete P373. Commons still has both mainspace (gallery) and category pages for topics, and the category pages are primary and have the most content; mainspace is utterly optional, and probably even less popular than it used to be. Though Wikidata has loosened the notability criteria and added links between main items and category items, there is still the question of how one deals with a Commons category being the primary page for a subject and sometimes a not-very-notable subject at that. How do we deal with Commons if P373 isn't on the main item? Problems no matter which way you try:
  1. The current sitelink standard is to put the Commons category on a Wikidata category item if there is one, and otherwise put the Commons category on the Wikidata main item. But if there's a Commons gallery (mainspace page), and Wikidata has no category item for that topic, then the Commons gallery gets the sitelink, and the Commons category gets no sitelink, because Wikidata is bound to 1:1 sitelink relationships, even though galleries aren't where most of the content is on Commons.
  2. One might propose that we simply create a Wikidata category item for every Commons category. But are Wikidata category items allowed for topics that have no main topic? I see that "one valid sitelink to a page on ... Wikimedia Commons" was added to Wikipedia:Notability, but I can't tell if that was by consensus; there seem to be more opposing that supporting the idea on Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). Commons categories don't have to be "notable" to exist. (Examples: Commons:Category:Slurry near St. David, Illinois in April 1973; Commons:Category:Images from the State Library of NSW album 7039; Commons:Category:2015-03-21 Morgan Park v. Lutheran Class 3A consolation basketball game; Commons:Category:LVIA F669 ap7 b86; Commons:Category:Random events in the USASMDC.) Wikidata now seems to allow very-low-notability articles — for example, on Wikinews and Wikisource — to qualify for Wikidata items. But on Commons, the category creation criteria is even lower. Only files have anything like a notability criterion: "realistically useful for an educational purpose" or legitimately "in use on another project"; a Commons category, despite usually being the main topic page on Commons, is created and retained simply on there being sufficient content to fill it. Commons doesn't allow blatant spam, but it doesn't prohibit sponsored content either. Does a company or product qualify for a Wikidata item just because someone uploaded enough files to Commons to get a category made? (By the way, even that thin criterion has been abused by some Wikidata evangelists/conquistadors, who have been invading Commons and creating new Commons categories with only one file, claiming that Commons rules don't prohibit it, then "coincidentally" linking the categories to existing Wikidata items to get credit from whoever's keeping track of Wikidata adoption metrics.)
  3. Even if every non-hidden Commons category now automatically qualifies for a Wikidata category item, there is still the process of creating each Wikidata item. It's been 5 years since I pointed out the burden of creating a category item on Wikipedia at Wikidata:Requests for deletions/Archive/2014/Properties/1#Commons category (P373) 2. (Granted, steps 5 and 6 aren't needed if there is no main topic.) Would we want a bot to create the Wikidata category items instead?
  So, until we have all of that settled, and a working implementation for all of it, P373 should stay: It's the only method that allows both a gallery and a category link (which is more important) to Commons to exist simultaneously for a Wikidata main topic item that doesn't have a Wikidata category item. --Closeapple (talk) 07:44, 9 September 2019 (UTC)

  @Closeapple: Notability is still something that's being argued about - basically the notability guideline doesn't match practice here any more. However, the cases that you talk about are a separate issue ('should all commons categories have Wikidata items?') - here we're talking about categories that are linked to from Wikidata/Wikipedia already, and those should already be notable enough to have items. Most items that have galleries linked to them already now have category items with the category sitelink where available, there aren't actually that many of them (Commons gallery (P935) is only used ~100k times). Note that we're coming up to the 2.5 million mark for commons:Category:Uses of Wikidata Infobox - and that's excluding taxons, which are around ~0.5 million, so the sitelinks are already in place for about half of Commons' categories now. Plus the Wikidata infobox on Commons makes it more valuable to go through the process you described before to create the sitelink - a P373 value just links one-way, which is kinda useless for Commons editors. Thanks. Mike Peel (talk) 08:07, 9 September 2019 (UTC)

•  Delete If Mike thinks it's ready to go, lets get this started, even if it will take another five years to implement the deletion. Step 1: remove the property from category items. Step 2: remove the property from items linked to a category. Step 3: remove the property from items with the sitelink. Step 4: ... --- Jura 07:59, 9 September 2019 (UTC)
•  Oppose for now. This property is widely used. Before deprecating there should be some tools which automatically uses commonscat from related item using P301/P971. JAn Dudík (talk) 10:49, 9 September 2019 (UTC)

  @JAn Dudík: Oppose deleting or oppose keeping? --Liuxinyu970226 (talk) 00:20, 4 December 2019 (UTC)

  I mean  Keep, but I agree with deprecation in future. JAn Dudík (talk) 08:56, 4 December 2019 (UTC)

• Can we have a demonstration, by removing the P373 statements from some items with a lot of sitelinks, to verify that all the interwiki linking still works? If it does, I support removing the redundant property. Ghouston (talk) 10:57, 9 September 2019 (UTC)

  @Ghouston, JAn Dudík: See the things I linked to in my post above, in particular there is a function in Module:WikidataIB ('getCommonsLink') that you can use to fetch the sitelinks via the linking properties. Also look at any Commons categories using the Wikidata Infobox to check the interwiki links. There are a lot of cases on other wikis that need to be changed to use this new code rather than accessing P373, though, which is why we need it to be deprecated first rather than just deleted immediately. Thanks. Mike Peel (talk) 11:56, 9 September 2019 (UTC)

  @Mike Peel: I am afraid, that there will be many problems. 1) Because of inexistence of global modules there will be necessary to update all Wikidata bodules in all wikis. Then update of all templates which uses P373. 2) There are many users who uses P373, but are not familiar with commons sitelink. 3) there are many cases where 1:1 linking is not possible. 4-n) etc. There will be BIG impact to all wikis, so There must be at first good solutoin with good documentation in many languages. And After this all should be possible to deprecate P373. – The preceding unsigned comment was added by JAn Dudík (talk • contribs).

  Deprecation to me implies that new statements using the property should not be added, the bots that maintain it should be stopped, and that it can be safely removed if desired. If the software isn't yet in place in all Wikis, then I don't think that step should be taken. Ghouston (talk) 00:18, 10 September 2019 (UTC)

•  Delete per Mike Peel. This property is nothing but awful and highly problematic programming spaghetti, for the reasons exposed. the mere fact that it exists is a continuous source of trouble, as tool developers may use them as a source for the commons cat, wide-spreading and perpetuating the problem till unmanageable levels. The link article-category and reverse is generally made through SetSiteLink. My perception is that most of this evilness emanated from a primeval misconception that Wikipedia Articles corresponded with Commons Galleries (generally false, by default, since Galleries are mere exhibitors for Commons categories, and there could be like 100 of them for a given subject, none of which with special preponderance over the others) and that Wikipedia Categories had any importance to Commons, and should preferably relate to Commons Categories (generally false too, though sometimes it can be useful to connect them, such as in "churches in municipality X", the kind of thing that probably will never have an article in Wikipedia). In any case, this property doesn't seem to be needed at all.--DarwIn (talk) 11:06, 9 September 2019 (UTC)

   Comment In case of removal, please check Listeria, as I seem to have noticed it uses this property to show the Commons Category in the lists (should be using SetSiteLink, otherwise it gets broken everytime someone moves a category in Commons).--DarwIn (talk) 11:08, 9 September 2019 (UTC)

•  Neutral I came to this discussion thinking to vote to keep it, but Mike Peel has a convincing argument. I can see in the future time when P373 can be retired and that would simplify our maintenance burden, and in general prevent the same info being stored in two places. I would also like to see some trimming of the number of unmaintained Commons galleries clogging the sitelinks, but that topic should be discussed on Commons. --Jarekt (talk) 11:59, 9 September 2019 (UTC)
•  Keep and delete other sites link. in a larger sense, deletion is not a quality improvement process, rather provide the ontology, team and method to improve wikidata to commons links. Slowking4 ‽ (Rama's revenge) 12:45, 9 September 2019 (UTC)

  @Slowking4: Can you elaborate, please? Without the sitelink, none of the interwiki links on Commons, nor the infobox, would work. It's akin to removing the interwiki links to the Wikipedias and replacing them with a property - you can then only see the link on Wikidata, not from the other wiki. Thanks. Mike Peel (talk) 13:18, 9 September 2019 (UTC)

  i'm saying the site link is more opaque and inexact. it is a problematic analogy to wikipedia articles, which commons does not have. we need to develop the ontology and mapping of commons content. you could map the many infoboxes to creator and institution (and depicts). but a consensus and action plan is required , deletion should be salted as a perennial rejected proposal.-- Slowking4 ‽ (Rama's revenge) 13:32, 9 September 2019 (UTC)

• Who cares - none of these hacks actually work well (e.g. [1]). We should either stop linking to Commons galleries (as they are an unmaintained wasteland) or push the Wikidata developers to implement a real way to add sitelinks to both File and Gallery pages at the same time. I can't understand why the Wikidata community want to waste countless hours dealing with these crappy hacks. Kaldari (talk) 15:10, 9 September 2019 (UTC)
• One item should have one Wikidata item page, ie. the item page should link articles as well as categories of its item – as sitelinks, not as properties. That's the core of the problem. --ŠJů (talk) 15:57, 9 September 2019 (UTC)
•  Keep read archives, not going to repeat myself. Multichill (talk) 16:57, 9 September 2019 (UTC)

  @Multichill: I've looked through the archives. At [2] you said "you would first need to change the notability policy before you can replace this template." - Wikidata:Notability has been changed to a certain extent, but further changes are still needed to match the policy with reality - which is a separate topic. You also mentioned phab:T49930, which has been resolved. In [3] you said "massive usage, not a good alternative" - sitelinks are that good alternative, as I've described above. I've also been working through the backlog of mismatches between enwp and wikidata sitelinks, where I've been finding many wrong P373 statements that have been imported from enwp and have been corrected in the sitelinks only, one example is this edit by your bot in 2009, which was imported to Wikidata in 2013, fixed via the sitelink on 2016, and I removed the P373 statement 2 days ago. Of course this is only one example, and of course I've cherry-picked it from my recent cleanup work since you were involved, but there do seem to be a lot of examples from a few years ago that are similar, which are being discovered by comparing the links with sitelinks. I hope that we can finally resolve this kind of issue by using the sitelinks, and if you are still opposed to that then I hope you can post the reasons here. Thanks. Mike Peel (talk) 20:12, 13 September 2019 (UTC)

  I don't think that changes to Wikidata:Notability can be ignored as a separate topic. The problem is that if you have an main Wikidata item which is sitelinked to a Commons gallery, and there's no existing category item, then there's nowhere to put a Commons sitelink. Wikidata:Notability forbids creating a new category item for Commons. Attempts have been made to change Wikidata:Notability but they have been unsuccessful. Ghouston (talk) 02:09, 14 September 2019 (UTC)

  I started another discussion at Wikidata talk:Notability about allowing certain category items for Commons. Ghouston (talk) 02:48, 14 September 2019 (UTC)

  I rather spend time on building things than on these destructive discussions. This deletion nomination is just negative energy. We're just wasting community time and energy here on something that hasn't been thought through properly. This discussion will just suck in more energy, come to a grinding halt at some point and some admin will close it as no consensus. What a waste. Multichill (talk) 19:09, 14 September 2019 (UTC)

•  Keep. Nothing has changed nieither in Wikidata nor in Wikipedia nor in my opinions. We have namespaces: articles and categories. Now both items of categories (we apply for them "other sites") and articles (we apply for them Commons category (P373)) have connections with categories of Commons. Very often other sites are used in items of articles. But as soon as we make statement topic's main category (P910) in article item bot immediately moves commons category sitelink to category item. (See, for example, recent history of Vikulovsky District (Q1753812)). If Commons category (P373) wouldn't exist connection between article item and commons category would be lost. So Commons category (P373) is the only effective and visual way to keep connection of articles items and commons categories. Removing the property is just losing of such way. Property's benefit was discussed n project chat. And besides I can repeat myself: "In Russian Wikipedia we use Commons category (P373) in a great deal of temlates including crucial important ones. Removing the property right now just would break links to Commons in a huge number of articles and categories, spoiled their interface.". --Ksc~ruwiki (talk) 18:45, 9 September 2019 (UTC)

  @Ksc~ruwiki: In that example, topic's main category (P910) and Commons category (P373) appear next to each other - click on the topic's main category and you see the commons category. It is one step further away, which isn't good, but it's not that far away. In terms of P373 usage on ruwiki, could you look into using {{#invoke:WikidataIB|getCommonsLink|qid={{{qid|}}}|onlycat=True}} using commons:Module:WikidataIB instead? That will then use the sitelinks instead of P373, and is part of the transition during deprecation that I suggested above. Thanks. Mike Peel (talk) 06:19, 10 September 2019 (UTC)

  if I call getCommonsLink without params and then pass "onlycat" will it return me gallery at first and category at second (both exist on commons)? Where does it get their names? --Igel B TyMaHe (talk) 07:31, 10 September 2019 (UTC)

  @Igel B TyMaHe: If you don't set qid it will use the Wikidata item that the page is sitelinked to. It follows topic's main category (P910) or category related to list (P1754) to the connected Wikidata item if available. If you set "onlycat=False" or leave that parameter out then it will return the gallery if available, then the category if not - if you set "onlycat=True" then it will only return the category link. It currently falls back to P373 as a transition measure. (With thanks to @RexxS: for the code). Thanks. Mike Peel (talk) 07:46, 10 September 2019 (UTC)

  It currently falls back to P373 as a transition measure — Certainly i'm asking how will it work without P373? (BTW P3722 (P3722) links to Commons the same way as P373 and "seems redundant with "Other sites" field. And we have no equivalents for other wikiprojects") --Igel B TyMaHe (talk) 08:20, 10 September 2019 (UTC)

  @Igel B TyMaHe: In my experience on enwp, pretty well - although there are still cases to clean up there, see en:Category:Commons category Wikidata tracking categories (I was hoping to get a bit further with that cleanup there before nominating P373 for deletion, but here we are.). P3722 (P3722) is set up incorrectly and needs to be fixed, it should work like category for recipients of this award (P2517), which links to the category item here not directly to Commons. Thanks. Mike Peel (talk) 08:28, 10 September 2019 (UTC)

  As I can see P373 will be replaced with [commons] link in "Other sites". But this one is for Commons gallery (P935). P935 should be deleted instead of P373, because P373 is link to the different item, P935 is to the same. [commons] link in "other sites" should be in Category item like in Category:Group of Seven (Q17420469). P373 shoud link to item and through it to commons. This is nonsence to link in "Other sites" to something that is not directly belongs to the item. There shouldn't be linking to Walt Disney in Mickey Mouse in "Other sites" or vice versa. --Igel B TyMaHe (talk) 14:07, 10 September 2019 (UTC)

•  Delete Per Mike Peel, I think some Dutchism discussions can be stopped, if the problem is one-per-one linking glitch, all the best thing we should and need to do is to break such a glitch, not use property to white-paint. --117.15.55.5 02:39, 10 September 2019 (UTC)
•  Delete per Mike Peel or at least let's try to deprecate this property once and for all. It's about time that we fix this thing. Sannita - not just another it.wiki sysop 20:50, 10 September 2019 (UTC)
•  Keep unless is Commons linking issue finally resolved (abandon commons galleries sitelinking - I am afraid it needs another lengthy RFC), then  Delete. --Jklamo (talk) 10:08, 11 September 2019 (UTC)
• Whether or not this is eventually gotten rid of, please modify c:Module:Creator to stop using P373 if so desired. Also check for other templates or modules that still rely on it.--Roy17 (talk) 21:49, 12 September 2019 (UTC)

  @Roy17: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)

  @Roy17: Creator now uses the sitelinks! Currently as well as P373, but if we decide to delete this property then there's now a clear migration path. Thanks. Mike Peel (talk) 07:58, 2 November 2021 (UTC)

•  Comment Voters should be aware that Commons category (P373) is currently used for sidebar ("In other projects") linking to Commons from Wikipedia articles. So deleting this property without a new technical solution will simply make the links disappear. --Matěj Suchánek (talk) 10:51, 14 September 2019 (UTC)

  @Matěj Suchánek: That's a good point, that should be fixed during a deprecation stage before deletion. I've filed phab:T232927. Thanks. Mike Peel (talk) 18:17, 14 September 2019 (UTC)

  A deprecation stage of a property means that it should not be added to items and should be removed there where possible. If that deprecation stage is present, the technical solutions to the sidebar (etc) ashould already have taken place. Again: first deprecation (= breaking) and then fixing is the wrong order. Romaine (talk) 07:53, 12 July 2020 (UTC)

• Deprecate per Mike Peel. At Wikimania last month, Mike and I talked about this exact issue (P:P373 being a piece of necessary evil to deal with misalignment of category and topic items), and I'm persuaded that we should at least try to migrate towards a more elegant solution. Deryck Chan (talk) 16:35, 15 September 2019 (UTC)
•  Keep Agree that the current situation is not the best, however I believe that 'other sites' is a ridiculous, kludgey solution that's even worse than this property. Gamaliel (talk) 20:19, 17 September 2019 (UTC)

  @Gamaliel: Why not apply phab:T54971 solution to Commons? --Liuxinyu970226 (talk) 21:55, 18 September 2019 (UTC)

• Deprecate. I also agree with Mike Peel. --Tinker Bell ★ ♥ 02:47, 20 September 2019 (UTC)
•  Question If this property is deleted, who will update the Wikidata-linked Creator template which current uses P373 to populate the "homecat" parameter? - PKM (talk) 20:14, 20 September 2019 (UTC)

  @PKM: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)

•  Keep Let's look at the practicalities. Suppose I have a large or large-ish set of items, and I want to identify which of them have Commons categories. With P373, I just need the following in my SPARQL query:

      ?item wdt:P373 ?commonscat
  

  Without P373 I have to do something like the following:

      OPTIONAL {
        ?commonsCategoryFromItem schema:about ?item;
                                 schema:isPartOf <https://commons.wikimedia.org/>.
        FILTER(STRSTARTS(STR(?commonsCategoryFromItem), "https://commons.wikimedia.org/wiki/Category:"))
      }
      OPTIONAL {
        ?item wdt:P910 ?catItem .
        ?commonsCategoryFromCatItem schema:about ?catItem;
                                    schema:isPartOf <https://commons.wikimedia.org/>.
        FILTER(STRSTARTS(STR(?commonsCategoryFromCatItem), "https://commons.wikimedia.org/wiki/Category:"))
      }
      BIND(COALESCE(?commonsCategoryFromItem, ?commonsCategoryFromCatItem) AS ?commonsCategory)
  

  Yes, it's possible (eg: https://w.wiki/8hM).
  But (i) it's a hell of a lot to have to remember for quite a simple thing, especially for SPARQL newbies; and (ii) the code above is a real resource-hog and far more likely to time out, if one tries to apply it for groups of items of any size.
  To start with there is the schema:about / schema:isPartOf join. This compares to P373 which is very specific. For each ?item the fragment above starts with in its solution set, P373 will typically identify only a single commonscat for each one, leading to a solution set going forward with about the same number of rows (or slightly smaller, as some items won't have commonscats). In contrast, schema:about connects the item to every article about it, in every Wikipedia. That may immediately expand the solution set by a factor of 20, before then a huge join with the set of all pages on Commons to reduce it down again; then a per-set-member string operation (a further notorious source of slowness) to filter out galleries etc and select just for categories; and then having to do the whole thing all over again, in case it's actually a parallel category-type item that is what is actually sitelinked to the Commons category. If the group of items is of any size (or if one's trying to do a COUNT query, such as how many churches have Commons categories), all this is slow-slow-slow-slow, so very likely to make the query time out without completing its execution.
  I accept that maintaining all the P373 entries as a set of convenience statements is a pain. But it is something that bots can and do efficiently manage. The value of maintaining P373 is that it makes corresponding queries much easier to write, and makes a huge range of queries possible to successfully execute that would otherwise time out. I think that makes P373 worth keeping.
  The other point is that currently almost all Wikipedias are using P373 to identify which Commons page should be linked to from the sidebar of an article page to give a category page rather than an article page; so, also, some modules on Commons. With P373 this is a very easy look-up. Yes, implementing the logic above is possible (I believe some Commons infoboxes may do it); but how big a job to implement this in the MediaWiki code?
  So, for these two reasons, keep (and keep maintained). Jheald (talk) 21:27, 21 September 2019 (UTC)

  Interestingly, actually running the numbers, the performance hit isn't quite as bad as I'd anticipated; but all the same it can be considerable. For quite a large dataset, I find the join using the sitelinks and additional P910 path is about six times slower than the join using P373 :

  Count of the number of items in class church building (Q16970) https://w.wiki/8vi : 2.039 seconds. Count of corresponding commons categories using P373 https://w.wiki/8vj : 4.187 seconds. Count of corresponding commons categories using sitelinks, P910 etc https://w.wiki/8vk : 14.450 seconds.

  Pinging search guru @Lucas Werkmeister (WMDE): to see whether he thinks the comparison is fair, and whether he has any thoughts/comments. Jheald (talk) 20:35, 26 September 2019 (UTC)

  @Jheald: Well, that last query presupposes that the sitelinks stay as messy as they currently are, doesn’t it? I’m not sure what Mike Peel is proposing, but if for the sake of argument we assume that category pages are always linked to separate category items (which are created if necessary), then a simpler query becomes possible, which doesn’t perform that much worse than the P373 version (though it’s still somewhat slower). --Lucas Werkmeister (WMDE) (talk) 11:24, 27 September 2019 (UTC)

  @Jheald, Lucas Werkmeister (WMDE): The sitelink query is messy, and it would be good if there was a better way, but I don't think Commons category (P373) is it. Having separate category items for all Commons categories would work with the current system, but that would need a different discussion. For now, I'm proposing that we just use the system as-is and follow topic's main category (P910) and category related to list (P1754) as needed.

  Querying P373 may give you quick results, however it will also give you incorrect results as it's not 100% in sync with the sitelinks. See some of my recent edits here for bad P373 value that I've been removing - there are quite a few of them. As it currently stands, bots add new ones, and pi bot tries to fix obviously bad ones (e.g., non-existent or redirects to the sitelink), but more complex cases (like a link to a completely different Commons category than is in the sitelink) need human review, and that doesn't happen enough. We could program the bots to always keep P373 in sync with the sitelink, but that's a change from the status quo, and will probably cause friction as people mistakenly edit P373 instead of the sitelink.

  In terms of implementation, I mentioned above that Module:WikidataIB's getCommonsLink function can be used to provide the sitelink, following topic's main category (P910) and category related to list (P1754) if needed, and I think that's started to be used in other language wikis to replace P373, but there is still a way to go. For the link within MediaWiki, I've posted phab:T232927 - I don't think it should be a big issue, but the developers haven't replied there yet. I'd hope that a 'deprecated' stage would help give time for the transition. Thanks. Mike Peel (talk) 10:37, 28 September 2019 (UTC)

  An expression could presumably also be added to SPARQL to return the Commons category. Ghouston (talk) 01:43, 29 September 2019 (UTC)

  For a shortcut to the heavy English module see w:ca:Module:WikidataCommonsCat. I agree with Mike that P373 should be the last option. --Vriullop (talk) 11:42, 14 December 2019 (UTC)

•  Keep I was told that site links could link to whatever page on Commons. So if we can attach a commons category to the item, its important to describe it properly. More over, there are (an I guess they are attached to this property, not to the sitelinks (for common)) multiple technical reason, why it should be kept (so before potetional removal, these technicalities should be work out). E.g. interwiki links from Commons, to Wikipedia, category templates etc. --Juandev (talk) 10:21, 23 September 2019 (UTC)

  @Juandev: interwiki links from Commons you may simply use c:Template:Q, to Wikipedia is not necessary because each Commons categories already have em, do you have at least an opposite example? Hell no. category templates are ditto. Liuxinyu970226 (talk) 02:12, 11 January 2022 (UTC)

  See also Meta-Wiki m:Multi-wiki templates MediaWiki.org mw:Global templates proposal on using templates cross-wiki-ly. Liuxinyu970226 (talk) 02:14, 11 January 2022 (UTC)

•  Keep It is now the only (simple) way to access the Commons category which belongs to an article or subject. --RolandUnger (talk) 06:03, 7 October 2019 (UTC)

  The access via topic's main category (P910) takes unnecessary computing time because of the call of another entity. Moreover, in many cases topic's main category (P910) is not defined. -- RolandUnger (talk) 06:10, 7 October 2019 (UTC)

•  Delete Please deprecate and later delete this property once and for all, the commonscat links are sufficient for the intended purposes. Linking more than two commons categories is not useful and therefore no reason to keep this property. Steak (talk) 10:48, 10 October 2019 (UTC)
•  Delete Per above, especially per Liuxinyu970226. T54971 might be a better solution to fix What Multichill concerns. --2409:8902:9301:F7F8:1FC0:6702:8454:4E37 02:13, 30 October 2019 (UTC)
•  Delete Problemic property, should consider more smart ways instead. --2409:8902:9001:6CE0:5E2F:BCDA:B1D9:2A6F 00:22, 4 December 2019 (UTC)
•  Keep Per above. + We will have problems with automatic cross-project linking without this property. --sasha (krassotkin) 14:13, 17 December 2019 (UTC)

  krassotkin is now WMF Global banned, strike or not? Liuxinyu970226 (talk) 02:06, 11 January 2022 (UTC)

•  Keep Sitelinks have some advantages over P373. However they lack flexibility (unique values, etc.) and no standard seems to have finally settled the articles vs categories issue. Therefore, P373 is still a useful fallback.--Pere prlpz (talk) 11:14, 26 December 2019 (UTC)

  @Mike Peel: How do you think about Krassotkin's and Pere prlpz's comments? --Liuxinyu970226 (talk) 03:38, 20 June 2020 (UTC)

  @Liuxinyu970226: I think I've already answered the points by @Pere prlpz, Krassotkin: elsewhere in this discussion - primarily that there is a standard approach to using the sitelinks, and P373 is mostly just a duplication, or at best an indication of places where we need to improve our modelling here or the commons category structure. Thanks. Mike Peel (talk) 09:21, 21 June 2020 (UTC)

•  Delete no reason to single out Commons, use topic's main category (P910) Michael FV (talk) 03:32, 9 January 2020 (UTC)
•  Delete phab:T54971 solution should be enough, please also consider nominating Multichill for WD:RFP/R since that guy only keeps Wrong claims by themselves. --117.136.54.109 23:20, 20 January 2020 (UTC)
•  Delete Redundancy must die. — Mike Novikoff 23:50, 10 February 2020 (UTC)
• No comments for over a month, probably best to close this one as no consensus. Multichill (talk) 20:07, 24 March 2020 (UTC)

  @Multichill: Oppose It looks like the currently vote is 13:13:1, which looks rather like neither way are fair, but at least 3 deletion rationales pointed phab:T54971 and phab:T232927, which is, although tricky, two better ways that can finally kill all the P373 functions, so unless if both are declined officially, "close as no consensus" is also unfair. --Liuxinyu970226 (talk) 08:17, 1 April 2020 (UTC)

•  Delete Unnecessary and useless. -- MovieFex (talk) 04:32, 29 March 2020 (UTC)
•  Delete Deprecate and later delete (redundant; a lot of people with no experience with Wikidata are very surprized to find out that we have such fundamental mess in linking to Commons categories) Vojtěch Dostál (talk) 08:11, 31 March 2020 (UTC)
•  Delete Deprecate and delete. Two ways of linking is source for errors and confusion. MrProperLawAndOrder (talk) 17:44, 11 April 2020 (UTC)
•  Delete Deprecate and delete. It is redundant and it was very confusing when I found out there were two properties doing essentially the same thing. Many of the keep votes say it is not ideal but that we should keep it until a proper solution is in place. Deprecating and deleting is a path towards that outcome. Kees08 (talk) 17:46, 12 April 2020 (UTC)
•  Delete Deprecate and delete. Per Kees08 redundant and confusing. TechContribution (talk) 20:37, 30 April 2020 (UTC)
•  Delete Deprecate and delete. Galleries can use Commons gallery (P935) if necessary. Commons could even be given its own Sitelink if needed. The RedBurn (ϕ) 20:46, 2 May 2020 (UTC)
•  Delete There are ways to query better. --111.32.68.231 02:42, 9 May 2020 (UTC)
•  Keep - So far I have only seen claims that this property is redunant but not the proof that it is 100% redunant. Sure there is certainly some redunancy but that does not take away that down the stream this is quaranteed always the case. To my feeling I read above here mostly about that it gives double work as when a category is created or changed it has to be updated in two ways. I read only a little about that this property is one of the most extensively used properties in the various Wikimedia platforms. This is big! The use of this prorty has been widely adopted in use in the various platforms and this is something that can't be simple marked as redunant as that would imply big consequences for the complete Wikimedia ecosphere. The implications are large as this property forms the foundation of interproject linking. First deprecating the foundation and then starting to think about alternatives is the wrong order. If it is really redunant, first a full inventory needs to be made of all the possible issues that come up. Also the sitelinking of Commons galleries needs to be made obsolete, as it is still common practise that these get priority over Commons categories! That common practise needs to be deprecated first. Then a solution needs to be invented/created for all the possible issues that come up. For example both the category as the article on Wikipedia about that subject link to the same category on Commons. What to do with cases with one category on Commons, two articles on Wikipedia. And so on. In the previous discussions about deleting this property various reasons have been given why it is a bad idea to delete this property, and above here these reasons have not or insufficiently been addressed. Romaine (talk) 05:17, 30 May 2020 (UTC)

  @Romaine: Over the last year or so I've worked through, and resolved, thousands of cases where P373 is different from the sitelink. I have yet to find a single one that is not due to mismodelling on a Wikipedia; on Commons; or here. That's not a big surprise, though, as P373 is designed to smooth over those cases of mismodeling, and to provide a temporary shortcut that lets you link two different topics with a single commons category. The only reason it is "one of the most extensively used properties" is because it pretends to be a sitelink - which I think is the most used aspect of Wikidata. We already have alternatives - use the Commons sitelinks, and use the Lua code linked to above to find the correct one through linking properties such as topic's main category (P910). This already handles the sitelinks to Commons galleries without needing a change of approach to sitelinking them from here. What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them. If you want to test this, please point out some tricky cases that need resolving! Thanks. Mike Peel (talk) 18:45, 5 June 2020 (UTC)

  Hi Mike Peel, Over the past years I also worked on resolving thousands of cases of issues with P373. So I am fully aware of the troubles with it. I agree that it is one of the most used properties because it pretends to be a sitelink, but I also disagree with that idea. The main principle of a sitelink is that there is a one to one an item on Wikidata and a category on Commons. For many subjects this is the case, but also for many subjects this is not the case. Over the past month (but also many times before that), I have come acros thousands of subjects that do not have a one to one Wikidata-Commons situation. So no, Commons sitelink is in many cases not an alternative. That is even worse than I thought before! I think it is even worth to investigate if it would be possible to abbolish Commons sitelinks in Wikidata (certainly for categories) (because sitelinks only allow a 1 to 1 support, all other data is not allowed), and move all the functionalitis that the Commons sitelinks provide to Commons/Wikipedia/etc, to the P373 property. Another alternative is that the Commons sitelinks are redesigned, but that is something I am hoping for more than a decade (as even before Wikidata existed this was already a problem to deal with in Wikipedia).
  "find the correct one through linking properties such as topic's main category (P910)" -> This is just one of the cases where this might be a solution, but there are various other situations to that have no solution. On this page I see no solutions offered to those, which is I think highly problematic. In Dutch we have a saying that people should not throw away shoes befre you got new ones. That is what is happening here.
  "What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them." -> Just alone for rijksmonuments in the Netherlands, almost every single municipality in the Netherlands has cases of for example even 18 items on Wikidata with only one category on Commons. So speaking about "not many of them", in percentages almost everything is small compared to millions.
  "If you want to test this, please point out some tricky cases that need resolving!" -> This is turning it around. You want to change something, then you need to come with the solutions. Most Wikidata uers have no idea that discussion is going on here, and will highly likely influence there work. Then expecting that the majority that is not present here comes with the tricky cases, that is not the way to work.
  What you are basically asking is just to go forward, without making sure you have the solutions in place first.
  Also that you minimalise the number of cases you think you would get, I would say underestimate, is a bad approach. With this kind of gigantic changes, decisions need to be based on facts and not on imagination. The simple thing that the number of cases involved is still not counted is troubling. In my previous message I wrote that as this property has usage in gigantic propertions, an inventory should be made. On this page I do not see such a thing happening (asking for examples is turning it around and is not an inventory). To me this feels like the issues that have brought up by various users are not taken seriously. The issues addressed concern situations that are not just simple (small) cases, but represent a large structural mismatch.
  I am also concerned about what has been done with my previous post from 30 May 2020. In there I made a first basic analysis of the situation. Also that has been ignored. As both the analysis and issues raised by users are not addressed first, this discussion is walking in a dead-end street and can only have one outcome: proposal rejected. Romaine (talk) 07:49, 12 July 2020 (UTC)

  @Romaine: From my experience, there are three types of items that need to link to the same Commons category - 'topic', 'list' and 'category' items (or maybe four, if you include 'categories of lists'). I think those are well modeled with the category/list linking properties. All of the other cases I've come across have been due to mis-modelling either here, on a Wikipedia, or on Commons - part of why I was asking for illustrative examples where this wasn't the case. Abolishing Commons sitelinks would be impossible now, as there is no other way to provide a bi-directional link between Commons and Wikidata, and copying QIDs around rather than using the sitelinks would create a maintenance nightmare that the auto-updating of commons categories avoids. For Rijksmonuments, I think having a container category for them works well, but if you're using Wikidata lists then you could automatically use the sitelinks the same as using P373 (also relevant to this point is the de-voy discussion below). I think the solutions already exist, otherwise I wouldn't be supporting this PfD so emphatically - and again, asking for cases where the solutions don't work. I hope that the Wikidata modelling is not so inflexible that a temporary fix introduced in 2013 *has* to continue into the future indefinitely. Thanks. Mike Peel (talk) 20:41, 13 July 2020 (UTC)

•  Keep - I don't deny that this property is confusing (especially for newcomers) and it's an ugly kludge, but given the fact that it's virtually impossible to do proper SPARQL queries without it, many things will break if we remove it, and many other things mentioned above (like the gallery / category problem) we can't really remove this property. Husky (talk) 23:07, 4 June 2020 (UTC)

  @Husky: There are work-arounds for SPARQL queries that were described above, although they could definitely be made simpler to use. The gallery/category problem is already solved from a sitelink perspective. I'm proposing a period where the property is deprecated, can you help solve the issues that might be caused by the property being deleted, please? Thanks. Mike Peel (talk) 18:48, 5 June 2020 (UTC)

•  Delete this property has always been an outlier and with the other sites link its now redundant and frankly highly confusing. EoRdE6^{(Come Talk to Me!)} 03:53, 12 June 2020 (UTC)
•  Keep Many uses, a lot of things would break and this is a really useful thing.--Ferdi2005_[Mail] 11:25, 9 July 2020 (UTC)

  @Ferdi2005: Yep, anything that impatient for Wikidata should always keep permanently, aren't they? Liuxinyu970226 (talk) 04:23, 11 January 2022 (UTC)

•  Keep causes too many problems for me to support deletion. Every issue needs to be addressed before deletion, as this is used a hell of a lot and will cause crosswiki issues. --IWI (talk) 17:14, 6 September 2020 (UTC)

  I would rather consider reasons like this are not valid keep reasons, but orphaned for our purposes. Liuxinyu970226 (talk) 04:25, 11 January 2022 (UTC)

•  Keep There are many occasions where a pairing category item exists so the (re-)use of the interwiki is not possible as it is used elsewhere. It needs to remain, and it needs to remain active and undeprecated.  — billinghurst sDrewth 05:48, 14 September 2020 (UTC)

  @billinghurst: Can you give some examples, please? Thanks. Mike Peel (talk) 08:40, 14 September 2020 (UTC)

  @Mike Peel: Something like Category:United States (Q1410960). I regularly do a merge/cleanup where I move the Commons category interwiki to the Category: item from the topic-item, ensuring we have the CommonsCat on the topic-item and adding the Topic-Cat: property. And over time I have also seen numerous species and redundant species names (whatever they are called) where the CommonsCat is on both items. [I don't remember maintenance activities specifics].  — billinghurst sDrewth 14:48, 14 September 2020 (UTC)

  @billinghurst: I think the cases like Category:United States (Q1410960)/United States of America (Q30) are already solved by following the topic's main category (P910)/category's main topic (P301) links, if not then they normally just need cleanup so they are properly linked, they don't really need Commons category (P373) except as a convenience shortcut. Thanks. Mike Peel (talk) 15:42, 14 September 2020 (UTC)

•  Keep for now. Removing P373 makes the querying the commosncat via SPARQL-queries and API queries one magnitude more complex. Rationale for removing the P373 is that there is no fast method for querying the commonscat backlink from Lua (= queries like this is my P373 value, what is my Wikidata ID? ) this could be fixed by adding relevant function to scribunto. Second problem is that the P373 values arent automatically updated when category is moved. This could be handled by bots like the double redirections are tracked and updated. --Zache (talk) 07:48, 7 January 2021 (UTC)
•  Keep This property is needed in order to show a link to the Commons category in the sidebar on Wikipedia and other projects when the category is linked in another item (see this discussion), at least not until phab:T232927 is resolved. --Thibaut (talk) 06:40, 20 May 2021 (UTC)

  @Thibaut120094: That function, if I remember correctly, has nothing to do with P373, that's just a cross-wiki link sidebar that match such links with language(s) you speak, this means even we don't use this property, we can also see that thing, unless you disable it via Special:Preferences, that sidebar remains when necessary. --Liuxinyu970226 (talk) 00:26, 13 July 2021 (UTC)

  I’m talking about this, it does show a link to the Commons category entered in Commons category (P373) of the linked item, it’s useful since we can’t add Commons categories as sitelink in items that are not categories (like a Wikipedia article).

  And "P373" is literally in the name of the Phabricator task. All of this is better explained here and here. --Thibaut (talk) 01:18, 13 July 2021 (UTC)

•  Speedy keep Widely in use, namely in Module:Authority control (Q11640331) in more than 100 projects, including Wikipedia, Wikisource, and others. This should be discussed at the Village Pump/Café on those projects before taking actions! --Amitie 10g (talk) 17:49, 29 May 2021 (UTC)

  @Amitie 10g: The discussion started in 2019, there's nothing speedy about it now... There is drop-in replacement Lua code available that can easily be used to replace existing uses, it's already in use on enwp (en:Template:Commons category for example). Thanks. Mike Peel (talk) 13:04, 9 July 2021 (UTC)

•  Keep for now, according to multiple arguments above. Peter17 (talk) 17:48, 19 July 2021 (UTC)

  @Peter17 If you think Per-above-ism is good for you, keep all properties per above, not just this one and delete others, then I think this WD:PFD page can be deprecated Liuxinyu970226 (talk) 07:58, 1 November 2021 (UTC)

Discussion (remaining issues)

I have a  Question for those that have !voted keep or similar (pinging @PKM, Esquilo, strakhov, Closeapple, JAn Dudík, Ghouston: @Slowking4, Kaldari, ŠJů, Multichill, Ksc~ruwiki, Jklamo:@Roy17, Matěj Suchánek, Gamaliel, Jheald, Juandev, RolandUnger:@Krassotkin, Pere prlpz, Romaine, Husky, Ferdi2005:). Please can you provide some examples where we still need Commons category (P373) rather than just using the sitelink (via topic's main category (P910)/category related to list (P1754) as necessary)? I think this issue mostly comes down to the inconvenience for SPARQL queries, and the need to sort out the sidebar links via phab:T232927, but are there data/other software issues as well that still need resolving? If there are, I'm happy to attempt to resolve those issues. Thanks. Mike Peel (talk) 21:44, 11 July 2020 (UTC)

• @Mike Peel: The doubleness is unwanted, however the core problem is that we often have 2 Wikidata item pages for 1 item (the first one for article links, the second one for category links of the same item). To link the two item pages mutually is complicated. The system solution would be to merge these pairs (eg. Music and Category:Music, or Paris and Category:Paris). But unfortunately, we must be realistic and accept that this right solution is unenforceable in the near future. If the creators of Wikidata did not think of this at the beginning, it will be very difficult to fix it later. But even if this will resolved, some complicated relations will remain: e.g. Painting vs. Category:Painting vs. Category:Paintings vs. List of paintings etc. We should have realized from the beginning that there are two main types of categories: "item categories" and "group categories". The creators of Wikidata had little experience with Commons, so they got the idea from Wikipedia that a typical category is a "group category", a and so they did not notice existence of "item categories" which are typical with singular names. "Item categories" (typically "singular categories") should be joined directly to the item page of their item. "Group categories" ("plural categories") are a different problem which can be treated in another, more analytical way.
  A sitelink is definitely more practical and more functional than just properties. The problem is that in some cases a sitelink is not available directly, but only through properties (P910, P1754, possibly other similar) as a sitelink of another item – and in these cases it is less accessible and less useful than P373. It is therefore not possible to call this entry by a simple link/expression. Thus, P373 translates the indirectly accessible data from the sitelink so that it can be understood even by simple templates, links and infoboxes. If we manage to implant any simple tool directly into the Mediawiki that can replace it, then we can leave and delete P373. Ideally, the remote indirect sitelink from the linked sister item page would appear and behave as if it were a direct sitelink. So it is necessary that the sitelink is really common to both item pages of the item. The easiest way to do this is to merge these pairs of item pages. All other solutions would be just a replacement, unnecessarily complicated and not fully functional. --ŠJů (talk) 22:44, 11 July 2020 (UTC)

  @ŠJů: I broadly agree with you. I generally think that there are three types of items here - I tend to talk about "topic" items, "category" items, and "list" items. I tried to explain that at User:Mike Peel/Commons linking (I should have linked to that above). It would be great if items did allow multiple sitelinks to the same wiki, and then they could be merged, but I understand that it was a deliberate design decision when Wikidata was started. It is easily possible to use Lua to cross between items using topic's main category (P910)/category's main topic (P301)/list related to category (P1753)/Template:P3754 - but it would be really nice if that could somehow be built into MediaWiki/Wikibase. Perhaps you could open a phabricator ticket for that? I don't agree that it should be a prerequisite to removing P373, though, since there is a workaround, and it's not that hard to implement. We could get into whether it's less or more functional than P373 if you want - I'd argue that the sitelinks give the 'right' answer more often now. Thanks. Mike Peel (talk) 20:09, 13 July 2020 (UTC)

• The approach I see here is problematic. This property is one of the most used properties, not just on Wikidata but in the entire Wikimedia ecosphere. Then I read here that only to less than 0,000001 % of the people involved is asked for input, while it effects almost every single community and Wikimedia wiki. With asking for examples, it is like it is talked about a property that is used only on a 1000 items. This is underestimating the problem and a clear sign that the problems addressed by various users is not taken really seriously. What is needed is a structural in depth inventory how any decision regarding the deprecation of this property will effect the entire ecosphere (and beyond?). Asking for "examples" to a selected group is a way to stimulate the bias to grow that there is no serious problem and all the opposal can be waved away. Also focussing on "examples" would cause to miss the structural problems that are shown by examples that just form the top of the iceberg. Romaine (talk) 08:20, 12 July 2020 (UTC)

  @Romaine: This is the standard venue for the discussion of properties for deletion, I'm not sure there's a better place elsewhere. I'm happy for more people to be pointed to this discussion, although on enwp that might count as 'canvassing'. I'm well aware of how widely the property is used - in terms of numbers, I'm to blame for the infobox on Commons that displays Wikidata information in over 3 million categories, and the work to add more Commons category sitelinks for that has indirectly doubled the number of P373 values (compare 1.4 million in 2017 to 2.9 million now). I've also mostly deprecated the use of P373 on enwp, and made a lot of automated edits to P373 along with the sitelinks via pi bot. If there is a structural issue that has not been covered here, then I'm missing it, and that's why I asked for examples of 'data/other software issues'. If you want an inventory that is more extensive than my personal experience from the last few years, how can we go about doing that? Thanks. Mike Peel (talk) 20:29, 13 July 2020 (UTC)

• For the most part I’ve stopped using this property, and i have no objection to deleting it. - PKM (talk) 23:15, 11 July 2020 (UTC)
• @Mike Peel: P373 and other properties are considerably used in vCard and Marker templates at the German Wikivoyage to present additional resources from other Wikimedia wikis -- including the Commons category -- among other information for different locations and institutions. The count of these template calls exceeds sometimes 250 times per article as can be learned from articles like Halle (Saale). There are some heavy restrictions to use Wikidata for this aim. We are calling (or trying to call) only one Wikidata entity per template call because the number of Lua Wikidata entity calls per article is limited to 400. That's why a lot of tables, for instance for P31, country, language, feature and currency data, are prepared to prevent using Wikidata. The other restriction is the computing time which is restricted to 10 seconds. Getting Wikidata entities is expensive. To get an imagination: The Lua computing time for the article mentioned takes about 1.5 seconds only for getting the entities (about 5 seconds in total for more than 250 templates). If we would get all data from Wikidata it would take about one minute and more. For comparison, usually one call of a Wikidata infobox at Commons takes three seconds.
  Commons links cannot be prepared in advance. We have only three ways to get the Commons categories: (1) from P373, (2) from sitelinks, and (3) from P910. The third way is time consuming/expensive (Lua computing time increase of about 30 per cent) and reduces the count of template calls by half and is therefore not applicable -- because of calling additional entities. Way 2 is only sometimes applicable if the Commons sitelink contains a category and not an article link. Unfortunately nobody thought of a separation of main space and category namespaces. This way is alternativly used in our templates. The first way is the only one which gives direct access to the Commons category.
  The next cause is why we should have two Wikidata items for one thing. There are about 100 millions Wikidata entries but only 5 millions English Wikipedia articles. For many items like hotels, restaurants, and so on there will be never a Wikipedia article but two Wikidata entries: one for the institution itself and a redundant one for its category because there are images at Commons.
  I am in direct contact with the programmers of the Wikibase API. But it seems the a further (drastic) computing time reduction is impossible.
  I assume that many voters for deletion never thought of the (comprehensive) usage of Wikidata data in articles. --RolandUnger (talk) 06:53, 12 July 2020 (UTC)

  @RolandUnger: Performance is an issue, I think this links in with the sparql query issue above too. I think de-voy is an extreme example of Wikidata use, but we have seen similar things with the Commons Wikidata Infobox recently too for complex items. I'm not sure it takes that much more resource to check the commons sitelink (which you're probably loading anyway), and if it's not to a category, then look up P910 and find the commonscat from there (you wouldn't need to check P373 any more). This wouldn't need to always be done, since the commons category is often with the topic item unless a commons gallery or other project category items exists (which links to your 'two items for one thing' point - normally there only needs to be one topic item that links to the commons category). I suspect the best solution in this case is to increase the allowed number of Wikidata entity calls and computing time for de-voy, if the performance really can't be improved further on the server side. I generally think the human cost of keeping P373 updated/in sync with the sitelinks outweighs the extra server time. Thanks. Mike Peel (talk) 19:50, 13 July 2020 (UTC)

  • For overlaping geographic objects. Example: Stendörren (Q55244845) and Stendörren nature reserve (Q10678413). Or Angödrommen (Q10411885) and Angödrommen nature reserve (Q30162836). An alternative is to merge them, but that would be conterproductive.
  • For submodels that does not have their own Commons category. Example: J 35A Draken (Q75226692) and Saab 35 Draken (Q461475). Or F-106A Delta Dart (Q76376752), F-106B Delta Dart (Q75211465) and Convair F-106 Delta Dart (Q753808). Maybe the Commons categories should be further subdivided, but it is a bit tiddly with a deep category tree with just one or a few files in each.

  Since Wikidata is more granular than Commons it is inevidable that there will be cases where multiple Wikidata objects are related to one Commons category. /ℇsquilo 08:24, 12 July 2020 (UTC)

  @Esquilo: I think in those cases, it makes sense to have separate commons categories, if there are enough photos. For the first set, see e.g., commons:Category:Yorkshire Dales vs. commons:Category:Yorkshire Dales National Park. For the second set, if they only have one photo, then it probably just needs a image (P18) value, but if there are multiple then why not have a commons category? I know aircraft photos in particular tend to be very tightly categorised by model on Commons, for example see commons:Category:de Havilland aircraft. Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)

• Generally, I don't oppose getting rid of this property (due to redundancy) if all concerns are claimed resolved or negligible. There are just matters which simply need to be considered with regards to the users of data (cf. the point I made about the sidebar). For the infoboxes and templates issue, each wiki has different attitude, though. For instance, cswiki uses w:cs:Modul:CommonsLink which is used in templates to fetch "commonscat" (or gallery) instead querying P373 or the sitelinks directly (the module decides where to look). Such design principle (cf. w:Separation of concerns) only requires changing one thing when Wikidata decides to change. --Matěj Suchánek (talk) 11:32, 12 July 2020 (UTC)

  @Matěj Suchánek: It looks like cswiki uses a similar approach to enwp/commons, that's good. Can you help convert other modules on cswiki and similar language wikis? Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)

  When necessary, I can weigh in. But naturally this change would demand prior communication. --Matěj Suchánek (talk) 09:20, 15 July 2020 (UTC)

• P373 is redundant, but there is a clear use case (give me a Commons category of the topic). Note that even the list at Property_talk:P373#Documentation of 100+ wikis and 1000+ templates is incomplete, usage is higher. Algorithmic P910-sitelink/sitelink way (caused by bad prior galleries sitelinking decision) is complicated and resource-intensive, while using P373 is simple.--Jklamo (talk) 12:37, 12 July 2020 (UTC)

  @Jklamo: Agreed it's simpler, and agreed it's redundant. Disagreed that it's complicated to check through P910 and sitelink - this is routinely done by en:Template:Commons_category and the one pointed out just above this. There are many uses, but those will only increase while this shortcut is still active, deprecating it would lead to a reduction of them. Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)

• @Mike Peel: There are some issues which complicates using only commonscatlink:
  • I recently tried to make some tables by listeriabot and P373 is much easier for getting than commonscatlink. So there should be some way for obtaining this link in one step like property.
  • And second problem is 1:1 - is almost impossible to have link to commons in all items where is now P373 only with sitelinks and P910 (and similar).
    • e.g in wikipedia is one article for museum (school, company...), but in Wikidata there are usually two items - institution and building. Article on Wikipedia is more often about institution, but in commons there are images for building.
    • Similar case is municipality which consists from more villages, but one of them have same name as municipality. Is some wikis there are two articles, in some one article, but usually both with the same commonscat.
    • Next case - protected area/another protected area/hill(pond, forest) with same name both located in same place but not necessary with same area.
    • Another cases - street, which is located on two different municipalities, village, which is divided in two municipalities... usually both have same commonscat
  • So there is not only topic's main category (P910), but also category related to list (P1754), said to be the same as (P460), coextensive with (P3403), partially coincident with (P1382), uses (P2283), occupant (P466) and probably some others for searching correct commonscat withou P373.
  JAn Dudík (talk) 06:01, 14 July 2020 (UTC)

  @JAn Dudík: In turn, (1) This is the sparql issue. It is possible to access the sitelinks (there was some example code to do this above), but it is more complex. (2a) Ideally in those cases we would have media for both the institution and the building - e.g., pictures of the people that work there, historical documents, etc. That's fine on Commons, and they may also have separate Wikipedia articles If they aren't notable enough to have such media/coverage, perhaps we shouldn't have separate items for them here at the moment. (2b) I think these need separate commons categories, one for the municipality and one for the village, otherwise we should probably default to linking them only from the municipality unless we're sure that the images are also only of the village (in which case having them in a separate category helps others realise that too). (2c) This is tricky, perhaps it can be solved via topic's main category (P910) as per the question below. (2d) If it's a single street, shouldn't it have a single item? BTW, in general we have the same problem with linking to Wikipedia articles in these cases, but Wikidata doesn't have a separate string property to do that. Thanks. Mike Peel (talk) 19:19, 15 July 2020 (UTC)

  Example of street which is divided into two municipalities Plavská (Q43535204) and Plavská (Q44761879). One part of this street is in city, second on the borders (every side of street is another municipality) and third in village. I know about situation that all street Hraniční (Q46214250) is in one municipality and the second Hraniční (Q46146535) have only houses with address in that street. But this virtual street have its own ID in street register, so merging is not the best solution.

  Problem with institution/building is primary Wikipedia problem, often tehre is one article about both. And often there are only photos of building, but article is about institution.

  There is also problem with topic's main category (Property:P910) which have property constraint (P2302)=distinct-values constraint (Q21502410). JAn Dudík (talk) 20:16, 16 July 2020 (UTC)

  @JAn Dudík: Are the streets physically connected, or separate? Personally I still think the best option is to merge them, if separate commons categories aren't appropriate, I don't think there's a problem with having multiple Czech street ID (P4533) values. Similarly, I think multiple topic's main category (P910) values are OK in exceptions like we're discussing here (and better than having P373), but generally there should only be one P910 value, so the constraint mostly makes sense. Thanks. Mike Peel (talk) 15:30, 18 July 2020 (UTC)

•  Comment @Mike Peel: Although I don't vote keep, neither vote delete here, I'm doubting that how to resolve things where duplicated Commons category (P373) values are really required for two and more items, as a pair of example: Transnistria (Q907112) , Transnistria (Q3537754) and Administrative-Territorial Units of the Left Bank of the Dniester (Q648767), currently all 3 items are pointing P373 to c:Category:Transnistria. --Liuxinyu970226 (talk) 11:56, 14 July 2020 (UTC)

  @Liuxinyu970226: This one is complex, good example. The best way I think this can be solved is through topic's main category (P910). The first two already used that to link to Category:Transnistria (Q8414718), I've done the same for the other and the inverse now. Does that make sense? I don't completely like this solution, but I think it's better than P373. Thanks. Mike Peel (talk) 19:19, 15 July 2020 (UTC)

• @Mike Peel: Instead of thinking outside the box, how about we throw the box out of the window?
  • Create new properties "Page on Wikipedia", "Page on Wikisource", "Page on Wiktionary" etc
  • Make those accessible through mw:Extension:Wikibase Client/Lua#mw.wikibase.getEntityIdForCurrentPage
  • Delete sitelinks entirely (..AFTER existing sitelink data has been copied to the new properties)
  • Use P373 for w:en:Template:Commons category etc
  — Alexis Jazz (talk or ping me) 02:40, 21 July 2020 (UTC)

  That would indeed make things more uniformly awful and unusable - it would no longer be a Commons-specific problem, *everyone* would have problems... Thanks. Mike Peel (talk) 08:10, 21 July 2020 (UTC)

  @Mike Peel: I see absolutely no reason why sitelinks can't be properties. If needed they could be presented to the user the same way sitelinks are currently presented, while internally working as a property. — Alexis Jazz (talk or ping me) 15:34, 21 July 2020 (UTC)

  @Alexis Jazz: Oh, you were serious? The problem is that properties are one-way - you can go from the Wikidata item to the linked page, but there's then no way to go backwards from that page to Wikidata. That's what sitelinks enable. Even if you could somehow recode properties to have those backlinks, how would you then handle cases where there are multiple backlinks to different Wikidata items? I just don't think what you're suggesting is possible. Thanks. Mike Peel (talk) 16:24, 21 July 2020 (UTC)

  @Mike Peel: How about redirects? Create a new namespace and have, for example, Sitelink:enwiki/Paris–Rouen (motor race) with "#REDIRECT[[Q1089270]]" as its contents. When a user adds a link to an item for that same page with a higher priority than the existing link, replace it. So one item could have the "Article on Wikipedia" property using high priority to become the sitelink while other items could have the same page in the "Article on Wikipedia" link with a lower priority. As an example, w:fr:Les Schtroumpfs (an article that describes both the Smurfs as a franchise as well as the comic book series) can be on Q11221 (the franchise) with high priority so mw.wikibase.getEntityIdForCurrentPage will return that when requesting the ID for that page. But it can also be added to Q4537599 (the comic book series) with normal priority. This wouldn't change the interwiki on frwiki, but now on w:en:The Smurfs (comics) there will be a usable interwiki link to frwiki, where currently there is none! This would also allow adding multiple article links from the same wiki to a single item. You could actually add a Commons category with high priority and the Commons gallery with a lower priority. Dream big. — Alexis Jazz (talk or ping me) 00:46, 22 July 2020 (UTC)

  @Alexis Jazz: It sounds like an overcomplicated solution. In particular, I really want to avoid manual QIDs being copied everywhere, as they are a nightmare to manage - much better to use sitelinks that auto-update, or keep the QIDs in structured data where bots can easily update them. What really annoys me here is that we *already* have a system that works well - just use sitelinks and topic's main category (P910)/category's main topic (P301) - everything beyond that, including Commons category (P373), just complicates things unnecessarily. Thanks. Mike Peel (talk) 18:49, 24 July 2020 (UTC)

  @Mike Peel: My suggestion does not require manually copying QIDs. The sitelinks work, but not well: there are many cases where we want to add more pages to one item or one page to multiple items. — Alexis Jazz (talk or ping me) 19:04, 24 July 2020 (UTC)

• I would love to just mark P373 as (DEPRECATED), but take much more times before the actual deletion, anyone oppose me? --Liuxinyu970226 (talk) 11:31, 25 July 2020 (UTC)
• @Liuxinyu970226: one month and half later, no comment. Go ahead :) Pamputt (talk) 06:58, 12 September 2020 (UTC)

  That's wrong. See comment in the section above.--Ksc~ruwiki (talk) 19:50, 13 September 2020 (UTC)

  @Ksc~ruwiki: Per which above? --Liuxinyu970226 (talk) 22:30, 1 October 2020 (UTC)

  All after 12 September 2020. --Ksc~ruwiki (talk) 18:31, 2 October 2020 (UTC)

  Sorry, since 25 July 2020. --Ksc~ruwiki (talk) 20:48, 3 October 2020 (UTC)

  @Liuxinyu970226: I would love to see that happen. I estimate that it would take 6-18 months after deprecation before the property was ready for deletion - while a bot can do most of the work (where P373 matches the sitelink) it will depend on how many cases need manual attention. Thanks. Mike Peel (talk) 18:41, 26 September 2020 (UTC)

•  Delete per Mike Peel. NMaia (talk) 10:23, 17 September 2020 (UTC)
•  Keep as long we don't have any better way to link commons, it should do. --opensofias (talk) 11:36, 21 September 2020 (UTC)

  @Opensofias: But we *do* have a better way to link to Commons, we have the sitelinks, and all of their auto-update and two-directional access goodness. We don't need this temporary non-updating and one-directional property any more. Thanks. Mike Peel (talk) 18:38, 26 September 2020 (UTC)

  @Mike Peel: if gallery pages were retired and those sitelinks would all go to categories, or there would be a seperate kind of sitelink specifically for categories, then that would make the property obsolete (as far as i'm concerned, anyway). tho burying all of Commons under "other sites" would still be kinda suck, i'd prefer if it were it's own kind of sitelink (along with Wikipedia, etc) --opensofias (talk) 22:04, 27 September 2020 (UTC)

  @Opensofias: I think Commons galleries are a distraction here - even if they were gone, then we still have both articles and categories on the Wikipedias to handle. That's why the setup of having the Commons category link on the category item if it exists, or on the topic item if it doesn't, works quite well. Code can follow the category's main topic (P301)/topic's main category (P910) links to find the appropriate Commons link. Where there are galleries, we can just create category items to work around them. Agreed that it would be better if the sitelink wasn't under 'other sites'! Thanks. Mike Peel (talk) 17:43, 29 September 2020 (UTC)

  New vkers @Ferdi2005, ImprovedWikiImprovment:, no comments to this better way? Why don't you consider changing your votes? --Liuxinyu970226 (talk) 02:48, 27 September 2020 (UTC)

  I'm not satisfied that issues will be fixed, as stated above. Please do not ping me here asking me to change my vote, just because you do not agree with it. You have already opposed a no consensus close and now you are trying to encourage the keep voters to change to delete. I don't feel I have anything to add here (my views very much mirror those of ŠJů above), which is why I had not commented. My position is keep. You can ping me with questions, but pinging me saying "why don't you consider changing your votes" is not good in my opinion. Maybe I'm misreading you somewhat here. --IWI (talk) 03:10, 27 September 2020 (UTC)

  @ImprovedWikiImprovment: I think your concerns are really bugs to fix by developers, rather than something we must "keep" something, that's why I would support phab:T54971 solution than keep this property, since this is really not only a Commons bug, but also a Northern Min bug, a Hakka bug, a Ladino (aka Judaeo-Spanish) bug, ... and even, a Wikidata bug. --Liuxinyu970226 (talk) 21:26, 27 September 2020 (UTC)

  And, about the small wikis, please can someone why says "keep P373 because small wikis will lost their values" watch up the m:Small wiki audit? Small wikis can be problemic even by keeping this property. --Liuxinyu970226 (talk) 21:41, 27 September 2020 (UTC)

• All of the issues discussed in the last months were either answered by Mike Peel, or they are concerns about the transition process from P373 to sitelinks. However, it was explained many times already that the property will NOT be deleted on the spot - on the contrary, it will be DEPRECATED and only deleted *after* all the transition issues are addressed. Everyone please keep this in mind. And if we fail to address some of the issues, we can always de-deprecate it. I'd suggest closing this proposal as there are no new arguments. All has been discussed and explained a hundred times. Vojtěch Dostál (talk) 14:42, 5 November 2020 (UTC)
•  Very strong keep unless there is a suitable solution for the Wikidata Infobox within taxa categories in Wikimedia Commons. Currently, the navigation links available in the infobox for the parent taxa are provided by this property, why we used this property? because a lot of sitelinks for taxa lead to galleries and not categories. Indeed if you manage to come to c:Category:Lepidoptera when you are in c:Category:Idea leuconoe and that you click on "Lepidoptera" within the infobox, its thanks to P373, because the sitelink in Lepidoptera (Q28319) a gallery page. Christian Ferrer (talk) 14:00, 24 December 2020 (UTC)

  @Christian Ferrer: See commons:Template_talk:Wikidata_Infobox#P373. This was something I was planning on tackling after deprecation of P373, but it can just as easily be sorted out now. Thanks. Mike Peel (talk) 19:59, 25 December 2020 (UTC)

  Ah ok, thanks, I have no specific reason to oppose if my concern can be fixed. Good holidays! Christian Ferrer (talk) 20:11, 25 December 2020 (UTC)

• How the 1:M relations should be modeled on wikidata? Ie. cases where the granularity in Wikidata is much higher than in Wikimedia Commons. (Example https://w.wiki/ryz ; a railway station consisting of several protected buildings with their own wikidata items and all are pointing to the same commons cat. ). --Zache (talk) 01:36, 26 December 2020 (UTC)

Part 3

So, there's good news! phab:T232927 now uses the sitelinks first, and only falls back to P373 where there are no sitelinks available. So this issue is now cleared (pinging those that raised this in their !votes: @Matěj Suchánek, Thibaut120094, Jheald:. Also note that 'other sites' is now 'multilingual sites'. The only major issue I see remaining is that it takes a lot longer to query sitelinks than P373s - I'm not sure what a good solution is there. Is easy queryability worth the extra maintenance burden (and load on servers for an extra 3m+ triples) or not? Up to you. There's also the usage on other wikis, but I don't think they'll seriously start migrating until we mark this as deprecated here (while noting that this isn't an ask for a fait accompli - the decision could be reversed at any time until the property is actually deleted). I really do want to see this closed soon one way or the other, as the uncertainty over this property paralyses progress (particularly with: should we start bot-removing P373, or bot-syncing P373 with the sitelinks). Thanks. Mike Peel (talk) 18:16, 30 October 2021 (UTC)

• (I drafted a much longer reply to this at User:Mike Peel/P373 - but decided that would be too much text at this point of time! Thanks. Mike Peel (talk) 18:42, 30 October 2021 (UTC))
• Deprecate P373, with full understanding of how complex this will be. It might be easier if a consensus could be developed on commons that commons categories should be linked to topics and not other categories. — Martin (MSGJ · talk) 11:24, 1 November 2021 (UTC)
• Nothing need to explain more, just  Support marking DEPRECATED. Liuxinyu970226 (talk) 12:16, 1 November 2021 (UTC)
•  Keep – P373 must not be discarded. --Gymnicus (talk) 18:21, 5 November 2021 (UTC)

  En, and every properties must also not be discarded, even created by former LTA creators, every properties have functions on every parts, we even shouldn't have WD:PFD page, right?! Liuxinyu970226 (talk) 01:35, 11 January 2022 (UTC)

•  Keep it'll ne used while multiple use of same category for more as one datarecords. --Derzno (talk) 12:00, 27 November 2021 (UTC)

  @Derzno: datarecords mean what? SPARQL? Then let's continue reporting via Phabricator, as it still has bugs regareless deprecating P373 or not. --Liuxinyu970226 (talk) 01:37, 11 January 2022 (UTC)

  @Liuxinyu970226: here an example. In commons many times the same subject has been used for similar objects like a mountain. This mountain could be the mountain by himself, a protected area named by the hill and possibly a inn on the top as well. All are in the same area and in the same cat in commons but definately all are not the same subject. Than you can use P373 for all three items but only once as "master" showing the infobox in commons cat. --Derzno (talk) 05:13, 11 January 2022 (UTC)

  Still, a bug pending reporting to Phabricator, not a panorama that can lead P373 permanently kept. Liuxinyu970226 (talk) 06:04, 11 January 2022 (UTC)

  @Derzno For your matter, I suggest you to propose splitting via c:COM:CFD. Liuxinyu970226 (talk) 13:48, 11 January 2022 (UTC)

  @Liuxinyu970226 Unfortunately this proposal doesn’t work in many cases. I’m working on cultural heritage monument (Bavaria) based on a structure given by the official public departments. In many cases we only have one picture is available (with the hope to getting more over the time). Not good but in the meantime accepted to provide one cat for such single pictures while following a common look and feel structure. The cat structure show in many cases only one picture for different items like a house, barn, wall or whatever having all own datarecords in wikidata. In this case the same picture will taken for all listet datarecords together wit P373. One record will be stay as the “master” with the wikidata infobox only. All others get only with P373 link related to this category. You can’t cut down again and again for one picture cats for the same picture . This blow up zero content and will be not accepted from people working day by day with cultural heritage monuments in commons. --Derzno (talk) 06:28, 15 January 2022 (UTC)

  @Derzno There are indeed situations where you want to link several items to the same Commons category (although I am not sure if that is true for your use case). Anyway, in such cases, you can easily link from all them using topic's main category (P910), as was suggested above by Mike. Did you consider this option? Vojtěch Dostál (talk) 10:54, 31 January 2022 (UTC)

  Folks I’d said everything related to my concerns. With permanent repetition of reasoning it’ll be not powerful and more convincing. Anyhow, I’ll see that most of you will get rid off and the work ends on high volume users like me. To make it short, I give up and do anything you want to do and I’m looking forward to find a workaround. Possibly I have to maintain again appr. 200k datasets of Bavarian monuments. Little frustrated greetings. Derzno (talk) 07:07, 4 February 2022 (UTC)

  FWIW, in this case a potential way proposed phab:T54971 would probably help you: to finally unbreak the unfair "one sitelink per one wiki" limits, but only limit the application sites to Commons, Incubator, mul.wikisource and beta.wikiversity. Liuxinyu970226 (talk) 02:22, 26 April 2022 (UTC)

•  Weak support for deprecating. JAn Dudík (talk) 08:21, 29 November 2021 (UTC)
•  Delete. However, something should be done about many gallery-pages which are completely redundant and useless, but cannot be deleted from Commons for some weird reason. No one uses them, no one wants them, but are still linked to WD items and Commons categories are linked through main category property (to an item with only Commons category sitelink). Wostr (talk) 16:05, 29 November 2021 (UTC)
•  Delete use sitelinks, that's what they are. 78.55.160.212 01:31, 10 January 2022 (UTC)
•  Delete (actually deprecate first, of course, that goes without saying). --Vojtěch Dostál (talk) 10:55, 31 January 2022 (UTC)
• Looks like this proposal to starting to edge towards consensus. It would be very helpful to have a detailed plan of exactly how the migration/deprecation would occur, so that no valuable links are lost — Martin (MSGJ · talk) 20:48, 12 February 2022 (UTC)

  @MSGJ: If this leads to deletion, my plan for implementing it would be:

  1. Manually post notices for all templates that currently use this property, to encourage them to migrate to using sitelinks (via the existing WikidataIB code, if they can't do this directly), and follow up on those discussions. Being realistic, this would take about 6 months to migrate uses over to the sitelinks.
  2. Propose a bot task that would remove all values where they match the sitelink (this should cover around 90% of them). This would be quick to code, but would take a few weeks to get through the bot approvals process, and it would take a few months to run through all uses.
  3. Semi-automatically run through remaining values to remove or migrate them to sitelinks, as appropriate. This is the most controversial part, and it would take a while to do this. It depends on which approach we take - the quickest would be just to remove the values, the slowest would be to manually check each of them to see if they could be turned into sitelinks. My preference would be in the middle, obvious issues would be resolved, the obvious bad values would be removed, and the tricky ones would be the last to be resolved.

  There would be multiple opportunities to provide input into this process if we go ahead with it. Thanks. Mike Peel (talk) 22:37, 12 February 2022 (UTC)

  I don't see any issue with points 1 and 2 myself. I would like to see a much more detailed plan for how to tackle the ones in point 3. Perhaps an algorithm/flowchart to show how the items will retain their links to related commons categories in each imaginable scenario. I will make a start on some of the easy cases, when I get a chance, but I'm sure you've got a lot more insight into the various possible situations. — Martin (MSGJ · talk) 12:51, 18 February 2022 (UTC)

  @Mike Peel: I have made a start on a possible algorithm for dealing with P373 in different situations. Please can you have a look and correct/add anything on Wikidata talk:Properties for deletion/P373? — Martin (MSGJ · talk) 14:20, 20 February 2022 (UTC)

•  Keep: In general, i would agree that redundancy should be avoided in advance, since it might leed to inconsistencies, but in this case I do not see the advantage of deleting this already existing property.
  for performance/scalability reasons (also see Wikidata:Query Service scaling update Aug 2021)
  • a lot of queries result in a timeout, they have to be split into several smaller expected result sets using additional constraints/filters/selection parameters or another tool/way/method/access path, e.g. Wikidata:Project_chat/Archive/2021/10#SPARQL_for_querying_all_objects_for_humans,_with_an_article_in_(german_language)_wikipedia_without_date_of_birth_in_wikidata
  • since begin of this year my watchlist is completley broken due to scalability problems: https://phabricator.wikimedia.org/T298847
  • to find a workaround for timeouts/scalability/performance problems redundancy might help. If one tool (e.g. PetScan, SPARQL, Quarry, API, HarvestTemplates, QuickStatement, ...) or way/method/access path (P373 vs. Sitelink) does not work to get the necessary information another tool/way/method/access path might work (e.h. without resulting in a timeout)
  • sitelinks are sometimes removed by vandals or by newbies by accident, instead of removing just one sitelink they remove all or a lot of sitelinks. The labels as well as the P373-property might help to re-identify the right wikidata object within the 96 millions existing objects (Special:Statistics) to reconnect
  Redundancy can be found at a lot of places, for example:
  • descriptions are maintained in wikidata objects and in articles, e.g. see d:Q60596895, en:Wikipedia:Short description / en:Wikipedia:WikiProject Short descriptions
  • various IDs like GND, VIAF, LCCN, IMDb, Filmportal, Transfermarkt, Wfb, ... are maintained in articles as well as in wikidata objects, e.g. see de:Wikipedia:Umfragen/Normdaten aus Wikidata
  • geographical locations and heritage monument IDs are maintained in articles, Commonscats, wikidata objects, ...
  • commonscats cound not only be found in wikidata-objects, but also in articles, regular categories and lists
  • within wikidata we have for example redundant relationsships between objects, for example "is part of/consists of", "kind/parent", category for list/list for category, article for category/category for article, "different from", ... where only one direction would be sufficient
  Redundancy might help to identify inconsistencies, duplicates and errors, for example, when trying to import/harvest various IDs from de-WP duplicate articles (different names, but same entity) or duplicate wikidata-objects (two objects with same IDs) can be identified due to constraint violations
  keeping the P373-property gives more flexibility (several objects might have the same P373-property-value, but only one of them might have a sitelink to a commonscat)
  When deleting the P373-property, queries and tools that have relied on this property might break, and it would reduce the possible ways/methods/access paths to takle a problem/information need if one way is not working (e.g. tool not available, query returns a timeout, etc.) --M2k~dewiki (talk) 15:32, 17 February 2022 (UTC)

  @M2k~dewiki: The query issue is the only good reason I've seen to keep this property. Redundancy does make things quicker, but it also makes it a lot harder to maintain - unless we want to automatically synchronise Commons category (P373) values with the sitelinks, which is something I could implement? Thanks. Mike Peel (talk) 21:41, 19 February 2022 (UTC)

  Hello @Mike Peel:, yes, In my opinion it should be synchronized automatically, if the commonscat property is empty, it should be filled by the value of the sitelink. --M2k~dewiki (talk) 21:58, 19 February 2022 (UTC)

  @M2k~dewiki: I'd prefer to just maintain the sitelinks, but if this PfD closes in favour of keeping P373, then I could write a bot script to synchronise it with the sitelinks. I expect that would cause a lot of issues with people trying to change the property value that get bot-reverted if they don't also update the sitelink, though, which could be avoided if we delete this property and just use the sitelinks. Thanks. Mike Peel (talk) 22:03, 19 February 2022 (UTC)

•  Delete: unnecessary redundancy. Not much more to be said. Tol (talk | contribs) @ 21:47, 17 April 2022 (UTC)

Time to end this trench war and close as no consensus? Multichill (talk) 15:34, 25 May 2022 (UTC)

Yeah ... maybe. But it will be back, you can be sure of that — Martin (MSGJ · talk) 21:00, 27 May 2022 (UTC)

@Multichill: This property is *continuously* causing confusion amongst editors, and it really isn't needed any more now that we have the sitelinks and the Wikidata Infobox on Commons. If this closes as no consensus, I would immediately re-nominate it for deletion. I've spent a lot of time on this discussion to respond to the concerns, and I think they have all been resolved as best as they can, so I really hope that we could start removing uses of this property soon. Thanks. Mike Peel (talk) 21:15, 28 May 2022 (UTC)

I'm afraid that we should close it, but not "no consensus", rather "CONSENSUS TO DEPRECATE P373". Liuxinyu970226 (talk) 10:18, 6 June 2022 (UTC)

Close as deprecate or keep but continuously override with bot (as discussed with M2k~dewiki in February this year). Anyway, most of the recent arguments are for deprecation. Vojtěch Dostál (talk) 08:51, 14 July 2022 (UTC)

@Mike Peel I created a diagram with Figma (link to interactive version) that explains this property deletion request and the proposed solution. Let me know if I got anything wrong and I'll change it.

Lectrician1 (talk) 21:53, 2 July 2022 (UTC)

That is useful and thanks for making that - it is not the whole picture though. Unlike your example, most item do not have a category item, so the commons sitelink goes on the item itself. The main reason that P373 is seen as useful/indispensable is that it is many-to-1 unlike the sitelinks which are 1-to-1. If there are multiple items (e.g. a museum and the building that houses the museum) which need to link to the same Commons category then it can be harder to do this without P373. By the way, you might be interested in what I started on the talk page. — Martin (MSGJ · talk) 13:44, 5 July 2022 (UTC)

@Lectrician1: Nice figure! The situation is *already* like the right-hand side, though, since the sitelinks are required for the Wikidata Infobox to work in Commons categories, this is what we've been implementing over the last 4 years or so. Except we *also* have the P373 layer over the top, which leads to the confusion. You might find User:Mike Peel/Commons linking useful for understanding the current situation. Thanks. Mike Peel (talk) 18:41, 5 July 2022 (UTC)

•  Keep I think we all have noticed a problem with redundancy from the very beginning, but also the clumsiness with the connection of the corresponding article, and later with the corresponding category of some Wikipedia. Think from little to the big, not vice versa. For example, you have an article about a small settlement, a village or a small town and a couple of photos and so you can make a category on Commons. But it is a very small chance that there will be a need for a specific category on Wikipedia and the Commons Gallery – for a long time. In this way, it seems to me that it is unnecessarily given a great advantage for the galleries. Also remember that on some wikipedia they have a very strict recommendation of a minimum of five articles to create a category. This is for case 1-to-1 Commons category to Wikipedia category. --Vhorvat (talk) 01:41, 26 July 2022 (UTC)

  @Vhorvat: I don't understand, sorry. You can link to a Commons category from a Wikidata item on the topic, you don't need to have separate categories on Wikipedias. Or if there's also a Commons gallery, you can just create a 'Category:' item on Wikidata and use category's main topic (P301)/topic's main category (P910) to link between them, no problems. This really doesn't need a dedicated property. Thanks. Mike Peel (talk) 20:14, 26 July 2022 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.