Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to navigation Jump to search

Properties for deletion
This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:
  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message on a project discussion page by notifying the participants.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Properties for deletion may be used:

  1. To merge a property to another, or request to deprecate a property in favor of another.
  2. To change the data type of a property currently being used.
  3. Rarely, to delete a property with no replacement (e.g. it refers to an external website that is closed and/or not suitable for Wikidata).

Properties for deletion should not be used:

  1. To change the scope or purpose of a property; these should be discussed at the talk page of the property, project chat, or requests for comment.
  2. To request of undeletion of a property. To challenge a recently closed properties for deletion, you may use administrators' noticeboard; otherwise, you may repropose the property.


On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.


Please add a new request at the bottom of this section, using {{subst:Rfd|1=PAGENAME|2=REASON FOR DELETION}}.

demonym (P1549)[edit]

demonym (P1549): (delete | history | links | entity usage | logs | discussion)

I think this property could be replaced with one that links to senses (e.g. sense 1 of Kenyan (L35249)); this would be especially useful for words with lots of conjugations. I have not created a new property proposal because it would be more appropriate to have the discussion in one place.

I've already created 161 English noun lexemes which would be able to replace current uses; it would also be necessary to create equivalent items for adjectives, as well as to create the relevant senses for the noun and adjective lexemes (I've only added a sense to L35249 so far). —Jc86035 (talk) 10:33, 4 November 2018 (UTC)

Notified 94 contributors to the property and its talk page: User:Nikki User:Abián User:Jura1 User:VIGNERON User:Tubezlob User:Jheald User:Lockal User:Infovarius User:Putnik User:Laddo User:Kalogeropoulos User:Innocent bystander User:Event User:Jakec User:Vinhtantran User:MaGa User:Labant User:K175 User:Autom User:Robin van der Vliet User:Matěj Suchánek User:Janezdrilc User:Ctschiebout User:Kevin Scannell User:Maria zaos User:Horcrux User:Soued031 User:Metsavend User:Obaid Raza User:İncelemeelemani User:Pinky sl User:Andreasmperu User:Рөстәм Нурыев User:Pmt User:Gustavo Rubén User:Oriciu User:Mr. Ibrahem User:زكريا User:ToJack User:Renessaince User:Arnaugir User:MisterSynergy User:AmaryllisGardener User:Beta16 User:Mahir256 User:Спасимир User:Asierog User:Avatar6 User:Wylve User:Şêr Jc86035 (talk) 10:39, 4 November 2018 (UTC) User:Krupolskiy Anonim User:YMS User:ಶಿವಕುಮಾರ್ ನಾಯಕ್ User:Hibm98 User:GAllegre User:Epìdosis User:Jklamo User:David1010 User:SR5 User:Máté User:Ślimaczek User:HakanIST User:FocalPoint User:Allen4names User:Mbch331 User:Zygimantus User:Fnielsen User:Peppepz User:Geraki User:Supaplex User:Thierry Caro User:NMaia User:Loischantada User:ANDROBETA User:Marklar2007 User:Kikos User:Raid5 User:Doostdar User:Palapa User:Octahedron80 User:Милан Јелисавчић User:Frokor User:Rippitippi User:Conny User:Qllach User:Miguillen User:יונה בנדלאק User:Liuxinyu970226 User:桂鷺淵 User:Bjankuloski06 User:Thomas11 User:Ayack User:Чаховіч Уладзіслаў User:Александр Сигачёв Jc86035 (talk) 10:41, 4 November 2018 (UTC)

I would like to note that the property is used as label for country of citizenship (P27) at huwiki. If the property is deleted, the current data needs to be imported into the newly accepted structure, and huwiki needs to be notified to create a workaround to the new structure if possible. Ideally, the new structure should make it possible. – Máté (talk) 12:10, 4 November 2018 (UTC)

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
@Autom: Do you have any specific place where this spcific property is used on svwiki? I see many potential problems with this property in the Swedish language, so at least I have never tried to use or even edit it. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:03, 19 April 2019 (UTC)
@Sextvå.tvånoll.ettsjunoll.sjufyra: It is used to display nationality in Faktamall biografi WD (via Wikidata2). In the article Bill Gates, the template does not return "USA" but "Amerikan", which is the value of demonym (P1549) [common gender (Q1305037), singular (Q110786)] of United States of America (Q30) (the country of citizenship (P27) of Bill Gates (Q5284)). /Autom (talk) 14:11, 20 April 2019 (UTC)
  • Symbol delete vote.svg Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)
  • Symbol delete vote.svg Delete The property demonym of (P6271) has been created. This one can now be deleted (first declare obsolete, move content, then delete).--Micru (talk) 17:30, 19 December 2018 (UTC)
  • Pictogram voting comment.svg Comment If this property is being used in an infobox or by a Lua module, it will need to be retained and to go on having its values added to and extended, at least and until such time as inverse property values become obtainable via Lua - as at present they are not. Jheald (talk) 18:09, 19 December 2018 (UTC)
  • Time2wait.svg On hold. I agree with Jheald that we need a place -> demonym property to keep infoboxes working. We should keep this property until we have a new Item -> Lexeme "demonym" property, migrate all existing uses and infoboxes, then delete P1549. Deryck Chan (talk) 15:52, 11 January 2019 (UTC)
  • Symbol delete vote.svg Delete Very barely used, and replacement is even available for these not more than 100 usages. --Liuxinyu970226 (talk) 12:44, 16 March 2019 (UTC)
  • Time2wait.svg On hold. Until infoboxes (as happens in cawiki) can be transformed after have access via LUA module. Thanks, Amadalvarez (talk) 12:47, 26 March 2019 (UTC)
  • Pictogram voting comment.svg Comment. As noted, 1) there is no wikibase client for lexemes, 2) there is no Lua function available for backlinks or API queries, pending of phab:T185313 that it seems silently declined for a year now. There is not any path from a wiki page like w:fr:Paris to reach Parisien (L26359). If these blockers are solved, there are still some concerns. How to deal with Parisien (L26359) or Parisienne (L25620)? How to obtain the demonym for a given language and a lexical category? At the end, it will be one more, or several, arbitrary access and it is expensive in Lua time usage that has limitations in infoboxes powered by Wikidata. --Vriullop (talk) 07:52, 27 March 2019 (UTC)
  • Symbol keep vote.svg Keep Keep this property because with this property is very easy to add some data. --Manu1400 (talk) 21:43, 18 August 2019 (UTC)
  • Symbol keep vote.svg Keep Very helpful, easy to use. HarryNº2 (talk) 12:07, 19 November 2019 (UTC)
  • Symbol keep vote.svg Keep Useful. --Obsuser (talk) 14:14, 25 November 2019 (UTC)
  • Symbol neutral vote.svg Neutral Symbol keep vote.svg Keep How to call an inhabitant of a neighborhood? We must also think of other languages. Nothing can replace it, for the moment. Examples: Germanopratin in Saint-Germain-des-Prés (Q604717), Planpalistain in Plainpalais (Q2546289). —Eihel (talk) 09:59, 26 November 2019 (UTC)
Symbol delete vote.svg Delete Doesn't useful, replacement available. --2409:8902:9001:6CE0:781B:941D:E99A:2367 00:16, 4 December 2019 (UTC)
Symbol delete vote.svg Delete Replacement available. -- 02:35, 9 May 2020 (UTC)
  • Symbol delete vote.svg Delete Having the information on the country makes country items that are already quite big bigger. The information is much better stored as sense. ChristianKl❫ 21:32, 18 May 2020 (UTC)
  • Symbol keep vote.svg Keep: Designating the inhabitants of a place by a specific name can be useful. Otherwise should we replace it with a longer expression ? Cquoi (talk) 10:49, 7 June 2020 (UTC)
  • Time2wait.svg On hold : the comments of Jheald and Vriullop sound pretty relevant to me, there are blocking points, so keep it for now. --FoeNyx (talk) 23:13, 15 November 2020 (UTC)
  • Symbol keep vote.svg Keep useful to designate inhabitants of a place. PAC2 (talk) 20:05, 10 January 2021 (UTC)
  • Symbol keep vote.svg Keep Using lexeme senses is a poor replacement since there will be one claim per language instead, severely bloating the item. It's better that the sense links to an item like we do today. Ainali (talk) 15:15, 12 February 2021 (UTC)
  • Symbol keep vote.svg Keep Extremely useful when translating label, descriptions, including in wikipedia templates.--Mikey641 (talk) 02:04, 9 March 2021 (UTC)
  • Symbol keep vote.svg Keep This is good for Wikidata but bad for infoboxes: Inverse properties is problematic, since is harder to code templates or modules to emulate the expected behaviour with inverse properties, and most of the nominators of those deletion request don't even address the problems that leads this deletions. One of the warnings says clearly:

Skull and Crossbones.svg Validate the property isn't being used in other projects (using {{ExternalUse}})

and if it is leave a message in Village pump of those projects! and this is an obvious case of potential use, and as this is already used, this request should be speedy closed. This should be discussed on other projects like Wikipedia first! --~~~~

doctoral student (P185)[edit]

doctoral student (P185): (delete | history | links | entity usage | logs | discussion)

Generally too many. Inverse should be sufficient --- Jura 17:59, 12 July 2019 (UTC)

  • I voted delete because I don't like redundancy in databases. But you are right, if it's used in templates then there's no proper mechanism for obtaining inverse properties. It's a technical flaw and the inverse properties may be needed. I'd have to look at it in more detail before voting. Ghouston (talk) 22:43, 23 February 2020 (UTC)
  • Symbol keep vote.svg Keep Because pair p184-p185 oldest and specialized than universal student (P802), student of (P1066). @@Deryck Chan: It's clear for me (and You). I asked about mechanism of merging. And seeing propose souris + suricate now. For why? Because they Tetrapoda :) --Dim Grits (talk) 15:05, 18 July 2019 (UTC)
  • Symbol delete vote.svg Delete: redundant with doctoral advisor (P184). Moreover, "student" word does not make understand that the activity of a PhD is the one of a researcher, "PhD candidate" would have been more convenient --Lupin~frwiki (talk) 11:50, 16 July 2019 (UTC)
  • Symbol delete vote.svg Delete: It is true. Redundant with doctoral advisor (P184). --İncelemeelemani (talk) 19:24, 17 July 2019 (UTC)
  • Symbol delete vote.svg Delete - redundant with doctoral advisor (P184). Many-to-one database relationships should be one-directional in Wikidata. Kaldari (talk) 15:15, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep @Kaldari, İncelemeelemani, Lupin~frwiki, Ghouston: it isn't redundant, it is an opposition to that item. As Dim Grits said, doctoral advisor (P184) is for "teacher", but doctoral student (P185) is for student! Sincerely, Nadzik (talk) 13:30, 23 February 2020 (UTC)
    • @Nadzik: Of course they mean different things, that's obvious. I meant that it's a redundant database relationship. As an analogy, we don't list all the species that fall under a genus item in Wikidata, instead we list the genus from the species item. Many-to-one database relationships should be one-directional in Wikidata. Kaldari (talk) 16:01, 25 February 2020 (UTC)
      • Pictogram voting comment.svg Comment this may also sometimes be a many-to-many relationship as one student can have multiple advisors. --Hannes Röst (talk) 01:28, 10 June 2020 (UTC)
@Nadzik, Dim Grits:: I realize I did not gave the international references on which I based my point, thank you for making me remind this: doctoral advisor (P184) and doctoral student (P185) do not designate the usual context of professor (or teacher) and student, since "PhD candidates are persons professionally engaged in R&D" (researchers) as stated in the Euraxess Charter & Code principles ( page 28-29). They details "The term Early-Stage Researcher 19 refers to researchers in the first four years (full-time equivalent) of their research activity, including the period of research training". This doc is endorsed by a lot of famous institutions and countries (see

Ping Danrok, Zolo. Nomen ad hoc (talk) 07:26, 14 July 2019 (UTC).

Also @Dim Grits, Hannolans, İncelemeelemani, Emptyfear, AttoRenato:@Lupin~frwiki, Mormegil, Rooiratel, Dumbassman: Those who recently edited this property. --Liuxinyu970226 (talk) 11:47, 15 July 2019 (UTC)
Also @Cgolds: who opened a related discussion on French Bistro, and who just suggested only keeping student (P802). Nomen ad hoc (talk) 06:46, 17 July 2019 (UTC).
  • Symbol keep vote.svg Keep. Infoboxes about professors often include a short list of prominent doctoral students. The inverse may be sufficient to generate a list of all students who have their own Wikidata items, but this property allows further curation of who are the most important students using ranks. @Lupin~frwiki: "PhD candidate" and "doctoral student" have different boundaries (other kinds of doctorate are not included) and different universities use different names, so I wouldn't advise rescoping the property.
    • Ok, I understand. So you would use this property for medicine doctorate for instance, I understand. Then "doctoral candidate" could then be much more convenient than "doctoral student". Do you agree? --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)
      • Probably not physician (Q39631), but likely to include other kinds of doctorates conferred after academic study: Doctor of Education (Q837184), Doctor of Engineering (Q17119067), Doctor of Laws (Q959320) and the University of Oxford which call their doctors of philosophy "DPhil" rather than "PhD". Deryck Chan (talk) 15:32, 19 July 2019 (UTC)
        • If I formulate it differently, you argue that doctoral "student" would be more convenient to use for medicine doctor candidate than doctoral candidate which should be used for research doctor candidate. I understand that either the difference between both people is notable and we should classify medicine doctors as students with field medicine or it is not and we should consider them as candidates.Lupin~frwiki (talk) 11:05, 29 July 2019 (UTC)

@Dim Grits: I think doctoral student (P185), doctoral advisor (P184) serve a different purpose from student (P802), student of (P1066). These two SPARQL queries [1][2] show editors have found uses in over 1000 biographical items where distinguishing between doctoral student-teacher relationships and other student-teacher relationships has been helpful. Deryck Chan (talk) 17:33, 16 July 2019 (UTC)

  • Pictogram voting comment.svg Comment A big problem imho that also concerns student (P802) has been to establish an inverse property constraint. The property would be totally valid as a way to store the main students or Phd candidates of a teacher. Currently most of the student of (P1066)/doctoral advisor (P184) relationships that I have filled during the past years have been also reversed (either by bot or by well-meaning users attempting to "correct" an apparent error) making the student (P802)/doctoral student (P185) information meaningless. I would agree to keep this property along with student (P802) if the constraint is entirely lifted. Alexander Doria (talk) 18:40, 16 July 2019 (UTC)
    • @Alexander Doria: I tend to agree that student of (P1066) and student (P802) should be inverse properties. Importance can be marked using rank, rather than removing unimportant (but truthful) entries. Deryck Chan (talk) 15:32, 19 July 2019 (UTC)
      • Agree too. Only mentioning "notable" students is IMHO too arbitrary... especially if "notability" isn't properly defined. Nomen ad hoc (talk) 15:38, 19 July 2019 (UTC).
      • Agree tooLupin~frwiki (talk) 11:05, 29 July 2019 (UTC)
    • Consistency can be assured but some work is needed. We can get the same information without this property. Use this kind of property to distinguish some items of the set does not seem a good idea since the choice of each item can be discussed and different in every country, field, etc. This selection should be let to each wikipedia page imho. --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)
  • Delete as redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 23 July 2019 (UTC)
  • Symbol delete vote.svg Delete A Wikipedia that only wants notable students via reverse lookup can simply only display students for which they have an article. ChristianKl❫ 10:07, 8 August 2019 (UTC)
    • @ChristianKl: Reverse lookup is hideously difficult in Lua... It's better to have a property to curate a list of notable students separately. Many infoboxes (e.g. w:en:Template:Infobox academic) include a "notable students" field, which if implemented using Wikidata should be P185 with preferred rank. Deryck Chan (talk) 10:42, 29 August 2019 (UTC)
  • Symbol keep vote.svg Keep People that consider it is redundant with doctoral advisor (P184), may be doesn't know that is impossible to get information via backlinks from LUA module and, of course, from infoboxes and any kind of wiki templates. SPARQL is a partial solutions for the real uses of WD, nowadays. If I'm wrong and somebody has a solutions to make some kind of haswbstatement from wiki templates or LUA Modules, please just tell me. Thanks. Amadalvarez (talk) 16:16, 12 August 2019 (UTC)
Listeria can provide you with such lists. --- Jura 17:21, 17 October 2019 (UTC)
Pictogram voting comment.svg Comment Not within a Infobox or any other template. Listeria must be applied article by article because it contains (written inside the SPARQL code) the specific Qid related with a specific item. So, it can't be used in a template that act with the Qid of the present article. Amadalvarez (talk) 17:31, 11 November 2019 (UTC)
@Amadalvarez: Shouldn't you change your second {{Keep}} to {{Comment}} or other suitable template, to avoid "multiple voting" problems? --Liuxinyu970226 (talk) 11:35, 20 November 2019 (UTC). ✓ Done, excuse me.Amadalvarez (talk) 15:55, 20 November 2019 (UTC)
  • Symbol delete vote.svg Delete Redundant inverse. --Yair rand (talk) 19:46, 15 September 2019 (UTC)
  • Symbol neutral vote.svg Neutral to Symbol keep vote.svg Keep As mentioned in the P802 deletion discussion below, I'm not so sure the breakage of "inverse" is a good idea based on any of the comments shared above. It was introduced once and I have a feeling it would be reintroduced. If the problem is that doctoral student (P185) is overused, relevance should be enforced harder. On the other hand, I think student (P802) is a better property for "famous apprentice". Jagulin (talk) 17:00, 17 October 2019 (UTC)
  • Symbol keep vote.svg Keep At least on zhwiki, the Listeria datas can't work well, it only pollutes with English-only text, and has no easy way to translate. --Liuxinyu970226 (talk) 03:40, 6 November 2019 (UTC)
  • Symbol delete vote.svg Delete or change to something more specific. Infoboxes don't show all doctoral students, do they? Michael FV (talk) 03:07, 9 January 2020 (UTC)
  • Symbol keep vote.svg Keep At least in Vietnamese, you really can't make confusions between nghiên cứu sinh (doctoral student) and cố vấn tiến sĩ (doctoral advisor). By following these vote-deleters' comments, it looks like some users are misleaded by their wrong translations of P184 and P185, a translation review is needed, note that I've corrected the Vietnamese translations. -- 22:43, 20 January 2020 (UTC)
    • I don't think the people who are saying they are redundant think they are the same thing. They are saying that the two-way database relationship is redundant. Kaldari (talk) 17:37, 25 February 2020 (UTC)
  • Symbol keep vote.svg Keep: useful IMHO.--Cbyd (talk) 20:55, 19 February 2020 (UTC)
  • Symbol keep vote.svg Keep Has language conflicts. -- 02:37, 9 May 2020 (UTC)
    • This could be an additional argument for deletion. --- Jura 10:10, 21 November 2020 (UTC)
  • Pictogram voting comment.svg Comment please note that for many Wikipedias it would more useful to list noteable students and postdoctoral researchers, therefore for articles about a professor it would be important to have a list of all personnel that s/he advised (students, postdocs, research associates etc). Some students switch fields after their PhD and their postdoc advisor is much more important for their career than their PhD advisor (at least in my field where long postdocs are common). Therefore it may make sense to change the categories to a advisor/advisee relationship that is more broad than doctoral student/advisor only. --Hannes Röst (talk) 01:33, 10 June 2020 (UTC)
    • @Hannes Röst: this is merely for "doctoral students". The inverse will still be available at "doctoral advisor" Property:P184. Correct referencing is probably more easily done on the later. --- Jura 10:10, 21 November 2020 (UTC)
  • Symbol keep vote.svg Keep - I can not see any cause for a deletion. Ofcourse such relationships are two-way-relationships. This must be always and in every data set. Either what we're doing here is serious work or not. If so - then it has to stay. If not, we can stop the whole Wikidata project. -- Marcus Cyron (talk) 22:16, 10 June 2020 (UTC)
    • @Marcus Cyron: Why would we need to repeat the inverses of thousands of "doctoral advisor" Property:P184 statements? This doesn't seem to be serious. --- Jura 10:03, 21 November 2020 (UTC)
      • @Jura1: - we do this in a lot of other cases too. You always need also the inverse data. How should you know about it, if you can't see it? We talk about seeing and reading, not about a querry request! -- Marcus Cyron (talk) 11:36, 21 November 2020 (UTC)
        • @Marcus Cyron: frequently we don't do this when there are 1-to-many relations. Some people are even reluctant to do it when it's a 1-1 relation (or 1 to few). I'm not really sure where one would want to read the list at Q982962#P185. How would you go about it? Where would you read it? I think one would generally query the underlying data. --- Jura 16:05, 21 November 2020 (UTC)
  • Symbol keep vote.svg Keep - Useful relation. Slightly different semantics between "is/was-student-of" and "has/had-doctoral-student". In an ideal world this would be a bidirectual-many-to-many-relation. In script reality this relation seems useful. Praxis example for usefulness (use-case): "Mathematics Genealogy Project", NDSU + Am.Math.Soc. This is what Wikipedia should have for every academic profession. Best, --Christianvater (talk) 12:49, 11 June 2020 (UTC)
  • Symbol keep vote.svg Keep Used by 35+ templates, clearly has user-case.--Jklamo (talk) 15:59, 2 January 2021 (UTC)
  • Symbol keep vote.svg Keep, an important property for science.--Arbnos (talk) 14:57, 28 April 2021 (UTC)
  • Symbol keep vote.svg Keep--Ferran Mir (talk) 07:45, 16 May 2021 (UTC)
  • Symbol keep vote.svg Keep There are both doctoral advisors (typically professor or adjunct professor/docent) and doctoral students. Kindly note that in many fields doctoral students are not Ph.D. students, as the title awarded is not Ph.D. but e.g. Ed.D., Psy.D., Mus.D., LL.D., Eng.D., etc. --Paju~wikidatawiki (talk) 00:06, 19 May 2021 (UTC)
  • Symbol keep vote.svg Keep See my above comment at #demonym (P1549), or find a solution that covers usage on other projects like Wikipedia, namely templates and modules. --Amitie 10g (talk) 17:49, 29 May 2021 (UTC)

Translation issues?![edit]

@Kaldari: If the problem pointed is correct, I believe that there can in fact result some users to wrongly daydream that two properties are having same meanings in their L1(or L2?)-speaking languages, and say that "X can be simply replaced by Y" even incorrect. as of 10:04, 1 April 2020 (UTC) the translations are:

lang P184 P185 P802 P1066
af Doktorale student Doktorale adviseur student student van
aln student i doktoraturës N/A N/A N/A
ar طلاب الدكتوراه مشرف الدكتوراه طلاب تتلمذ على يد
تتلمذ على يد, تعلم لدى, تتلمذ على, تتلمذت على يد
ast N/A direutor de tesis
direutora de tesis
discípulu, discípula, alumnu, alumna, maestru de, maestra de, profesor de, profesora de
az N/A elmi rəhbəri tələbəsi
tələbə, tələbələr, tələbələri
ba аспиранттар ғилми етәксе уҡыусылар
уҡыусы, студент, студенттар
кемдә уҡыған
уҡытыусы, уҡытыусылар
be аспіранты / дактаранты
аспіранты, дактаранты, кіраўнік у
навуковы кіраўнік вучні
вучань, студэнт
студэнт каго
Навуковы кіраўнік, настаўнік, уплыў
be-tarask асьпірант навуковы кіраўнік
вучаньстудэнты, вучні, студэнт чый студэнт
bg аспирант
научен ръководител студент ученик на
bn N/A N/A ছাত্র শিক্ষক
br N/A rener-tezenn N/A bet studier
bs doktorant savjetnik za izradu doktorata student-asistent student
ca estudiant doctoral director de tesi
director doctoral, supervisor doctoral
alumne, mestre de, deixeble
alumne/a de, professor
cs doktorand vedoucí disertační práce
vedoucí práce, učitel
učitelem (koho), učitelkou (koho), studenti
učitelé, žákem (koho), student (koho)
cy myfyriwr doethurol
myfyrwraig ddoethurol
ymgynghorydd y doethor disgybl
myfyrwraig, myfyriwr
disgybl y canlynol
ahro, darlithydd, arwr
da doktoratsstuderende doktoratsrådgiver elev
studerende, student
elev af
lærer, underviser, porfessor, mentor, mester
de Doktorand
Doktoranden, Promovend, Promovendin, Doktorandin
Doktorvater, Gutachter, Doktormutter
Schüler von
el διδακτορικός φοιτητής διδακτορικός σύμβουλος 内容单元格 内容单元格
en doctoral student
doctoral advisor
advisor, doctoral supervisor, supervisor, PhD advisor, promotor
students, teacher of, pupil, pupils, disciple, disciples, teacher to
student of
teacher, professor, pupil of, supervisor, academic supervisor, disciple of, studied under, master, mentor, advisor, tutor
en-ca N/A N/A 内容单元格 student of
en-gb doctoral student doctoral supervisor student
students, teacher of, pupil, pupils, disciple, disciples
student of
teacher, professor, pupil of, supervisor, academic supervisor, disciple of, studied under, master, mentor, advisor, tutor
eo doktorigito doktoriginto studento(j) studento de
es doctorando
estudiante doctoral
supervisor doctoral
directora de tesis, director de tesis, asesora doctoral, supervisora doctoral, asesor doctoral
discípula, pupilo, pupila, alumno, alumna, aprendiz
alumno de
estudiante de, discípulo de, profesor, supervisor, mentor, tutor, aprendiz de
et N/A doktoritöö juhendaja õpilased on (oli) ... õpilane
eu doktorego ikaslea tesi zuzendaria ikaslea honen ikaslea
fa دانشجوی دکتری استاد راهنمای تز دکترا شاگردان از دانشجویانِ
fi tohtoriopiskelija väitöstyön ohjaaja
ohjaava professori
oppilas oppilaana
opettaja, mestari, mentori, ohjaaja
fr doctorant
étudiant de thèse
directeur de thèse
directrice de thèse, responsable de thèse, thèse
étudiant, maître de, professeur de, élève, disciple, apprenti
élève de
professeur, enseignant, étudiant chez, apprenti de, maître
frr N/A N/A student student faan
ga N/A comhairleoir dochtúireachta
stiúrthóir dochtúireachta
mac/iníon léinn mac/iníon léinn de chuid
gl doutorando
doutoranda, doutorandos, doutorandas, estudante de doutoramento, estudantes de doutoramento
director de tese
directora de tese
docente de alumno de
gu N/A N/A વિદ્યાર્થી આ વ્યક્તિનો વિદ્યાર્થી
ha N/A N/A dalibi N/A
he מונחה לדוקטורט
מנחה לדוקטורט תלמיד
תלמידה, תלמידים
תלמיד של
תלמידה של
hr student na doktoratu mentor na doktoratu student 内容单元格
hsb N/A N/A šuler
student, šulerjo, studenća
hu doktorandusz témavezető tanítvány
diákjai, diák
tanítványa neki, professzor
hy ասպիրանտներ / դոկտորանտներ գիտական ղեկավար աշակերտներ աշակերտել է
ia doctorando director de these N/A N/A
id murid doktoral penasihat doktoral murid murid dari
ilo doktoral nga estudiante doktoral a nagbalbalakad N/A N/A
is doktorsnemi doktorsleiðbeinandi N/A N/A
it studente di dottorato
ha supervisionato, ha studente di dottorato, è stato supervisore di dottorato di
direttore di tesi
ha avuto come direttore di tesi, è stato supervisionato da
discepolo, allievo, scolaro, maestro di, insegnante di, docente di, studenti, discepoli, allievi, scolari
studente di
allievo di, discepolo di, scolaro di
ja 博士課程指導学生
博士課程指導学生, 指導学生
指導教員, 博士課程指導教授, 博士論文指導教授, 指導教授
教え子, 門下生
恩師, 教師
ka დოქტორანტი სამეცნიერო ხელმძღვანელი სტუდენტი
ვისი მოსწავლე
kn N/A N/A ವಿದ್ಯಾರ್ಥಿ N/A
ko 다음 박사과정 학생들을 지도함
박사과정, 박사과정학생, 지도 중인 박사과정, 지도했던 박사과정, 지도 중인 박사과정 학생, 지도했던 박사과정 학생, 지도 중인 박사과정학생, 지도 학생, 지도학생, 박사과정 학생, 이 교수가 지도해 준 박사과정 학생들, 이 교수가 지도해 준 박사과정 학생, 다음 박사과정 학생을 지도함, 다음 학생을 지도함, 이 교수가 지도해 준 학생들, 이 교수가 지도해 준 학생
박사과정 당시 지도교수
박사논문 지도교수, 지도 교수, 지도교수, 논문지도교수, 논문 지도교수, 박사과정 지도교수, 박사과정시절 지도교수, 박사과정 학생 시절 지도교수, 박사과정 학생시절 지도교수, 박사과정 시절 지도교수
다음의 스승이었음
학생들, 학생, 제자들, 다음을 제자로 두었음, 다음의 스승이었음, 제자, 다음의 선생이었음, 다음의 스승임, 다음의 선생임, 다음의 스승, 다음의 선생, 다음의 선생님임, 다음의 선생님
다음의 제자였음
선생, 교수, 지도교수, 지도 교수, 담임, 담임 교사, 담임교사, 담임선생, 다음의 제자임, 다음 교수의 제자임, 다음 선생의 제자임, 다음 교사의 제자임, 다음의 학생이었음, 스승, 스승들, 선생님, 선생님들, 선생들, 다음의 학생임, 다음의 제자, 다음의 학생
ksh Dokterant
Doktervatter N/A N/A
ku (include variants) N/A N/A xwendekar xwendekarê
la N/A N/A discipulus praeceptor
lb N/A Dokterpapp
Schüler Schüler vu(n)
lfn N/A N/A studiante N/A
lt N/A N/A studentas yra mokinys
lv N/A N/A studenti
mg N/A mpitondra tezy N/A N/A
mk докторски аспирант докторски ментор ученик учел кај
ml N/A N/A വിദ്യാര്‍ത്ഥി N/A
mr N/A N/A विद्यार्थी चा विद्यार्थी
शिक्षक, प्रोफेसर, लेक्चरर, चा शिष्य, मास्तर
ms anak didik kedoktoran penasihat kedoktoran pelajar
murid, anak didikan, mendidik, membimbing, mengajar, guru kepada, cikgu kepada, pendidik kepada, pembimbing kepada, pengajar kepada
nb doktorgradsstudent doktorgradsveileder elev
elev av
mentor, læremester, studerte under
nds N/A Doktervader N/A Schöler von
nl promovendus promotor student
leerling, leraar van
student van
leerling van, leermeester, leraar
nn doktogradsstudent doktorgradsrettleiar N/A elev av
nqo N/A ߞߎߡߘߊߞߎ߲ (ߕߍߛ) ߗߋߕߌ߮ N/A N/A
oc estudiant de tèsi director de tèsi N/A N/A
or N/A N/A ଛାତ୍ର N/A
pl doktorant
nadzorowani studenci
promotor doktoratu
promotor, promotor doktorski
uczył się u
studiował u, uczyła się u, studiowała u
pt doutorando orientador de doutoramento estudante
estudante de
aluno de
pt-br doutorando orientador de doutorado N/A estudante de
aluno de
ro studenți la doctorat
conducător de doctorat pentru, conducător de doctorat al, doctoranți
conducător de doctorat
conducătorul doctoratului
profesor pentru, profesor al, discipol, elev, elevi, discipoli, student
elev al
profesor, învățător, discipol al, școlit de, învățat de, student al, școlită de, învățată de, studentă a, elevă a
ru аспиранты / докторанты
руководитель у, аспиранты, докторанты
научный руководитель
научрук, руководитель
ученик, ученица, студент, студентка, студенты
обучался у
чей студент, ученик кого, учитель, учился у, студент кого, был учеником, проходил обучение у, учителя
sa N/A N/A N/A अस्य शिश्यः
अध्यापकः, गुरुः, आचार्यस्य छात्रः
scn studenti di dutturatu rilaturi dâ tesi di dutturatu studenti studenti di
prufissuri, maistru, nsignanti
sco doctoral student doctoral advisor student student o
sd N/A N/A شاگرد N/A
se N/A N/A studeanta
oahppi, stuđeanta
sl doktorski študenti
doktorski mentor
doktorski profesor
učenci, učil
učenec od
smn N/A N/A uáppee N/A
sms N/A N/A mättʼtõõtti N/A
sq student i doktoraturës këshilltar të doktoraturës
mbikëqyrësi i doktoraturës
N/A student i
sr (include variants) студент на докторском раду ментор на докторском раду студент/student студент код/student kod
sv doktorand handledare student student till
ta முனைவர் பட்ட மாணவர் முனைவர் பட்ட ஆலோசகர் மாணவர்கள் N/A
te N/A N/A విద్యార్థి
ఎవరి విద్యార్థి
tg N/A N/A шогирдон аз донишҷӯёни
th N/A N/A ศิษย์
ลูกศิษย์, นักเรียน, นักศึกษา
tr doktora öğrencisi doktora danışmanı
danışman, doktora sorumlusu, sorumlu
öğrenci kimin öğrencisi
ts xichudeni xa tidyondzo tavudokodela mutsundzuxi wa nkanelo ya tidyondzo talehenhla
xichudeni xa
tt (include variants) N/A фәнни җитәкче шәкертләр N/A
uk аспіранти / докторанти
здобувач ступеня
науковий керівник відомі учні
учень, учні, студент, студенти, вчитель (для кого:)
навчався в
вихователь, керівник, ментор, професор, учитель, навчався в, навчалася в, був студентом, була студентом, був учнем, була учнем
ur ڈاکٹورل شاگرد ڈاکٹورل مشیر شاگرد
طالب علم
vi nghiên cứu sinh
giám sát
cố vấn tiến sĩ
cố vấn, giám sát tiến sĩ, giám sát viên, Cố vấn tiến sĩ, người ủng hộ
sinh viên
giáo viên của, học sinh, đệ tử
sinh viên của
giáo viên, Giáo sư, học trò của, giám sát viên, giám sát học tập, đệ tử của, học theo, bậc thầy, người hướng dẫn, cố vấn, gia sư
yi דאקטאראנט דאקטאראט-מענטאר תלמיד N/A
yo N/A N/A akẹ́ẹ̀kọ́ akẹ́ẹ̀kọ́ ti
ọ̀gá akẹ́ẹ̀kọ́
yue N/A 博士導師 學生 老師
zh (include variants) 博士生
导师/導師, 顾问/顧問, 博士生顾问/博士生顧問
徒弟, 弟子, 门徒, 門徒
师傅/師傅, 師/师, 导师/導師, 教师/教師

--Liuxinyu970226 (talk) 10:04, 1 April 2020 (UTC)

student (P802)[edit]

student (P802): (delete | history | links | entity usage | logs | discussion)

Same as for doctoral student (P185): generally too many, and redundant with the reverse property. The most prominent students could be referenced with significant person (P3342) (and a role qualified as student (Q48282)) instead. —Nomen ad hoc (talk) 19:38, 28 July 2019 (UTC)

  • Symbol delete vote.svg Delete per nomination. Nomen ad hoc (talk) 19:39, 28 July 2019 (UTC).
  • Symbol delete vote.svg Delete Idem. student (P802) was originally supposed to keep only the main students but has been used in practice as an inverse property for student of (P1066) (notably after the inception of an inverse contraint). I agree that using the property properly wasn't that obvious (sources rarely differentiate the main and secondary students of a person). Anyway, it is currently cumbersome to maintain and do not bring anything new. Alexander Doria (talk) 18:47, 29 July 2019 (UTC)
  • Symbol delete vote.svg Delete - Premeditated (talk) 07:55, 5 August 2019 (UTC)
  • Symbol neutral vote.svg Neutral leaning toward Symbol delete vote.svg Delete as it's indeed redundant wuth the inverse and it's a one-to-many relationship. Pinging the top 5 users of this property: @Simon Villeneuve, Yamaha5, Aiaiaiaiaia, Villy Fink Isaksen, AttoRenato:. Cheers, VIGNERON (talk) 06:15, 8 August 2019 (UTC)
    @VIGNERON: Is there any rule or recommendation against one-to-many or did I misunderstand why you mentioned that? I suppose student of (P1066) is also one-to-many (so actually I'd say the concepts are many-to-many). Removing student (P802) would supposedly remove also inverse claim, but it should first be investigated what that claim means in machine understanding of the property. I think many properties do enforce inverse property today, and even if it's cumbersome to maintain it might be re-added later if we can't make clear why it shouldn't. Jagulin (talk) 05:00, 17 October 2019 (UTC)
  • Symbol neutral vote.svg Neutral Will somebody move the present values of P802 to P3342 ?. We access to P802 in template:infotaula persona of cawiki. I have no problem to change, but without lose the contents. Thanks,Amadalvarez (talk) 15:59, 12 August 2019 (UTC)
    We would ask a bot. Cheers, Nomen ad hoc (talk) 16:12, 12 August 2019 (UTC).
    Let me know when this should be moved. I can create a script for this. Edoderoo (talk) 17:37, 18 August 2019 (UTC)
    Thanks dear Edoderoo. Well, when (and if) a reasonable consensus will be reached? Best, Nomen ad hoc (talk) 18:26, 18 August 2019 (UTC).
    Right now, nobody is against deletion (if data is moved, which is an obvious requirement to me). Lets give it some time, it's holidays season, and there is no need to rush. Edoderoo (talk) 18:06, 19 August 2019 (UTC)
    All right. Nomen ad hoc (talk) 18:17, 19 August 2019 (UTC).
    I assume that the data moved will incorporate a qualifier object has role (P3831) = schoolchild (Q48942) or similar, because P3342 is a generic property and need the person role which is implicit in the P802. Thanks !,Amadalvarez (talk) 18:18, 31 August 2019 (UTC)
    @Nomen ad hoc: Did I misunderstand that the proposition was mainly a means to remove the less prominent/relevant student-relations. Are you suggesting to move each current claim as a first step, to prevent new students added and the "relevance" evaluated over time, or that the evaluation of relevance performed before the move? Isn't the problem in that case that student of (P1066) will still be overused?
    @Nomen ad hoc: Did you also have feedback on these questions? Jagulin (talk) 16:49, 17 October 2019 (UTC)
    @Amadalvarez, Edoderoo: When you say "without loss", are you disagreeing that the student property is overused or do you just want to make sure that the important students are not lost? Would it be feasible to use student of (P1066) in infobox if that was complete enough? Jagulin (talk) 05:00, 17 October 2019 (UTC)
  • @Jagulin: I understant this kind of properties actually mean "remarkable students", not "all the students in his/her whole life". So, if it has been overused, clean it is not a problem to me and even better for infoboxes, which must be a summary, not a list. However, may not be necessary to move to another property, but just clean it. My "do not lose" was refered to the effect of change the property, not to clean their not rellevant content. Thanks, Amadalvarez (talk) 07:18, 17 October 2019 (UTC)
  • Symbol delete vote.svg Delete, but please make sure that no data is lost (including qualifiers and sources) during the transition. --Yair rand (talk) 19:44, 15 September 2019 (UTC)
  • I made a request at WD:RBOT, if there is no issue brought up I will do this task in the coming weeks, to finish this request afterwards. Edoderoo (talk) 14:49, 28 September 2019 (UTC)
  • Symbol keep vote.svg Keep if it's meant to be moved to a property other than student of (P1066). --- Jura 15:54, 28 September 2019 (UTC)
    @Jura1: I think it has been assumed that the inverse property is already matching, but you have a point in that this should be confirmed first. Do you agree that student (P802) has been overused (for non-relevant students) and should those "mistakes" be transferred to student of (P1066) by bot or removed first? I interpret your vote here as "moving to another claim will change nothing", but I'm unsure if you also mean "we should instead monitor data (e.g. relevance) and clarify the usage instructions" or "there is no problem with current usage". Jagulin (talk) 05:00, 17 October 2019 (UTC)
  • Symbol delete vote.svg Delete if moved to student of (P1066). --- Jura 15:54, 28 September 2019 (UTC)
  • Symbol keep vote.svg Keep I base this on reading the discussions here. Currently it hasn't been made clear what removal of the property would solve. I've asked for clarifications which may change my view. Current position: Monitoring data relevancy is better than making the statements more complex as a means to get less data. If "inverse constraints" are not to be used (always cumbersome to maintain), that should probably be a bigger discussion rather than per property. Jagulin (talk) 05:00, 17 October 2019 (UTC)
  • Discuss @Nomen ad hoc: Did you already have a successful case with doctoral student (P185) to tell about? How did the community react to the change and what kind of bot-work was done? Jagulin (talk) 05:00, 17 October 2019 (UTC)
    Please see #Property:P185 above. Nomen ad hoc (talk) 08:07, 17 October 2019 (UTC).
    I see, so no experience yet. I suggest to not rush this change, but learn from PhD first. Jagulin (talk) 16:49, 17 October 2019 (UTC)
  • Symbol keep vote.svg Keep: clearer relationship than anything else especially in relations from earlier centuries Palotabarát (talk) 10:39, 20 October 2019 (UTC)
  • Symbol delete vote.svg Delete Clearly-than-god no consensus to keep such old-school schema. Replacement is now available. --Liuxinyu970226 (talk) 04:54, 1 January 2020 (UTC)
  • Symbol delete vote.svg Delete too many, information should be stored by inverse. Michael FV (talk) 03:16, 9 January 2020 (UTC)
  • Symbol keep vote.svg Keep nghiên cứu sinh (doctoral student) is different by sinh viên (student) in Vietnamese. -- 23:11, 20 January 2020 (UTC)
Symbol keep vote.svg Keep Has language conflicts. -- 02:39, 9 May 2020 (UTC)

Baltisches Biographisches Lexikon digital ID (former scheme) (P2580)[edit]

Baltisches Biographisches Lexikon digital ID (former scheme) (P2580): (delete | history | links | entity usage | logs | discussion)

The IDs used for this property are not stable. Some IDs consist of names, others of name+date, VIAF or GND. They are changing regularly. Example:

All three formatter URL (P1630) are marked as "link death". The BBLD user is blocked but still active (using sock puppets and different IPs) and produced a lot of confusion on Wikidata and German Wikipedia (de:Vorlage Diskussion:BBLD). Imho this property should be deleted. Although the BBLD may be useful the IDs imported to Wikidata are useless. —Kolja21 (talk) 14:09, 31 August 2019 (UTC)

Probably other sock puppet: User:Juliuseberhard. --Kolja21 (talk) 02:13, 1 September 2019 (UTC)

  • Symbol delete vote.svg Delete until IDs aren't persistent. Nomen ad hoc (talk) 18:17, 2 September 2019 (UTC).
  • If this was just another property for an online version of an old encyclopedia (like various others we have), there wouldn't be a reason to delete it. Unfortunately, there are several problems surrounding this particular site. One is the lack of stability of the site/IDs, another is the user/person behind it. The slugs/IDs used by the sites are not consistent and prone to change at any given moment, with no persistent ID or redirects from old values available. The other problem is the person who has been working on adding these IDs. Who AFAIK has been globally banned from all Wikimedida projects and still continues editing via IPs and sock puppets. It also seems this user is the person (or one of the persons) maintaining the website in question - so it would seem he's the one who keeps changing the entries' slugs/"IDs" himself and causing the problems on Wikidata when editors here try to come up with solutions to these changes. And has even been posting rants about Wikidata and Wikidata/Wikipedia users on that website. Overall, while the property might have some - albeit small - value, I have my doubts that all the constant changes, arguments, rants, blocks of IPs and sock puppets, etc. behind the scenes on Wikidata and Wikipedia are worth the hassle of keeping it around. --Kam Solusar (talk) 17:44, 15 September 2019 (UTC)
  • @Edgars2007: who proposed the property in good faith. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 30 October 2019 (UTC)
  • New edits by IP Example:
    Reginald Gruehn (Q2137976) (1929-2002)
    Baltisches Biographisches Lexikon digital ID (former scheme) (P2580): Gruehn-Reginald-1901-1991
    IP added: GND ID (P227): GND 119712716X with source BBLD:
    --Kolja21 (talk) 21:57, 28 December 2019 (UTC)
  • Symbol delete vote.svg Delete Vandalism targets. --Liuxinyu970226 (talk) 04:56, 1 January 2020 (UTC)
  • Symbol keep vote.svg Keep stay real adress on --Arachn0 (talk) 11:53, 2 January 2020 (UTC)
  • Symbol keep vote.svg Keep IDs are being improved now. --Mzngan (talk) 09:57, 6 January 2020 (UTC)
  • Symbol keep vote.svg Keep since used by several Wikipedias to generate external links, values should be fixed, vandalism undone. Michael FV (talk) 03:20, 9 January 2020 (UTC)
    @Michael FV: "used by several Wikipedias" isn't a proper keep reason, please consider other good reasons, thx. --Liuxinyu970226 (talk) 00:32, 10 January 2020 (UTC)
  • Pictogram voting comment.svg Comment "Mzngan" and "Michael FV" seems to be sock puppets of the global banned user. BTW one more example of BBLD IDs:
    • Heinricus Meurch (Q55195758) = Meurch-Heinricus-um-1699 [3]
    • Heinricus Meurch (Q55195758) = Meyendorff-Christoph-Gustav-Alexander-Frh.-v.-1796-1865 [4]
    • Heinricus Meurch (Q55195758) = GND1052457312 [5]
    • Heinricus Meurch (Q64690920) = Meurch-Heinricus-1676-1710 [6]
Imho both items can be merged. See also Property talk:P227/Duplicates with more items created because of constantly changing BBLD IDs (using different spellings, ISNI, VIAF now GND). --Kolja21 (talk) 00:49, 17 January 2020 (UTC)
@Kolja21: m:Steward_requests/Checkuser/2020-02#Tobias_Conradi_(or_影武者?)@wikidata tells me  unlikely. --Liuxinyu970226 (talk) 01:58, 25 February 2020 (UTC)
  • Symbol keep vote.svg Keep. The central maintenance of the BBLD IDs in Wikidata is easier than maintenance in individual Wikipedias, deleting the property would increase the workload for Wikipedia editors in the field of Baltic Germans.
The BBLD IDs are used for creating references in
  1. Wikidata, where it is often the only reference apart from VIAF (P214) and the GND (P227) - for the items in question the VIAF record is frequently based on the GND record and the GND record on the BBLD record
  2. Wikipedias // Google evidence
  3. the GND (authority file, hosted by the German National Library) // Google evidence
  4. publicly financed projects like the Deutsche Biographie, a major biographical publication // Google evidence
  5. privately owned projects like, which is also used in Wikidata (d:Property:P2600) // Google evidence.
The BBLD is a continuation of the DBBL (Deutschbaltisches biographisches Lexikon 1710-1960) which is frequently cited in the NDB for items about Baltic Germans. Both works are cited in scientific publications.
If IDs have been deprecated they should be either marked as such - the ("list of Wikidata reasons for deprecation") could indicate that marking values as deprecated is possible in Wikidata - or if no verifiable source is found they should be deleted.
David Feest, spokesperson of the Baltic Historical Commission for the BBLD and a reader of Wikipedia. Davidfeest (talk) 07:52, 20 January 2020 (UTC)

Commons category (P373)[edit]

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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol delete vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol delete vote.svg 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 Symbol keep vote.svg 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)
  • Symbol delete vote.svg 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)
    • Pictogram voting comment.svg 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)
  • Symbol neutral vote.svg 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)
  • Symbol keep vote.svg 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. [7]). 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)
  • Symbol keep vote.svg Keep read archives, not going to repeat myself. Multichill (talk) 16:57, 9 September 2019 (UTC)
    @Multichill: I've looked through the archives. At [8] 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 [9] 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)
  • Symbol keep vote.svg 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:G7 (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)
Symbol delete vote.svg 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. -- 02:39, 10 September 2019 (UTC)
  • Symbol delete vote.svg 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 sysop 20:50, 10 September 2019 (UTC)
  • Symbol keep vote.svg Keep unless is Commons linking issue finally resolved (abandon commons galleries sitelinking - I am afraid it needs another lengthy RFC), then Symbol delete vote.svg 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)
Pictogram voting comment.svg 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)
  • Symbol keep vote.svg 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)
  • Deprecate. I also agree with Mike Peel. --Tinker Bell 02:47, 20 September 2019 (UTC)
  • Pictogram voting question.svg 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)
  • Symbol keep vote.svg 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:
      ?commonsCategoryFromItem schema:about ?item;
                               schema:isPartOf <>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromItem), ""))
      ?item wdt:P910 ?catItem .
      ?commonsCategoryFromCatItem schema:about ?catItem;
                                  schema:isPartOf <>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromCatItem), ""))
    BIND(COALESCE(?commonsCategoryFromItem, ?commonsCategoryFromCatItem) AS ?commonsCategory)
Yes, it's possible (eg:
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) : 2.039 seconds. Count of corresponding commons categories using P373 : 4.187 seconds. Count of corresponding commons categories using sitelinks, P910 etc : 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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol delete vote.svg 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)
  • Symbol delete vote.svg 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)
Symbol delete vote.svg Delete Problemic property, should consider more smart ways instead. --2409:8902:9001:6CE0:5E2F:BCDA:B1D9:2A6F 00:22, 4 December 2019 (UTC)
  • Symbol keep vote.svg Keep Per above. + We will have problems with automatic cross-project linking without this property. --sasha (krassotkin) 14:13, 17 December 2019 (UTC)
  • Symbol keep vote.svg 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)
  • Symbol delete vote.svg Delete no reason to single out Commons, use topic's main category (P910) Michael FV (talk) 03:32, 9 January 2020 (UTC)
  • Symbol delete vote.svg 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. -- 23:20, 20 January 2020 (UTC)
  • Symbol delete vote.svg 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)
  • Symbol delete vote.svg Delete Unnecessary and useless. -- MovieFex (talk) 04:32, 29 March 2020 (UTC)
  • Symbol delete vote.svg 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)
  • Symbol delete vote.svg Delete Deprecate and delete. Two ways of linking is source for errors and confusion. MrProperLawAndOrder (talk) 17:44, 11 April 2020 (UTC)
  • Symbol delete vote.svg 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)
  • Symbol delete vote.svg Delete Deprecate and delete. Per Kees08 redundant and confusing. TechContribution (talk) 20:37, 30 April 2020 (UTC)
  • Symbol delete vote.svg 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)
Symbol delete vote.svg Delete There are ways to query better. -- 02:42, 9 May 2020 (UTC)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol delete vote.svg 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)
  • Symbol keep vote.svg Keep Many uses, a lot of things would break and this is a really useful thing.--Ferdi2005[Mail] 11:25, 9 July 2020 (UTC)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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)

Discussion (remaining issues)[edit]

I have a Pictogram voting question.svg 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)
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). 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)
  • Pictogram voting comment.svg 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 Transnistria (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?
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. Face-wink.svgAlexis 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)
  • Symbol delete vote.svg Delete per Mike Peel. NMaia (talk) 10:23, 17 September 2020 (UTC)
  • Symbol keep vote.svg 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)
  • Symbol keep vote.svg 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 ; 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)

IPA number order (P3917)[edit]

IPA number order (P3917): (delete | history | links | entity usage | logs | discussion)

This is an external identifier, but has the wrong datatype ("Quantity"). We could create a property, with the correct datatype, and migrate values. However, as there are only 173 of them, perhaps migrating to catalog code (P528), suitably qualified, would be better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:14, 15 September 2019 (UTC)

@Giovanni Alfredo Garciliano Diaz, ChristianKl: do you have any opinion? To me, I do not see why number is not the correct datatype. Do you mean it should be external identifier? If so, to which link? Or string? Or something else? Pamputt (talk) 06:19, 16 September 2019 (UTC)
We don't have a number datatype and the quantity type we do has it's +/- interval by default.
I don't have strong feelings but would be okay with migrating it to catalog code (P528). ChristianKl❫ 07:50, 16 September 2019 (UTC)
When I proposed P3917, I ignored many things about how Wikidata work. Now, I agree with migrating it to catalog code (P528). --Tinker Bell 02:21, 20 September 2019 (UTC)
  • Symbol delete vote.svg Delete a number is not a quantity, store information in a new property with the correct datatype: external identifier. Michael FV (talk) 03:42, 9 January 2020 (UTC)
Symbol keep vote.svg Keep Used by some MediaWiki extensions, Please consult before deletions. -- 02:45, 9 May 2020 (UTC)
@Krenair: ^^ Is this really? ^^ --Liuxinyu970226 (talk) 23:45, 9 May 2020 (UTC)
I have no idea but I haven't been able to find references to P3917 myself, on or in a search of most MediaWiki extension repositories. --Krenair (talkcontribs) 00:34, 10 May 2020 (UTC)
Symbol delete vote.svg Delete Agree with migration to P528. --SilentSpike (talk) 21:41, 15 June 2020 (UTC)

territory claimed by (P1336)[edit]

territory claimed by (P1336): (delete | history | links | entity usage | logs | discussion)

Based on this RFC, I think it's now the good time we deprecate it, it's already enough to say something is conflicting between two and more countries, by adding qualifiers to their country (P17) values. —Liuxinyu970226 (talk) 00:13, 15 November 2019 (UTC)

Pictogram voting comment.svg Comment Who will move current uses to a new ontology ?. I think we cannot delete until there are no uses of it.Amadalvarez (talk) 09:14, 15 November 2019 (UTC)
@Amadalvarez: Just merge em back to P17, see RFC for details. --Liuxinyu970226 (talk) 22:59, 16 November 2019 (UTC)
  • Symbol keep vote.svg Keep not only a country can claim territory. Michael FV (talk) 03:51, 9 January 2020 (UTC)
    @Michael FV: Please read that RFC carefully before such voting keep, thx. --Liuxinyu970226 (talk) 00:31, 10 January 2020 (UTC)
  • Some uses of this are countries claimed by another country, or by each other. With this change, would Cyprus would only have "country: Northern Cyprus" and Northern Cyprus only have "country: Cyprus", or would the items also have P17 statements linking to themselves? There are probably others that are similar. Peter James (talk) 16:24, 17 January 2020 (UTC)
  • Symbol keep vote.svg Keep given the points mentioned in the rfc --- Jura 11:02, 20 January 2020 (UTC)

j*:@Jura1: Which point. --2409:8902:9001:1F4F:1444:B367:16E3:3F84 00:59, 21 January 2020 (UTC)

  • Symbol delete vote.svg Delete Given that this is spammly used to make so-called claim e.g. wrongly says that "Shenzhen is a part of Hong Kong". -- 22:32, 20 January 2020 (UTC)
Symbol delete vote.svg Delete Replacement available. -- 22:09, 9 May 2020 (UTC)
  • Pictogram voting comment.svg Comment I repeat my concern that the current information should be move to new ontology before delete. Liuxinyu970226 told me that "I follow RFC", but I'm user of this information in WD powered infoboxes. I'll take care handling new structure in infoboxes code, but not migrating data, because IMHO it should be move in a batch process when the change were full approved. Thanks, Amadalvarez (talk) 16:57, 21 May 2020 (UTC)
  • In addition, could you please write down the final ontology with {{Claim}} or similar. I'm not sure if "new properties" described in inital proposal have been created (and what are?) or you decide use some other proposed in the discussion. What are the final combination of property and qualifiers for each circumstances described in "Proposal section" ?. etc. Maybe in your mind it's very clear, but a RFC is open for "comments". So, if it is still open, please ping me when we have a final ontology. Thanks, Amadalvarez (talk) 19:36, 21 May 2020 (UTC)
Pictogram voting comment.svg Comment Could you give an example of new modelling for instance in the very famous Taiwan (Q865) and People's Republic of China (Q148) ? I'm interested as I'm having a topic here Bouzinac💬✒️💛 20:49, 13 September 2020 (UTC)

Deutsche Bahn station category (P5105)[edit]

Deutsche Bahn station category (P5105): (delete | history | links | entity usage | logs | discussion)

I don't think we need a specialized property than station class (P5606). GZWDer (talk) 21:46, 8 December 2019 (UTC)

Multichill (talk) Thryduulf (talk) 21:38, 2 November 2013 (UTC) -revi (talkcontribslogs)-- 01:13, 3 November 2013 (UTC) (was Hym411) User:JarrahTree (talk) 06:32, 3 November 2013 (UTC) A.Bernhard (talk) 08:28, 9 November 2013 (UTC) Micru (talk) 12:36, 9 November 2013 (UTC) Steenth (talk) YLSS (talk) 13:59, 25 November 2013 (UTC) Konggaru (talk) 12:31, 14 December 2013 (UTC) Elmarbu (talk) 21:48, 17 December 2013 (UTC) Nitrolinken (talk) 16:30, 14 February 2014 (UTC) George23820 Talk‎ 17:39, 17 August 2014 (UTC) Daniele.Brundu (talk) 21:34, 30 August 2015 (UTC) Dannebrog Spy (talk) 16:13, 9 December 2015 (UTC) Knoxhale 18:39, 26 June 2016 (UTC) happy5214 22:48, 8 July 2016 (UTC) Jklamo (talk) 07:32, 15 August 2016 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits DarTar (talk) 16:36, 5 September 2016 (UTC) Pizza1016 (talk | contribs) 01:33, 10 November 2016 (UTC) Sascha GPD (talk) 23:00, 1 February 2017 (UTC) Liuxinyu970226 (talk) 09:09, 2 February 2017 (UTC) A1AA1A (talk) 18:17, 21 May 2017 (UTC) Mauricio V. Genta (talk) 13:56, 9 June 2017 (UTC) Sam Wilson 10:26, 18 June 2017 (UTC) Danielt998 (talk) 05:01, 28 August 2017 (UTC) Maxim75 (talk) 06:04, 22 September 2017 (UTC) NCFriend (talk) 12:29, 2 August 2017 (UTC) Fabio Bettani (talk) 17:48, 3 June 2018 (UTC) Geogast (talk) 23:51, 13 July 2018 (UTC) Jc86035 (talk) 08:48, 18 July 2018 (UTC) Bodhisattwa (talk) 19:29, 17 December 2018 (UTC) Jinoytommanjaly (talk) 13:13, 21 May 2019 (UTC) OktaRama2010 (talk) 00:25, 1 May 2020 (UTC) PhiH (talk) 14:20, 26 July 2020 (UTC) Jcornelius (talk) 18:47, 30 July 2020 (UTC) Mackensen (talk) 15:21, 29 August 2020 (UTC) Michgrig (talk) 22:04, 20 December 2020 (UTC)Pictogram voting comment.svg Notified participants of WikiProject Railways and especially, because it's used by hu:Sablon:Állomás infobox, @B.Zsolt, Tacsipacsi: ^^ --Liuxinyu970226 (talk) 00:54, 10 December 2019 (UTC)
Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)
Symbol keep vote.svg Keep Wikidata have lot of external identifiers, why need deletion? --B.Zsolt (talk) 13:31, 11 December 2019 (UTC)
Symbol delete vote.svg Delete@B.Zsolt: Because there's a more useful identifier as replacement. --Liuxinyu970226 (talk) 14:53, 11 December 2019 (UTC)
Symbol delete vote.svg Delete per Andy. This is an item property btw, not an external identifier property. Multichill (talk) 19:04, 12 December 2019 (UTC)
Symbol delete vote.svg Delete after data migration. Robin van der Vliet (talk) (contribs) 00:43, 16 December 2019 (UTC)
Symbol keep vote.svg Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:27, 16 December 2019 (UTC)
Symbol delete vote.svg Delete The specific property (P5105) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the operator can be inferred from the station category items, so including the operator as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)
  • Symbol keep vote.svg Keep per Thryduulf Michael FV (talk) 04:01, 9 January 2020 (UTC)
  • Symbol keep vote.svg Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 11:04, 20 January 2020 (UTC)
  • Symbol delete vote.svg Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. -- 23:22, 20 January 2020 (UTC)
  • Symbol keep vote.svg Keep per above Germartin1 (talk) 09:55, 2 April 2020 (UTC)
    @Jura1, Germartin1: "Enables reports with someone's bot" isn't a valid keep reason, we can ask them on Github to request cancelling their relative codes. --Liuxinyu970226 (talk) 00:49, 8 April 2020 (UTC)
Symbol delete vote.svg Delete As values are only items, merge em back won't hurt anything. -- 22:11, 9 May 2020 (UTC)
  • Symbol delete vote.svg Delete No need to fragment data into multiple properties. --Tinker Bell 01:55, 25 October 2020 (UTC)

United Kingdom Department for Transport railway station category (P5330)[edit]

United Kingdom Department for Transport railway station category (P5330): (delete | history | links | entity usage | logs | discussion)

I don't think we need a specialized property than station class (P5606). GZWDer (talk) 21:46, 8 December 2019 (UTC)

Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)
Symbol keep vote.svg Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:28, 16 December 2019 (UTC)

Multichill (talk) Thryduulf (talk) 21:38, 2 November 2013 (UTC) -revi (talkcontribslogs)-- 01:13, 3 November 2013 (UTC) (was Hym411) User:JarrahTree (talk) 06:32, 3 November 2013 (UTC) A.Bernhard (talk) 08:28, 9 November 2013 (UTC) Micru (talk) 12:36, 9 November 2013 (UTC) Steenth (talk) YLSS (talk) 13:59, 25 November 2013 (UTC) Konggaru (talk) 12:31, 14 December 2013 (UTC) Elmarbu (talk) 21:48, 17 December 2013 (UTC) Nitrolinken (talk) 16:30, 14 February 2014 (UTC) George23820 Talk‎ 17:39, 17 August 2014 (UTC) Daniele.Brundu (talk) 21:34, 30 August 2015 (UTC) Dannebrog Spy (talk) 16:13, 9 December 2015 (UTC) Knoxhale 18:39, 26 June 2016 (UTC) happy5214 22:48, 8 July 2016 (UTC) Jklamo (talk) 07:32, 15 August 2016 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits DarTar (talk) 16:36, 5 September 2016 (UTC) Pizza1016 (talk | contribs) 01:33, 10 November 2016 (UTC) Sascha GPD (talk) 23:00, 1 February 2017 (UTC) Liuxinyu970226 (talk) 09:09, 2 February 2017 (UTC) A1AA1A (talk) 18:17, 21 May 2017 (UTC) Mauricio V. Genta (talk) 13:56, 9 June 2017 (UTC) Sam Wilson 10:26, 18 June 2017 (UTC) Danielt998 (talk) 05:01, 28 August 2017 (UTC) Maxim75 (talk) 06:04, 22 September 2017 (UTC) NCFriend (talk) 12:29, 2 August 2017 (UTC) Fabio Bettani (talk) 17:48, 3 June 2018 (UTC) Geogast (talk) 23:51, 13 July 2018 (UTC) Jc86035 (talk) 08:48, 18 July 2018 (UTC) Bodhisattwa (talk) 19:29, 17 December 2018 (UTC) Jinoytommanjaly (talk) 13:13, 21 May 2019 (UTC) OktaRama2010 (talk) 00:25, 1 May 2020 (UTC) PhiH (talk) 14:20, 26 July 2020 (UTC) Jcornelius (talk) 18:47, 30 July 2020 (UTC) Mackensen (talk) 15:21, 29 August 2020 (UTC) Michgrig (talk) 22:04, 20 December 2020 (UTC)Pictogram voting comment.svg Notified participants of WikiProject Railways Thryduulf (talk) 14:29, 16 December 2019 (UTC)

Symbol delete vote.svg Delete I agree with GZWDer and Andy, not need to have a special property and delete after migration. Multichill (talk) 18:48, 16 December 2019 (UTC)
Symbol delete vote.svg Delete The specific property (P5330) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the network can be inferred from the station category items, so including the network as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)
Symbol delete vote.svg Delete Per above, unlike station codes and line numbers where both may triage URL schemes, linking to these items for ranking of stations are good enough. --Liuxinyu970226 (talk) 11:26, 17 December 2019 (UTC)
Additionally, should we redesign the {{Ping project|Railways}} to be {{Ping project|Taxonomy}} like? --Liuxinyu970226 (talk) 11:27, 17 December 2019 (UTC)
  • Symbol keep vote.svg Keep per description of P5606: "Use subproperties where available" Michael FV (talk) 04:03, 9 January 2020 (UTC)
    @Michael FV, Thryduulf: If there's no URL schemes for "subproperties" available, then there are entirely no reason to have subproperties, we can merge them back to this one now. --Liuxinyu970226 (talk) 00:30, 10 January 2020 (UTC)
    @Liuxinyu970226: If you think a property needs to be merged then what you need to do is get consensus to merge it, not nominate it for deletion. My recommendation to keep this stands. Thryduulf (talk) 09:53, 10 January 2020 (UTC)
@Thryduulf: Hmm, is there be possible to merge two or more properties without deleting? --Liuxinyu970226 (talk) 09:52, 23 October 2020 (UTC)
  • Symbol keep vote.svg Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 10:58, 20 January 2020 (UTC)
  • Symbol delete vote.svg Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. ForIvan_A._Krestinin'sbot, Ithink weshouldasktheproblem viatheirGithub? -- 23:23, 20 January 2020 (UTC)
Symbol delete vote.svg Delete As values are only items, merge em back won't hurt anything. -- 22:11, 9 May 2020 (UTC)
  • Symbol delete vote.svg Delete No need to fragment data into multiple properties. --Tinker Bell 01:53, 25 October 2020 (UTC)

Argentinian Historic Heritage ID (P4587)[edit]

Argentinian Historic Heritage ID (P4587): (delete | history | links | entity usage | logs | discussion)

Doesn't exist anymore (and is not coming back in the same format) —Mauricio V. Genta (talk) 01:00, 10 December 2019 (UTC)

Keep and mark as historic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:06, 10 December 2019 (UTC)
If it was used a lot I would say mark as historic, but I see it's used less than 50 times so in this case it's not really worth the effort to keep it around. @Mauricio V. Genta: what's the replacement for Argentina? Looking in the monuments database I see links, but these go nowhere. Multichill (talk) 19:01, 12 December 2019 (UTC)
Nothing. It was really kind of a test, i did not see the property request in time to vote negative. They do not have a URI or unique ID for them, not even in physical paper. From my position in WMAR, and as a museology student in the school that depend on the National Commission of Monuments, already advised them in better practices and the uses of URIs..but there is no budget. Mauricio V. Genta (talk) 04:52, 13 December 2019 (UTC)
Symbol delete vote.svg Delete Since no archives available for em. --Liuxinyu970226 (talk) 03:42, 8 January 2020 (UTC)
  • Symbol keep vote.svg Keep shutdown of other site is no reason for deletion of information from own site. Michael FV (talk) 04:12, 9 January 2020 (UTC)
    @Michael FV: obsolete Wikidata property (Q18644427) says "If there is no archived version mark for deletion with "obsolete Wikidata property"", so do you have any archive places of this? If not, then shutted down is just a valid reason to delete this. --Liuxinyu970226 (talk) 00:58, 10 January 2020 (UTC)
  • It's hardly used, otherwise I'd keep it. --- Jura 10:59, 20 January 2020 (UTC)
  • Symbol delete vote.svg Delete Neither archives nor replacements available. -- 23:25, 20 January 2020 (UTC)
  • Symbol keep vote.svg Keep. How can we be sure the data isn't available somewhere (there are archives other than and this wouldn't be eventually useful? Just add a notice that it's historical. BrokenSegue (talk) 05:59, 21 May 2020 (UTC)
  • Symbol keep vote.svg Keep, as some of the links from are still accessible through the Wayback machine. See e.g.Teatro Colón (Q827401). --DavidJRasp (talk) 17:40, 9 August 2020 (UTC)
  • Symbol keep vote.svg Keep Keep and mark as historic. --Sezgin İbiş (talk) 22:06, 6 September 2020 (UTC)
  • Symbol delete vote.svg Delete per the above. NMaia (talk) 02:31, 14 October 2020 (UTC)

Familypedia person ID (P4193)[edit]

Familypedia person ID (P4193): (delete | history | links | entity usage | logs | discussion)

This property is redundant and should be replaced by Fandom article ID (P6262) Trade (talk) 16:28, 22 March 2020 (UTC)

Symbol delete vote.svg Delete Just once parameters migrations are done. --Liuxinyu970226 (talk) 11:22, 24 March 2020 (UTC)
Symbol delete vote.svg Delete Per nomination. The Property is very redundant. Current uses should be migrated. –MJLTauk 07:56, 16 November 2020 (UTC)

Scoresway soccer person ID (P3043)[edit]

Scoresway soccer person ID (P3043): (delete | history | links | entity usage | logs | discussion) does not exist any more. Their website says Scoresway has a new home at So now the links redirect to Soccerway website, which means it's a duplicate to Soccerway player ID. Other Scoresway IDs need deleting aswell, but are possibly not duplicated. Pelmeen10 (talk) 10:52, 2 April 2020 (UTC)

  • Symbol delete vote.svg Delete on this and the others - but you should probably not remove id's until there's a consensus reached here. ArthurPSmith (talk) 18:09, 2 April 2020 (UTC)
  • A little Symbol keep vote.svg Keep, please confirm that if there's online archives (e.g. from for or not. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
    @Liuxinyu970226: covers all the soccer (football) articles with the exact same content +updates, so online archives are not needed here. Pelmeen10 (talk) 12:05, 3 April 2020 (UTC)
    @Liuxinyu970226, Pelmeen10: A ping without a new ~~~~ is not a ping. —Eihel (talk) 17:17, 3 April 2020 (UTC)
    Symbol delete vote.svg Delete By my recent searching of, there's indeed no archives of those URLs. --Liuxinyu970226 (talk) 12:14, 22 April 2020 (UTC)
  • Symbol keep vote.svg Keep 72000 uses. --- Jura 08:09, 10 April 2020 (UTC)
    • @Jura1: What's the point when Soccerway ID covers it 100% (I've checked the archived pages). The ID's are even the same. User:Zyxw recently added Soccerway ID's to all that had Scoresway ID's. So no information is lost here and archives not needed. But he also did the opposite - adding Scoresway ID's based on their Soccerway ID's, I don't know why. Pelmeen10 (talk) 12:44, 11 April 2020 (UTC)
  • Symbol delete vote.svg Delete, after ensuring that all entities with the Scoresway property have the equivalent Soccerway property and any templates using Scoresway are updated to use Soccerway. Both websites were/are owned by Perform Group and displayed the same data. The main difference was that Scoresway used a common formatter URL for players, managers, and referees ($1) while Soccerway uses different URLs ($1/,$1/,$1/). The old Scoresway player URLs such as now redirect to the main page (not the player page). On a related note, it might make sense to add new properties for Soccerway coach/manager ID and Soccerway referee ID, similar to how Soccerbase has Soccerbase player ID (P2193), Soccerbase manager ID (P2195), and Soccerbase referee ID (P7465). -- Zyxw (talk) 08:10, 12 April 2020 (UTC)
  • Symbol delete vote.svg Delete Germartin1 (talk) 09:09, 3 May 2020 (UTC)
  • Symbol keep vote.svg Keep The benefit is in being able to resolve the identifier, not just the linked content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 25 May 2020 (UTC)
    @Pigsonthewing: It's already confirmed unable to resolve this identifier. --Liuxinyu970226 (talk) 12:59, 2 June 2020 (UTC)
    Not so; if a user has the ID value "783", they can currently access Wikidata to resolve that value to Gary Caldwell (Q334628). If we delete the property, that will no longer be the case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:05, 2 June 2020 (UTC)
  • One of the properties should be deleted, however the text portion of Soccerway IDs are meaningless and not necessary (as shown by the current URL for Scoresway soccer person ID (P3043)). Therefore, I believe any items with Soccerway player ID (P2369) but not Scoresway soccer person ID (P3043) should have the ID transferred over, and then Soccerway player ID (P2369) should be deleted. This would make Soccerway IDs far easier to work with (for example in queries), as sometimes the text portion of Soccerway IDs are trimmed or malformed when imported to Soccerway player ID (P2369). S.A. Julio (talk) 17:37, 27 October 2020 (UTC)

Scoresway volleyball person ID (P6066)[edit]

Scoresway volleyball person ID (P6066): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as is defunct. I already removed the few usages it had. Pelmeen10 (talk) 11:14, 2 April 2020 (UTC)

  • A little Symbol keep vote.svg Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
    • @Liuxinyu970226: Online archives are mostly not available (specific links has to be checked one by one). Only if the link was used as a reference in Wikipedia - then automatically makes a copy (but unfortunately often the links were not). So in some cases the archives may be available, but what would you do with these properties after kept? Seems pretty useless to me. Pelmeen10 (talk) 12:22, 3 April 2020 (UTC)
      • @Pelmeen10: Why delete information though? Why remove existing entries? I suggest you revert you removal of its usages and we keep it. BrokenSegue (talk) 19:14, 29 May 2020 (UTC)
  • Pictogram voting comment.svg Comment hardly used. --- Jura 08:10, 10 April 2020 (UTC)
  • Symbol delete vote.svg Delete No archive, 15 uses only.--Jklamo (talk) 14:26, 6 September 2020 (UTC)

Scoresway rugby person ID (P6065)[edit]

Scoresway rugby person ID (P6065): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as is defunct. I already removed the few usages it had. Pelmeen10 (talk) 12:36, 2 April 2020 (UTC)

  • A little Symbol keep vote.svg Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
  • Had never more than 50 uses .. I'd tend to delete this --- Jura 08:18, 10 April 2020 (UTC)
    • Then, please discuss at the projects where is used first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

Scoresway handball person ID (P4451)[edit]

Scoresway handball person ID (P4451): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as is defunct. Pelmeen10 (talk) 19:56, 2 April 2020 (UTC)

Scoresway tennis person ID (P6308)[edit]

Scoresway tennis person ID (P6308): (delete | history | links | entity usage | logs | discussion)

Pages do not exist as is defunct. Pelmeen10 (talk) 19:56, 2 April 2020 (UTC)

  • A little Symbol keep vote.svg Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
  • >800 uses. I'd tend to keep. --- Jura 08:15, 10 April 2020 (UTC)
  • Remove, useless. Stryn (talk) 13:56, 13 April 2020 (UTC)

Joconde IDs[edit]

I propose to merge these properties to one single property for consistency. See User_talk:Vladimir_Alexiev#Joconde_IDs.--GZWDer (talk) 06:37, 4 April 2020 (UTC)

Symbol delete vote.svg Delete That's fine with me. But you should maybe propose a new property for this first, or pick one of them to be the main one? ArthurPSmith (talk) 17:32, 6 April 2020 (UTC)
I rescind my vote here given the discussion below - if there are cases where the same item would have identifiers from more than one of these properties, then keeping them separate seems the better choice. I really don't have a strong opinion on this either way though. ArthurPSmith (talk) 13:24, 8 April 2020 (UTC)
Symbol keep vote.svg Keep Those properties link to different and specific vocabularies. For reuse, we need this differentiation. For example on Nicolas Poussin (Q41554) with the value of Joconde author ID (P7711) we can make a link trough the structured data on to make enable a specific search to the POP results on Jocond Artist field. --Shonagon (talk) 11:39, 7 April 2020 (UTC)
Symbol keep vote.svg Keep If we merge the Joconde properties it may lead to confusion between similar terms used in different vocabularies and lose their original meaning. For example Domaine : Afrique du Nord and Lieux : Afrique du Nord --Christelle Molinié (talk) 16:06, 7 April 2020 (UTC)
As Joconde is a French website:

Benoît Prieur
Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Nattes à chat
Pierre André
Mathieu Kappler
Archives nationales DJI
Pictogram voting comment.svg Notified participants of WikiProject France --Liuxinyu970226 (talk) 01:23, 8 April 2020 (UTC)

  • Symbol keep vote.svg Keep: same as for Shonagon. Nomen ad hoc (talk) 06:56, 8 April 2020 (UTC).
  • Symbol neutral vote.svg Neutral both cases (unique property or separate properties) have advantages. For the records, there was a unique property P3905 (P3905) (created in 2017, Wikidata:Property proposal/Ginco id) but it has been deleted (in 2018) and split into these separate properties. I'm not keen to go back to the previous situation without a good reason. That said, to answer @ArthurPSmith: question, if we go back so a single property, the best would be to undelete P3905 (P3905). Cdlt, VIGNERON (talk) 08:13, 8 April 2020 (UTC)
  • Symbol keep vote.svg Keep Per Shonagon, Christelle Molinié and VIGNERON. There are edge cases that would be too far and wide to solve easily, seeing as some items can fall into two (or more ? ) categories, depending on the axis you want to reach them from, and it is actually sometimes interesting to search all items by one axis, which merging all properties would make a bit more complicated. As an aside, unlike what was said on Vladimir Alexiev's talk page, they aren't "UUIDs" as they're not 128-bit integers (even assuming the letters to be 8-bit) : unique identifiers aren't necessarily UUIDs… Alphos (talk) 09:14, 8 April 2020 (UTC)
  • I suggest you synthesis and maybe a unanimous exit will see the light of day. Above all, tell me if I write bullshit!
    1. I think ArthurPSmith votes {{Vd}} because he sees that it is technically possible. The identifiers of each property will always be linked to a part of, but in a different way (url_prefix) and will always point to the right page (for each property). I think he has in mind the example of IMDb ID (P345): IDs present for each part (tt, nm, etc.), but linked by a single property. But he expressed the reservation that a proposal be made. (Maybe he's even waiting for a "Pull request" for index.php ?)
    2. So the opinions of @Shonagon, Christelle Molinié, Alphos: can be guaranteed, whether it is Author, Location or Domain, and whether it is UUid or not.
    3. For P3905 (P3905) from VIGNERON, the return of this property should not be useful, but when I see that sword (Q12791) has not been carried over to Thésaurus de la désignation des objets mobiliers ID (P4979), it would be useful to recover the old forgotten IDs.
    4. According to the problems formulated above, single-value constraint (Q19474404) and distinct-values constraint (Q21502410) will no longer be used in the future Property and indicated in the proposal. Only the complexity of RegEx will allow proper use.
    5. For RegEx, I recommend a separation of a term designating one of the old Property by : and the IDs themselves. The old RegEx will be taken over to form the new RegEx. So the future Regex will have the following form: (thesaurus:(T69-[1-9]\d{0,6}|T96-[1-9]\d{0,6})|author:(T513-[1-9]\d{0,4}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|domain:(T51-[1-9]\d{0,2}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|epoch:[1-9]\d{0,5}|etc. I don't know how long a RegEx can take on WD. Current Ids will take a prefix: thesaurus, author, domain, epoch, etc. Example of ID provided by Shonagon: Nicolas Poussin (Q41554)author:T513-25084. syntax clarification (P2916) should be used to refer contributors.
    6. Before deletion, the old IDs should be taken back. They are 363. This is why I agree with Symbol delete vote.svg Delete: some current properties have less than 10 entries. Maybe an Open Refine would take the IDs (fetch URL?). I would also like a proposal before deletion. Warmest regards —Eihel (talk) 12:30, 8 April 2020 (UTC)
  • Symbol neutral vote.svg NeutralEihel (talk) 01:31, 19 February 2021 (UTC)
  • My first idea (before discussion with Vladimir Alexiev and this proposal) is to create a new property "Joconde UUID" and rename all other properties to "Joconde legacy xxx ID".--GZWDer (talk) 12:59, 8 April 2020 (UTC)
@Eihel: I'm sure I understand your position. You say « the return of this property should not be useful » and then « I agree with {{Vd}} », but deletion of the separate properties is exactly the same as return to P3905 (P3905).
Plus, the analogy with IMDb ID (P345) is only partially relevant as each part is separate and disjoint (it's tt or - exclusive or - nm, which make it easier to manage and maintain) while here there is a lot of overlap between the thesauri (it's T69- and T96- for example) which may cause some trouble (including but not limited to the "single value" constraint as you pointed out; the "unique distinct value" constraint is still true though).
Cheers, VIGNERON (talk) 13:45, 8 April 2020 (UTC)
@Eihel: Yes that could have been a solution except that unfortunately the prefix is not reliable. It is a remnant of an old system for ancient entries. All new entries use UUID and are intentionally opaque. Example of artist Joconde with UUID: MASCAUX Claude Léon. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)
  • I have another point for deletion: there seems to be much more thesauri than Wikidata properties we have. Creating an property for each of them does not seems scalable.--GZWDer (talk) 13:48, 8 April 2020 (UTC)
@GZWDer: These vocabularies are all those of the Joconde database and are particularly important in France, used for hundreds of museum collections. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)
  • Pictogram voting comment.svg Comment This thus look rather un-coodinated. We also seem to have more properties than some of those properties have actual uses. How many more properties should there be created? --- Jura 08:13, 10 April 2020 (UTC)
  • Symbol keep vote.svg Keep See @Christelle Molinié, Shonagon: had a phone call a few days ago with colleagues at the french Ministry of Culture. (@DannyS712, ArthurPSmith, 99of9, Nikola Tulechki, Crowjane7, GZWDer:). They said they'll keep separate thesauri, are very interested in linking to WD, and are working to link the thesauri to POP (the FR aggregation of artworks). I completely agree with Christelle that we have to respect the wish/organization of the thesaurus provider, despite some messiness in their organization. What we need to do is below. I hope people, @Christelle Molinié, Shonagon: can help with the last 3 bullets (the last 2 are the big-effort part) --Vladimir Alexiev (talk) 10:28, 23 April 2020 (UTC)
    • Relax regexes to just [\w-]+
    • Edit formatterURL to remove T69- (and the like)
    • Migrate existing values to put T69- (and the like) inside the value
    • Create a central page to describe all FR thesauri, with description, links to home page and prop, MnM catalog. A good place is a sub-page of Wikidata:WikiProject Visual arts
    • Import more of the thesauri to Mix-n-Match catalogs so they can be coreferenced
    • (when there is interest) Create more props and catalogs for more thesauri
Yes I see a point for doing so. I withdrew the deletion request but this should not be closed yet until others agree Vladimir Alexiev's proposal.--GZWDer (talk) 12:15, 23 April 2020 (UTC)
Vladimir Alexiev's proposal sounds fine to me. ArthurPSmith (talk) 20:44, 30 April 2020 (UTC)
  • I dont't think the id should be changed to include the database identifier if we keep separate properties. --- Jura 07:58, 2 May 2020 (UTC)
OTH, the format seems to be either "<database id><old id>" or "<uuid>" .. --- Jura 08:03, 2 May 2020 (UTC)

@Alphos, @ArthurPSmith, @Christelle Molinié, @Eihel, @GZWDer, @Jura, @Liuxinyu970226, @Nomen ad hoc, @VIGNERON, @Vladimir Alexiev
Following the various suggestions:

IMHO, creating more props for more thesauri is a challenge depending on the interest of the thesaurus and the implication of wikidata editors. For information there is a script on Github that can help to convert a data.culture vocabulary (in RDF/XML syntax) to a CSV file for Mix'n'Match, using the SKOS poperties (altLabel, broader, narrower) for description.
Best regards --Shonagon (talk) 11:43, 12 May 2020 (UTC)

Thanks @Shonagon: that's great!

Hi @Vladimir Alexiev: I've started the translation here but haven't finished yet. Maybe a lot of things to correct...--Christelle Molinié (talk) 10:15, 27 May 2020 (UTC)
Symbol keep vote.svg Keep Okay, per Vladimir Alexiev, I don't think that deprecating it is good for us. --Liuxinyu970226 (talk) 22:41, 3 June 2020 (UTC)

Symbol delete vote.svg Delete How do I add to telephone (Q11035)? There does not seem to be an applicable Joconde (Q809825) vocabulary property here even though these are now all managed under the same GINCO ("Gestion Informatisée de Nomenclatures Collaboratives et Ouvertes") software at the Ministry of Culture (France) (Q384602). Also newer terms have UUID identifiers that do not specify a specific vocabulary. This and the fact that they all currently have the same valued for ARK formatter (P8054) and formatter URL (P1630) makes me think these various properties ought to be merged. If we are to keep the separate Joconde (Q809825) properties they should be restricted to the appropriate Archival Resource Key (Q2860403) subspace instead of attempting to share the same. Some method should be devised to support the newer UUID identifiers too. Thanks. 02:06, 13 September 2020 (UTC)

Nobel prize ID (P3188)[edit]

Nobel prize ID (P3188): (delete | history | links | entity usage | logs | discussion)

This property is obsolete. When created we assumed that had a stable web which is not the case. As Nobelprize has an API were every Nobelprize winner is identified with an unique persistant number a new property Nobel Laureate API ID (P8024) has been created. This new property Nobel Laureate API ID (P8024) is now also used by Template:Nobelprize (Q91652187) as we now have a new linking model see T248939 and T251055Salgo60 (talk) 04:38, 30 April 2020 (UTC)

Why is it that when I click on the link at Nobel_prize_ID I get taken to a biography, and when I click on the new links I get an error message? This is the new link we are using for Marie Curie: Marie Curie This is the the old link Marie Curie. All three examples at Nobel Laureate API ID give error messages. What is going on? We should keep the old system in place until the new system is stable. --RAN (talk) 15:13, 6 May 2020 (UTC)
@Richard Arthur Norton (1958- ): had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 09:36, 13 May 2020 (UTC)
  • The problem appears to be fixed now. --RAN (talk) 05:04, 9 May 2020 (UTC) had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 10:43, 17 May 2020 (UTC)
  • Symbol delete vote.svg Delete: sounds sensible. Nomen ad hoc (talk) 18:06, 10 May 2020 (UTC).
  • Symbol keep vote.svg Keep: decent coverage (100%?), seems to be stable (since 4 years), used by other WMF sites, and the other id redirects there too. --- Jura 20:45, 13 May 2020 (UTC)
Pictogram voting comment.svg Comment I guess every third Nobelprize link has en:Link rot in en:Wikipedia and Nobel prize ID (P3188) has been impossible to maintain as it has changed more times when has done a new webdesign. Now takes responsibility for maintain this and we just need to store the unique number in Wikidata - Salgo60 (talk) 10:51, 17 May 2020 (UTC)
We already do store it. There is no need to delete historic information. This is not Wikipedia. --- Jura 11:20, 17 May 2020 (UTC)
Pictogram voting comment.svg Comment@Jura:please explain. The IT people at also see the chaos with linking the old web and agree of this new approach
- Salgo60 (talk) 01:07, 18 May 2020 (UTC)
  • Wikidata isn't here for the IT people at Identifiers here can be used outside the source database. If you find a database problematic, maybe you shouldn't propose storing (additional) identifiers for it. --- Jura 10:29, 18 May 2020 (UTC)
@Jura1: the discussion is about if we can delete Nobel prize ID (P3188) or not. I see no arguments why we shouldn't delete it
Just to update you on the background:
  1. Wikipedia has a lot of en:Linkrot to as the old approach with a relative path stored in Nobel prize ID (P3188) is not stable and has shown not working (I have seen no example of someone using it because of the bad quality)
    1. has had the anti-pattern when they redesigned the web or part of the web they changed urls and had no redirects --> Wikipedia got en:Linkrot and we couldn't maintain Nobel prize ID (P3188)
  2. created an API where every winner got an unique persistent id eg. en:Albert_Einstein has 26
  3. I have before raised this problem with the people that Wikipedia thinks is not stable linking (see blogpost 2019-feb) Wikipedia gets a lot of link root
  4. Mar 31 2020 see Task T248939 the following request was sent to the Nobel people if they could help Wikipedia making the linking more stable
  5. answer Apr 15 2020
  6. Wed, Apr 29, 11:42 AM the new solution was implemented using Nobel Laureate API ID (P8024)
Nobel prize ID (P3188) is and has been obsolete the last years so I recommend to delete it if no one can explain who is using it
- 18:37, 21 May 2020 (UTC)
I think you explained your webdirectory approach in detail. There are various ways of maintaining such things in an automated way, without alienating all users and requiring them to use a redirect service. --- Jura 20:00, 21 May 2020 (UTC)
@Jura: "redirect service"?!=?! tells us link us using the unique number we have dedicated every prizewinner as this is the only way we can manage the en:Linkrot. Step 1 is always to have persistently identifiers and now we have that

Did a fast check to see the quality of the old property Nobel prize ID (P3188) list compared with the new. Can be used if someone would like to maintain Nobel prize ID (P3188), less problem than I thought but now we have an easy way to find what the "correct link is" and with the new approach has "one" landing page for every Nobelprize winner also if they have received more prizes...

- Salgo60 (talk) 10:22, 22 May 2020 (UTC)

  • A little support Symbol delete vote.svg Delete, as I'm confused that what "redirect service" that @Jura1: said is. --Liuxinyu970226 (talk) 22:39, 3 June 2020 (UTC)
I guess the redirect mentioned is that Albert Einstein (Q937) with Nobel Laureate API ID (P8024)
  • has the following pattern with an unique number 26 --> that gets an redirect to
  • if we look at the usage of Nobel prize ID (P3188) we can see that the Nobelprize people also has created redirects when they changed the pages location. The problem is that this was not good maintained at the As they now has an API with unique numbers for every Nobelprize winner I guess this redirects will be easier to maintain for them and much easier for Wikidata as our link will be stable
- Salgo60 (talk) 09:35, 4 June 2020 (UTC)
  • Symbol delete vote.svg Delete I see no value in keeping this property. If we go ahead with deletion I suggest we warn wmfprojects who uses it, they should some time to change to the new ID before deletion IMO. Maybe we can put a redirect to this discussion on the deleted page or indicate in some way why it was deleted.  – The preceding unsigned comment was added by So9q (talk • contribs) at 12:59, 2 February 2021 (UTC) (UTC).
  • Symbol delete vote.svg Delete The property as described does not work with the Nobel Prize's present website (eg, medicine/laureates/1990/thomas should be medicine/1990/thomas/. It's not necessarily difficult to change all instances on wikidata, but such maintenance would have to be done if we keep the category, and at that point, it would almost certainly be better to use the more-stable API property. Mathmitch7 (talk) 22:50, 15 April 2021 (UTC)
  • Symbol keep vote.svg Keep Not used in Template:Nobelprize at the English Wikipedia but referenced at its documentation. Please discuss at the Village Pump first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

opponent during disputation (P3323)[edit]

opponent during disputation (P3323): (delete | history | links | entity usage | logs | discussion)

Too precise IMHO (less than 50 use cases); reviewed by (P4032) could be used instead (with a qualifier) —Nomen ad hoc (talk) 18:05, 10 May 2020 (UTC)

@Jura1: FYI. Nomen ad hoc (talk) 18:05, 10 May 2020 (UTC).

Also, @Jonathan Groß, Marcus Cyron, Frank Schulenburg, Tusculum, Pigsonthewing, ChristianKl: Nomen ad hoc (talk) 18:11, 10 May 2020 (UTC). @ArthurPSmith, WiseWoman, DerHexer: Nomen ad hoc (talk) 18:11, 10 May 2020 (UTC).
  • We debated a property called "proponent during disputation" why do we now have one called "opponent during disputation"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 10 May 2020 (UTC)
    Because the translation of the official term “adversariorum partes suscipient” suggests opponent. ;) Best, DerHexer (talk) 18:52, 10 May 2020 (UTC)
    The proposal mentioned no such term. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:52, 10 May 2020 (UTC)

I can't see any cause for a deletion. It's of great importance for science history. But not always easy to figure out. To delete it would be definetly work against the Wikidata mission. -- Marcus Cyron (talk) 21:01, 10 May 2020 (UTC)

has edition or translation (P747)[edit]

has edition or translation (P747): (delete | history | links | entity usage | logs | discussion)

The property is not needed as we have the inserve Property:P629. ChristianKl❫ 17:28, 15 May 2020 (UTC)

Morrigan68 (talk) 17:09, 7 March 2021 (UTC) Aubrey
Viswaprabha (talk)
Maximilianklein (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
PKM (talk) 19:58, 10 October 2014 (UTC)
Revi 16:54, 29 November 2014 (UTC)
Giftzwerg 88 (talk) 23:36, 1 January 2015 (UTC)
Almondega (talk) 00:17, 5 August 2015 (UTC)
Jura to help sort out issues with other projects
Skim (talk) 13:52, 24 June 2016 (UTC)
Marchitelli (talk) 12:29, 5 August 2016 (UTC)
Alexmar983 (talk) 23:53, 28 August 2016 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 10:44, 29 August 2016 (UTC)
Chiara (talk) 14:15, 29 August 2016 (UTC)
Thibaut120094 (talk) 20:31, 14 September 2016 (UTC)
Ivanhercaz | Discusión Plume pen w.png 15:30, 31 October 2016 (UTC)
YULdigitalpreservation (talk) 17:35, 10 November 2016 (UTC)
PatHadley (talk) 21:51, 15 December 2016 (UTC)
Erica (ohmyerica) (talk) 19:26, 1 January 2017 (UTC)
Mauricio V. Genta (talk) 05:38, 12 March 2017 (UTC)
Sam Wilson 09:24, 24 May 2017 (UTC)
Sic19 (talk) 22:25, 12 July 2017 (UTC)
MartinPoulter (talk) 09:21, 20 July 2017 (UTC)
ThelmadatterThelmadatter (talk) 01:11, 13 September 2017 (UTC)
Zeroth (talk) 15:01, 16 September 2017 (UTC)
Beat Estermann (talk) 20:07, 12 November 2017 (UTC)
Shilonite - specialize in cataloging Jewish & Hebrew books
Elena moz
Oa01 (talk) 10:52, 3 February 2018 (UTC)
Maria zaos (talk) 11:39, 25 March 2018 (UTC)
Wikidelo (talk) 13:07, 15 April 2018 (UTC)
Mfchris84 (talk) 10:08, 27 April 2018 (UTC)
Mlemusrojas (talk) 3:36, 30 April 2018 (UTC)
salgo60 Salgo60 (talk) 12:42, 8 May 2018 (UTC)
Dick Bos (talk) 14:35, 16 May 2018 (UTC)
Marco Chemello (BEIC) (talk) 07:26, 30 May 2018 (UTC)
 徵國單  (討論 🀄) (方孔錢 💴) 14:35, 20 July 2018 (UTC)
Alicia Fagerving (WMSE)
Louize5 (talk) 20:05, 11 September 2018 (UTC)
Viztor (talk) 05:48, 6 November 2018 (UTC)
RaymondYee (talk) 21:12, 29 November 2018 (UTC)
Merrilee (talk) 22:14, 29 November 2018 (UTC)
Kcoyle (talk) 22:17, 29 November 2018 (UTC)
JohnMarkOckerbloom (talk) 22:58, 29 November 2018 (UTC)
Tris T7 TT me
Helmoony (talk) 19:49, 8 December 2018 (UTC)
Shooke (talk) 19:17, 12 January 2019 (UTC)
DarwIn (talk) 14:58, 14 January 2019 (UTC)
I am Davidzdh. 16:08, 18 February 2019 (UTC)
Juandev (talk) 10:03, 27 February 2019 (UTC)
Buccalon (talk) 15:51, 27 March 2019 (UTC)
MJLTalk 16:48, 8 April 2019 (UTC)
Rosiestep (talk) 20:26, 24 April 2019 (UTC)
Dcflyer (talk) 12:23, 7 May 2019 (UTC)
Susanna Giaccai (talk) 05:56, 29 July 2019 (UTC)
Asaf Bartov (talk) 19:03, 31 July 2019 (UTC)
Msuicat (talk) 17:58, 6 August 2019 (UTC)
SilentSpike (talk) 15:27, 12 August 2019 (UTC)
TheFireBender (talk) 12:40, 20 August 2019 (UTC)
Jumtist (talk) 21:45, 22 October 2019 (UTC)
DrLibraryCat (talk) 18:25, 25 November 2019 (UTC)
ShawnMichael100 (talk) 20:04, 25 November 2019 (UTC)
Lmbarrier (talk) 19:47, 2 December 2019 (UTC)
Satpal Dandiwal (talk) 17:32, 16 December 2019 (UTC)
Rosiestep (talk) 17:08, 14 February 2020 (UTC)
Clifford Anderson (talk) 01:37, 1 April 2020 (UTC)
Discostu (talk) 09:02, 9 April 2020 (UTC)
Subodh (talk)
Iwan.Aucamp (talk) 14:02, 27 April 2020 (UTC)
Алексей Скрипник (talk) 15:31, 4 May 2020 (UTC)
MLeonStewart (talk) 18:04, 11 May 2020 (UTC)
ArielBritoJiménez (talk) 16:17, 31 May 2020 (UTC)
DanielleJWiki (talk) 16:16, 8 June 2020 (UTC)
Ninovolador (talk)
Alex (talk) 06:05, 3 August 2020 (UTC)
Alex_Q (talk) 11:11, 18 September 2020 (UTC)
See the bright light (talk)
Alessandra Boccone (talk) 11:18, 6 November 2020 (UTC)
Uomovariabile (talk) 09:54, 13 November 2020 (UTC)
Pru.mitchell (talk) 08:11, 17 November 2020 (UTC)
Carlobia (talk) 13:34, 26 November 2020 (UTC)
Mathieu Kappler (talk) 11:31, 12 December 2020 (UTC)
Pierre Tribhou (talk) 19:19, 28 December 2020 (UTC)
Alessandra.Moi (talk) 16:54, 20 February 2021 (UTC)
Kind data (talk) 18:09, 23 February 2021 (UTC)
Morrigan68 (talk) 17:11, 7 March 2021 (UTC)
ChristianBRoy (talk) 15:06, 27 April 2021 (UTC)
Antoine2711 (talk) 15:08, 27 April 2021 (UTC)
Ssstela (talk) 20:11, 22 May 2021 (UTC)
♦ L. Inafuko (talk) 21:20, 28 May 2021 (UTC)
Pictogram voting comment.svg Notified participants of WikiProject Books. Nomen ad hoc (talk) 19:49, 15 May 2020 (UTC).

  • For many books, I think things would be considerably easier if entities for such works were closer to the way lexemes work, i.e. with sub-entities for editions.
    The above property is a step in that direction. (Obviously, for works with many editions, the property isn't that useful). --- Jura 09:00, 16 May 2020 (UTC)
  • @ChristianKl: Der Nutzen der Eigenschaft wird unter Wikidata:WikiProject Books erläutert. Auf der dortigen Diskussionsseite könnte man diskutieren, falls sie überflüssig ist oder klarer beschrieben werden soll. --Kolja21 (talk) 19:38, 18 May 2020 (UTC)
    • @Kolja21: Es ist Konvention auf Wikidata die Diskussion, ob Eigenschaften gelöscht werden auf dieser Seite zu führen. ChristianKl❫ 20:59, 18 May 2020 (UTC)
  • @ChristianKl: since when is having inverse a reason for deletion? There is "child" too. I don't know why inverse exists, there might be reasons, but then it should be stated why any of the reasons do not apply here. MrProperLawAndOrder (talk) 21:04, 18 May 2020 (UTC)
  • We don't have any policy (or general norm) that suggests the need for a long post to start a deletion discussion that goes through detailed analysis. You haven't provided any reasoning for why the tradeoffs of introducing a new norm are worthwhile here. ChristianKl❫ 20:22, 19 May 2020 (UTC)
  • Symbol delete vote.svg Delete. --Tinker Bell 03:10, 20 May 2020 (UTC)
  • @ChristianKl: For the time being, I would be hesitant to support the deletion of this property. The property should eventually no longer be necessary, but there isn't yet sufficient support within other parts of MediaWiki for handling object-to-subject queries (even though Wikidata itself and third-party reusers would not be adversely affected by its deletion). As such, since inverse properties may still be used by other Wikimedia projects, I would suggest waiting until phab:T167521 and phab:T209559 have been resolved in a satisfactory manner. Are there any properties which have already been deleted due to being inverse properties? Jc86035 (talk) 17:06, 21 May 2020 (UTC)
  • Symbol keep vote.svg Keep I agree with Jc86035, until the Wikibase datastructure changegs, this should not be deleted. I also don't like this redundancy, but I think we need to wait. Germartin1 (talk) 07:38, 1 June 2020 (UTC)
  • Temporary Symbol keep vote.svg Keep per Jc86035, needs technical changes before deletion. --Liuxinyu970226 (talk) 22:55, 3 June 2020 (UTC)
  • Symbol delete vote.svg Delete --Haansn08 (talk) 02:04, 7 June 2020 (UTC)
  • Temporary Symbol keep vote.svg Keep per Jc86035. --Epìdosis 15:58, 8 June 2020 (UTC)
  • Symbol keep vote.svg Keep I am not a big fan of inverse properties, but this one is reasonably populated and mainly used by 9+ templates across multiple wikis. Is there any alternative for these templates? --Jklamo (talk) 16:24, 8 June 2020 (UTC)
  • Symbol keep vote.svg Keep. Very useful. How to easily find editions of some book from other edition? e.g. how to find bulgarian translaiton of The Raven (Q22726) from one of czech translations? see also phab:T128173. JAn Dudík (talk) 09:53, 15 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral. Think this makes sense here Mozilla Public License (Q308915) though I guess I can see how it is a bad crutch ... so neutral. Iwan.Aucamp (talk) 21:28, 7 July 2020 (UTC)
  • Symbol keep vote.svg Keep As long as complementary properties do not automatically work on both sides, it is necessary to mirror them in the inverse property. --ŠJů (talk) 23:52, 11 July 2020 (UTC)
  • Symbol keep vote.svg Keep Deleting it would be premature. Why rush? Antoine2711 (talk) 16:59, 30 October 2020 (UTC)
  • Symbol keep vote.svg Keep per Jklamo and ŠJů Vojtěch Dostál (talk) 14:30, 5 November 2020 (UTC)
  • Pictogram voting comment.svg Comment having to add both sides of any inverse relationship is a PITA, and having the ability to add a linkage from either side is a far better means, unidirectional only means will suck, especially when you are usually creating the item on the other side of a relationship.  — billinghurst sDrewth 04:23, 24 January 2021 (UTC)
  • Symbol keep vote.svg Keep until we implement a project wide policy of not having any bidirectional properties, this deletion request seems really arbitrary since it's just as useful as any other. Ainali (talk)

mountain range (P4552)[edit]

mountain range (P4552): (delete | history | links | entity usage | logs | discussion)

Too specific (not universal) alternative of geomorphological unit (P4688). These both can be merged with located on terrain feature (P706) which is the most universal, and its aliases indicate that it is intended also for similar nature-geographical location (geomorphological features/units and standing bodies of water). continent (P30) is also redundant. Various parallel types of division we can manage through qualifiers.

The localisation should be universal and hierarchic as well as located in the administrative territorial entity (P131) is. —ŠJů (talk) 23:37, 11 July 2020 (UTC)

Previous RFD: Wikidata:Requests_for_deletions/Archive/2014/Properties/1#P295
  • Symbol keep vote.svg Keep. It's just a way too important property for all sorts of items. Thierry Caro (talk) 08:45, 4 September 2020 (UTC)
  • Symbol keep vote.svg Keep until better ways of retrieving and filtering statements are developed on wikis Vojtěch Dostál (talk) 14:29, 5 November 2020 (UTC)
  • Symbol keep vote.svg Keep Not used in Template:Infobox mountain at the English Wikipedia but referenced at its documentation. Please discuss at the Village Pump first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)
  • Symbol keep vote.svg Keep This is a very important property for various items(glaciers comes to mind), so before merging it with another property lets open a discussion on the talk page and ping relevant projects. Abbe98 (talk) 13:02, 7 June 2021 (UTC)

Filmstarts title ID (P8531)[edit]

Initial discussion[edit]

Second discussion (?)[edit]

@Pamputt, Jura1: Jura1 reverted my archive action because "closed by involved admin", is this meaning that we should re-open the deletion discussions here? --Liuxinyu970226 (talk) 10:42, 23 October 2020 (UTC)
  • Symbol delete vote.svg Delete Unless if @pamputt, eihel: can explain why this is so-called "useful". -- 03:02, 27 October 2020 (UTC)

Symbol keep vote.svg Keep Hello Liuxinyu970226 Hello, Jura1 put up the same resistance for this closing. The community will be monopolized by trivia. I think I have to give a slightly stronger reply. …for 10 Seconds (Q169103), 177818 is the identifier for AlloCiné film ID (P1265) and 137934 is the identifier for filmstarts. There is no identifier for this movie for AdoroCinema film ID (P7777) and the contents are different. So the motivation of the applicant is still incorrect. We have all been clear and Pamputt is also doing what makes sense to her. This property was created because I contradicted Jura1's opposition in the proposal. If this contributor gives the same motivation here, the result is the same. Should an admin also archive closed debates? No, if Jura1 has a valid request, I am ready to discuss it, but we must follow the opinion of the community. If Pamputt creates a property because she considers the opposition to the creation to be unreasonable, I have no problem with closing a PFD if there are completely identical reasons and with stronger reasons if she's an admin. Jura1, you can focus on your own proposals… by putting the right datatype for example Face-grin.svg. Cordially. —Eihel (talk) 13:26, 27 October 2020 (UTC)

  • Symbol delete vote.svg Delete Thanks for re-opening this: the administrator (who created it before the usual seven day wait) is misusing their admin role by closing the deletion request.
    Besides, as noted just above, the identifier is identical to the one used in another property and the numbers show this eventually leads to massive duplication.--- Jura 19:33, 2 December 2020 (UTC)
@Liuxinyu970226: still only Jura1 (and one IP) opposes the creation of this property. Can we close this discussion now or should we wait longer (I do not expect more discussion about this, especially after the Eihel's reply). Pamputt (talk) 09:12, 4 January 2021 (UTC)
  • Pictogram voting comment.svg Comment: Out of 124 usages of the property, there are 41 identical to Allociné ID, 3 different, 80 without Allociné ID (and 52966 usages of Allociné ID without Filmstarts ID). --Mormegil (talk) 13:01, 4 January 2021 (UTC)
    @Jura1: If there are no conflicting uses, that does not mean that there are the same identifiers, on the contrary. When you add "this is the same identifier", I wonder if you are reading the comments correctly. Or is it preventing everyone from contributing serenely, or taking up time? It has not just been created, it is you who put this property here just after its creation more than five months ago, it is not by chance. The creation followed a normal process following the responses to your opposition during the proposal. The creation of this property was not prevented in any way, but you pursue your idea as if you have blinders. I gave examples, Mormegil gave examples and data of the differences. It's the first time I've seen someone interpret the numbers on WD. I add another identifier different from Allociné. You are not being fair. For the other properties, this is not the place to be discussed. Your anti-collaborative attitude is not appreciated at all and I'm not the only one to think that. —Eihel (talk) 12:14, 9 February 2021 (UTC)

@Jura1, Liuxinyu970226: can we consider the dicussions are over? Pamputt (talk) 06:45, 27 January 2021 (UTC)

@Pamputt: I think what Jura1 think is, this can be closed, but not by you, nor any administrators that are directly made their efforts here, it must therefore be closed by non-involved administrators. --Liuxinyu970226 (talk) 04:03, 7 February 2021 (UTC)

Media Art Database author ID (former scheme) (P3231)[edit]

Media Art Database author ID (former scheme) (P3231): (delete | history | links | entity usage | logs | discussion)

Old item is defunct since November 2019, when site owners replaced ids with a new ones. I've added these new ids (Media Arts Database ID (P7886)) for all 5539 statements. Here is a query for checking. —Lockal (talk) 19:31, 29 August 2020 (UTC)

Symbol delete vote.svg Delete as replaced. --Liuxinyu970226 (talk) 06:21, 1 September 2020 (UTC)
Symbol delete vote.svg Delete but we should first warn the wikis which seem to be using this property @Lockal: Vojtěch Dostál (talk) 14:27, 5 November 2020 (UTC)
Last user (except for usage in comments with {{P}}) is arzwiki. I tried to notify them here, but this page is not very active, unfortunately. --Lockal (talk) 21:19, 5 December 2020 (UTC)
@Lockal: Not getting an immediate response does not mean the page is not active, waiting the nomination result, @علاء: Please advice, Thanks. HitomiAkane (talk) 22:42, 5 December 2020 (UTC)
Symbol delete vote.svg Delete per nom. --Jeanjung212 (talk) 01:38, 21 April 2021 (UTC)
Symbol delete vote.svg Delete per nom. Flixwito^(•‿•)^ 08:44, 3 May 2021 (UTC)

Mixer game ID (former scheme) (P7335)[edit]

Mixer game ID (former scheme) (P7335): (delete | history | links | entity usage | logs | discussion)

Mixer became defunct in July 2020, and it's no longer a working property - it leads to the Mixer closure landing page. —CrystallineLeMonde (talk) 16:37, 1 September 2020 (UTC)

Why delete a valid property? The data is potentially useful for joining to other databases or through archives. Keep but deprecate. BrokenSegue (talk) 17:09, 1 September 2020 (UTC)
Marked as Wikidata property for a discontinued website (Q60457486). --Liuxinyu970226 (talk) 23:04, 2 September 2020 (UTC)
  • Symbol keep vote.svg Keep It's useful to see which games that were available on Twitch vs Mixer.--Trade (talk) 20:51, 12 September 2020 (UTC)
What are you opposed to, Trade? Against deletion {{Vk}} or against property {{Vd}}. —Eihel (talk) 15:57, 14 September 2020 (UTC)
  • Pictogram voting comment.svg Comment @BrokenSegue, Liuxinyu970226, Trade: Please read the description of Wikidata property for a discontinued website (Q60457486). Your opinions leave me a little skeptical. —Eihel (talk) 01:06, 13 September 2020 (UTC)
    @Eihel: And why your comment isn't? I just added such a mark, if you think I did wrong, why not revert me? And I have no opinions on vd or not this. --Liuxinyu970226 (talk) 01:09, 13 September 2020 (UTC)
    @Eihel: The statement on that page re: deletion is bad and I doubt represents policy or concensus or even was the result of discussion. Don't delete possibly useful data. BrokenSegue (talk) 01:10, 13 September 2020 (UTC)
  • Symbol delete vote.svg Delete per nomination. See also a similar situation with YouTube Gaming shutdown. Regards Kirilloparma (talk) 01:31, 13 September 2020 (UTC)
    • @Kirilloparma: Would your opinion change if I told you a large amount of mixer is archived? BrokenSegue (talk) 20:38, 13 September 2020 (UTC)
      • Unfortunately, not really. Well, there are some incomprehensible links that you provided, I have opened them and nothing has changed, since there is no link to the archive itself, only some incomprehensible files that need to be downloaded to my PC ... What are they for and how can they help Wikidata? As for the site itself, Mixer (just like Youtube Gaming) simply offered the user nothing more than a streaming service. So the question is, why should we have empty links to defunct streaming service? I would understand if this happened to IGDB site, since archived links to it would contain a lot of useful information for Wikidata (see example), but in the case of Mixer on the contrary, just empty links which once led to a streaming service, but now they no longer work and are no longer needed, so yeah, I am not changing my opinion at this point and still think this property should be removed. Regards Kirilloparma (talk) 22:06, 14 September 2020 (UTC)
        • The files you didn't download are Web ARChive (Q7978505)s and the primary way websites are archived in bulk. Why should we have links to a dead site? We shouldn't. We should remove the links. But the identifiers remain meaningful (they provide meaning to those archives and allow us to join to other databases that may have stored Mixer game ids). Still nobody has explained what harm these identifiers are doing. I mean what value did you think having this identifier provided when the website was up? It's the same value now except you have to go to the WARC files. BrokenSegue (talk) 02:27, 15 September 2020 (UTC)
  • Symbol neutral vote.svg Neutral {{Vd}} Why skeptical? Why is this property valid if it no longer fulfills the function for which it was created, BrokenSegue? Which database will use Wikidata IDs for a closed site, BrokenSegue? Can we still see games available on Mixer to compare them to another site, Trade? When a site is closed therefore the property attached to the site is obsolete: Label, P1630, Base URL… and Q60457486. Consensus and discussion are the basis of the preliminary debate to the creation of the property, and serve as a policy. What is rightly debated is whether the "data is possibly useful". As these are external ids, you need to have archives. The link to your page consists of meta-information and are not saved pages that can be used to replace property IDs. And although archives can be found, this was a site offering streaming… whose server is also on the SLD. So an archive will go to an empty page of interesting content, but filled with advertising. Clearly unnecessary. So deletion is the only solution, there is no mysterious utility. Cordially. —Eihel (talk) 16:49, 14 September 2020 (UTC)
    • @Eihel: Respectfully you are mistaken. The link to the data I provided is not just meta-information. It is saved pages. If anyone goes through those archives they will be glad we didn't delete this property. Further, I'm unclear what value deleting this property achieves or what harm keeping it does. The value of an external identifier is not merely the URL it takes you to (as evidenced by the identifiers that have no URL). BrokenSegue (talk) 16:56, 14 September 2020 (UTC)
    Hello BrokenSegue Hello Ok. Let's say I'm looking for Arabian Nights (Q1145946) infos (Item taken completely at random, but valid in most cases) that was available on Mixer, where can I find it? Please. —Eihel (talk) 05:59, 18 April 2021 (UTC)
    @Eihel: To find a particular video game I would have to download the entire corpus from the archive which I'm not doing for you (it's much more than 1TB). But I downloaded one at random and looked for game ids. The downloads of the channel information from mixer includes the ID of the game currently being played (in this case it was 70323=Fortnite (Q349375)). You can replicate this by downloading this 8GB file [10] and searching for "70323" to find all the linked data. If you downloaded any warc file though it would be evident it's not just metadata as you claimed. BrokenSegue (talk) 14:48, 18 April 2021 (UTC)
    I can not do better Face-smile.svgEihel (talk) 19:39, 18 April 2021 (UTC)
  • Tend to Symbol keep vote.svg Keep since their values are archived by, which may give a way to replace its URL scheme. --Liuxinyu970226 (talk) 21:45, 27 September 2020 (UTC)
  • Pictogram voting comment.svg Comment There seems to be decent archiving in the Wayback machine, so I went ahead and added a formatter URL (P1630) accordingly. Jean-Fred (talk) 14:19, 29 September 2020 (UTC)
  • Symbol keep vote.svg Keep unless it shouldn't have been added in the first place --- Jura 07:20, 15 October 2020 (UTC)
  • Symbol keep vote.svg Keep: it can still be used to extract data from the internet archive. --Shisma (talk) 18:12, 5 February 2021 (UTC)
  • Symbol keep vote.svg Keep If the deceased don't lose their names even when those names fall out of use centuries later, why should we deny an association between former users and their previously associated Mixer ids? If anything, I will argue that this information is necessary to not only link further information, but also to be able to identify previous information such as clips from the ArchiveTeam Mixer collection, a point which was already raised by BrokenSegue and (talk)Shisma (talk). Themadprogramer (talk) 08:47, 27 March 2021 (UTC)
  • Symbol keep vote.svg Keep Mixer was an important piece of video game streaming history, I don't think we should delete the data just because the website is down. AntisocialRyan (talk) 18:46, 9 May 2021 (UTC) player ID (former scheme) (P6615)[edit] player ID (former scheme) (P6615): (delete | history | links | entity usage | logs | discussion)

Kicker changed its website, and all the IDs that we have stored are invalid now. Therefore this property is not useful anymore. Steak (talk) 15:38, 16 September 2020 (UTC)

many of the id's links are archived. e.g. this one. though the link format is broken at the moment. deprecate and mark as obsolete but keep. here's a list of archived entries. BrokenSegue (talk) 16:51, 16 September 2020 (UTC)
If this property is deleted, the non-numeric identifiers should be transferred to the new property prior to being removed. S.A. Julio (talk) 17:28, 27 October 2020 (UTC) player ID (actual scheme) (P8912) has been created. Pamputt (talk) 21:29, 4 December 2020 (UTC)
I would love to say Symbol delete vote.svg Delete, @BrokenSegue: to me the scheme has been largely changed, results the former property can't compatible with the current scheme entirely, probably the core algorithm of this service has re-written. --Liuxinyu970226 (talk) 14:48, 10 December 2020 (UTC)
  • Symbol keep vote.svg Keep Even though the ID is not visible in the URL anymore, it is still present in the source code of the page and still works fine to redirect to the page (eg.). I added some Wikidata usage instructions within the property page in order to retrive the ID : "To find the Kicker ID, open the page source and look after "objectId: "spielersteckbrief: XXXXX"" where XXXXX is the ID". Therefore I think this property has no reason to be deleted Kwayst (talk) 16:22, 17 March 2021 (UTC)

shrinkage (P7079)[edit]

shrinkage (P7079): (delete | history | links | entity usage | logs | discussion)

Unused — 17:15, 13 October 2020 (UTC)

Arthur Rubin
Nomen ad hoc
The Anome
Daniel Mietchen
John Samuel
Jeremy Dover
Pictogram voting comment.svg Notified participants of WikiProject Mathematics ^^ --Liuxinyu970226 (talk) 22:21, 13 October 2020 (UTC)

  •  Support There literally is no usage [11]. It seems like a weird property to begin with, so I don't mind deleting it.— The Erinaceous One 🦔 02:52, 14 October 2020 (UTC)

@Thibdx: (proposal creator) Tobias1984
Daniel Mietchen
Simon Villeneuve
Toni 001
Marc André Miron
Pictogram voting comment.svg Notified participants of WikiProject Physics (more appropriate than maths) author  TomT0m / talk page 06:53, 14 October 2020 (UTC)

  •  Support This isn't even used in the given example. --Mu301 (talk) 13:05, 14 October 2020 (UTC)
  • Symbol keep vote.svg Keep It certainly had support, no usage is not reason to delete it Germartin1 (talk) 19:30, 20 October 2020 (UTC)
    • @The-erinaceous-one, Mu301, Germartin1: As header:  Support or  Oppose what? Please, use Symbol keep vote.svg Keep or Symbol delete vote.svg Delete. —Eihel (talk) 20:17, 20 October 2020 (UTC)
    • @Germartin1: By that logic, we should never delete any property because they all had support at one point. But sometimes we are collectively mistaken on whether a particular property will be useful so we should be open to deleting unused properties. — The Erinaceous One 🦔 21:27, 20 October 2020 (UTC)
  • Symbol delete vote.svg Delete @Germartin1: Not really to be used due to hard technical challanges, if the technical problem is solved in the near future, this can be request-restored. --Liuxinyu970226 (talk) 09:50, 23 October 2020 (UTC)
  • Symbol delete vote.svg Delete Vojtěch Dostál (talk) 14:12, 5 November 2020 (UTC)
  • Symbol keep vote.svg Keep Unless there is an actual problem with the property, no use is a poor reason. If we are just missing active users with an interest in updating materials, let's have this property hanging around, it costs much less energy than trying to undelete it later. Ainali (talk) 15:11, 12 February 2021 (UTC)
  • Symbol keep vote.svg Keep, disuse is not a reason to delete. Arbnos (talk) 21:38, 27 April 2021 (UTC)

third-party formatter URL (P3303)[edit]

third-party formatter URL (P3303): (delete | history | links | entity usage | logs | discussion)

Merge with formatter URL (P1630). The distinction between first-party and third-party URLs is rather arbitrary. And because only creates external links for P1630 and not for P3303, third-party URLs are often placed in P1630 if no first-party URL exists (e.g. autonomous system number (P3797), Minecraft UUID (P8727)). We can use ranks to define the best URL(s), and use nature of statement (P5102) to mark URLs as 'official' or 'unofficial' if need be, but having two separate properties just seems unnecessary. —IagoQnsi (talk) 17:04, 23 October 2020 (UTC)

  • Is there some Wikibase code change that allows that? --- Jura 12:29, 24 October 2020 (UTC)
  • @IagoQnsi: Maybe the name should be modified, but I don't see the purpose of having multiple P1630's on a property. The Wikibase UI will only use one of them, and I'm not sure it currently correctly selects the preferred one (there's a delay in any case, so it's complex to check). The advantage of a separate P3303 is that it makes clear that the entity making use of it needs to do the formatting themselves, the Wikibase UI won't help. Merging with P1630 will confuse that. ArthurPSmith (talk) 22:26, 24 October 2020 (UTC)
  • If Wikibase can select the preferred format over multiple claims, I'll support it. --Tinker Bell 01:44, 25 October 2020 (UTC)
  • Symbol keep vote.svg Keep It is important to distinguish primary 'official' formatter and the third party formatters. But it would be nice to have a tool/gadget to display external links also from third-party formatters.--Jklamo (talk) 10:40, 27 October 2020 (UTC)
  • Symbol delete vote.svg Delete @Jklamo: No need to "distinguish", we should be neutral on every URL schemes. --Liuxinyu970226 (talk) 08:32, 30 October 2020 (UTC)
  • Symbol delete vote.svg Delete We don't have a rule that formatter URL (P1630) can only be filled with official formatter urls. If we want to store information about some formatter urls being official we can do that better explicitely via qualifiers. In addition we can use the preferred rank to chose the formatter url that's used by default. ChristianKl❫ 23:30, 1 December 2020 (UTC)
  • Can somebody test/confirm that Wikidata's UI does correctly select the preferred Formatter URL value, if there are several? ArthurPSmith (talk) 18:32, 2 December 2020 (UTC)
    • I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do). --- Jura 19:42, 2 December 2020 (UTC)
      • FYI I added a preferred formatter URL a couple of days ago to ID (P8988) and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate). We might want to test some more, but it looks like maybe this issue is actually ok now. ArthurPSmith (talk) 19:06, 1 January 2021 (UTC)
  • I feel like there is something important missing in this discussion. There are multiple use cases at play: 1. The built-in functionality of linkifying the property value. 2. Secondary links to various more- or less- related websites/tools using the same identifier. I completely agree the current official distinction between #1 and #2 (#1 is “first-party/official”, #2 is “third-party/unofficial”) is wrong (and that distinction is not even important or interesting) and does not match the current usage. What we need is one linkifying URL template (OK, we could use the preferred rank for that), plus a potentially unbounded set of URL templates with an agreed-upon way to indicate where that URL leads. I mean, nature of statement (P5102) unofficial (Q29509080) is nice but in fact, I don’t really care. What I’d like to have is a drop-down menu next to each ISBN statement, showing me the links to various online book databases, libraries, e-shops, whatever (now, for the specific case of ISBNs, we outsourced this job to Special:Booksources which is the “official formatter” for ISBNs… funny, right?). Ditto for DOIs, OIDs, MeSH codes, … So, sure, we might merge P1630 and P3303 and use the rank to mark the primary linkifier. But I think it is not the greatest priority. For now, I’d say Symbol keep vote.svg Keep and rename both to indicate the distinction is not first-party/third-party, but auto-linkifier/additional links (cf. ArthurPSmith above). Then, let’s use operator (P137) (or anything else) for each of these additional URLs, and then let’s build a gadget (or Wikibase core functionality) to use the data in the property. That would be useful. --Mormegil (talk) 13:24, 18 December 2020 (UTC)
    • @Mormegil: I like this idea of a gadget to make these "live" - I think we'd need an additional qualifier though to label the links in a drop-down list, no? ArthurPSmith (talk) 19:07, 1 January 2021 (UTC)
    • @Mormegil: just noting that your suggested gadget sounds a little like Entity Explosion, which shows these links even if you don't start from Wikidata. --99of9 (talk) 04:54, 17 February 2021 (UTC)
      • It seems to me EE works “inversely” in a sense, doesn’t it? I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property. On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs. I added a screenshot. → --Mormegil (talk) 15:19, 18 February 2021 (UTC)
Demonstration of Entity Explosion when used from a Wikidata item
        • @Mormegil: It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a operator (P137) or a matching language). See this screenshot. I haven't advertised this feature much - perhaps I should! --99of9 (talk) 06:11, 19 February 2021 (UTC)
  • Symbol keep vote.svg Keep per Jklamo and Mormegil, whose comments I completely support. --Epìdosis 20:12, 30 December 2020 (UTC)
  • Symbol delete vote.svg Delete Per Liuxinyu970226 and ChristianKl. --Nw520 (talk) 15:31, 18 February 2021 (UTC)
  • Placeholder Symbol keep vote.svg Keep for now. I use this as part of the decision making in Entity Explosion, so have a preference for not doing extra work if there is a way of reconceiving of the difference between these two properties. --99of9 (talk) 01:13, 21 February 2021 (UTC)
  • Symbol keep vote.svg Keep - I use Entity Explosion and its excellent for a property like Eionet bathingWaterIdentifier (P9616) were we lack a "EU" formatter but maybe have formatters for some countries like Sweden (Q34) - Salgo60 (talk) 07:55, 6 June 2021 (UTC)

Religion, et al[edit]

political ideology (P1142)[edit]

political ideology (P1142): (delete | history | links | entity usage | logs | discussion)

Now duplicates with religion or world view (P8929)Nomen ad hoc (talk) 19:26, 7 December 2020 (UTC)

ideology (Q7257) doesn't subclass world view (Q49447) and shouldn't. ChristianKl❫ 18:27, 9 December 2020 (UTC)
Ahem. Does this new property only apply to German law? Nomen ad hoc (talk) 19:48, 9 December 2020 (UTC).
Do you think there are other cases where both of those things get bundled together? ChristianKl❫ 11:19, 26 December 2020 (UTC)

religion (P140)[edit]

religion (P140): (delete | history | links | entity usage | logs | discussion)

Now duplicates with religion or world view (P8929)Nomen ad hoc (talk) 19:27, 7 December 2020 (UTC)

the proposer of religion or world view (P8929) specifically said they didn't want this deleted saying "P140 is more appropriate e.g. when describing places of worship, because a marginal number of them are agnostic or atheist. P1142 is based on the clearly-defined same-name class Q12909644 and I would not consider it redundant." Some other commenters on the property creation discussion explicitly wanted to keep these. I think this new property was probably a mistake because we don't have clear picture of what we're doing now. BrokenSegue (talk) 15:24, 8 December 2020 (UTC)
  • Symbol keep vote.svg Keep Not a duplicate, the new property better handles things that are philosophies and not religions. ArthurPSmith (talk) 14:31, 28 December 2020 (UTC)
  • Pictogram voting comment.svg Comment Assuming that the reason for differentiating between this property and religion or world view (P8929) is so that this one can be used for places of worship, I would suggest that "for the religion or denomination" more clearly expresses the function of this property (and would more clearly differentiate the two properties). I've added "denomination" here because sometimes the values for this property are not religions but subdivisions of ones – Baptists (Q93191), Reform Judaism (Q1133485), etc. Ham II (talk) 18:31, 30 April 2021 (UTC)
  • Symbol keep vote.svg Keep, not a duplicate, but an important property for religious buildings and structures, and for other aspects too.Arbnos (talk) 14:23, 24 May 2021 (UTC)
  • Symbol keep vote.svg Keep widely in use in several templates and modules at some Wikipedias. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

political alignment (P1387)[edit]

political alignment (P1387): (delete | history | links | entity usage | logs | discussion)

May now be redundant with religion or world view (P8929)Nomen ad hoc (talk) 04:05, 12 December 2020 (UTC)

  • definitely Symbol keep vote.svg Keep here. this property is very narrowly scoped. BrokenSegue (talk) 04:56, 26 December 2020 (UTC)
  • Symbol keep vote.svg Keep. This property has a very narrow scope as you can see in the value constraint and is useful for it. Daask (talk) 13:27, 3 May 2021 (UTC)
  • Symbol keep vote.svg Keep, not a duplicate.Arbnos (talk) 14:40, 24 May 2021 (UTC)

religion or world view (P8929)[edit]

religion or world view (P8929): (delete | history | links | entity usage | logs | discussion)

Creation was done without clear consensus; duplicates political ideology (P1142) and religion (P140), with no consensus to replace them. What a mess. —Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:16, 15 December 2020 (UTC)

  • Symbol keep vote.svg Keep: better than "Religion" and "World View" properties. Nomen ad hoc (talk) 06:19, 16 December 2020 (UTC).
  • Symbol delete vote.svg Delete per Andy. NMaia (talk) 01:45, 18 December 2020 (UTC)
  • Symbol delete vote.svg Delete messy, no consensus to create. --Jklamo (talk) 03:14, 18 December 2020 (UTC)
  • definitely a mess. unsure what to do though... BrokenSegue (talk) 20:17, 20 December 2020 (UTC)
  • Symbol delete vote.svg Delete again, as I said on proposal page "religion" and "philosophical stance" are orthogonal, joining these two concepts is like having "color of eyes or height" property . --Lockal (talk) 19:50, 22 December 2020 (UTC)
  • Symbol delete vote.svg Delete, per Lockal. These are not similar things. What a mess... --Yair rand (talk) 06:03, 23 December 2020 (UTC)
  • Symbol keep vote.svg Keep Did any of you actually read the property proposal discussion? There was more than twice as many votes in favor as against creation, and there were clear examples given where the existing properties are insufficient. If you really want to delete this property then you need to explain how you will support expanding the use of religion (P140) or otherwise adjusting the use of existing properties to cover the needed cases. ArthurPSmith (talk) 18:17, 23 December 2020 (UTC)
  • Pictogram voting comment.svg CommentFirst of all I wonna throw in movement (P135), which has not yet been mentioned, but also intersects with this property.
I was following the property proposal discussion and didn't participate, because my point of view on this question is mostly based on my philologic education and and not driven by questions of usability. But now a little theoretic input might actually be helpful in the discussion.
It appears to me, that one of the main problems is the different connotation of world view (Q49447) in different languages. The german word "Weltanschauung" has been used at least since the 19th century and has first been used by romanticistic artists and basically ment seeing the world as it is, without delusion. It has been adapted by the Nazis and saw a shift of connotation somewhat around 1930. There has been a lot of discussion of the term by german philosophers in post-war-germany, most notably Heidegger and Klemperer. The present denotation appears pretty hard to grasp. Duden defines «Weltanschauung» as «Gesamtheit von Anschauungen, die die Welt und die Stellung des Menschen in der Welt betreffen» (Totality of views concerning the world and the position of man in the world). This would most definitely include religions. And yet, «Religion oder Weltanschauung» (Religion or Worldview) is a well-used syntagma in german. So this definition appear not to grasp the every-day use of this term. ChristianKl wrote that social democracy (Q121254) is not fitting in the term «Weltanschauung», the same way anthroposophy (Q184719) does. So what exactly counts as «Weltanschauung» varies a lot. I don't have a lot of knowledge of the history of the english term «world view», but a quick search with google ngram (Link) reveals, that it has not been used until as recently as the 1970s. Since the history of the english term is much shorter, the meaning appears to be way easier to grasp and apparently matches the definition Duden gives for »Weltanschauung».
What are the consequences for this discussion? Having a catch-all property that can include all kinds of views, beliefs and convictions of political, religious or philosophic origin should in my opinion not be named «Weltanschauung» in german, since there's no universally agreed upon meaning.
Practical considerations: I would like to be able to specifically query for users by their religion and their political views. For example:
A list of anarchists and their religion (Query). Our data is obviously very incomplete, but I'd say that from a query perspective it's more useful to have fine grained properties. -- Dr.üsenfieber (talk) 04:42, 26 December 2020 (UTC)
  • @ArthurPSmith: Consensus is not just about votes but about there being clarity around the open questions. There's no clarity around whether or not political views are inside or outside of the scope in that discussion. There's just the example items that suggests that they are outside. I don't think there are 4 support votes and 2 oppose votes for any interpretation of what the property should mean either. Different people supported different kinds of properties. ChristianKl❫ 11:34, 26 December 2020 (UTC)
  • I didn't ever understand the discussion as implying the property was to include things like "social democracy". That seemed clear from the start. Perhaps the proposer worded it strangely, but the problem from the beginning was that political ideology (P1142) is being used for things like humanism (Q46158), racism (Q8461), atheism (Q7066), even Catholicism (Q1841), and the mentioned anthroposophy (Q184719). Views like atheism (Q7066) are also described using religion (P140) but neither property really fits. How do you resolve this without this new property? That seemed absolutely clear from the discussion, at least to me. ArthurPSmith (talk) 21:28, 26 December 2020 (UTC)
    • @ArthurPSmith: If you understand it in a way that it doesn't include it, how do you count that there are twice as much in favor? Under that view it has 3 oppose votes and 4 support ones. If you understand it that way the property had 3 oppose votes and 4 votes in favor. ChristianKl❫ 22:46, 26 December 2020 (UTC)
  • Symbol keep vote.svg Keep: see: world view (Q49447) Maybe political ideology (P1142) and religion (P140) should thrown awy. --Succu (talk) 22:30, 26 December 2020 (UTC)
  • Symbol delete vote.svg Delete and rename religion (P140) to include ''world view''. This is entirely subjective and we are, I believe, trying to split a continuum into discrete parts. I vote to delete because its obviously confusing to have two items naming religion. Including world view with religion piggy-backs on the logic of that German law that started all this: the concepts are different, but not necessarily distinct. And for our purposes, they behave in much the same way. As to movement (P135), political ideology (P1142), and political alignment (P1387) I never felt anything wrong with those and they subjectively feel a bit further afield from religion (P140). Politics and Religion are also two massive and distinct spheres of public discourse and should, in the spirit of French Revolution (Q6534), be kept separate. --Matthias Winkelmann (talk) 18:36, 11 January 2021 (UTC)
  • Symbol delete vote.svg Delete - Per Matthias Winkelmann, this property is very confusing. Let's expand the use of religion (P140) to include worldview. Husky (talk) 21:47, 12 January 2021 (UTC)
  • Pictogram voting comment.svg Comment If those who are the major users of religion (P140) find the proposal to expand its use acceptable, I agree that that is a better solution. ArthurPSmith (talk) 16:58, 13 January 2021 (UTC)
  • Symbol delete vote.svg Delete – this is a term often used as a catch-all in legislation to reflect 'sincerely held beliefs'. The exegesis of the 'political or religious' term is rooted strongly in an intent to protect political emanations rooted in religious belief, e.g. opposition to, say, mandatory public education as an emanation of the religious beliefs of some Amish groups. The formulation is legally beneficial in that it avoids fruitless discussion about whether a religiously-motivated view about public life should be protected as a religious view or not. It doesn't lend itself, however, to defining people. I see atheism (Q7066) as an argument, but atheism (Q7066) is a clearly religious position, even if it is often associated with a political emanation, secularism (Q216920) (there are religious secularists and there might be, at least in theory, atheists who believe there is some inherent worth in religious groups having some involvement with civil government).  – The preceding unsigned comment was added by Ari T. Benchaim (talk • contribs) at 23:44, June 21, 2021‎ (UTC).

FFF male player ID (former scheme) (P4883)[edit]

FFF male player ID (former scheme) (P4883): (delete | history | links | entity usage | logs | discussion)

The website was heavily changed, and now all IDs lead to the main page. Therefore the property is useless now. Steak (talk) 08:32, 18 December 2020 (UTC)

FFF female player ID (former scheme) (P4886) has also been affected by this change. Have replacement properties been created? Peter James (talk) 09:19, 20 December 2020 (UTC)
is there a way to do a 1:1 mapping to their new schema (if there is one)? Looks like got most of them so at the very least move the property to pointing there. BrokenSegue (talk) 20:13, 20 December 2020 (UTC)
I added an formatter so Symbol keep vote.svg Keep until someone has a better idea. BrokenSegue (talk) 20:17, 20 December 2020 (UTC)
A proposal on a new property can be found here. --Hadibe (talk) 00:26, 31 December 2020 (UTC)
All of the 57 usages in German Wikipedia have been changed to the new IDs and could be imported automarically to Wikidata. --Hadibe (talk) 08:58, 1 January 2021 (UTC)

liturgical rank (P9002)[edit]

liturgical rank (P9002): (delete | history | links | entity usage | logs | discussion)

Created by Vogone by ignoring the need for support votes on property that wasn't labeled as ready and without engaging with the proposal page the way we usually do when creating properties. —ChristianKl❫ 12:54, 1 January 2021 (UTC)

The creation is still in process (as you can see, obviously not all steps of the creation process have been completed, yet) and there were no outstanding issues on a months-old proposal. I would argue all four creation criteria were met in this case, and the proposal was mentioned in multiple other places over the course of the past half year to seek further input. --Vogone (talk) 13:53, 1 January 2021 (UTC)
  • Template:Speedy delete please ask a property creator to look into it once issues are sorted out. --- Jura 14:31, 1 January 2021 (UTC)
    It would be helpful to know which issues are outstanding. On the proposal itself none were raised, bar a question whether this property could be used for other religions where applicable, and this question was affirmed. I will delete the property if there is indeed an issue left that I have missed. --Vogone (talk) 14:39, 1 January 2021 (UTC)
    The issue of how this property behaves outside of Christian tradition seems to be open. ChristianKl❫ 15:52, 1 January 2021 (UTC)
    As MF-Warburg already pointed out twice it is applicable for every religion which has a similar concept of religious feasts. I'd like to add that this is a nonproblem simply by the fact that no other religion is known to have such a sophisticated liturgy. – K​P​F​C​💬 16:05, 1 January 2021 (UTC)
    Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. --MF-W 17:43, 1 January 2021 (UTC)
    Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property.  – The preceding unsigned comment was added by ChristianKl (talk • contribs).
    We are not discussing about feast day (P841) here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general (en:liturgy is however already not a Christianity-specific term). --MF-W 11:37, 2 January 2021 (UTC)
  • Symbol keep vote.svg Keep There were 2 supporting comments in the proposal discussion, although neither one used the support template to express that, which is unusual. Vogone was one of the two, however, so should have requested the proposal be created by an independent property creator. Please check how other property creations are done before creating another one, thanks. ArthurPSmith (talk) 19:12, 1 January 2021 (UTC)
    • @ArthurPSmith: I don't think that comments from people who don't know the property creation process well enough to use the support template should be seen as demonstrating consensus for creation when there are people who are familiar with our process that still point to open issues. Our policy does say "i.e. an opposing voice with no thought behind it should not block creation, but a single reasonable opposing voice against many supporters may do so". ChristianKl❫ 10:57, 2 January 2021 (UTC)
      • @ChristianKl: But there weren't any opposing voices either, reasonable or unreasonable. All questions raised had been addressed. Not sure what your point is here. ArthurPSmith (talk) 19:08, 4 January 2021 (UTC)
  • For ease of access, here is the original proposal. --MF-W 11:37, 2 January 2021 (UTC)
  • Symbol keep vote.svg Keep as one of the supporting persons in the proposal. Also I fail to see any open issues – K​P​F​C​💬 20:38, 7 January 2021 (UTC)

number of vaccinations (P9107)[edit]

number of vaccinations (P9107): (delete | history | links | entity usage | logs | discussion)

@Pamputt: created the property in violation of our rules. Our rules ask for "All opposing points of discussion should be addressed before creation occurs." The point about whether the property should be about the amount of people who got a vaccine dose or the amount of people who got all vaccine doses that are planned is not cleared and without it being clear the property will likely have some data of both and thus be mislead users who expect it to provide sensible data. —ChristianKl❫ 22:14, 2 February 2021 (UTC)

  • Symbol keep vote.svg Keep For reference here is the proposal discussion. While it's true that nobody provided a specific solution to ChristianKl's question, we generally use qualifiers to specify such details; in practice addressing this is going to come up immediately for anybody trying to use the property; I would hope the resolution finds a place on the property talk page. I don't think this broadly supported and clearly useful property needs to be deleted for this reason. ArthurPSmith (talk) 22:31, 2 February 2021 (UTC)
    • @ArthurPSmith: It's a property that's likely to misinform people in an important public health area. Basically your idea is that people are likely to use qualifiers for this property, which means they won't use it in the way it was proposed to be used. Don't worry, nobody is going to use the property in the way it was suggested in the property proposal seems to me a bad argument. If we find out that people actually use it in the way that it was proposed, would you think your assessment is wrong? ChristianKl❫ 13:00, 8 February 2021 (UTC)
  • Pictogram voting comment.svg Comment I have never understood why WD did not simply model this way [number] /of/ [what] --Bouzinac💬✒️💛 08:21, 8 February 2021 (UTC)
    • Agree - Salgo60 (talk) 01:53, 9 February 2021 (UTC)
    • Because it's unspecific and doesn't tell us the predicate of the relationship. English users will find it in many cases easy to guess what's meant based on context. Speakers of languages that don't have a direct equivalent to of will find it harder and generally there are cases where it might not be 100% clear what the predicate is. In many cases In many cases has parts of the class (P2670) with quantity (P1114) takes the same effort as [number] /of/ [what] would need but is more precise and it's clear to everyone what the predicate is.
Furthermore having the property proposal process gets data to be standardized so that different people don't understand the relationship differently and put in different things with the same properties.
I don't think requiring people who want to add data about vaccinations to Wikidata to first decide on which data they actually want to add before they get a property that allows them to input data to be unreasonable. It prevents people from getting mislead by inconsistent data with matter for important health data. ChristianKl❫ 21:06, 9 February 2021 (UTC)
Pictogram voting comment.svg Comment It may be worth clarifying whether this property includes number of persons vaccinated to immunity or number of vaccines administered. In particular for COVID-19, where two-dose and single-dose vaccines are co-marketed, this is important.  – The preceding unsigned comment was added by Ari T. Benchaim (talk • contribs) at 23:47, June 21, 2021‎ (UTC).

coordinates of depicted place (P9149)[edit]

coordinates of depicted place (P9149): (delete | history | links | entity usage | logs | discussion)

I missed the proposal of this property (sorry), but this seems to be a lazy approach to creating a new item with a coordinate location (P625) value, which will only cause more work further down the line. It's better to sort it out properly at the start. Pinging those involved in the property creation, @Jheald, Jura1, GZWDer, Ainali, NMaia, Multichill: —Mike Peel (talk) 21:21, 15 February 2021 (UTC)

  • The proposal has been open for nearly 3 months. Nominating properties for deletion on the same day the property was created is bad practice and disruptive. So I'm closing this one. No whataboutism (Q4053075) please. Those previous ones were disruptive too. Appeals at Wikidata:Administrators' noticeboard. Multichill (talk) 21:34, 15 February 2021 (UTC)
    • @Multichill: I posted there yesterday, there has been no response. You created the property, you can't unilaterally close the discussion here, hence why I'm re-opening it. If you want me to stop, try answering the alternative solution I raised here? Thanks. Mike Peel (talk) 20:25, 17 February 2021 (UTC)
  • I personally find this property useful, especially on Wikimedia Commons. There you can specify both the camera position and the object position. Using the property ... you now have the option of specifying both positions in the "image data object". Symbol keep vote.svg Keep --Gymnicus (talk) 14:22, 19 February 2021 (UTC)
    @Gymnicus: The camera position makes sense, as that's arbitrary. But the object location isn't - you'll want to say that the image depicts the object anyway, so why not just create an item for it and use coordinate location (P625), rather than unnecessarily duplicating data? Thanks. Mike Peel (talk) 10:14, 24 February 2021 (UTC)
@Mike Peel: That is your opinion. I also like the property coordinates of depicted place (P9149). In addition, it is not the case with every image that the object coordinates are the same as the coordinates in the data object. Simply for the reason that objects are divided into various sub-objects, which, however, do not deserve their own data object. --Gymnicus (talk) 10:27, 24 February 2021 (UTC)
Symbol keep vote.svg Keep Let's take a painting of the eifel tower located in a London art gallery:
coordinates of depicted place (P9149) - Coords somewhere near the Eifel tower
coordinate location (P625) - Coords somewhere in London
location of the point of view (P7108) - Coords where to photo of the painting was made
The data object does not have the same coords at the object it depicts. --Schlurcher (talk) 13:54, 24 March 2021 (UTC)

Sicilian Regional Assembly numeric ID (P8152)[edit]

Sicilian Regional Assembly numeric ID (P8152): (delete | history | links | entity usage | logs | discussion)

Duplicates Property:P8151. Seems to have been created without proper proposal (see Wikidata:Property_proposal/Sicilian_Regional_Assembly_ID) --- Jura 19:51, 22 February 2021 (UTC)

GS1 Global Product Classification brick code (P5420)[edit]

GS1 Global Product Classification brick code (P5420): (delete | history | links | entity usage | logs | discussion)

Needs to be merged to GS1 GPC code (P8957), which has a lot more metadata. I can migrate the values (the former has 122, the latter 45) —Vladimir Alexiev (talk) 21:53, 22 March 2021 (UTC)

I guess the new property has a slightly larger scope. Otherwise, I would have kept the earlier one. --- Jura 21:20, 30 March 2021 (UTC)

AICS Chemical ID (former scheme) (P7049)[edit]

AICS Chemical ID (former scheme) (P7049): (delete | history | links | entity usage | logs | discussion)

Replaced without reusing IDs —SCIdude (talk) 14:47, 29 March 2021 (UTC) @Dhx1:

In short, the database has been replaced [12] and the new database does not use the old identifiers. Not only do our identifiers now link to the Wayback Machine but, because the database was not really functional for long (few months?), the archived pages do not show anything. --SCIdude (talk) 14:47, 29 March 2021 (UTC)

  • I was tending to agree with deletion on the basis of the Internet Archive and Trove neither having any saved pages from the old online database using the IDs of AICS Chemical ID (former scheme) (P7049). Additionally the example links of [13], [14] and [15] are not saved correctly by the Internet Archive, which seems to think all these example IDs match up with a single chemical in the database. Then I stumbled across [16], which indicates at least some pages were being saved by the Internet Archive correctly up to 2 years prior to AICS Chemical ID (former scheme) (P7049) existing in Wikidata. This property is used over 16,000 times on Wikidata items and who knows how many of these uses does result in an archived page off the old NICNAS inventory website. Given the lack of archiving observed and seemingly invalid archived pages when Internet Archive did make an attempt, I'm tending to GA candidate.svg Weak support the deletion of AICS Chemical ID (former scheme) (P7049) instead of the usual case of leaving AICS Chemical ID (former scheme) (P7049) in a deprecated state (for the purpose of Internet Archive etc linking). Mix'n'Match seems to contain the full catalogue of previous IDs but what is the point if there is no copy of the original page available? --Dhx1 (talk) 13:28, 30 March 2021 (UTC)
  • I updated the label, but given the number of uses and the importance of the database, I'm not really convinced by the deletion proposal. If the identifier was used elsewhere than on the website, I think that should be kept. If it wasn't used elsewhere, somehow our description of the identifier has a problem. @99of9: who worked on this mostly. --- Jura 21:19, 30 March 2021 (UTC)
  • Grrrr... I hate when databases do this. I'm accepting of my wasted efforts, but can't quite bring myself to vote for deletion! MnM will still be there in the unlikely event that we want to restore the data. --99of9 (talk) 21:44, 30 March 2021 (UTC)
  • this is really sad. we need to get better at archiving these external identifier URLs BrokenSegue (talk) 00:06, 31 March 2021 (UTC)
  • It looks to me that the reason the Wayback Machine only has a fraction of the pages is because they were only online for a few months, not because the links were defect. What does that tell about the creator's intention or the database's quality? Do we really need to keep something alive that had not much time to mature? --SCIdude (talk) 12:59, 1 April 2021 (UTC)
    • It seems the database has been around for years.
      Is it in (or is that the same)? --- Jura 14:20, 1 April 2021 (UTC)
  • No objections. --Egon Willighagen (talk) 13:57, 2 April 2021 (UTC)

ScoreStorybook company ID (P9416)[edit]

ScoreStorybook company ID (P9416): (delete | history | links | entity usage | logs | discussion)

ScoreStorybook is a side project of Inforegister (Inforegister ID (P9321) recently created as well). Identifiers for the latter for the most part seem to be same and ScoreStorybook entries apparently can be linked using existing Business Registry code (Estonia) (P6518) identifiers if necessary (e.g. [17] for Q31273705). So ScoreStorybook identifier seems redudant to the latter two identifiers. Moreover ScoreStorybook is a commercial project that relies on heavy advertising, and so the sole reason to request creation of this property was most likely the improvment of business goals by means of manipulating Google results via Wikidata metadata. @UWashPrincipalCataloger, Marie Rosin: —2001:7D0:81F7:B580:2C7B:6201:436A:B2C0 08:40, 6 April 2021 (UTC)

Bilibili bangumi ID (P6453)[edit]

Bilibili bangumi ID (P6453): (delete | history | links | entity usage | logs | discussion)

This property is identical to bilibili ID (P5733). Since it has only been used 6 times, it would be easy to migrate current uses to bilibili ID (P5733). Meanwhile, we should probably change the label of bilibili ID (P5733) to "Bilibili bangumi ID" to better reflect the scope of the property and distinguish it from other Bilibili properties like Bilibili userID (P6455) and Bilibili video ID (P6456). —Stevenliuyi (talk) 06:07, 17 April 2021 (UTC)

  • Symbol delete vote.svg Delete I agree after reviewing these properties. One thing to keep in mind when updating is they're using slightly different formats for their URLs/identifiers as one includes the 'md' at the start of every ID and the other doesn't. --Jeanjung212 (talk) 01:30, 21 April 2021 (UTC)

MovieMeter director ID (former scheme) (P1969)[edit]

MovieMeter director ID (former scheme) (P1969): (delete | history | links | entity usage | logs | discussion)

In 2015 this property was proposed based on the idea that the website is similar to Rotten Tomatoes. That is not the case at all. Rotten Tomatoes has more authority and more impact than MovieMeter, for which not a single source can be found to establish any kind of notability. Hiro (talk) 17:01, 23 April 2021 (UTC)

I don't know about the original proposal but it's used over 17,000 times and the site seems to be real (and in Dutch). I see you're proposing the NL wikipedia page nl:MovieMeter for deletion, but Wikidata criteria are a little different from Wikipedia's. ArthurPSmith (talk) 17:22, 23 April 2021 (UTC)
The website is real, yes. But so is this website. The property creation criteria say nothing about a condition or limitations, but I presume that there needs to be more about a website than just its existance before a property can be based on it? Hiro (talk) 17:39, 23 April 2021 (UTC)
Is the information on the website reliable or not? Mbch331 (talk) 08:22, 24 April 2021 (UTC)
I don't know. It seems to be copied from IMDb, so, sure. Is that all it takes? Copy information from one database to start another one and have it made a property? Hiro (talk) 10:36, 24 April 2021 (UTC)

MovieMeter film ID (P1970)[edit]

MovieMeter film ID (P1970): (delete | history | links | entity usage | logs | discussion)

In 2015 this property was proposed based on the idea that the website is similar to Rotten Tomatoes. That is not the case at all. Rotten Tomatoes has more authority and more impact than MovieMeter, for which not a single source can be found to establish any kind of notability. Hiro (talk) 17:01, 23 April 2021 (UTC)

  • how would deleting this property improve wikidata now that it already exists? is it being used to spam? BrokenSegue (talk) 00:27, 24 April 2021 (UTC)
The real question is how this property improves Wikidata. It was created under the false pretense that the website is similar to Rotten Tomatoes. It is not. We are just pumping data around by having this property. We already have the IMDb-properties, why have another one that links to a much smaller website that has the exact same information but targeted at a much smaller audience of which the review scores are insignificant and irrelevant. Please don't tell me that the only counterargument is that the website exists. Hiro (talk) 07:31, 28 April 2021 (UTC)
we have lots of properties that cover the same ground. BrokenSegue (talk) 00:38, 8 May 2021 (UTC)
My point is not that IMDb should be the only source of movie related information. The problem that I have with the MovieMeter-properties is that MovieMeter is not as significant. The counterarguments that the website exists and that the property already exists, don't hold up to scrutiny:
  • A website that exists, might not add any value to Wikidata or other Wikimedia projects. In the header above I linked to another website that 'exists' but holds no significance by any standard. Whether a website does add value, should be discussed in the property proposal. When the two properties were proposed in 2015, the only argument was "similar to Rotten Tomatoes". I challenge that argument as MovieMeter is not similar to Rotten Tomatoes. Sure, both sites are focused on movies and user generated content and reviews, but that's it. There is no similarity in significance, no similarity in usage.
  • No property should exist forever, just for the sake of it. Hence the existence of this very page. If a property does not add any value, it should be deleted. Deleting anything without value, adds to the overall value. Hiro (talk) 16:56, 24 May 2021 (UTC)

Please give a reason. 21:00, 2 May 2021 (UTC)

Please read everything I wrote. There are your reasons. Hiro (talk) 08:01, 6 May 2021 (UTC)



FFF female player ID (former scheme) (P4886)[edit]

FFF female player ID (former scheme) (P4886): (delete | history | links | entity usage | logs | discussion)

Same reason as FFF male player ID (former scheme) (P4883) :The website was heavily changed, and now all IDs lead to the main page. Therefore the property is useless now. Every ID have been transferred into their new ID which is FFF player ID (new scheme) (P9264) Kwayst (talk) 11:04, 26 May 2021 (UTC)

Benoît Prieur
Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Nattes à chat
Pierre André
Mathieu Kappler
Archives nationales DJI
Pictogram voting comment.svg Notified participants of WikiProject France Delusion23
Japan Football
Unnited meta
Сидик из ПТУ
Pictogram voting comment.svg Notified participants of WikiProject Association football Pamputt (talk) 06:21, 3 June 2021 (UTC)

Q107050364 ‬[edit]

Shoftim BeIsrael judge ID (P3751)[edit]

Shoftim BeIsrael judge ID (P3751): (delete | history | links | entity usage | logs | discussion) is defunct. —עלי (talk) 00:50, 3 June 2021 (UTC)

@עלי: being defunct is not alone a reason to delete. also you went through and removed all the links to this property which makes assessing whether we should keep it impossible. please undo that. BrokenSegue (talk) 01:28, 3 June 2021 (UTC)
@BrokenSegue: I will not do something as useless as that. Sorry. You may examine the Wikidata property example (P1855) of this property, so it's not impossible. When a property's sole purpose is linking to a website, I think the website being defunct is sufficient reason to delete the property. It was a sufficient reason to delete its template at hewiki. Having said that, tipping you for a useless property is enough. Accept or reject the request, I am not going to spend even one more second of my time regarding this property. Thanks. עלי (talk) 01:59, 3 June 2021 (UTC)
@עלי: wow... that was needlessly hostile. Deleting all usages of a property and then listing it for deletion is obviously the wrong order to do something in. It's like blanking an item and then listing it for deletion. What hewiki does has no bearing here. There is potential value in external identifier for defunct websites. BrokenSegue (talk) 03:20, 3 June 2021 (UTC)
@BrokenSegue: No, there isn't. At least not when we are talking about a private website, who holds a private nonofficial database. The website died and its identifiers died with him. Please elucidate what could be the potential value, regarding this specific property. Sorry for my previous impatient reply. עלי (talk) 03:56, 3 June 2021 (UTC)
@עלי: often websites are well archived by some third party e.g. In those cases these identifiers can still be used by looking at the archives. Additionally if a website's identifiers are used elsewhere on the Internet then having these identifiers remains valuable for joining between databases. BrokenSegue (talk) 04:11, 3 June 2021 (UTC)
Pictogram voting comment.svg Comment Some pages are archived at Internet Archive, e.g. --Stevenliuyi (talk) 04:09, 3 June 2021 (UTC)
Fine. I will not pursue this request any further. Wasted enough of my time, that's wikidata's maintenance administrators concern anyways. Thanks. עלי (talk) 04:16, 3 June 2021 (UTC)