Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to navigation Jump to search

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

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

Properties for deletion may be used:

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

Properties for deletion should not be used:

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


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


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

demonym (P1549)[edit]

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

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

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

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)[reply]

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)[reply]

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

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

and if it is leave a message in Village pump of those projects! and this is an obvious case of potential use, and as this is already used, this request should be speedy closed. This should be discussed on other projects like Wikipedia first! --Amitie 10g (talk) 17:46, 15 July 2021 (UTC)[reply]
  • Symbol keep vote.svg Keep Nouns of countries are usually well known, Gentilés could be a question. I cannot understand how "Gentilé of" would help to find the gentilé of a country or a place. --Pa2chant.bis (talk) 07:35, 15 September 2021 (UTC)[reply]

doctoral student (P185)[edit]

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

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

  • 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)[reply]
@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).[reply]

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)[reply]
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).[reply]
  • Symbol keep vote.svg Keep. Infoboxes about professors often include a short list of prominent doctoral students. The inverse may be sufficient to generate a list of all students who have their own Wikidata items, but this property allows further curation of who are the most important students using ranks. @Lupin~frwiki: "PhD candidate" and "doctoral student" have different boundaries (other kinds of doctorate are not included) and different universities use different names, so I wouldn't advise rescoping the property.
    • Ok, I understand. So you would use this property for medicine doctorate for instance, I understand. Then "doctoral candidate" could then be much more convenient than "doctoral student". Do you agree? --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)[reply]
      • 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)[reply]
        • 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)[reply]

@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)[reply]

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

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:[reply]

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)[reply]

student (P802)[edit]

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

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

  • Symbol delete vote.svg Delete per nomination. Nomen ad hoc (talk) 19:39, 28 July 2019 (UTC).[reply]
  • Symbol delete vote.svg Delete Idem. student (P802) was originally supposed to keep only the main students but has been used in practice as an inverse property for student of (P1066) (notably after the inception of an inverse contraint). I agree that using the property properly wasn't that obvious (sources rarely differentiate the main and secondary students of a person). Anyway, it is currently cumbersome to maintain and do not bring anything new. Alexander Doria (talk) 18:47, 29 July 2019 (UTC)[reply]
  • Symbol delete vote.svg Delete - Premeditated (talk) 07:55, 5 August 2019 (UTC)[reply]
  • Symbol neutral vote.svg Neutral leaning toward Symbol delete vote.svg Delete as it's indeed redundant wuth the inverse and it's a one-to-many relationship. Pinging the top 5 users of this property: @Simon Villeneuve, Yamaha5, Aiaiaiaiaia, Villy Fink Isaksen, AttoRenato:. Cheers, VIGNERON (talk) 06:15, 8 August 2019 (UTC)[reply]
    @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)[reply]
  • Symbol neutral vote.svg Neutral Will somebody move the present values of P802 to P3342 ?. We access to P802 in template:infotaula persona of cawiki. I have no problem to change, but without lose the contents. Thanks,Amadalvarez (talk) 15:59, 12 August 2019 (UTC)[reply]
    We would ask a bot. Cheers, Nomen ad hoc (talk) 16:12, 12 August 2019 (UTC).[reply]
    Let me know when this should be moved. I can create a script for this. Edoderoo (talk) 17:37, 18 August 2019 (UTC)[reply]
    Thanks dear Edoderoo. Well, when (and if) a reasonable consensus will be reached? Best, Nomen ad hoc (talk) 18:26, 18 August 2019 (UTC).[reply]
    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)[reply]
    All right. Nomen ad hoc (talk) 18:17, 19 August 2019 (UTC).[reply]
    I assume that the data moved will incorporate a qualifier object has role (P3831) = schoolchild (Q48942) or similar, because P3342 is a generic property and need the person role which is implicit in the P802. Thanks !,Amadalvarez (talk) 18:18, 31 August 2019 (UTC)[reply]
    @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)[reply]
    @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)[reply]
  • @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)[reply]
  • Symbol delete vote.svg Delete, but please make sure that no data is lost (including qualifiers and sources) during the transition. --Yair rand (talk) 19:44, 15 September 2019 (UTC)[reply]
  • 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)[reply]
  • Symbol keep vote.svg Keep if it's meant to be moved to a property other than student of (P1066). --- Jura 15:54, 28 September 2019 (UTC)[reply]
    @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)[reply]
  • Symbol delete vote.svg Delete if moved to student of (P1066). --- Jura 15:54, 28 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep I base this on reading the discussions here. Currently it hasn't been made clear what removal of the property would solve. I've asked for clarifications which may change my view. Current position: Monitoring data relevancy is better than making the statements more complex as a means to get less data. If "inverse constraints" are not to be used (always cumbersome to maintain), that should probably be a bigger discussion rather than per property. Jagulin (talk) 05:00, 17 October 2019 (UTC)[reply]
  • 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)[reply]
    Please see #Property:P185 above. Nomen ad hoc (talk) 08:07, 17 October 2019 (UTC).[reply]
    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)[reply]
  • Symbol keep vote.svg Keep: clearer relationship than anything else especially in relations from earlier centuries Palotabarát (talk) 10:39, 20 October 2019 (UTC)[reply]
  • Symbol delete vote.svg Delete Clearly-than-god no consensus to keep such old-school schema. Replacement is now available. --Liuxinyu970226 (talk) 04:54, 1 January 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete too many, information should be stored by inverse. Michael FV (talk) 03:16, 9 January 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep nghiên cứu sinh (doctoral student) is different by sinh viên (student) in Vietnamese. -- 23:11, 20 January 2020 (UTC)[reply]
Symbol keep vote.svg Keep Has language conflicts. -- 02:39, 9 May 2020 (UTC)[reply]

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

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

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

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

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

  • Symbol delete vote.svg Delete until IDs aren't persistent. Nomen ad hoc (talk) 18:17, 2 September 2019 (UTC).[reply]
  • 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)[reply]
  • @Edgars2007: who proposed the property in good faith. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 30 October 2019 (UTC)[reply]
  • 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)[reply]
  • Symbol delete vote.svg Delete Vandalism targets. --Liuxinyu970226 (talk) 04:56, 1 January 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep stay real adress on --Arachn0 (talk) 11:53, 2 January 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep IDs are being improved now. --Mzngan (talk) 09:57, 6 January 2020 (UTC)[reply]
    • Only 3 edits. Most likely sock puppet. --Kolja21 (talk) 05:33, 23 August 2021 (UTC)[reply]
  • Symbol keep vote.svg Keep since used by several Wikipedias to generate external links, values should be fixed, vandalism undone. Michael FV (talk) 03:20, 9 January 2020 (UTC) / One day user --Kolja21 (talk) 05:33, 23 August 2021 (UTC)[reply]
    @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)[reply]
  • Pictogram voting comment.svg Comment "Mzngan" and "Michael FV" seems to be sock puppets of the global banned user. BTW one more example of BBLD IDs:
    • Heinricus Meurch (Q55195758) = Meurch-Heinricus-um-1699 [3]
    • Heinricus Meurch (Q55195758) = Meyendorff-Christoph-Gustav-Alexander-Frh.-v.-1796-1865 [4]
    • Heinricus Meurch (Q55195758) = GND1052457312 [5]
    • Heinricus Meurch (Q64690920) = Meurch-Heinricus-1676-1710 [6]
Imho both items can be merged. See also Property talk:P227/Duplicates with more items created because of constantly changing BBLD IDs (using different spellings, ISNI, VIAF now GND). --Kolja21 (talk) 00:49, 17 January 2020 (UTC)[reply]
@Kolja21: m:Steward_requests/Checkuser/2020-02#Tobias_Conradi_(or_影武者?)@wikidata tells me  unlikely. --Liuxinyu970226 (talk) 01:58, 25 February 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep. The central maintenance of the BBLD IDs in Wikidata is easier than maintenance in individual Wikipedias, deleting the property would increase the workload for Wikipedia editors in the field of Baltic Germans.
The BBLD IDs are used for creating references in
  1. Wikidata, where it is often the only reference apart from VIAF (P214) and the GND (P227) - for the items in question the VIAF record is frequently based on the GND record and the GND record on the BBLD record
  2. Wikipedias // Google evidence
  3. the GND (authority file, hosted by the German National Library) // Google evidence
  4. publicly financed projects like the Deutsche Biographie, a major biographical publication // Google evidence
  5. privately owned projects like, which is also used in Wikidata (d:Property:P2600) // Google evidence.
The BBLD is a continuation of the DBBL (Deutschbaltisches biographisches Lexikon 1710-1960) which is frequently cited in the NDB for items about Baltic Germans. Both works are cited in scientific publications.
If IDs have been deprecated they should be either marked as such - the ("list of Wikidata reasons for deprecation") could indicate that marking values as deprecated is possible in Wikidata - or if no verifiable source is found they should be deleted.
David Feest, spokesperson of the Baltic Historical Commission for the BBLD and a reader of Wikipedia. Davidfeest (talk) 07:52, 20 January 2020 (UTC)[reply]
  • Pictogram voting comment.svg Comment I would like to make clear that whoever the said "BBLD user" is, he is neither working for the Baltic Historical Commission, nor is he in any way involved in the BBLD project of the commission. David Feest, board member of the Baltic Historical Commission Davidfeest (talk) 08:25, 13 August 2021 (UTC)[reply]
    • @Davidfeest: Danke für die Rückmeldung. Parallel zu den Edits des sogenannten "BBLD user" werden GNDs mit dem Bibliothekssigel DE-2813 angelegt. Es kann sich daher nicht einfach um einen externen "Fan" handeln. Letzten Monat hat er bis zu drei Sockenpuppen pro Tag angelegt, siehe de:Benutzer Diskussion:WahrheitFuerAlle. Der Wartungsaufwand, den er in Wikipedia und Wikidata verursacht, ist enorm. @Emu: FYI. --Kolja21 (talk) 05:10, 23 August 2021 (UTC)[reply]

Commons category (P373)[edit]

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

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

@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)[reply]
@Liuxinyu970226: The links 2 and 3 don't seem to work. The RedBurn (ϕ) 20:30, 2 May 2020 (UTC)[reply]
@Nomen ad hoc, Liuxinyu970226, The RedBurn: The links are : 1, 2, 3, 4. —Eihel (talk) 11:04, 30 May 2020 (UTC)[reply]
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)[reply]
  • Symbol keep vote.svg Keep - needed when the Commons site link is connected to a Gallery page. - PKM (talk) 05:03, 9 September 2019 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
  • Symbol keep vote.svg Keep The "other site"-link is a one-to-one mapping from Commons to a Wikidata object (and its interwiki links). Commons category (P373) is a many-to-many mapping to Commons. /ℇsquilo 06:04, 9 September 2019 (UTC)[reply]
    • @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)[reply]
      • 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)[reply]
  • Symbol delete vote.svg Delete - or in the immediate future, deprecate until the remaining cases that don't match the sitelinks are resolved (while bot-removing matching cases to unearth the mismatches). This property served its purpose as a temporary work-around, but nowadays the Commons sitelinks are used, both to link to Wikidata from Commons (using commons:Template:Wikidata Infobox), and also to link from Wikipedias (using en:Template:Commonscat/en:Module:WikidataIB's getCommonsLink function). Keeping P373 around just adds to the maintenance burden, as it needs to be kept in sync with the sitelinks (the sitelinks automatically update when a category is moved/deleted, P373 has to be manually/bot-updated), and that's particularly difficult here since things like Wikidata:Database reports/Constraint violations/P373 are continuously broken/outdated. There is a lot of work still to do to get rid of this property - in particular, uses on various wikis need to be changed to use the sitelink instead - but I'm not sure that will start unless the property is clearly marked as deprecated/on its way out, in favour of the better solution of the sitelinks. Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep Per previous threads. Apparently nothing changed. I may add keeping Commons gallery (P935) and deleting P373 while allowing gallery-sitelinks doesn't make much sense. Galleries should be deprecated as Commons sitelinks. strakhov (talk) 06:27, 9 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep: P373 is still the least-bad kludge for dealing with Wikidata's original sin of insisting on 1:1 item correspondence between projects, despite being founded long after Commons. As Liuxinyu970226 mentioned, this is at least the 4th nomination to delete P373. Commons still has both mainspace (gallery) and category pages for topics, and the category pages are primary and have the most content; mainspace is utterly optional, and probably even less popular than it used to be. Though Wikidata has loosened the notability criteria and added links between main items and category items, there is still the question of how one deals with a Commons category being the primary page for a subject and sometimes a not-very-notable subject at that. How do we deal with Commons if P373 isn't on the main item? Problems no matter which way you try:
    1. The current sitelink standard is to put the Commons category on a Wikidata category item if there is one, and otherwise put the Commons category on the Wikidata main item. But if there's a Commons gallery (mainspace page), and Wikidata has no category item for that topic, then the Commons gallery gets the sitelink, and the Commons category gets no sitelink, because Wikidata is bound to 1:1 sitelink relationships, even though galleries aren't where most of the content is on Commons.
    2. One might propose that we simply create a Wikidata category item for every Commons category. But are Wikidata category items allowed for topics that have no main topic? I see that "one valid sitelink to a page on ... Wikimedia Commons" was added to Wikipedia:Notability, but I can't tell if that was by consensus; there seem to be more opposing that supporting the idea on Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). Commons categories don't have to be "notable" to exist. (Examples: Commons:Category:Slurry near St. David, Illinois in April 1973; Commons:Category:Images from the State Library of NSW album 7039; Commons:Category:2015-03-21 Morgan Park v. Lutheran Class 3A consolation basketball game; Commons:Category:LVIA F669 ap7 b86; Commons:Category:Random events in the USASMDC.) Wikidata now seems to allow very-low-notability articles — for example, on Wikinews and Wikisource — to qualify for Wikidata items. But on Commons, the category creation criteria is even lower. Only files have anything like a notability criterion: "realistically useful for an educational purpose" or legitimately "in use on another project"; a Commons category, despite usually being the main topic page on Commons, is created and retained simply on there being sufficient content to fill it. Commons doesn't allow blatant spam, but it doesn't prohibit sponsored content either. Does a company or product qualify for a Wikidata item just because someone uploaded enough files to Commons to get a category made? (By the way, even that thin criterion has been abused by some Wikidata evangelists/conquistadors, who have been invading Commons and creating new Commons categories with only one file, claiming that Commons rules don't prohibit it, then "coincidentally" linking the categories to existing Wikidata items to get credit from whoever's keeping track of Wikidata adoption metrics.)
    3. Even if every non-hidden Commons category now automatically qualifies for a Wikidata category item, there is still the process of creating each Wikidata item. It's been 5 years since I pointed out the burden of creating a category item on Wikipedia at Wikidata:Requests for deletions/Archive/2014/Properties/1#Commons category (P373) 2. (Granted, steps 5 and 6 aren't needed if there is no main topic.) Would we want a bot to create the Wikidata category items instead?
So, until we have all of that settled, and a working implementation for all of it, P373 should stay: It's the only method that allows both a gallery and a category link (which is more important) to Commons to exist simultaneously for a Wikidata main topic item that doesn't have a Wikidata category item. --Closeapple (talk) 07:44, 9 September 2019 (UTC)[reply]
  • @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)[reply]
  • Symbol delete vote.svg Delete If Mike thinks it's ready to go, lets get this started, even if it will take another five years to implement the deletion. Step 1: remove the property from category items. Step 2: remove the property from items linked to a category. Step 3: remove the property from items with the sitelink. Step 4: ... --- Jura 07:59, 9 September 2019 (UTC)[reply]
  •  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)[reply]
    @JAn Dudík: Oppose deleting or oppose keeping? --Liuxinyu970226 (talk) 00:20, 4 December 2019 (UTC)[reply]
    I mean Symbol keep vote.svg Keep, but I agree with deprecation in future. JAn Dudík (talk) 08:56, 4 December 2019 (UTC)[reply]
  • 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)[reply]
    • @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)[reply]
      • @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)[reply]
  • Symbol delete vote.svg Delete per Mike Peel. This property is nothing but awful and highly problematic programming spaghetti, for the reasons exposed. the mere fact that it exists is a continuous source of trouble, as tool developers may use them as a source for the commons cat, wide-spreading and perpetuating the problem till unmanageable levels. The link article-category and reverse is generally made through SetSiteLink. My perception is that most of this evilness emanated from a primeval misconception that Wikipedia Articles corresponded with Commons Galleries (generally false, by default, since Galleries are mere exhibitors for Commons categories, and there could be like 100 of them for a given subject, none of which with special preponderance over the others) and that Wikipedia Categories had any importance to Commons, and should preferably relate to Commons Categories (generally false too, though sometimes it can be useful to connect them, such as in "churches in municipality X", the kind of thing that probably will never have an article in Wikipedia). In any case, this property doesn't seem to be needed at all.--DarwIn (talk) 11:06, 9 September 2019 (UTC)[reply]
    • Pictogram voting comment.svg Comment In case of removal, please check Listeria, as I seem to have noticed it uses this property to show the Commons Category in the lists (should be using SetSiteLink, otherwise it gets broken everytime someone moves a category in Commons).--DarwIn (talk) 11:08, 9 September 2019 (UTC)[reply]
  • Symbol neutral vote.svg Neutral I came to this discussion thinking to vote to keep it, but Mike Peel has a convincing argument. I can see in the future time when P373 can be retired and that would simplify our maintenance burden, and in general prevent the same info being stored in two places. I would also like to see some trimming of the number of unmaintained Commons galleries clogging the sitelinks, but that topic should be discussed on Commons. --Jarekt (talk) 11:59, 9 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep and delete other sites link. in a larger sense, deletion is not a quality improvement process, rather provide the ontology, team and method to improve wikidata to commons links. Slowking4 ‽ (Rama's revenge) 12:45, 9 September 2019 (UTC)[reply]
    • @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)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Symbol keep vote.svg Keep read archives, not going to repeat myself. Multichill (talk) 16:57, 9 September 2019 (UTC)[reply]
    @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)[reply]
    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)[reply]
    I started another discussion at Wikidata talk:Notability about allowing certain category items for Commons. Ghouston (talk) 02:48, 14 September 2019 (UTC)[reply]
    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)[reply]
  • Symbol keep vote.svg Keep. Nothing has changed nieither in Wikidata nor in Wikipedia nor in my opinions. We have namespaces: articles and categories. Now both items of categories (we apply for them "other sites") and articles (we apply for them Commons category (P373)) have connections with categories of Commons. Very often other sites are used in items of articles. But as soon as we make statement topic's main category (P910) in article item bot immediately moves commons category sitelink to category item. (See, for example, recent history of Vikulovsky District (Q1753812)). If Commons category (P373) wouldn't exist connection between article item and commons category would be lost. So Commons category (P373) is the only effective and visual way to keep connection of articles items and commons categories. Removing the property is just losing of such way. Property's benefit was discussed n project chat. And besides I can repeat myself: "In Russian Wikipedia we use Commons category (P373) in a great deal of temlates including crucial important ones. Removing the property right now just would break links to Commons in a huge number of articles and categories, spoiled their interface.". --Ksc~ruwiki (talk) 18:45, 9 September 2019 (UTC)[reply]
    @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)[reply]
    • 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)[reply]
      • @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)[reply]
        • 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)[reply]
          • @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)[reply]
            • 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)[reply]
Symbol delete vote.svg Delete Per Mike Peel, I think some Dutchism discussions can be stopped, if the problem is one-per-one linking glitch, all the best thing we should and need to do is to break such a glitch, not use property to white-paint. -- 02:39, 10 September 2019 (UTC)[reply]
  • Symbol delete vote.svg Delete per Mike Peel or at least let's try to deprecate this property once and for all. It's about time that we fix this thing. Sannita - not just another sysop 20:50, 10 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep unless is Commons linking issue finally resolved (abandon commons galleries sitelinking - I am afraid it needs another lengthy RFC), then Symbol delete vote.svg Delete. --Jklamo (talk) 10:08, 11 September 2019 (UTC)[reply]
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)[reply]
@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)[reply]
@Roy17: Creator now uses the sitelinks! Currently as well as P373, but if we decide to delete this property then there's now a clear migration path. Thanks. Mike Peel (talk) 07:58, 2 November 2021 (UTC)[reply]
Pictogram voting comment.svg Comment Voters should be aware that Commons category (P373) is currently used for sidebar ("In other projects") linking to Commons from Wikipedia articles. So deleting this property without a new technical solution will simply make the links disappear. --Matěj Suchánek (talk) 10:51, 14 September 2019 (UTC)[reply]
@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)[reply]
A deprecation stage of a property means that it should not be added to items and should be removed there where possible. If that deprecation stage is present, the technical solutions to the sidebar (etc) ashould already have taken place. Again: first deprecation (= breaking) and then fixing is the wrong order. Romaine (talk) 07:53, 12 July 2020 (UTC)[reply]
  • 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)[reply]
  • Symbol keep vote.svg Keep Agree that the current situation is not the best, however I believe that 'other sites' is a ridiculous, kludgey solution that's even worse than this property. Gamaliel (talk) 20:19, 17 September 2019 (UTC)[reply]
  • Deprecate. I also agree with Mike Peel. --Tinker Bell 02:47, 20 September 2019 (UTC)[reply]
  • Pictogram voting question.svg Question If this property is deleted, who will update the Wikidata-linked Creator template which current uses P373 to populate the "homecat" parameter? - PKM (talk) 20:14, 20 September 2019 (UTC)[reply]
    @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)[reply]
  • Symbol keep vote.svg Keep Let's look at the practicalities. Suppose I have a large or large-ish set of items, and I want to identify which of them have Commons categories. With P373, I just need the following in my SPARQL query:
    ?item wdt:P373 ?commonscat
Without P373 I have to do something like the following:
      ?commonsCategoryFromItem schema:about ?item;
                               schema:isPartOf <>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromItem), ""))
      ?item wdt:P910 ?catItem .
      ?commonsCategoryFromCatItem schema:about ?catItem;
                                  schema:isPartOf <>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromCatItem), ""))
    BIND(COALESCE(?commonsCategoryFromItem, ?commonsCategoryFromCatItem) AS ?commonsCategory)
Yes, it's possible (eg:
But (i) it's a hell of a lot to have to remember for quite a simple thing, especially for SPARQL newbies; and (ii) the code above is a real resource-hog and far more likely to time out, if one tries to apply it for groups of items of any size.
To start with there is the schema:about / schema:isPartOf join. This compares to P373 which is very specific. For each ?item the fragment above starts with in its solution set, P373 will typically identify only a single commonscat for each one, leading to a solution set going forward with about the same number of rows (or slightly smaller, as some items won't have commonscats). In contrast, schema:about connects the item to every article about it, in every Wikipedia. That may immediately expand the solution set by a factor of 20, before then a huge join with the set of all pages on Commons to reduce it down again; then a per-set-member string operation (a further notorious source of slowness) to filter out galleries etc and select just for categories; and then having to do the whole thing all over again, in case it's actually a parallel category-type item that is what is actually sitelinked to the Commons category. If the group of items is of any size (or if one's trying to do a COUNT query, such as how many churches have Commons categories), all this is slow-slow-slow-slow, so very likely to make the query time out without completing its execution.
I accept that maintaining all the P373 entries as a set of convenience statements is a pain. But it is something that bots can and do efficiently manage. The value of maintaining P373 is that it makes corresponding queries much easier to write, and makes a huge range of queries possible to successfully execute that would otherwise time out. I think that makes P373 worth keeping.
The other point is that currently almost all Wikipedias are using P373 to identify which Commons page should be linked to from the sidebar of an article page to give a category page rather than an article page; so, also, some modules on Commons. With P373 this is a very easy look-up. Yes, implementing the logic above is possible (I believe some Commons infoboxes may do it); but how big a job to implement this in the MediaWiki code?
So, for these two reasons, keep (and keep maintained). Jheald (talk) 21:27, 21 September 2019 (UTC)[reply]
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)[reply]
@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)[reply]
@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)[reply]
An expression could presumably also be added to SPARQL to return the Commons category. Ghouston (talk) 01:43, 29 September 2019 (UTC)[reply]
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)[reply]
  • Symbol keep vote.svg Keep I was told that site links could link to whatever page on Commons. So if we can attach a commons category to the item, its important to describe it properly. More over, there are (an I guess they are attached to this property, not to the sitelinks (for common)) multiple technical reason, why it should be kept (so before potetional removal, these technicalities should be work out). E.g. interwiki links from Commons, to Wikipedia, category templates etc. --Juandev (talk) 10:21, 23 September 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep It is now the only (simple) way to access the Commons category which belongs to an article or subject. --RolandUnger (talk) 06:03, 7 October 2019 (UTC)[reply]
  • Symbol delete vote.svg Delete Please deprecate and later delete this property once and for all, the commonscat links are sufficient for the intended purposes. Linking more than two commons categories is not useful and therefore no reason to keep this property. Steak (talk) 10:48, 10 October 2019 (UTC)[reply]
  • Symbol delete vote.svg Delete Per above, especially per Liuxinyu970226. T54971 might be a better solution to fix What Multichill concerns. --2409:8902:9301:F7F8:1FC0:6702:8454:4E37 02:13, 30 October 2019 (UTC)[reply]
Symbol delete vote.svg Delete Problemic property, should consider more smart ways instead. --2409:8902:9001:6CE0:5E2F:BCDA:B1D9:2A6F 00:22, 4 December 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep Per above. + We will have problems with automatic cross-project linking without this property. --sasha (krassotkin) 14:13, 17 December 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep Sitelinks have some advantages over P373. However they lack flexibility (unique values, etc.) and no standard seems to have finally settled the articles vs categories issue. Therefore, P373 is still a useful fallback.--Pere prlpz (talk) 11:14, 26 December 2019 (UTC)[reply]
    @Mike Peel: How do you think about Krassotkin's and Pere prlpz's comments? --Liuxinyu970226 (talk) 03:38, 20 June 2020 (UTC)[reply]
    @Liuxinyu970226: I think I've already answered the points by @Pere prlpz, Krassotkin: elsewhere in this discussion - primarily that there is a standard approach to using the sitelinks, and P373 is mostly just a duplication, or at best an indication of places where we need to improve our modelling here or the commons category structure. Thanks. Mike Peel (talk) 09:21, 21 June 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete no reason to single out Commons, use topic's main category (P910) Michael FV (talk) 03:32, 9 January 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete phab:T54971 solution should be enough, please also consider nominating Multichill for WD:RFP/R since that guy only keeps Wrong claims by themselves. -- 23:20, 20 January 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Redundancy must die. — Mike Novikoff 23:50, 10 February 2020 (UTC)[reply]

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

@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)[reply]
  • Symbol delete vote.svg Delete Unnecessary and useless. -- MovieFex (talk) 04:32, 29 March 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Deprecate and later delete (redundant; a lot of people with no experience with Wikidata are very surprized to find out that we have such fundamental mess in linking to Commons categories) Vojtěch Dostál (talk) 08:11, 31 March 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Deprecate and delete. Two ways of linking is source for errors and confusion. MrProperLawAndOrder (talk) 17:44, 11 April 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Deprecate and delete. It is redundant and it was very confusing when I found out there were two properties doing essentially the same thing. Many of the keep votes say it is not ideal but that we should keep it until a proper solution is in place. Deprecating and deleting is a path towards that outcome. Kees08 (talk) 17:46, 12 April 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Deprecate and delete. Per Kees08 redundant and confusing. TechContribution (talk) 20:37, 30 April 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Deprecate and delete. Galleries can use Commons gallery (P935) if necessary. Commons could even be given its own Sitelink if needed. The RedBurn (ϕ) 20:46, 2 May 2020 (UTC)[reply]
Symbol delete vote.svg Delete There are ways to query better. -- 02:42, 9 May 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep - So far I have only seen claims that this property is redunant but not the proof that it is 100% redunant. Sure there is certainly some redunancy but that does not take away that down the stream this is quaranteed always the case. To my feeling I read above here mostly about that it gives double work as when a category is created or changed it has to be updated in two ways. I read only a little about that this property is one of the most extensively used properties in the various Wikimedia platforms. This is big! The use of this prorty has been widely adopted in use in the various platforms and this is something that can't be simple marked as redunant as that would imply big consequences for the complete Wikimedia ecosphere. The implications are large as this property forms the foundation of interproject linking. First deprecating the foundation and then starting to think about alternatives is the wrong order. If it is really redunant, first a full inventory needs to be made of all the possible issues that come up. Also the sitelinking of Commons galleries needs to be made obsolete, as it is still common practise that these get priority over Commons categories! That common practise needs to be deprecated first. Then a solution needs to be invented/created for all the possible issues that come up. For example both the category as the article on Wikipedia about that subject link to the same category on Commons. What to do with cases with one category on Commons, two articles on Wikipedia. And so on. In the previous discussions about deleting this property various reasons have been given why it is a bad idea to delete this property, and above here these reasons have not or insufficiently been addressed. Romaine (talk) 05:17, 30 May 2020 (UTC)[reply]
    @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)[reply]
    Hi Mike Peel, Over the past years I also worked on resolving thousands of cases of issues with P373. So I am fully aware of the troubles with it. I agree that it is one of the most used properties because it pretends to be a sitelink, but I also disagree with that idea. The main principle of a sitelink is that there is a one to one an item on Wikidata and a category on Commons. For many subjects this is the case, but also for many subjects this is not the case. Over the past month (but also many times before that), I have come acros thousands of subjects that do not have a one to one Wikidata-Commons situation. So no, Commons sitelink is in many cases not an alternative. That is even worse than I thought before! I think it is even worth to investigate if it would be possible to abbolish Commons sitelinks in Wikidata (certainly for categories) (because sitelinks only allow a 1 to 1 support, all other data is not allowed), and move all the functionalitis that the Commons sitelinks provide to Commons/Wikipedia/etc, to the P373 property. Another alternative is that the Commons sitelinks are redesigned, but that is something I am hoping for more than a decade (as even before Wikidata existed this was already a problem to deal with in Wikipedia).
    "find the correct one through linking properties such as topic's main category (P910)" -> This is just one of the cases where this might be a solution, but there are various other situations to that have no solution. On this page I see no solutions offered to those, which is I think highly problematic. In Dutch we have a saying that people should not throw away shoes befre you got new ones. That is what is happening here.
    "What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them." -> Just alone for rijksmonuments in the Netherlands, almost every single municipality in the Netherlands has cases of for example even 18 items on Wikidata with only one category on Commons. So speaking about "not many of them", in percentages almost everything is small compared to millions.
    "If you want to test this, please point out some tricky cases that need resolving!" -> This is turning it around. You want to change something, then you need to come with the solutions. Most Wikidata uers have no idea that discussion is going on here, and will highly likely influence there work. Then expecting that the majority that is not present here comes with the tricky cases, that is not the way to work.
    What you are basically asking is just to go forward, without making sure you have the solutions in place first.
    Also that you minimalise the number of cases you think you would get, I would say underestimate, is a bad approach. With this kind of gigantic changes, decisions need to be based on facts and not on imagination. The simple thing that the number of cases involved is still not counted is troubling. In my previous message I wrote that as this property has usage in gigantic propertions, an inventory should be made. On this page I do not see such a thing happening (asking for examples is turning it around and is not an inventory). To me this feels like the issues that have brought up by various users are not taken seriously. The issues addressed concern situations that are not just simple (small) cases, but represent a large structural mismatch.
    I am also concerned about what has been done with my previous post from 30 May 2020. In there I made a first basic analysis of the situation. Also that has been ignored. As both the analysis and issues raised by users are not addressed first, this discussion is walking in a dead-end street and can only have one outcome: proposal rejected. Romaine (talk) 07:49, 12 July 2020 (UTC)[reply]
    @Romaine: From my experience, there are three types of items that need to link to the same Commons category - 'topic', 'list' and 'category' items (or maybe four, if you include 'categories of lists'). I think those are well modeled with the category/list linking properties. All of the other cases I've come across have been due to mis-modelling either here, on a Wikipedia, or on Commons - part of why I was asking for illustrative examples where this wasn't the case. Abolishing Commons sitelinks would be impossible now, as there is no other way to provide a bi-directional link between Commons and Wikidata, and copying QIDs around rather than using the sitelinks would create a maintenance nightmare that the auto-updating of commons categories avoids. For Rijksmonuments, I think having a container category for them works well, but if you're using Wikidata lists then you could automatically use the sitelinks the same as using P373 (also relevant to this point is the de-voy discussion below). I think the solutions already exist, otherwise I wouldn't be supporting this PfD so emphatically - and again, asking for cases where the solutions don't work. I hope that the Wikidata modelling is not so inflexible that a temporary fix introduced in 2013 *has* to continue into the future indefinitely. Thanks. Mike Peel (talk) 20:41, 13 July 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep - I don't deny that this property is confusing (especially for newcomers) and it's an ugly kludge, but given the fact that it's virtually impossible to do proper SPARQL queries without it, many things will break if we remove it, and many other things mentioned above (like the gallery / category problem) we can't really remove this property. Husky (talk) 23:07, 4 June 2020 (UTC)[reply]
    @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)[reply]
  • Symbol delete vote.svg Delete this property has always been an outlier and with the other sites link its now redundant and frankly highly confusing. EoRdE6(Come Talk to Me!) 03:53, 12 June 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep Many uses, a lot of things would break and this is a really useful thing.--Ferdi2005[Mail] 11:25, 9 July 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep causes too many problems for me to support deletion. Every issue needs to be addressed before deletion, as this is used a hell of a lot and will cause crosswiki issues. --IWI (talk) 17:14, 6 September 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep There are many occasions where a pairing category item exists so the (re-)use of the interwiki is not possible as it is used elsewhere. It needs to remain, and it needs to remain active and undeprecated.  — billinghurst sDrewth 05:48, 14 September 2020 (UTC)[reply]
    @billinghurst: Can you give some examples, please? Thanks. Mike Peel (talk) 08:40, 14 September 2020 (UTC)[reply]
    @Mike Peel: Something like Category:United States (Q1410960). I regularly do a merge/cleanup where I move the Commons category interwiki to the Category: item from the topic-item, ensuring we have the CommonsCat on the topic-item and adding the Topic-Cat: property. And over time I have also seen numerous species and redundant species names (whatever they are called) where the CommonsCat is on both items. [I don't remember maintenance activities specifics].  — billinghurst sDrewth 14:48, 14 September 2020 (UTC)[reply]
    @billinghurst: I think the cases like Category:United States (Q1410960)/United States of America (Q30) are already solved by following the topic's main category (P910)/category's main topic (P301) links, if not then they normally just need cleanup so they are properly linked, they don't really need Commons category (P373) except as a convenience shortcut. Thanks. Mike Peel (talk) 15:42, 14 September 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep for now. Removing P373 makes the querying the commosncat via SPARQL-queries and API queries one magnitude more complex. Rationale for removing the P373 is that there is no fast method for querying the commonscat backlink from Lua (= queries like this is my P373 value, what is my Wikidata ID? ) this could be fixed by adding relevant function to scribunto. Second problem is that the P373 values arent automatically updated when category is moved. This could be handled by bots like the double redirections are tracked and updated. --Zache (talk) 07:48, 7 January 2021 (UTC)[reply]
  • Symbol keep vote.svg Keep This property is needed in order to show a link to the Commons category in the sidebar on Wikipedia and other projects when the category is linked in another item (see this discussion), at least not until phab:T232927 is resolved. --Thibaut (talk) 06:40, 20 May 2021 (UTC)[reply]
    @Thibaut120094: That function, if I remember correctly, has nothing to do with P373, that's just a cross-wiki link sidebar that match such links with language(s) you speak, this means even we don't use this property, we can also see that thing, unless you disable it via Special:Preferences, that sidebar remains when necessary. --Liuxinyu970226 (talk) 00:26, 13 July 2021 (UTC)[reply]
    I’m talking about this, it does show a link to the Commons category entered in Commons category (P373) of the linked item, it’s useful since we can’t add Commons categories as sitelink in items that are not categories (like a Wikipedia article).
    And "P373" is literally in the name of the Phabricator task. All of this is better explained here and here. --Thibaut (talk) 01:18, 13 July 2021 (UTC)[reply]
  • Symbol keep vote.svg Speedy keep Widely in use, namely in Module:Authority control (Q11640331) in more than 100 projects, including Wikipedia, Wikisource, and others. This should be discussed at the Village Pump/Café on those projects before taking actions! --Amitie 10g (talk) 17:49, 29 May 2021 (UTC)[reply]
    • @Amitie 10g: The discussion started in 2019, there's nothing speedy about it now... There is drop-in replacement Lua code available that can easily be used to replace existing uses, it's already in use on enwp (en:Template:Commons category for example). Thanks. Mike Peel (talk) 13:04, 9 July 2021 (UTC)[reply]
  • Symbol keep vote.svg Keep for now, according to multiple arguments above. Peter17 (talk) 17:48, 19 July 2021 (UTC)[reply]
    @Peter17 If you think Per-above-ism is good for you, keep all properties per above, not just this one and delete others, then I think this WD:PFD page can be deprecated Liuxinyu970226 (talk) 07:58, 1 November 2021 (UTC)[reply]

Discussion (remaining issues)[edit]

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

  • @Mike Peel: The doubleness is unwanted, however the core problem is that we often have 2 Wikidata item pages for 1 item (the first one for article links, the second one for category links of the same item). To link the two item pages mutually is complicated. The system solution would be to merge these pairs (eg. Music and Category:Music, or Paris and Category:Paris). But unfortunately, we must be realistic and accept that this right solution is unenforceable in the near future. If the creators of Wikidata did not think of this at the beginning, it will be very difficult to fix it later. But even if this will resolved, some complicated relations will remain: e.g. Painting vs. Category:Painting vs. Category:Paintings vs. List of paintings etc. We should have realized from the beginning that there are two main types of categories: "item categories" and "group categories". The creators of Wikidata had little experience with Commons, so they got the idea from Wikipedia that a typical category is a "group category", a and so they did not notice existence of "item categories" which are typical with singular names. "Item categories" (typically "singular categories") should be joined directly to the item page of their item. "Group categories" ("plural categories") are a different problem which can be treated in another, more analytical way.
A sitelink is definitely more practical and more functional than just properties. The problem is that in some cases a sitelink is not available directly, but only through properties (P910, P1754, possibly other similar) as a sitelink of another item – and in these cases it is less accessible and less useful than P373. It is therefore not possible to call this entry by a simple link/expression. Thus, P373 translates the indirectly accessible data from the sitelink so that it can be understood even by simple templates, links and infoboxes. If we manage to implant any simple tool directly into the Mediawiki that can replace it, then we can leave and delete P373. Ideally, the remote indirect sitelink from the linked sister item page would appear and behave as if it were a direct sitelink. So it is necessary that the sitelink is really common to both item pages of the item. The easiest way to do this is to merge these pairs of item pages. All other solutions would be just a replacement, unnecessarily complicated and not fully functional. --ŠJů (talk) 22:44, 11 July 2020 (UTC)[reply]
@ŠJů: I broadly agree with you. I generally think that there are three types of items here - I tend to talk about "topic" items, "category" items, and "list" items. I tried to explain that at User:Mike Peel/Commons linking (I should have linked to that above). It would be great if items did allow multiple sitelinks to the same wiki, and then they could be merged, but I understand that it was a deliberate design decision when Wikidata was started. It is easily possible to use Lua to cross between items using topic's main category (P910)/category's main topic (P301)/list related to category (P1753)/Template:P3754 - but it would be really nice if that could somehow be built into MediaWiki/Wikibase. Perhaps you could open a phabricator ticket for that? I don't agree that it should be a prerequisite to removing P373, though, since there is a workaround, and it's not that hard to implement. We could get into whether it's less or more functional than P373 if you want - I'd argue that the sitelinks give the 'right' answer more often now. Thanks. Mike Peel (talk) 20:09, 13 July 2020 (UTC)[reply]
  • The approach I see here is problematic. This property is one of the most used properties, not just on Wikidata but in the entire Wikimedia ecosphere. Then I read here that only to less than 0,000001 % of the people involved is asked for input, while it effects almost every single community and Wikimedia wiki. With asking for examples, it is like it is talked about a property that is used only on a 1000 items. This is underestimating the problem and a clear sign that the problems addressed by various users is not taken really seriously. What is needed is a structural in depth inventory how any decision regarding the deprecation of this property will effect the entire ecosphere (and beyond?). Asking for "examples" to a selected group is a way to stimulate the bias to grow that there is no serious problem and all the opposal can be waved away. Also focussing on "examples" would cause to miss the structural problems that are shown by examples that just form the top of the iceberg. Romaine (talk) 08:20, 12 July 2020 (UTC)[reply]
@Romaine: This is the standard venue for the discussion of properties for deletion, I'm not sure there's a better place elsewhere. I'm happy for more people to be pointed to this discussion, although on enwp that might count as 'canvassing'. I'm well aware of how widely the property is used - in terms of numbers, I'm to blame for the infobox on Commons that displays Wikidata information in over 3 million categories, and the work to add more Commons category sitelinks for that has indirectly doubled the number of P373 values (compare 1.4 million in 2017 to 2.9 million now). I've also mostly deprecated the use of P373 on enwp, and made a lot of automated edits to P373 along with the sitelinks via pi bot. If there is a structural issue that has not been covered here, then I'm missing it, and that's why I asked for examples of 'data/other software issues'. If you want an inventory that is more extensive than my personal experience from the last few years, how can we go about doing that? Thanks. Mike Peel (talk) 20:29, 13 July 2020 (UTC)[reply]
  • For the most part I’ve stopped using this property, and i have no objection to deleting it. - PKM (talk) 23:15, 11 July 2020 (UTC)[reply]
  • @Mike Peel: P373 and other properties are considerably used in vCard and Marker templates at the German Wikivoyage to present additional resources from other Wikimedia wikis -- including the Commons category -- among other information for different locations and institutions. The count of these template calls exceeds sometimes 250 times per article as can be learned from articles like Halle (Saale). There are some heavy restrictions to use Wikidata for this aim. We are calling (or trying to call) only one Wikidata entity per template call because the number of Lua Wikidata entity calls per article is limited to 400. That's why a lot of tables, for instance for P31, country, language, feature and currency data, are prepared to prevent using Wikidata. The other restriction is the computing time which is restricted to 10 seconds. Getting Wikidata entities is expensive. To get an imagination: The Lua computing time for the article mentioned takes about 1.5 seconds only for getting the entities (about 5 seconds in total for more than 250 templates). If we would get all data from Wikidata it would take about one minute and more. For comparison, usually one call of a Wikidata infobox at Commons takes three seconds.
Commons links cannot be prepared in advance. We have only three ways to get the Commons categories: (1) from P373, (2) from sitelinks, and (3) from P910. The third way is time consuming/expensive (Lua computing time increase of about 30 per cent) and reduces the count of template calls by half and is therefore not applicable -- because of calling additional entities. Way 2 is only sometimes applicable if the Commons sitelink contains a category and not an article link. Unfortunately nobody thought of a separation of main space and category namespaces. This way is alternativly used in our templates. The first way is the only one which gives direct access to the Commons category.
The next cause is why we should have two Wikidata items for one thing. There are about 100 millions Wikidata entries but only 5 millions English Wikipedia articles. For many items like hotels, restaurants, and so on there will be never a Wikipedia article but two Wikidata entries: one for the institution itself and a redundant one for its category because there are images at Commons.
I am in direct contact with the programmers of the Wikibase API. But it seems the a further (drastic) computing time reduction is impossible.
I assume that many voters for deletion never thought of the (comprehensive) usage of Wikidata data in articles. --RolandUnger (talk) 06:53, 12 July 2020 (UTC)[reply]
@RolandUnger: Performance is an issue, I think this links in with the sparql query issue above too. I think de-voy is an extreme example of Wikidata use, but we have seen similar things with the Commons Wikidata Infobox recently too for complex items. I'm not sure it takes that much more resource to check the commons sitelink (which you're probably loading anyway), and if it's not to a category, then look up P910 and find the commonscat from there (you wouldn't need to check P373 any more). This wouldn't need to always be done, since the commons category is often with the topic item unless a commons gallery or other project category items exists (which links to your 'two items for one thing' point - normally there only needs to be one topic item that links to the commons category). I suspect the best solution in this case is to increase the allowed number of Wikidata entity calls and computing time for de-voy, if the performance really can't be improved further on the server side. I generally think the human cost of keeping P373 updated/in sync with the sitelinks outweighs the extra server time. Thanks. Mike Peel (talk) 19:50, 13 July 2020 (UTC)[reply]
Since Wikidata is more granular than Commons it is inevidable that there will be cases where multiple Wikidata objects are related to one Commons category.
/ℇsquilo 08:24, 12 July 2020 (UTC)[reply]
@Esquilo: I think in those cases, it makes sense to have separate commons categories, if there are enough photos. For the first set, see e.g., commons:Category:Yorkshire Dales vs. commons:Category:Yorkshire Dales National Park. For the second set, if they only have one photo, then it probably just needs a image (P18) value, but if there are multiple then why not have a commons category? I know aircraft photos in particular tend to be very tightly categorised by model on Commons, for example see commons:Category:de Havilland aircraft. Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)[reply]
  • Generally, I don't oppose getting rid of this property (due to redundancy) if all concerns are claimed resolved or negligible. There are just matters which simply need to be considered with regards to the users of data (cf. the point I made about the sidebar). For the infoboxes and templates issue, each wiki has different attitude, though. For instance, cswiki uses w:cs:Modul:CommonsLink which is used in templates to fetch "commonscat" (or gallery) instead querying P373 or the sitelinks directly (the module decides where to look). Such design principle (cf. w:Separation of concerns) only requires changing one thing when Wikidata decides to change. --Matěj Suchánek (talk) 11:32, 12 July 2020 (UTC)[reply]
@Matěj Suchánek: It looks like cswiki uses a similar approach to enwp/commons, that's good. Can you help convert other modules on cswiki and similar language wikis? Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)[reply]
When necessary, I can weigh in. But naturally this change would demand prior communication. --Matěj Suchánek (talk) 09:20, 15 July 2020 (UTC)[reply]
  • P373 is redundant, but there is a clear use case (give me a Commons category of the topic). Note that even the list at Property_talk:P373#Documentation of 100+ wikis and 1000+ templates is incomplete, usage is higher. Algorithmic P910-sitelink/sitelink way (caused by bad prior galleries sitelinking decision) is complicated and resource-intensive, while using P373 is simple.--Jklamo (talk) 12:37, 12 July 2020 (UTC)[reply]
@Jklamo: Agreed it's simpler, and agreed it's redundant. Disagreed that it's complicated to check through P910 and sitelink - this is routinely done by en:Template:Commons_category and the one pointed out just above this. There are many uses, but those will only increase while this shortcut is still active, deprecating it would lead to a reduction of them. Thanks. Mike Peel (talk) 19:21, 13 July 2020 (UTC)[reply]
  • @Mike Peel: There are some issues which complicates using only commonscatlink:
    • I recently tried to make some tables by listeriabot and P373 is much easier for getting than commonscatlink. So there should be some way for obtaining this link in one step like property.
    • And second problem is 1:1 - is almost impossible to have link to commons in all items where is now P373 only with sitelinks and P910 (and similar).
      • e.g in wikipedia is one article for museum (school, company...), but in Wikidata there are usually two items - institution and building. Article on Wikipedia is more often about institution, but in commons there are images for building.
      • Similar case is municipality which consists from more villages, but one of them have same name as municipality. Is some wikis there are two articles, in some one article, but usually both with the same commonscat.
      • Next case - protected area/another protected area/hill(pond, forest) with same name both located in same place but not necessary with same area.
      • Another cases - street, which is located on two different municipalities, village, which is divided in two municipalities... usually both have same commonscat
    • So there is not only topic's main category (P910), but also category related to list (P1754), said to be the same as (P460), coextensive with (P3403), partially coincident with (P1382), uses (P2283), occupant (P466) and probably some others for searching correct commonscat withou P373. JAn Dudík (talk) 06:01, 14 July 2020 (UTC)[reply]
      @JAn Dudík: In turn, (1) This is the sparql issue. It is possible to access the sitelinks (there was some example code to do this above), but it is more complex. (2a) Ideally in those cases we would have media for both the institution and the building - e.g., pictures of the people that work there, historical documents, etc. That's fine on Commons, and they may also have separate Wikipedia articles If they aren't notable enough to have such media/coverage, perhaps we shouldn't have separate items for them here at the moment. (2b) I think these need separate commons categories, one for the municipality and one for the village, otherwise we should probably default to linking them only from the municipality unless we're sure that the images are also only of the village (in which case having them in a separate category helps others realise that too). (2c) This is tricky, perhaps it can be solved via topic's main category (P910) as per the question below. (2d) If it's a single street, shouldn't it have a single item? BTW, in general we have the same problem with linking to Wikipedia articles in these cases, but Wikidata doesn't have a separate string property to do that. Thanks. Mike Peel (talk) 19:19, 15 July 2020 (UTC)[reply]
      Example of street which is divided into two municipalities Plavská (Q43535204) and Plavská (Q44761879). One part of this street is in city, second on the borders (every side of street is another municipality) and third in village. I know about situation that all street Hraniční (Q46214250) is in one municipality and the second Hraniční (Q46146535) have only houses with address in that street. But this virtual street have its own ID in street register, so merging is not the best solution.
      Problem with institution/building is primary Wikipedia problem, often tehre is one article about both. And often there are only photos of building, but article is about institution.
      There is also problem with topic's main category (Property:P910) which have property constraint (P2302)=distinct-values constraint (Q21502410). 20:16, 16 July 2020 (UTC)
      @JAn Dudík: Are the streets physically connected, or separate? Personally I still think the best option is to merge them, if separate commons categories aren't appropriate, I don't think there's a problem with having multiple Czech street ID (P4533) values. Similarly, I think multiple topic's main category (P910) values are OK in exceptions like we're discussing here (and better than having P373), but generally there should only be one P910 value, so the constraint mostly makes sense. Thanks. Mike Peel (talk) 15:30, 18 July 2020 (UTC)[reply]
  • Pictogram voting comment.svg Comment @Mike Peel: Although I don't vote keep, neither vote delete here, I'm doubting that how to resolve things where duplicated Commons category (P373) values are really required for two and more items, as a pair of example: Transnistria (Q907112) , Transnistria (Q3537754) and Administrative-Territorial Units of the Left Bank of the Dniester (Q648767), currently all 3 items are pointing P373 to c:Category:Transnistria. --Liuxinyu970226 (talk) 11:56, 14 July 2020 (UTC)[reply]
    @Liuxinyu970226: This one is complex, good example. The best way I think this can be solved is through topic's main category (P910). The first two already used that to link to Category:Transnistria (Q8414718), I've done the same for the other and the inverse now. Does that make sense? I don't completely like this solution, but I think it's better than P373. Thanks. Mike Peel (talk) 19:19, 15 July 2020 (UTC)[reply]
  • @Mike Peel: Instead of thinking outside the box, how about we throw the box out of the window?
Alexis Jazz (talk or ping me) 02:40, 21 July 2020 (UTC)[reply]
That would indeed make things more uniformly awful and unusable - it would no longer be a Commons-specific problem, *everyone* would have problems... Thanks. Mike Peel (talk) 08:10, 21 July 2020 (UTC)[reply]
@Mike Peel: I see absolutely no reason why sitelinks can't be properties. If needed they could be presented to the user the same way sitelinks are currently presented, while internally working as a property. — Alexis Jazz (talk or ping me) 15:34, 21 July 2020 (UTC)[reply]
@Alexis Jazz: Oh, you were serious? The problem is that properties are one-way - you can go from the Wikidata item to the linked page, but there's then no way to go backwards from that page to Wikidata. That's what sitelinks enable. Even if you could somehow recode properties to have those backlinks, how would you then handle cases where there are multiple backlinks to different Wikidata items? I just don't think what you're suggesting is possible. Thanks. Mike Peel (talk) 16:24, 21 July 2020 (UTC)[reply]
@Mike Peel: How about redirects? Create a new namespace and have, for example, Sitelink:enwiki/Paris–Rouen (motor race) with "#REDIRECT[[Q1089270]]" as its contents. When a user adds a link to an item for that same page with a higher priority than the existing link, replace it. So one item could have the "Article on Wikipedia" property using high priority to become the sitelink while other items could have the same page in the "Article on Wikipedia" link with a lower priority. As an example, w:fr:Les Schtroumpfs (an article that describes both the Smurfs as a franchise as well as the comic book series) can be on Q11221 (the franchise) with high priority so mw.wikibase.getEntityIdForCurrentPage will return that when requesting the ID for that page. But it can also be added to Q4537599 (the comic book series) with normal priority. This wouldn't change the interwiki on frwiki, but now on w:en:The Smurfs (comics) there will be a usable interwiki link to frwiki, where currently there is none! This would also allow adding multiple article links from the same wiki to a single item. You could actually add a Commons category with high priority and the Commons gallery with a lower priority. Dream big. Face-wink.svgAlexis Jazz (talk or ping me) 00:46, 22 July 2020 (UTC)[reply]
@Alexis Jazz: It sounds like an overcomplicated solution. In particular, I really want to avoid manual QIDs being copied everywhere, as they are a nightmare to manage - much better to use sitelinks that auto-update, or keep the QIDs in structured data where bots can easily update them. What really annoys me here is that we *already* have a system that works well - just use sitelinks and topic's main category (P910)/category's main topic (P301) - everything beyond that, including Commons category (P373), just complicates things unnecessarily. Thanks. Mike Peel (talk) 18:49, 24 July 2020 (UTC)[reply]
@Mike Peel: My suggestion does not require manually copying QIDs. The sitelinks work, but not well: there are many cases where we want to add more pages to one item or one page to multiple items. — Alexis Jazz (talk or ping me) 19:04, 24 July 2020 (UTC)[reply]
  • I would love to just mark P373 as (DEPRECATED), but take much more times before the actual deletion, anyone oppose me? --Liuxinyu970226 (talk) 11:31, 25 July 2020 (UTC)[reply]
  • @Liuxinyu970226: one month and half later, no comment. Go ahead :) Pamputt (talk) 06:58, 12 September 2020 (UTC)[reply]
  • That's wrong. See comment in the section above.--Ksc~ruwiki (talk) 19:50, 13 September 2020 (UTC)[reply]
@Ksc~ruwiki: Per which above? --Liuxinyu970226 (talk) 22:30, 1 October 2020 (UTC)[reply]
All after 12 September 2020. --Ksc~ruwiki (talk) 18:31, 2 October 2020 (UTC)[reply]
Sorry, since 25 July 2020. --Ksc~ruwiki (talk) 20:48, 3 October 2020 (UTC)[reply]
  • @Liuxinyu970226: I would love to see that happen. I estimate that it would take 6-18 months after deprecation before the property was ready for deletion - while a bot can do most of the work (where P373 matches the sitelink) it will depend on how many cases need manual attention. Thanks. Mike Peel (talk) 18:41, 26 September 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete per Mike Peel. NMaia (talk) 10:23, 17 September 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep as long we don't have any better way to link commons, it should do. --opensofias (talk) 11:36, 21 September 2020 (UTC)[reply]
    @Opensofias: But we *do* have a better way to link to Commons, we have the sitelinks, and all of their auto-update and two-directional access goodness. We don't need this temporary non-updating and one-directional property any more. Thanks. Mike Peel (talk) 18:38, 26 September 2020 (UTC)[reply]
    @Mike Peel: if gallery pages were retired and those sitelinks would all go to categories, or there would be a seperate kind of sitelink specifically for categories, then that would make the property obsolete (as far as i'm concerned, anyway). tho burying all of Commons under "other sites" would still be kinda suck, i'd prefer if it were it's own kind of sitelink (along with Wikipedia, etc) --opensofias (talk) 22:04, 27 September 2020 (UTC)[reply]
    @Opensofias: I think Commons galleries are a distraction here - even if they were gone, then we still have both articles and categories on the Wikipedias to handle. That's why the setup of having the Commons category link on the category item if it exists, or on the topic item if it doesn't, works quite well. Code can follow the category's main topic (P301)/topic's main category (P910) links to find the appropriate Commons link. Where there are galleries, we can just create category items to work around them. Agreed that it would be better if the sitelink wasn't under 'other sites'! Thanks. Mike Peel (talk) 17:43, 29 September 2020 (UTC)[reply]
    New vkers @Ferdi2005, ImprovedWikiImprovment:, no comments to this better way? Why don't you consider changing your votes? --Liuxinyu970226 (talk) 02:48, 27 September 2020 (UTC)[reply]
    I'm not satisfied that issues will be fixed, as stated above. Please do not ping me here asking me to change my vote, just because you do not agree with it. You have already opposed a no consensus close and now you are trying to encourage the keep voters to change to delete. I don't feel I have anything to add here (my views very much mirror those of ŠJů above), which is why I had not commented. My position is keep. You can ping me with questions, but pinging me saying "why don't you consider changing your votes" is not good in my opinion. Maybe I'm misreading you somewhat here. --IWI (talk) 03:10, 27 September 2020 (UTC)[reply]
    @ImprovedWikiImprovment: I think your concerns are really bugs to fix by developers, rather than something we must "keep" something, that's why I would support phab:T54971 solution than keep this property, since this is really not only a Commons bug, but also a Northern Min bug, a Hakka bug, a Ladino (aka Judaeo-Spanish) bug, ... and even, a Wikidata bug. --Liuxinyu970226 (talk) 21:26, 27 September 2020 (UTC)[reply]
    And, about the small wikis, please can someone why says "keep P373 because small wikis will lost their values" watch up the m:Small wiki audit? Small wikis can be problemic even by keeping this property. --Liuxinyu970226 (talk) 21:41, 27 September 2020 (UTC)[reply]
  • All of the issues discussed in the last months were either answered by Mike Peel, or they are concerns about the transition process from P373 to sitelinks. However, it was explained many times already that the property will NOT be deleted on the spot - on the contrary, it will be DEPRECATED and only deleted *after* all the transition issues are addressed. Everyone please keep this in mind. And if we fail to address some of the issues, we can always de-deprecate it. I'd suggest closing this proposal as there are no new arguments. All has been discussed and explained a hundred times. Vojtěch Dostál (talk) 14:42, 5 November 2020 (UTC)[reply]
  • Symbol keep vote.svg Very strong keep unless there is a suitable solution for the Wikidata Infobox within taxa categories in Wikimedia Commons. Currently, the navigation links available in the infobox for the parent taxa are provided by this property, why we used this property? because a lot of sitelinks for taxa lead to galleries and not categories. Indeed if you manage to come to c:Category:Lepidoptera when you are in c:Category:Idea leuconoe and that you click on "Lepidoptera" within the infobox, its thanks to P373, because the sitelink in Lepidoptera (Q28319) a gallery page. Christian Ferrer (talk) 14:00, 24 December 2020 (UTC)[reply]
    @Christian Ferrer: See commons:Template_talk:Wikidata_Infobox#P373. This was something I was planning on tackling after deprecation of P373, but it can just as easily be sorted out now. Thanks. Mike Peel (talk) 19:59, 25 December 2020 (UTC)[reply]
Ah ok, thanks, I have no specific reason to oppose if my concern can be fixed. Good holidays! Christian Ferrer (talk) 20:11, 25 December 2020 (UTC)[reply]

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

Part 3[edit]

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

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

IPA number order (P3917)[edit]

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

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

@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)[reply]
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)[reply]
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)[reply]
  • Symbol delete vote.svg Delete a number is not a quantity, store information in a new property with the correct datatype: external identifier. Michael FV (talk) 03:42, 9 January 2020 (UTC)[reply]
Symbol keep vote.svg Keep Used by some MediaWiki extensions, Please consult before deletions. -- 02:45, 9 May 2020 (UTC)[reply]
@Krenair: ^^ Is this really? ^^ --Liuxinyu970226 (talk) 23:45, 9 May 2020 (UTC)[reply]
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)[reply]
Symbol delete vote.svg Delete Agree with migration to P528. --SilentSpike (talk) 21:41, 15 June 2020 (UTC)[reply]

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)[reply]

Pictogram voting comment.svg Comment Who will move current uses to a new ontology ?. I think we cannot delete until there are no uses of it.Amadalvarez (talk) 09:14, 15 November 2019 (UTC)[reply]
@Amadalvarez: Just merge em back to P17, see RFC for details. --Liuxinyu970226 (talk) 22:59, 16 November 2019 (UTC)[reply]
  • Symbol keep vote.svg Keep not only a country can claim territory. Michael FV (talk) 03:51, 9 January 2020 (UTC)[reply]
    @Michael FV: Please read that RFC carefully before such voting keep, thx. --Liuxinyu970226 (talk) 00:31, 10 January 2020 (UTC)[reply]
  • 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)[reply]
  • Symbol keep vote.svg Keep given the points mentioned in the rfc --- Jura 11:02, 20 January 2020 (UTC)[reply]

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

  • Symbol delete vote.svg Delete Given that this is spammly used to make so-called claim e.g. wrongly says that "Shenzhen is a part of Hong Kong". -- 22:32, 20 January 2020 (UTC)[reply]
Symbol delete vote.svg Delete Replacement available. -- 22:09, 9 May 2020 (UTC)[reply]
  • Pictogram voting comment.svg Comment I repeat my concern that the current information should be move to new ontology before delete. Liuxinyu970226 told me that "I follow RFC", but I'm user of this information in WD powered infoboxes. I'll take care handling new structure in infoboxes code, but not migrating data, because IMHO it should be move in a batch process when the change were full approved. Thanks, Amadalvarez (talk) 16:57, 21 May 2020 (UTC)[reply]
  • 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)[reply]
Pictogram voting comment.svg Comment Could you give an example of new modelling for instance in the very famous Taiwan (Q865) and People's Republic of China (Q148) ? I'm interested as I'm having a topic here Bouzinac💬✒️💛 20:49, 13 September 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep The idea is to replace the property by 4 others ones ; The properties "recognition" (qualifier only), "recognized by", and "not recognized by" and "de jure"/"de facto" properties. It should result in very long lists of countries in the infobox (among 200 countries, who recognises, who does'nt ?), et complicate the problem. --Pa2chant.bis (talk) 07:19, 15 September 2021 (UTC)[reply]
    I'm totally confused by your propose of re-using it, repeating will only waste RAMs of Wikimedia servers, aren't they?
    If you think we need better way, to not delete P1336 and, in your opinion, to re-classify the disputed territories, write them on that link RFC, otherwise as someone anonymous said above, Replacement available. Liuxinyu970226 (talk) 07:56, 1 November 2021 (UTC)[reply]

Deutsche Bahn station category (P5105)[edit]

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

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

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

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

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

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

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

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

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

Argentinian Historic Heritage ID (P4587)[edit]

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

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

Keep and mark as historic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:06, 10 December 2019 (UTC)[reply]
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)[reply]
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)[reply]
Symbol delete vote.svg Delete Since no archives available for em. --Liuxinyu970226 (talk) 03:42, 8 January 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep shutdown of other site is no reason for deletion of information from own site. Michael FV (talk) 04:12, 9 January 2020 (UTC)[reply]
    @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)[reply]
  • It's hardly used, otherwise I'd keep it. --- Jura 10:59, 20 January 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Neither archives nor replacements available. -- 23:25, 20 January 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep. How can we be sure the data isn't available somewhere (there are archives other than and this wouldn't be eventually useful? Just add a notice that it's historical. BrokenSegue (talk) 05:59, 21 May 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep, as some of the links from are still accessible through the Wayback machine. See e.g.Teatro Colón (Q827401). --DavidJRasp (talk) 17:40, 9 August 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep Keep and mark as historic. --Sezgin İbiş (talk) 22:06, 6 September 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete per the above. NMaia (talk) 02:31, 14 October 2020 (UTC)[reply]

Familypedia person ID (P4193)[edit]

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

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

Symbol delete vote.svg Delete Just once parameters migrations are done. --Liuxinyu970226 (talk) 11:22, 24 March 2020 (UTC)[reply]
Symbol delete vote.svg Delete Per nomination. The Property is very redundant. Current uses should be migrated. –MJLTauk 07:56, 16 November 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep per above. --- Jura 08:22, 22 September 2021 (UTC)[reply]

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)[reply]

  • Symbol delete vote.svg Delete on this and the others - but you should probably not remove id's until there's a consensus reached here. ArthurPSmith (talk) 18:09, 2 April 2020 (UTC)[reply]
  • A little Symbol keep vote.svg Keep, please confirm that if there's online archives (e.g. from for or not. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)[reply]
    @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)[reply]
    @Liuxinyu970226, Pelmeen10: A ping without a new ~~~~ is not a ping. —Eihel (talk) 17:17, 3 April 2020 (UTC)[reply]
    Symbol delete vote.svg Delete By my recent searching of, there's indeed no archives of those URLs. --Liuxinyu970226 (talk) 12:14, 22 April 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep 72000 uses. --- Jura 08:09, 10 April 2020 (UTC)[reply]
    • @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)[reply]
  • Symbol delete vote.svg Delete, after ensuring that all entities with the Scoresway property have the equivalent Soccerway property and any templates using Scoresway are updated to use Soccerway. Both websites were/are owned by Perform Group and displayed the same data. The main difference was that Scoresway used a common formatter URL for players, managers, and referees ($1) while Soccerway uses different URLs ($1/,$1/,$1/). The old Scoresway player URLs such as now redirect to the main page (not the player page). On a related note, it might make sense to add new properties for Soccerway coach/manager ID and Soccerway referee ID, similar to how Soccerbase has Soccerbase player ID (P2193), Soccerbase manager ID (P2195), and Soccerbase referee ID (P7465). -- Zyxw (talk) 08:10, 12 April 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete Germartin1 (talk) 09:09, 3 May 2020 (UTC)[reply]
  • Symbol keep vote.svg Keep The benefit is in being able to resolve the identifier, not just the linked content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 25 May 2020 (UTC)[reply]
    @Pigsonthewing: It's already confirmed unable to resolve this identifier. --Liuxinyu970226 (talk) 12:59, 2 June 2020 (UTC)[reply]
    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)[reply]
  • One of the properties should be deleted, however the text portion of Soccerway IDs are meaningless and not necessary (as shown by the current URL for Scoresway soccer person ID (P3043)). Therefore, I believe any items with Soccerway player ID (P2369) but not Scoresway soccer person ID (P3043) should have the ID transferred over, and then Soccerway player ID (P2369) should be deleted. This would make Soccerway IDs far easier to work with (for example in queries), as sometimes the text portion of Soccerway IDs are trimmed or malformed when imported to Soccerway player ID (P2369). S.A. Julio (talk) 17:37, 27 October 2020 (UTC)[reply]

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)[reply]

  • A little Symbol keep vote.svg Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)[reply]
    • @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)[reply]
  • Pictogram voting comment.svg Comment hardly used. --- Jura 08:10, 10 April 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete No archive, 15 uses only.--Jklamo (talk) 14:26, 6 September 2020 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

Joconde IDs[edit]

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

Symbol delete vote.svg Delete That's fine with me. But you should maybe propose a new property for this first, or pick one of them to be the main one? ArthurPSmith (talk) 17:32, 6 April 2020 (UTC)[reply]
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)[reply]
Symbol keep vote.svg Keep Those properties link to different and specific vocabularies. For reuse, we need this differentiation. For example on Nicolas Poussin (Q41554) with the value of Joconde author ID (P7711) we can make a link trough the structured data on to make enable a specific search to the POP results on Jocond Artist field. --Shonagon (talk) 11:39, 7 April 2020 (UTC)[reply]
Symbol keep vote.svg Keep If we merge the Joconde properties it may lead to confusion between similar terms used in different vocabularies and lose their original meaning. For example Domaine : Afrique du Nord and Lieux : Afrique du Nord --Christelle Molinié (talk) 16:06, 7 April 2020 (UTC)[reply]
As Joconde is a French website:

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

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

@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)[reply]

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)[reply]
Symbol keep vote.svg Keep Okay, per Vladimir Alexiev, I don't think that deprecating it is good for us. --Liuxinyu970226 (talk) 22:41, 3 June 2020 (UTC)[reply]

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

You cannot currently add it because "Thésaurus-matières pour l'indexation des archives locales" is not made into a WD property. Given that we now have many people involved in this effort on WD, i think we should leave it up to them to decide which thesauri are worth exposing on WD. --Vladimir Alexiev (talk) 11:38, 24 November 2021 (UTC)[reply]

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)[reply]

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)[reply]
@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)[reply]
  • The problem appears to be fixed now. --RAN (talk) 05:04, 9 May 2020 (UTC)[reply] had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 10:43, 17 May 2020 (UTC)[reply]
  • Symbol delete vote.svg Delete: sounds sensible. Nomen ad hoc (talk) 18:06, 10 May 2020 (UTC).[reply]
  • Symbol keep vote.svg Keep: decent coverage (100%?), seems to be stable (since 4 years), used by other WMF sites, and the other id redirects there too. --- Jura 20:45, 13 May 2020 (UTC)[reply]
Pictogram voting comment.svg Comment I guess every third Nobelprize link has en:Link rot in en:Wikipedia and Nobel prize ID (P3188) has been impossible to maintain as it has changed more times when has done a new webdesign. Now takes responsibility for maintain this and we just need to store the unique number in Wikidata - Salgo60 (talk) 10:51, 17 May 2020 (UTC)[reply]
We already do store it. There is no need to delete historic information. This is not Wikipedia. --- Jura 11:20, 17 May 2020 (UTC)[reply]
Pictogram voting comment.svg Comment@Jura:please explain. The IT people at also see the chaos with linking the old web and agree of this new approach
- Salgo60 (talk) 01:07, 18 May 2020 (UTC)[reply]
  • 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)[reply]
@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)[reply]
@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)[reply]

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

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)[reply]

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

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).[reply]
  • 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)[reply]
    Because the translation of the official term “adversariorum partes suscipient” suggests opponent. ;) Best, DerHexer (talk) 18:52, 10 May 2020 (UTC)[reply]
    The proposal mentioned no such term. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:52, 10 May 2020 (UTC)[reply]

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)[reply]