Wikidata:Properties for deletion

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.

Add a new request


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): (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)
  •   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)
  •   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)
  •   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)
  •   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)
  •   Delete Very barely used, and replacement is even available for these not more than 100 usages. --Liuxinyu970226 (talk) 12:44, 16 March 2019 (UTC)
  •   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)
  •   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)
  •   Keep Keep this property because with this property is very easy to add some data. --Manu1400 (talk) 21:43, 18 August 2019 (UTC)
  •   Keep Very helpful, easy to use. HarryNº2 (talk) 12:07, 19 November 2019 (UTC)
  •   Keep Useful. --Obsuser (talk) 14:14, 25 November 2019 (UTC)
  •   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)
  Delete Doesn't useful, replacement available. --2409:8902:9001:6CE0:781B:941D:E99A:2367 00:16, 4 December 2019 (UTC)
  Delete Replacement available. -- 02:35, 9 May 2020 (UTC)
  •   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)


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)
  •   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)
  •   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)
  •   Delete: It is true. Redundant with doctoral advisor (P184). --İncelemeelemani (talk) 19:24, 17 July 2019 (UTC)
  •   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)
  •   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)
@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).
  •   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)

  •   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)
  •   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)
  •   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)
  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)
  •   Delete Redundant inverse. --Yair rand (talk) 19:46, 15 September 2019 (UTC)
  •   Neutral to   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)
  •   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)
  •   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)
  •   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)
  •   Keep: useful IMHO.--Cbyd (talk) 20:55, 19 February 2020 (UTC)
  Keep Has language conflicts. -- 02:37, 9 May 2020 (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)


writing languages (P6886): (delete | history | links | entity usage | logs | discussion)

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

@Hsarrazin, Accurimbono, Candalua, Yann, NMaia: @Robin van der Vliet, PKM, Yair rand, Circeus, Amadalvarez: (who voted for this property) - I only happened to find this discussion yesterday !! --Hsarrazin (talk) 17:13, 11 November 2019 (UTC)

@Hsarrazin: You know that I gave my support conditioned to a clear definition adjusting the boundaries to avoid overlapping with languages spoken, written or signed (P1412). In my opinion, the definition of P1412 must be changed to avoid people say that both are duplicated. Amadalvarez (talk) 17:47, 11 November 2019 (UTC)

This property duplicates languages spoken, written or signed (P1412). —EncycloPetey (talk) 14:19, 21 July 2019 (UTC)

  •   Keep The property is well-delimited (only the language used in written work) and there's a clear rational for its inception (languages spoken, written or signed (P1412) is not appropriate for Wikisource). Alexander Doria (talk) 18:09, 21 July 2019 (UTC)
    It is not well-delimited. What limits it? If an author publishes an edition of a work by another author, with added commentary in a different language, then is the language of the original work considered or just the language of the commentary? This is a very real situation, as editors of Classical works often publish edited editions of Classical works in the original language, along with a translation and notes. So, if an author publishes an Ancient Greek edition of Menander, with an English translation, and footnotes in French, German, Greek, and English, then which language(s) has the author written in?
    this is about the language of each writer/author... the language for the editor is their own... the fact that they comment a work in another language doesn't make this other language their language... --Hsarrazin (talk) 17:02, 11 November 2019 (UTC)
    Why is "languages spoken, written, or signed" not appropriate for Wikisource? Don't speeches and orations count towards "language written"? Wikisource hosts many transcribed speeches and lectures. Wikisource also hosts audio recordings of works, which are not written. And do works recorded secondhand by another individual count as written by the original author or speaker, or is this a language written by the secondhand writer only? This matters for authors like Jesus and Socrates, who have no known works written by the authors themselves. Do we count personal correspondence to family and colleagues (which can be hosted on Wikisource), or only published works, and what if the correspondence is later published? And once we see how broad "writing language" is in this light, then how is it any different from "languages spoken, written, or signed"?
    Clearly this is a property of individual works written by the author. Each work has a language (or languages) it which it was written, and some works (such as musical works) are written in no language at all. If we are to use this property, it should be justified by a work written in that language, which shows that it is a property of the work written, and not the author who wrote it. --EncycloPetey (talk) 20:28, 21 July 2019 (UTC)
  • Delete as redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:21, 23 July 2019 (UTC)

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   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)
  Notified participants of WikiProject Books -- Bodhisattwa (talk) 20:18, 23 July 2019 (UTC)

@Bodhisattwa: Ping doesn't work with groups that large. Also, why notify only "Books" but not participants in other publication-related groups such as Wikidata:WikiProject Periodicals, Wikidata:WikiProject Theatre, or Wikidata:WikiProject Anime and Manga? Books are not the only kind of written works that exist. --EncycloPetey (talk) 22:53, 23 July 2019 (UTC)
@EncycloPetey:, you are always free to ping these project participants also. :-) -- Bodhisattwa (talk) 16:20, 24 July 2019 (UTC)
Technically   Keep, unless if I haven't heard some Phabricator tasks in order to resolve some bugs, it's still true that languages spoken, written or signed (P1412) is incompatible with some Wikisource gadgets. --Liuxinyu970226 (talk) 14:28, 25 July 2019 (UTC)
  • Could you please clarify which Wikisource projects are affected by this, and how? English Wikisource is not affected at all. --EncycloPetey (talk) 20:00, 27 July 2019 (UTC)
Another keep reason: There are some J-pop teams e.g. B'z (Q150186), which they write their songs in English, then translate to Japanese, and officially publich their songs in Japanese. --Liuxinyu970226 (talk) 21:58, 31 August 2019 (UTC)
  Comment Which is the purpose of this property ? To describe the language in which a work was written, we use the language of work or name (P407). So why do we need a new property ? To get the language(s) used by a writer, just extract the language(s) of all his works. Snipre (talk) 20:59, 29 July 2019 (UTC)
Please try the following query (language of works by Joseph Conrad):
SELECT ?work ?workLabel ?language ?languageLabel WHERE {
  ?work wdt:P31 wd:Q47461344 ;
        wdt:P50 wd:Q82925.
  ?work wdt:P407 ?language.

   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
Try it!
No need to duplicate the data. Snipre (talk) 21:28, 29 July 2019 (UTC)
no, this is not to indicate in what language a work was originally written ; it is to indicate in which languages a writer wrote : if X only wrote in French, a text in English must be a translation - all works from all writers are not on wikidata, and will never be (not for decades).
also, it helps to autocategorize, while languages spoken, written or signed (P1412) generates many wrong categories, especially for esperantists... --Hsarrazin (talk) 12:44, 9 November 2019 (UTC)
Firstly, a lot of authors don't have their works in Wikidata. Secondly, I don't think it's possible to do a SPARQL query on Wikipedia or Wikisource. Robin van der Vliet (talk) (contribs) 19:49, 21 August 2019 (UTC)
  Keep If a person grew up in China and wrote letters in Chinese, but published works only in Spanish, how would you know that person could write in both languages without this property? Not every published work will be in Wikidata, and certainly not most private correspondence. This property adds information not available otherwise. ArthurPSmith (talk) 14:02, 30 July 2019 (UTC)
  • @ArthurPSmith: You've misunderstood this property. It's not about what the author chose to publish, but for the language of their works as published by anyone. If they wrote letters in Chinese, and those letters were published (even after their death) than that qualifies under this property. It is not unusual for a person's diary or letters to be discovered and published once they have died. --EncycloPetey (talk) 15:07, 9 August 2019 (UTC)
  • @EncycloPetey: Ah, I was responding to Snipre's claim. Regarding P1412, the proposal explicitly discussed this: "We used languages spoken, written or signed (P1412) for long, but it is now flooded with all sorts of languages that people read, or speak, or even understand, which leads to nonsense info about the writing languages of an author, like saying Jules Verne (Q33977) wrote in esperanto, and a discussion on frws, aiming to remove info coming from wikidata because of this..." ArthurPSmith (talk) 17:27, 12 August 2019 (UTC)
    @ArthurPSmith: Snipre said that the property is a duplication, and it is. Wikidata does not duplicate information. Snipre also showed that the information you desire can be extracted from their works. Their works are anything they produced, whether published or not, but Wikisource is concerned only with works published in some form, so I do not understand how your response pertains to that. Why would French Wikisource need information about languages in which a person wrote, but are used in works that will not be hosted on Wikisource? Also, there is nothing on Wikidata that says Jules Verne wrote in Esperanto. Fr.WS can correct the problem by relabelling their template output to match the content coded at Wikidata. --EncycloPetey (talk) 17:35, 12 August 2019 (UTC)
to be able to know whether texts in French from a certain author could have been written by them, or arenecessarily translations ! (an then search for who the translator is, and if they are Public domain too ! all wikisources do not do this search as thoroughly as we do on frws... but it is important !--Hsarrazin (talk) 12:44, 9 November 2019 (UTC)
  Keep The property is clearly delimited (only for languages used in written works) and there's a good reason for its existence (it's needed on the French Wikisource). Maybe User:Hsarrazin can explain better how this property is used on the French Wikisource and why it's needed. Robin van der Vliet (talk) (contribs) 23:48, 30 July 2019 (UTC)
  Keep, the removal is contrary to the sense in Wikidata.--Arbnos (talk) 18:36, 1 August 2019 (UTC)
  Keep per Robin van der Vliet. --Epìdosis 17:35, 9 August 2019 (UTC)
  Delete as nominator. The only rationale I've seen presented for keeping this property is that French Wikisource wants it. It is not the purpose of Wikidata to cater to desires of individual projects. --EncycloPetey (talk) 20:44, 10 August 2019 (UTC)
first, we used languages spoken, written or signed (P1412), but this property is now flooded by all languages that a person can use, which is not equivalent to the language used to write works - this led to many wrong categories... - and written language is not equivalent to writing language (as a work language for a writer)
on frwikisource, our author pages are managed totally frow wikidata : i.e. ALL data about an author are stored here, NOT on wikisource... if wikidata leads to wrong categories or wrong info for the specific use of wikisource (we edit texts, and are preoccupied with copyright matters), this could lead to a lot of misunderstanding, and contributors loosing trust in wd... --Hsarrazin (talk) 16:58, 11 November 2019 (UTC)
  Delete Redundant. languages spoken, written or signed (P1412) with qualifier object has role (P3831) and written language (Q1149626) does the same job.--Jklamo (talk) 07:57, 19 August 2019 (UTC)
@Jklamo: Can also work for B'z? --Liuxinyu970226 (talk) 11:15, 6 October 2019 (UTC)
  Keep it is not a duplicate : it is the only way to know, for people who practice more than 1 language, in which language they really published... please read the creation discussion - it is really important ! --Hsarrazin (talk) 12:30, 9 November 2019 (UTC)
  Keep. This property is indeed useful to know in which language(s) an author wrote. A qualifier on languages spoken, written or signed (P1412) might to the job but a stand alone property seems nicer to me. We use this property to fill the categories by author language on the French Wikisource Author: pages. Tpt (talk) 19:01, 9 November 2019 (UTC)
  • Weakly   Delete. I see that it is possible to make a logical distinction between writing languages (P6886) and languages spoken, written or signed (P1412), but this discussion shows disagreement about where the line is drawn. Some editors advocate keeping P6886 because we want to record the subset of languages that an author can write in, even if there is no notable published works in that written language; other editors advocate keeping P6886 to record the subset of languages that an author has published in. It seems that the first purpose is redundant over languages spoken, written or signed (P1412) with qualifier object has role (P3831); the second purpose is redundant to an auto-generated list from Wikidata items of one's published works. I think this property can add value, but we need to make a strong, clearly demarcated case for an infobox field, for this property to be useful. Deryck Chan (talk) 18:49, 11 November 2019 (UTC)
  •   Keep En français la propriété est très clairement limitée et précise, j'invite donc les contributeurs locuteurs d'autres langues à effectuer une vérification. Jérémy-Günther-Heinz Jähnick (talk) 09:14, 12 November 2019 (UTC)
  •   Keep I think this is relevant. Some time ago I stumbled over writer Olga Grjasnowa (Q106083) who does not publish in her mother tongue (yet). I wondered how to express that her mother tongue is Russian, she speaks Russian and German, but publishes in German. In my opinion the descriptions and the property proposal make it quite clear that this is intended for the languages they wrote their work in, not for any language they use(d) to write. There may be misinterpretations by people who use it (as it is the case for many properties) but in this case I don't think that it is the fault of the property itself (one could add some clarification or improve the label). As pointed out by Hsarrazin there will be always authors without a complete list of their work in Wikidata - for those it won't be possible to deduce this property from their work. I also like Hsarrazin's point that such a property would allow to find possible errors in the metadata of their work/works related to them. One could use languages spoken, written or signed (P1412) with a qualifier, but I see no advantage in this. - Valentina.Anitnelav (talk) 12:37, 12 November 2019 (UTC)
  •   Keep; semantics of this property is different from what […] languages spoken, written or signed (P1412) […] / object has role (P3831) written language (Q1149626) represents. @Deryck Chan: I think it is unrealistic to expect complete modeling of all individual works of an author/creator, so auto-generating the list of languages is generally unfeasible. I do agree, however, that the definition of this property could be clarified regarding translations, notability, etc.   Comment Do we have a property akin to “works have been translated into [language]”?―BlaueBlüte (talk) 05:17, 30 December 2019 (UTC)
  •   Keep since languages spoken, written or signed (P1412) is different. Michael FV (talk) 03:12, 9 January 2020 (UTC)
  •   Keep as this property is more suitable than languages spoken, written or signed (P1412) to Wikisource projects. -- Bodhisattwa (talk) 05:15, 13 January 2020 (UTC)
  •   Delete. Redundant, per above. --Yair rand (talk) 05:57, 13 January 2020 (UTC)
  •   Delete redundant. --- Jura 11:00, 20 January 2020 (UTC)
  •   Delete Translations can be merged. -- 23:08, 20 January 2020 (UTC)
  Keep No socalled conflicts here. -- 02:38, 9 May 2020 (UTC)


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)

  •   Delete per nomination. Nomen ad hoc (talk) 19:39, 28 July 2019 (UTC).
  •   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)
  •   Delete - Premeditated (talk) 07:55, 5 August 2019 (UTC)
  •   Neutral leaning toward   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)
  •   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) = pupil (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)
  •   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)
  •   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)
  •   Delete if moved to student of (P1066). --- Jura 15:54, 28 September 2019 (UTC)
  •   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)
  •   Keep: clearer relationship than anything else especially in relations from earlier centuries Palotabarát (talk) 10:39, 20 October 2019 (UTC)
  •   Delete Clearly-than-god no consensus to keep such old-school schema. Replacement is now available. --Liuxinyu970226 (talk) 04:54, 1 January 2020 (UTC)
  •   Delete too many, information should be stored by inverse. Michael FV (talk) 03:16, 9 January 2020 (UTC)
  •   Keep nghiên cứu sinh (doctoral student) is different by sinh viên (student) in Vietnamese. -- 23:11, 20 January 2020 (UTC)
  Keep Has language conflicts. -- 02:39, 9 May 2020 (UTC)


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)

  •   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)
  •   Delete Vandalism targets. --Liuxinyu970226 (talk) 04:56, 1 January 2020 (UTC)
  •   Keep stay real adress on --Arachn0 (talk) 11:53, 2 January 2020 (UTC)
  •   Keep IDs are being improved now. --Mzngan (talk) 09:57, 6 January 2020 (UTC)
  •   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)
  •   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)
  •   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): (delete | history | links | entity usage | logs | discussion)

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

@Nomen ad hoc: Please read archives listed in its talk page carefully: 1, 2, 3, 4 (if links can't work properly, use Ctrl+F type P373), this was PFDed for 4 times and their results were all keep. --Liuxinyu970226 (talk) 22:03, 8 September 2019 (UTC)
@Liuxinyu970226: The links 2 and 3 don't seem to work. The RedBurn (ϕ) 20:30, 2 May 2020 (UTC)
@Nomen ad hoc, Liuxinyu970226, The RedBurn: The links are : 1, 2, 3, 4. —Eihel (talk) 11:04, 30 May 2020 (UTC)
Unless if @GZWDer, Lavallen, Ivan A. Krestinin, Izno, Doostdar:@Jakec, Cycn, Esquilo, Multichill, Paperoastro:@GautierPoupeau, Tamawashi, Micru, ערן, Closeapple:@TomT0m, JAn Dudík, Pasleim, Jklamo, Hanay:@Rippitippi, Sannita, Jianhui67, ŠJů, Jmabel:@Discasto, Marsupium, Mike Peel, Kaldari, Ghouston:@Strakhov, Jheald, Jura1, Slowking4, DarwIn:@Jarekt, Deryck Chan, PKM, Derzno, Ksc~ruwiki:@Krenair, Amire80, Jon Harald Søby, Tgr, Tpt: those guys said something against their previous keep, I would love to non-admin close this discussion. --Liuxinyu970226 (talk) 04:05, 9 September 2019 (UTC)
  •   Keep - needed when the Commons site link is connected to a Gallery page. - PKM (talk) 05:03, 9 September 2019 (UTC)
    @PKM: In those cases, just create an item with instance of (P31)=Wikimedia category (Q4167836), and use topic's main category (P910)/category's main topic (P301) to link to the topic item, e.g. Category:Isaac Newton (Q7215722) vs. Isaac Newton (Q935). Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)
    @Mike Peel: you make a compelling case below. But I'd prefer that we standardize on linking to Commons categories not Galleries. - PKM (talk) 06:41, 9 September 2019 (UTC)
    @PKM: So would I! But others seem to disagree. Although, that wouldn't change things in the example I gave, since en:Category:Isaac Newton also uses the Commons sitelink via Category:Isaac Newton (Q7215722). Thanks. Mike Peel (talk) 06:46, 9 September 2019 (UTC)
  •   Keep The "other site"-link is a one-to-one mapping from Commons to a Wikidata object (and its interwiki links). Commons category (P373) is a many-to-many mapping to Commons. /ℇsquilo 06:04, 9 September 2019 (UTC)
    • @Esquilo: We may consider to break such glitch, see reasons at phab:T54971. --2409:8902:9021:3DF1:579C:FBA1:7BB1:D3E0 00:30, 21 September 2019 (UTC)
      • I consider that to be a bad thing. There are numberous cases when multiple Wikipedia articles uses images from the same Commons category. Wikidata structure should reflect this usage. /ℇsquilo 09:17, 21 September 2019 (UTC)
  •   Delete - or in the immediate future, deprecate until the remaining cases that don't match the sitelinks are resolved (while bot-removing matching cases to unearth the mismatches). This property served its purpose as a temporary work-around, but nowadays the Commons sitelinks are used, both to link to Wikidata from Commons (using commons:Template:Wikidata Infobox), and also to link from Wikipedias (using en:Template:Commonscat/en:Module:WikidataIB's getCommonsLink function). Keeping P373 around just adds to the maintenance burden, as it needs to be kept in sync with the sitelinks (the sitelinks automatically update when a category is moved/deleted, P373 has to be manually/bot-updated), and that's particularly difficult here since things like Wikidata:Database reports/Constraint violations/P373 are continuously broken/outdated. There is a lot of work still to do to get rid of this property - in particular, uses on various wikis need to be changed to use the sitelink instead - but I'm not sure that will start unless the property is clearly marked as deprecated/on its way out, in favour of the better solution of the sitelinks. Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)
  •   Keep Per previous threads. Apparently nothing changed. I may add keeping Commons gallery (P935) and deleting P373 while allowing gallery-sitelinks doesn't make much sense. Galleries should be deprecated as Commons sitelinks. strakhov (talk) 06:27, 9 September 2019 (UTC)
  •   Keep: P373 is still the least-bad kludge for dealing with Wikidata's original sin of insisting on 1:1 item correspondence between projects, despite being founded long after Commons. As Liuxinyu970226 mentioned, this is at least the 4th nomination to delete P373. Commons still has both mainspace (gallery) and category pages for topics, and the category pages are primary and have the most content; mainspace is utterly optional, and probably even less popular than it used to be. Though Wikidata has loosened the notability criteria and added links between main items and category items, there is still the question of how one deals with a Commons category being the primary page for a subject and sometimes a not-very-notable subject at that. How do we deal with Commons if P373 isn't on the main item? Problems no matter which way you try:
    1. The current sitelink standard is to put the Commons category on a Wikidata category item if there is one, and otherwise put the Commons category on the Wikidata main item. But if there's a Commons gallery (mainspace page), and Wikidata has no category item for that topic, then the Commons gallery gets the sitelink, and the Commons category gets no sitelink, because Wikidata is bound to 1:1 sitelink relationships, even though galleries aren't where most of the content is on Commons.
    2. One might propose that we simply create a Wikidata category item for every Commons category. But are Wikidata category items allowed for topics that have no main topic? I see that "one valid sitelink to a page on ... Wikimedia Commons" was added to Wikipedia:Notability, but I can't tell if that was by consensus; there seem to be more opposing that supporting the idea on Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). Commons categories don't have to be "notable" to exist. (Examples: Commons:Category:Slurry near St. David, Illinois in April 1973; Commons:Category:Images from the State Library of NSW album 7039; Commons:Category:2015-03-21 Morgan Park v. Lutheran Class 3A consolation basketball game; Commons:Category:LVIA F669 ap7 b86; Commons:Category:Random events in the USASMDC.) Wikidata now seems to allow very-low-notability articles — for example, on Wikinews and Wikisource — to qualify for Wikidata items. But on Commons, the category creation criteria is even lower. Only files have anything like a notability criterion: "realistically useful for an educational purpose" or legitimately "in use on another project"; a Commons category, despite usually being the main topic page on Commons, is created and retained simply on there being sufficient content to fill it. Commons doesn't allow blatant spam, but it doesn't prohibit sponsored content either. Does a company or product qualify for a Wikidata item just because someone uploaded enough files to Commons to get a category made? (By the way, even that thin criterion has been abused by some Wikidata evangelists/conquistadors, who have been invading Commons and creating new Commons categories with only one file, claiming that Commons rules don't prohibit it, then "coincidentally" linking the categories to existing Wikidata items to get credit from whoever's keeping track of Wikidata adoption metrics.)
    3. Even if every non-hidden Commons category now automatically qualifies for a Wikidata category item, there is still the process of creating each Wikidata item. It's been 5 years since I pointed out the burden of creating a category item on Wikipedia at Wikidata:Requests for deletions/Archive/2014/Properties/1#Commons category (P373) 2. (Granted, steps 5 and 6 aren't needed if there is no main topic.) Would we want a bot to create the Wikidata category items instead?
So, until we have all of that settled, and a working implementation for all of it, P373 should stay: It's the only method that allows both a gallery and a category link (which is more important) to Commons to exist simultaneously for a Wikidata main topic item that doesn't have a Wikidata category item. --Closeapple (talk) 07:44, 9 September 2019 (UTC)
  • @Closeapple: Notability is still something that's being argued about - basically the notability guideline doesn't match practice here any more. However, the cases that you talk about are a separate issue ('should all commons categories have Wikidata items?') - here we're talking about categories that are linked to from Wikidata/Wikipedia already, and those should already be notable enough to have items. Most items that have galleries linked to them already now have category items with the category sitelink where available, there aren't actually that many of them (Commons gallery (P935) is only used ~100k times). Note that we're coming up to the 2.5 million mark for commons:Category:Uses of Wikidata Infobox - and that's excluding taxons, which are around ~0.5 million, so the sitelinks are already in place for about half of Commons' categories now. Plus the Wikidata infobox on Commons makes it more valuable to go through the process you described before to create the sitelink - a P373 value just links one-way, which is kinda useless for Commons editors. Thanks. Mike Peel (talk) 08:07, 9 September 2019 (UTC)
  •   Delete If Mike thinks it's ready to go, lets get this started, even if it will take another five years to implement the deletion. Step 1: remove the property from category items. Step 2: remove the property from items linked to a category. Step 3: remove the property from items with the sitelink. Step 4: ... --- Jura 07:59, 9 September 2019 (UTC)
  •   Oppose for now. This property is widely used. Before deprecating there should be some tools which automatically uses commonscat from related item using P301/P971. JAn Dudík (talk) 10:49, 9 September 2019 (UTC)
    @JAn Dudík: Oppose deleting or oppose keeping? --Liuxinyu970226 (talk) 00:20, 4 December 2019 (UTC)
    I mean   Keep, but I agree with deprecation in future. JAn Dudík (talk) 08:56, 4 December 2019 (UTC)
  • Can we have a demonstration, by removing the P373 statements from some items with a lot of sitelinks, to verify that all the interwiki linking still works? If it does, I support removing the redundant property. Ghouston (talk) 10:57, 9 September 2019 (UTC)
    • @Ghouston, JAn Dudík: See the things I linked to in my post above, in particular there is a function in Module:WikidataIB ('getCommonsLink') that you can use to fetch the sitelinks via the linking properties. Also look at any Commons categories using the Wikidata Infobox to check the interwiki links. There are a lot of cases on other wikis that need to be changed to use this new code rather than accessing P373, though, which is why we need it to be deprecated first rather than just deleted immediately. Thanks. Mike Peel (talk) 11:56, 9 September 2019 (UTC)
      • @Mike Peel: I am afraid, that there will be many problems. 1) Because of inexistence of global modules there will be necessary to update all Wikidata bodules in all wikis. Then update of all templates which uses P373. 2) There are many users who uses P373, but are not familiar with commons sitelink. 3) there are many cases where 1:1 linking is not possible. 4-n) etc. There will be BIG impact to all wikis, so There must be at first good solutoin with good documentation in many languages. And After this all should be possible to deprecate P373. – The preceding unsigned comment was added by JAn Dudík (talk • contribs).
        • Deprecation to me implies that new statements using the property should not be added, the bots that maintain it should be stopped, and that it can be safely removed if desired. If the software isn't yet in place in all Wikis, then I don't think that step should be taken. Ghouston (talk) 00:18, 10 September 2019 (UTC)
  •   Delete per Mike Peel. This property is nothing but awful and highly problematic programming spaghetti, for the reasons exposed. the mere fact that it exists is a continuous source of trouble, as tool developers may use them as a source for the commons cat, wide-spreading and perpetuating the problem till unmanageable levels. The link article-category and reverse is generally made through SetSiteLink. My perception is that most of this evilness emanated from a primeval misconception that Wikipedia Articles corresponded with Commons Galleries (generally false, by default, since Galleries are mere exhibitors for Commons categories, and there could be like 100 of them for a given subject, none of which with special preponderance over the others) and that Wikipedia Categories had any importance to Commons, and should preferably relate to Commons Categories (generally false too, though sometimes it can be useful to connect them, such as in "churches in municipality X", the kind of thing that probably will never have an article in Wikipedia). In any case, this property doesn't seem to be needed at all.--DarwIn (talk) 11:06, 9 September 2019 (UTC)
    •   Comment In case of removal, please check Listeria, as I seem to have noticed it uses this property to show the Commons Category in the lists (should be using SetSiteLink, otherwise it gets broken everytime someone moves a category in Commons).--DarwIn (talk) 11:08, 9 September 2019 (UTC)
  •   Neutral I came to this discussion thinking to vote to keep it, but Mike Peel has a convincing argument. I can see in the future time when P373 can be retired and that would simplify our maintenance burden, and in general prevent the same info being stored in two places. I would also like to see some trimming of the number of unmaintained Commons galleries clogging the sitelinks, but that topic should be discussed on Commons. --Jarekt (talk) 11:59, 9 September 2019 (UTC)
  •   Keep and delete other sites link. in a larger sense, deletion is not a quality improvement process, rather provide the ontology, team and method to improve wikidata to commons links. Slowking4 ‽ (Rama's revenge) 12:45, 9 September 2019 (UTC)
    • @Slowking4: Can you elaborate, please? Without the sitelink, none of the interwiki links on Commons, nor the infobox, would work. It's akin to removing the interwiki links to the Wikipedias and replacing them with a property - you can then only see the link on Wikidata, not from the other wiki. Thanks. Mike Peel (talk) 13:18, 9 September 2019 (UTC)
      • i'm saying the site link is more opaque and inexact. it is a problematic analogy to wikipedia articles, which commons does not have. we need to develop the ontology and mapping of commons content. you could map the many infoboxes to creator and institution (and depicts). but a consensus and action plan is required , deletion should be salted as a perennial rejected proposal.-- Slowking4 ‽ (Rama's revenge) 13:32, 9 September 2019 (UTC)
  • Who cares - none of these hacks actually work well (e.g. [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)
  •   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)
  •   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)
  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)
  •   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)
  •   Keep unless is Commons linking issue finally resolved (abandon commons galleries sitelinking - I am afraid it needs another lengthy RFC), then   Delete. --Jklamo (talk) 10:08, 11 September 2019 (UTC)
Whether or not this is eventually gotten rid of, please modify c:Module:Creator to stop using P373 if so desired. Also check for other templates or modules that still rely on it.--Roy17 (talk) 21:49, 12 September 2019 (UTC)
@Roy17: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)
  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)
  • Deprecate per Mike Peel. At Wikimania last month, Mike and I talked about this exact issue (P:P373 being a piece of necessary evil to deal with misalignment of category and topic items), and I'm persuaded that we should at least try to migrate towards a more elegant solution. Deryck Chan (talk) 16:35, 15 September 2019 (UTC)
  •   Keep Agree that the current situation is not the best, however I believe that 'other sites' is a ridiculous, kludgey solution that's even worse than this property. Gamaliel (talk) 20:19, 17 September 2019 (UTC)
  • Deprecate. I also agree with Mike Peel. --Tinker Bell 02:47, 20 September 2019 (UTC)
  •   Question If this property is deleted, who will update the Wikidata-linked Creator template which current uses P373 to populate the "homecat" parameter? - PKM (talk) 20:14, 20 September 2019 (UTC)
    @PKM: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)
  •   Keep Let's look at the practicalities. Suppose I have a large or large-ish set of items, and I want to identify which of them have Commons categories. With P373, I just need the following in my SPARQL query:
    ?item wdt:P373 ?commonscat
Without P373 I have to do something like the following:
      ?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)
  •   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)
  •   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)
  •   Delete Please deprecate and later delete this property once and for all, the commonscat links are sufficient for the intended purposes. Linking more than two commons categories is not useful and therefore no reason to keep this property. Steak (talk) 10:48, 10 October 2019 (UTC)
  •   Delete Per above, especially per Liuxinyu970226. T54971 might be a better solution to fix What Multichill concerns. --2409:8902:9301:F7F8:1FC0:6702:8454:4E37 02:13, 30 October 2019 (UTC)
  Delete Problemic property, should consider more smart ways instead. --2409:8902:9001:6CE0:5E2F:BCDA:B1D9:2A6F 00:22, 4 December 2019 (UTC)
  •   Keep Per above. + We will have problems with automatic cross-project linking without this property. --sasha (krassotkin) 14:13, 17 December 2019 (UTC)
  •   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)
  •   Delete no reason to single out Commons, use topic's main category (P910) Michael FV (talk) 03:32, 9 January 2020 (UTC)
  •   Delete phab:T54971 solution should be enough, please also consider nominating Multichill for WD:RFP/R since that guy only keeps Wrong claims by themselves. -- 23:20, 20 January 2020 (UTC)
  •   Delete Redundancy must die. — Mike Novikoff 23:50, 10 February 2020 (UTC)

No comments for over a month, probably best to close this one as no consensus. Multichill (talk) 20:07, 24 March 2020 (UTC)

@Multichill:  Oppose It looks like the currently vote is 13:13:1, which looks rather like neither way are fair, but at least 3 deletion rationales pointed phab:T54971 and phab:T232927, which is, although tricky, two better ways that can finally kill all the P373 functions, so unless if both are declined officially, "close as no consensus" is also unfair. --Liuxinyu970226 (talk) 08:17, 1 April 2020 (UTC)
  •   Delete Unnecessary and useless. -- MovieFex (talk) 04:32, 29 March 2020 (UTC)
  •   Delete Deprecate and later delete (redundant; a lot of people with no experience with Wikidata are very surprized to find out that we have such fundamental mess in linking to Commons categories) Vojtěch Dostál (talk) 08:11, 31 March 2020 (UTC)
  •   Delete Deprecate and delete. Two ways of linking is source for errors and confusion. MrProperLawAndOrder (talk) 17:44, 11 April 2020 (UTC)
  •   Delete Deprecate and delete. It is redundant and it was very confusing when I found out there were two properties doing essentially the same thing. Many of the keep votes say it is not ideal but that we should keep it until a proper solution is in place. Deprecating and deleting is a path towards that outcome. Kees08 (talk) 17:46, 12 April 2020 (UTC)
  •   Delete Deprecate and delete. Per Kees08 redundant and confusing. TechContribution (talk) 20:37, 30 April 2020 (UTC)
  •   Delete Deprecate and delete. Galleries can use Commons gallery (P935) if necessary. Commons could even be given its own Sitelink if needed. The RedBurn (ϕ) 20:46, 2 May 2020 (UTC)
  Delete There are ways to query better. -- 02:42, 9 May 2020 (UTC)
  •   Keep - So far I have only seen claims that this property is redunant but not the proof that it is 100% redunant. Sure there is certainly some redunancy but that does not take away that down the stream this is quaranteed always the case. To my feeling I read above here mostly about that it gives double work as when a category is created or changed it has to be updated in two ways. I read only a little about that this property is one of the most extensively used properties in the various Wikimedia platforms. This is big! The use of this prorty has been widely adopted in use in the various platforms and this is something that can't be simple marked as redunant as that would imply big consequences for the complete Wikimedia ecosphere. The implications are large as this property forms the foundation of interproject linking. First deprecating the foundation and then starting to think about alternatives is the wrong order. If it is really redunant, first a full inventory needs to be made of all the possible issues that come up. Also the sitelinking of Commons galleries needs to be made obsolete, as it is still common practise that these get priority over Commons categories! That common practise needs to be deprecated first. Then a solution needs to be invented/created for all the possible issues that come up. For example both the category as the article on Wikipedia about that subject link to the same category on Commons. What to do with cases with one category on Commons, two articles on Wikipedia. And so on. In the previous discussions about deleting this property various reasons have been given why it is a bad idea to delete this property, and above here these reasons have not or insufficiently been addressed. Romaine (talk) 05:17, 30 May 2020 (UTC)
    @Romaine: Over the last year or so I've worked through, and resolved, thousands of cases where P373 is different from the sitelink. I have yet to find a single one that is not due to mismodelling on a Wikipedia; on Commons; or here. That's not a big surprise, though, as P373 is designed to smooth over those cases of mismodeling, and to provide a temporary shortcut that lets you link two different topics with a single commons category. The only reason it is "one of the most extensively used properties" is because it pretends to be a sitelink - which I think is the most used aspect of Wikidata. We already have alternatives - use the Commons sitelinks, and use the Lua code linked to above to find the correct one through linking properties such as topic's main category (P910). This already handles the sitelinks to Commons galleries without needing a change of approach to sitelinking them from here. What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them. If you want to test this, please point out some tricky cases that need resolving! Thanks. Mike Peel (talk) 18:45, 5 June 2020 (UTC)
  •   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)


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)
  •   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)
  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)

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)

  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)
  •   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)
  •   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)

  •   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)
  Delete Replacement available. -- 22:09, 9 May 2020 (UTC)
  •   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)


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)   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)
  Keep Wikidata have lot of external identifiers, why need deletion? --B.Zsolt (talk) 13:31, 11 December 2019 (UTC)
  Delete@B.Zsolt: Because there's a more useful identifier as replacement. --Liuxinyu970226 (talk) 14:53, 11 December 2019 (UTC)
  Delete per Andy. This is an item property btw, not an external identifier property. Multichill (talk) 19:04, 12 December 2019 (UTC)
  Delete after data migration. Robin van der Vliet (talk) (contribs) 00:43, 16 December 2019 (UTC)
  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)
  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)
  •   Keep per Thryduulf Michael FV (talk) 04:01, 9 January 2020 (UTC)
  •   Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 11:04, 20 January 2020 (UTC)
  •   Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. -- 23:22, 20 January 2020 (UTC)
  •   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)
  Delete As values are only items, merge em back won't hurt anything. -- 22:11, 9 May 2020 (UTC)


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)
  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)   Notified participants of WikiProject Railways Thryduulf (talk) 14:29, 16 December 2019 (UTC)

  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)
  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)
  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)
  •   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)
  •   Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 10:58, 20 January 2020 (UTC)
  •   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)
  Delete As values are only items, merge em back won't hurt anything. -- 22:11, 9 May 2020 (UTC)


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)
  Delete Since no archives available for em. --Liuxinyu970226 (talk) 03:42, 8 January 2020 (UTC)
  •   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)
  •   Delete Neither archives nor replacements available. -- 23:25, 20 January 2020 (UTC)
  •   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) person ID (P4285)Edit person ID (P4285): (delete | history | links | entity usage | logs | discussion)

(i) this is exactly the same identifier as for IdRef ID (P269); (ii) all references are now included on the SUDOC authorities (here's an example). Nomen ad hoc (talk) 08:14, 18 February 2020 (UTC)

It seems to me that I already found researchers who have person ID (P4285) and no IdRef ID (P269) or the opposite (have IdRef ID (P269) and no person ID (P4285)). Maybe a SPARQL query can find all these cases. Pamputt (talk) 09:23, 18 February 2020 (UTC)
I already heard about that oddity too. Any example, perhaps? Nomen ad hoc (talk) 11:38, 18 February 2020 (UTC).
@Envlh: FYI. Nomen ad hoc (talk) 11:44, 18 February 2020 (UTC).
Pour les francophones, voir aussi cette discussion. Pamputt (talk) 09:26, 18 February 2020 (UTC)
IF we can be sure that ALL people with person ID (P4285) also are in IDRef, then OK to   Delete. --Hsarrazin (talk) 13:52, 18 February 2020 (UTC)
  Keep As explained two years ago, because one property is a subset of the other, you need to keep both (if you have only IdRef ID (P269), you can't guess if a value in exists). Participants of the previous discussion should be notified. — Envlh (talk) 16:57, 18 February 2020 (UTC)
I'm afraid that only @Trivialist: can tell us that if there are records (or like) of former URL schemes or not, if yes, I would consider keep and change its formatter URL (P1630), if not, there's no problems anymore to delete. --Liuxinyu970226 (talk) 03:59, 2 March 2020 (UTC)
@Liuxinyu970226: What are you talking about? Trivialist (talk) 11:00, 2 March 2020 (UTC)
As Envlh said that Participants of the previous discussion should be notified, @Fralambert, Thierry Caro, Framawiki, DarTar, Pigsonthewing:@ديفيد عادل وهبة خليل 2: --Liuxinyu970226 (talk) 07:08, 9 March 2020 (UTC)
  Keep all people who has a IdRef ID (P269) do not have a person ID (P4285). And I've already seen two different identifiers used for IDref and I then contacted SUDOC and they merge both ID but it may happen. Pamputt (talk) 07:17, 30 April 2020 (UTC)
Pamputt, tu as des exemples de personnes avec un identifiant mais pas SUDOC ? Merci, Nomen ad hoc (talk) 18:08, 10 May 2020 (UTC).
@Nomen ad hoc:, non pas en tête. Et peut-être que ça a été corrigé depuis. Mais une requête SPARQL devrait permettre de les trouver. Pamputt (talk) 18:28, 10 May 2020 (UTC)
  Keep Per Pamputt, not enough be a reason to replace. --Liuxinyu970226 (talk) 04:29, 21 May 2020 (UTC)


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)

  Delete Just once parameters migrations are done. --Liuxinyu970226 (talk) 11:22, 24 March 2020 (UTC)


perpetrator (P8031): (delete | history | links | entity usage | logs | discussion)

Open questions in creation discussion --- Jura 08:08, 28 March 2020 (UTC)

No need due to participant (P710). --Infovarius (talk) 18:10, 29 March 2020 (UTC)

It's pretty bizarre to call the perpetrator of a terrorist attack a 'participant'. Participant makes it sound like a contest or recurring event @Thierry Caro, Tinker Bell, Misc, Jklamo: --Trade (|talk) 02:03, 31 March 2020 (UTC)

@Trade , I do not see "participant" in the property, I may miss some context, could you detail ? --Misc (talk) 08:42, 31 March 2020 (UTC)
Infovarius thinks that the property is unnecessary since we just can use "participant" instead. --Trade (talk) 15:21, 31 March 2020 (UTC)
  Keep I think this level of property detail is ok, given precedents here already. ArthurPSmith (talk) 18:21, 9 April 2020 (UTC)
  • In the meantime, the question has been resolved in the proposal discussion. If no other reasons for deletion had come up, I'd withdraw this. --- Jura 08:00, 10 April 2020 (UTC)


victim (P8032): (delete | history | links | entity usage | logs | discussion)

Premature creation, created before the usual wait of a week --- Jura 08:38, 28 March 2020 (UTC)

  John Doe   edit
object has role victim
▼ 0 reference
+ add reference

+ add value

--SixTwoEight (talk) 22:09, 3 April 2020 (UTC)

) 19:44, 2 June 2020 (UTC)

  •   Keep Husky (talk) 23:11, 4 June 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)

  •   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   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)
      Delete By my recent searching of, there's indeed no archives of those URLs. --Liuxinyu970226 (talk) 12:14, 22 April 2020 (UTC)
  •   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)
  •   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)
  •   Delete Germartin1 (talk) 09:09, 3 May 2020 (UTC)
  •   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)

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   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)
  •   Comment hardly used. --- Jura 08:10, 10 April 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   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)

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   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 IDsEdit

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)

  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)
  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)
  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:

Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Nattes à chat
  Notified participants of WikiProject France --Liuxinyu970226 (talk) 01:23, 8 April 2020 (UTC)

  •   Keep: same as for Shonagon. Nomen ad hoc (talk) 06:56, 8 April 2020 (UTC).
  •   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)
  •   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   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)
  • 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   Delete », 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)
  •   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)
  •   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)
  Keep Okay, per Vladimir Alexiev, I don't think that deprecating it is good for us. --Liuxinyu970226 (talk) 22:41, 3 June 2020 (UTC)

NASA active astronaut ID - DO NOT USE (P8102)Edit

NASA active astronaut ID - DO NOT USE (P8102): (delete | history | links | entity usage | logs | discussion)

Wikidata:Property proposal/NASA active astronaut ID

 · First criterion. There is no consensus: 1 approval and 2 negative comments indicating that the property cannot be realized.
 · The proposal contains an error on the RegEx and has been copied identically into the property.
 · A gap: subject item according to the old property.
 · Domain lacking precision and not reported on the property.
 · In short, the property, in the current state, cannot be put into production. I added this fact to the Property Label (since error). As I already wrote, the property contains errors, as well as many shortcomings. The proposal has been left fallow for 1.5 months. The NASA biographical ID (P2030) is still active, and, for my taste, it is this property which should simply be changed by a discussion on its TP. If Epìdosis has no outlet, I will provide a proposal on it when the time comes. This nonsenseThis issue needs to be resolved before.

Like what this discussion is not trivial. Cordially. —Eihel (talk) 23:17, 9 April 2020 (UTC)

Participant, proposing user, concerned with the old property: @Epìdosis, ArthurPSmith, Amitie 10g: and @Adert, Pigsonthewing, Jura1, יונה_בנדלאק, Trade: —Eihel (talk) 23:33, 9 April 2020 (UTC)

considering only Former (maybe also Management) and Active Astronauts, I don't see an economic way to have Former and Active Astronauts in the same property; so, my conclusion was that, being Former Astronauts the great majority, we could readapt old P2030 for Former Astronauts and create a new property P8102 for Active Astronauts. If no better alternative is found, I think that the property should be kept. --Epìdosis 07:52, 10 April 2020 (UTC)
  •   Keep Now that the property exists I don't see that it hurts anything to keep it. I would have agreed with the suggestion to wait, but neither of the "negative" comments explicitly stated they opposed creation, so I don't think the creator did anything wrong here, it was a judgment call. NASA did recently accept several thousand applications to become astronauts - here's a page on it - so I do think the number will be higher soon. ArthurPSmith (talk) 13:20, 13 April 2020 (UTC)
  speedy delete Created by wrong parameters, just re-create it. -- 22:07, 9 May 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)
  •   Delete: sounds sensible. Nomen ad hoc (talk) 18:06, 10 May 2020 (UTC).
  •   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)
  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)
  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   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)
  • has now 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)

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 (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)

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   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)
  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)
  •   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)
  •   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   Keep per Jc86035, needs technical changes before deletion. --Liuxinyu970226 (talk) 22:55, 3 June 2020 (UTC)


content partnership category (P8252): (delete | history | links | entity usage | logs | discussion)

This property was created last week as a result of this proposal. Unfortunately it was created with "string" datatype, rather than "item". Using strings for commons category links has several significant drawbacks compared to sitelinks through a category item: in particular, it's not possible to access the Wikidata item back from the Commons category, and it does not automatically update when the category is renamed. This is why category for people born here (P1464), category for pictures taken with camera (P2033), category for recipients of this award (P2517), category for the interior of the item (P7561), category for ship name (P7782) and category for maps (P7867) are all "item" datatype, linking to items like Category:Maps of Berlin (Q15143387).

I think we need a replacement property that is of "item" format; I am happy to bot-migrate existing cases over to category items so we don't lose any data, in the same way that I did for category for maps (P7867). I apologise for not noticing the property proposal here. Pinging those involved in the property discussion: @Dominic, Jheald, Arbnos, Kwj2772, Ahmad252, Dispe: Thanks. Mike Peel (talk) 19:00, 28 May 2020 (UTC)

If this is really better to use item instead of string, I guess one should also "convert" Commons category (P373). Pamputt (talk) 20:18, 28 May 2020 (UTC)
@Pamputt: See Wikidata:Properties_for_deletion#Property:P373 above... The equivalent to link to category items there is topic's main category (P910), although category sitelinks also go in the topic items unless there is an existing category item or a gallery. Thanks. Mike Peel (talk) 20:21, 28 May 2020 (UTC)
As you can see from the proposal, I modeled this on P373, which I did not realize was controversial. Having read the discussions, though, I am just left confused, as it doesn't seem like any of the options are really an improvement. I see the problem, but I think introducing a system that requires users to create a new item with the correct sitelink statement as a prerequisite to adding the P8252 statement to the original item is a pretty ugly user experience. You say you would migrate the existing ones, but that doesn't help the workflow for future uses. I don't think I even understood that was how Commons category properties worked before now, and I have a million Wikidata edits, so I'm not new.Dominic (talk) 21:11, 28 May 2020 (UTC)
@Dominic: Unfortunately I haven't found a better solution to this yet. The core problem is that you can't have multiple sitelinks to Commons from the same item, and that's unlikely to change (the assumption is built into the Wikidata data model). I come at this from the Commons side of things, where the sitelinks are essential for the Wikidata Infobox to work without it becoming a maintenance nightmare of manually defined QIDs everywhere. For the workflow in the future, it is a pain to do it manually for a lot of cases, but I think QuickStatements can do it in bulk, and if there's a list of QIDs and categories then I can always run pywikibot through a batch. For background, the bot code I used for the map categories is at [10], which is QuickStatements-esq (the 'newitem' function creates the item, "wd_item.addClaim" adds the link). Thanks. Mike Peel (talk) 06:59, 29 May 2020 (UTC)
@Mike Peel: Is there a Phabricator ticket for this? It seems like the ideal solution is to have a data type that allows us to link a page in a Wikimedia project, rather than having to create an item for each one we might want to refer to. Dominic (talk) 20:44, 1 June 2020 (UTC)
@Dominic: Probably. meta:Community Wishlist Survey 2017/Multimedia and Commons/Improve support of interwiki links on Commons using Wikidata might be a good starting point. It quickly goes into wider issues like phab:T54971. Any solution needs to be bi-directional, not just linking from here to Commons, but also having the reverse link back from Commons to here. Thanks. Mike Peel (talk) 21:41, 1 June 2020 (UTC)
@Pasleim: Re [11], did I do it correctly this time? Thanks. Mike Peel (talk) 17:38, 29 May 2020 (UTC)
I would say so. Now users can decide without being presented with a fait accompli. --Pasleim (talk) 15:18, 2 June 2020 (UTC)
  •   Delete use item datatype as every other similar property we created recently. --- Jura 07:08, 29 May 2020 (UTC)
  •   Delete Seems too prematurely created. --Liuxinyu970226 (talk) 11:11, 30 May 2020 (UTC)
    • @Liuxinyu970226: Just to defend Pamputt a bit here, properties are commonly created with fewer supports than that (as long as there is not opposition), and the proposal was open for over 2 months. I don't think it was premature to create it, just that no one objected when the discussion was held. Dominic (talk) 20:44, 1 June 2020 (UTC)
      •   Delete The problem isn't premature creation but lack of sanity checking which Pamputt should have done. It's fine when people who don't know a lot about how properties get constructed sometimes created proposals that need improvement but those shouldn't be created in the problematic state by property creators. ChristianKl❫ 23:15, 3 June 2020 (UTC)
        • I don't view this as @Pamputt's fault at all, given the available information and the existence of Commons category (P373), the creation of the property in this form would seem reasonable. And as it stands, the property works as intended - I just think it could have been done better using the 'item' format. I really should have noticed this property proposal earlier and commented on it, and again, apologies for not doing that. Thanks. Mike Peel (talk) 18:57, 5 June 2020 (UTC)
          • Thanks for pinging me :). Mike Peel has indeed well explained what happened in my mind. I wonder whether the datatype was good and indeed I have taken the example of Commons category (P373) which is by far the most used similar item. Moreover, the property was proposed on March 5th and I created it on May 22nd. So it remained visible for debate for more than 2 months and no one noticed the "wrong" type either. Considering the debate about Commons category (P373) above, it seems that the community does not have a unanimous opinion on the best way to model the Commons categories. Anyway, I do not understand really the debate here (if there is one). This property is not widely used yet so we can easily delete it and create a new one with another type; it is not a big deal. Pamputt (talk) 19:09, 5 June 2020 (UTC)