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.

Edit

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.


Requests[edit]

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


Property:P1549[edit]

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

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

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

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

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

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

Property:P185[edit]

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

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

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

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

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

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

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


Translation issues?![edit]

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

lang P184 P185 P802 P1066
af Doktorale student Doktorale adviseur student student van
aln student i doktoraturës N/A N/A N/A
ar طلاب الدكتوراه مشرف الدكتوراه طلاب تتلمذ على يد
تتلمذ على يد, تعلم لدى, تتلمذ على, تتلمذت على يد
ast N/A direutor de tesis
direutora de tesis
estudiante
discípulu, discípula, alumnu, alumna, maestru de, maestra de, profesor de, profesora de
N/A
az N/A elmi rəhbəri tələbəsi
tələbə, tələbələr, tələbələri
müəllimi
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
estudiant
alumne, mestre de, deixeble
mestre
alumne/a de, professor
cs doktorand vedoucí disertační práce
vedoucí práce, učitel
student
učitelem (koho), učitelkou (koho), studenti
učitel
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
Promotionsbetreuer
Doktorvater, Gutachter, Doktormutter
Schüler
Student
Schüler von
Lehrer
el διδακτορικός φοιτητής διδακτορικός σύμβουλος 内容单元格 内容单元格
en doctoral student
supervise
doctoral advisor
advisor, doctoral supervisor, supervisor, PhD advisor, promotor
student
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ípulo
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
irakasle
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
élève
é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
N/A
hu doktorandusz témavezető tanítvány
diákjai, diák
tanár
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
studente
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
Doktorand
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
Doktermamm
Schüler Schüler vu(n)
lfn N/A N/A studiante N/A
lt N/A N/A studentas yra mokinys
mokytojas
lv N/A N/A studenti
skolēni
N/A
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
N/A
nb doktorgradsstudent doktorgradsveileder elev
student
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
student
uczeń
uczył się u
studiował u, uczyła się u, studiowała u
pt doutorando orientador de doutoramento estudante
aluno
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
studenți
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
N/A
sl doktorski študenti
doktoranti
doktorski mentor
doktorski profesor
študenti
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 ศิษย์
ลูกศิษย์, นักเรียน, นักศึกษา
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
mutsundzuxi
muchudeni
machudeni
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)

Property:P6886[edit]

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

This property is being used by:

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


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

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

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

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

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

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

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

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

Property:P802[edit]

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

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

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

Property:P2580[edit]

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

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

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

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

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

Property:P373[edit]

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

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

@Nomen ad hoc: Please read archives listed in its talk page carefully: 1, 2, 3, 4 (if links can't work properly, use Ctrl+F type P373), this was PFDed for 4 times and their results were all keep. --Liuxinyu970226 (talk) 22:03, 8 September 2019 (UTC)
@Liuxinyu970226: The links 2 and 3 don't seem to work. The RedBurn (ϕ) 20:30, 2 May 2020 (UTC)
@Nomen ad hoc, Liuxinyu970226, The RedBurn: The links are : 1, 2, 3, 4. —Eihel (talk) 11:04, 30 May 2020 (UTC)
Unless if @GZWDer, Lavallen, Ivan A. Krestinin, Izno, Doostdar:@Jakec, Cycn, Esquilo, Multichill, Paperoastro:@GautierPoupeau, Tamawashi, Micru, ערן, Closeapple:@TomT0m, JAn Dudík, Pasleim, Jklamo, Hanay:@Rippitippi, Sannita, Jianhui67, ŠJů, Jmabel:@Discasto, Marsupium, Mike Peel, Kaldari, Ghouston:@Strakhov, Jheald, Jura1, Slowking4, DarwIn:@Jarekt, Deryck Chan, PKM, Derzno, Ksc~ruwiki:@Krenair, Amire80, Jon Harald Søby, Tgr, Tpt: those guys said something against their previous keep, I would love to non-admin close this discussion. --Liuxinyu970226 (talk) 04:05, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep - needed when the Commons site link is connected to a Gallery page. - PKM (talk) 05:03, 9 September 2019 (UTC)
    @PKM: In those cases, just create an item with instance of (P31)=Wikimedia category (Q4167836), and use topic's main category (P910)/category's main topic (P301) to link to the topic item, e.g. Category:Isaac Newton (Q7215722) vs. Isaac Newton (Q935). Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)
    @Mike Peel: you make a compelling case below. But I'd prefer that we standardize on linking to Commons categories not Galleries. - PKM (talk) 06:41, 9 September 2019 (UTC)
    @PKM: So would I! But others seem to disagree. Although, that wouldn't change things in the example I gave, since en:Category:Isaac Newton also uses the Commons sitelink via Category:Isaac Newton (Q7215722). Thanks. Mike Peel (talk) 06:46, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep The "other site"-link is a one-to-one mapping from Commons to a Wikidata object (and its interwiki links). Commons category (P373) is a many-to-many mapping to Commons. /ℇsquilo 06:04, 9 September 2019 (UTC)
    • @Esquilo: We may consider to break such glitch, see reasons at phab:T54971. --2409:8902:9021:3DF1:579C:FBA1:7BB1:D3E0 00:30, 21 September 2019 (UTC)
      • I consider that to be a bad thing. There are numberous cases when multiple Wikipedia articles uses images from the same Commons category. Wikidata structure should reflect this usage. /ℇsquilo 09:17, 21 September 2019 (UTC)
  • Symbol delete vote.svg Delete - or in the immediate future, deprecate until the remaining cases that don't match the sitelinks are resolved (while bot-removing matching cases to unearth the mismatches). This property served its purpose as a temporary work-around, but nowadays the Commons sitelinks are used, both to link to Wikidata from Commons (using commons:Template:Wikidata Infobox), and also to link from Wikipedias (using en:Template:Commonscat/en:Module:WikidataIB's getCommonsLink function). Keeping P373 around just adds to the maintenance burden, as it needs to be kept in sync with the sitelinks (the sitelinks automatically update when a category is moved/deleted, P373 has to be manually/bot-updated), and that's particularly difficult here since things like Wikidata:Database reports/Constraint violations/P373 are continuously broken/outdated. There is a lot of work still to do to get rid of this property - in particular, uses on various wikis need to be changed to use the sitelink instead - but I'm not sure that will start unless the property is clearly marked as deprecated/on its way out, in favour of the better solution of the sitelinks. Thanks. Mike Peel (talk) 06:08, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep Per previous threads. Apparently nothing changed. I may add keeping Commons gallery (P935) and deleting P373 while allowing gallery-sitelinks doesn't make much sense. Galleries should be deprecated as Commons sitelinks. strakhov (talk) 06:27, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep: P373 is still the least-bad kludge for dealing with Wikidata's original sin of insisting on 1:1 item correspondence between projects, despite being founded long after Commons. As Liuxinyu970226 mentioned, this is at least the 4th nomination to delete P373. Commons still has both mainspace (gallery) and category pages for topics, and the category pages are primary and have the most content; mainspace is utterly optional, and probably even less popular than it used to be. Though Wikidata has loosened the notability criteria and added links between main items and category items, there is still the question of how one deals with a Commons category being the primary page for a subject and sometimes a not-very-notable subject at that. How do we deal with Commons if P373 isn't on the main item? Problems no matter which way you try:
    1. The current sitelink standard is to put the Commons category on a Wikidata category item if there is one, and otherwise put the Commons category on the Wikidata main item. But if there's a Commons gallery (mainspace page), and Wikidata has no category item for that topic, then the Commons gallery gets the sitelink, and the Commons category gets no sitelink, because Wikidata is bound to 1:1 sitelink relationships, even though galleries aren't where most of the content is on Commons.
    2. One might propose that we simply create a Wikidata category item for every Commons category. But are Wikidata category items allowed for topics that have no main topic? I see that "one valid sitelink to a page on ... Wikimedia Commons" was added to Wikipedia:Notability, but I can't tell if that was by consensus; there seem to be more opposing that supporting the idea on Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). Commons categories don't have to be "notable" to exist. (Examples: Commons:Category:Slurry near St. David, Illinois in April 1973; Commons:Category:Images from the State Library of NSW album 7039; Commons:Category:2015-03-21 Morgan Park v. Lutheran Class 3A consolation basketball game; Commons:Category:LVIA F669 ap7 b86; Commons:Category:Random events in the USASMDC.) Wikidata now seems to allow very-low-notability articles — for example, on Wikinews and Wikisource — to qualify for Wikidata items. But on Commons, the category creation criteria is even lower. Only files have anything like a notability criterion: "realistically useful for an educational purpose" or legitimately "in use on another project"; a Commons category, despite usually being the main topic page on Commons, is created and retained simply on there being sufficient content to fill it. Commons doesn't allow blatant spam, but it doesn't prohibit sponsored content either. Does a company or product qualify for a Wikidata item just because someone uploaded enough files to Commons to get a category made? (By the way, even that thin criterion has been abused by some Wikidata evangelists/conquistadors, who have been invading Commons and creating new Commons categories with only one file, claiming that Commons rules don't prohibit it, then "coincidentally" linking the categories to existing Wikidata items to get credit from whoever's keeping track of Wikidata adoption metrics.)
    3. Even if every non-hidden Commons category now automatically qualifies for a Wikidata category item, there is still the process of creating each Wikidata item. It's been 5 years since I pointed out the burden of creating a category item on Wikipedia at Wikidata:Requests for deletions/Archive/2014/Properties/1#Commons category (P373) 2. (Granted, steps 5 and 6 aren't needed if there is no main topic.) Would we want a bot to create the Wikidata category items instead?
So, until we have all of that settled, and a working implementation for all of it, P373 should stay: It's the only method that allows both a gallery and a category link (which is more important) to Commons to exist simultaneously for a Wikidata main topic item that doesn't have a Wikidata category item. --Closeapple (talk) 07:44, 9 September 2019 (UTC)
  • @Closeapple: Notability is still something that's being argued about - basically the notability guideline doesn't match practice here any more. However, the cases that you talk about are a separate issue ('should all commons categories have Wikidata items?') - here we're talking about categories that are linked to from Wikidata/Wikipedia already, and those should already be notable enough to have items. Most items that have galleries linked to them already now have category items with the category sitelink where available, there aren't actually that many of them (Commons gallery (P935) is only used ~100k times). Note that we're coming up to the 2.5 million mark for commons:Category:Uses of Wikidata Infobox - and that's excluding taxons, which are around ~0.5 million, so the sitelinks are already in place for about half of Commons' categories now. Plus the Wikidata infobox on Commons makes it more valuable to go through the process you described before to create the sitelink - a P373 value just links one-way, which is kinda useless for Commons editors. Thanks. Mike Peel (talk) 08:07, 9 September 2019 (UTC)
  • Symbol delete vote.svg Delete If Mike thinks it's ready to go, lets get this started, even if it will take another five years to implement the deletion. Step 1: remove the property from category items. Step 2: remove the property from items linked to a category. Step 3: remove the property from items with the sitelink. Step 4: ... --- Jura 07:59, 9 September 2019 (UTC)
  •  Oppose for now. This property is widely used. Before deprecating there should be some tools which automatically uses commonscat from related item using P301/P971. JAn Dudík (talk) 10:49, 9 September 2019 (UTC)
    @JAn Dudík: Oppose deleting or oppose keeping? --Liuxinyu970226 (talk) 00:20, 4 December 2019 (UTC)
    I mean Symbol keep vote.svg Keep, but I agree with deprecation in future. JAn Dudík (talk) 08:56, 4 December 2019 (UTC)
  • Can we have a demonstration, by removing the P373 statements from some items with a lot of sitelinks, to verify that all the interwiki linking still works? If it does, I support removing the redundant property. Ghouston (talk) 10:57, 9 September 2019 (UTC)
    • @Ghouston, JAn Dudík: See the things I linked to in my post above, in particular there is a function in Module:WikidataIB ('getCommonsLink') that you can use to fetch the sitelinks via the linking properties. Also look at any Commons categories using the Wikidata Infobox to check the interwiki links. There are a lot of cases on other wikis that need to be changed to use this new code rather than accessing P373, though, which is why we need it to be deprecated first rather than just deleted immediately. Thanks. Mike Peel (talk) 11:56, 9 September 2019 (UTC)
      • @Mike Peel: I am afraid, that there will be many problems. 1) Because of inexistence of global modules there will be necessary to update all Wikidata bodules in all wikis. Then update of all templates which uses P373. 2) There are many users who uses P373, but are not familiar with commons sitelink. 3) there are many cases where 1:1 linking is not possible. 4-n) etc. There will be BIG impact to all wikis, so There must be at first good solutoin with good documentation in many languages. And After this all should be possible to deprecate P373. – The preceding unsigned comment was added by JAn Dudík (talk • contribs).
        • Deprecation to me implies that new statements using the property should not be added, the bots that maintain it should be stopped, and that it can be safely removed if desired. If the software isn't yet in place in all Wikis, then I don't think that step should be taken. Ghouston (talk) 00:18, 10 September 2019 (UTC)
  • Symbol delete vote.svg Delete per Mike Peel. This property is nothing but awful and highly problematic programming spaghetti, for the reasons exposed. the mere fact that it exists is a continuous source of trouble, as tool developers may use them as a source for the commons cat, wide-spreading and perpetuating the problem till unmanageable levels. The link article-category and reverse is generally made through SetSiteLink. My perception is that most of this evilness emanated from a primeval misconception that Wikipedia Articles corresponded with Commons Galleries (generally false, by default, since Galleries are mere exhibitors for Commons categories, and there could be like 100 of them for a given subject, none of which with special preponderance over the others) and that Wikipedia Categories had any importance to Commons, and should preferably relate to Commons Categories (generally false too, though sometimes it can be useful to connect them, such as in "churches in municipality X", the kind of thing that probably will never have an article in Wikipedia). In any case, this property doesn't seem to be needed at all.--DarwIn (talk) 11:06, 9 September 2019 (UTC)
    • Pictogram voting comment.svg Comment In case of removal, please check Listeria, as I seem to have noticed it uses this property to show the Commons Category in the lists (should be using SetSiteLink, otherwise it gets broken everytime someone moves a category in Commons).--DarwIn (talk) 11:08, 9 September 2019 (UTC)
  • Symbol neutral vote.svg Neutral I came to this discussion thinking to vote to keep it, but Mike Peel has a convincing argument. I can see in the future time when P373 can be retired and that would simplify our maintenance burden, and in general prevent the same info being stored in two places. I would also like to see some trimming of the number of unmaintained Commons galleries clogging the sitelinks, but that topic should be discussed on Commons. --Jarekt (talk) 11:59, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep and delete other sites link. in a larger sense, deletion is not a quality improvement process, rather provide the ontology, team and method to improve wikidata to commons links. Slowking4 ‽ (Rama's revenge) 12:45, 9 September 2019 (UTC)
    • @Slowking4: Can you elaborate, please? Without the sitelink, none of the interwiki links on Commons, nor the infobox, would work. It's akin to removing the interwiki links to the Wikipedias and replacing them with a property - you can then only see the link on Wikidata, not from the other wiki. Thanks. Mike Peel (talk) 13:18, 9 September 2019 (UTC)
      • i'm saying the site link is more opaque and inexact. it is a problematic analogy to wikipedia articles, which commons does not have. we need to develop the ontology and mapping of commons content. you could map the many infoboxes to creator and institution (and depicts). but a consensus and action plan is required , deletion should be salted as a perennial rejected proposal.-- Slowking4 ‽ (Rama's revenge) 13:32, 9 September 2019 (UTC)
  • Who cares - none of these hacks actually work well (e.g. [7]). We should either stop linking to Commons galleries (as they are an unmaintained wasteland) or push the Wikidata developers to implement a real way to add sitelinks to both File and Gallery pages at the same time. I can't understand why the Wikidata community want to waste countless hours dealing with these crappy hacks. Kaldari (talk) 15:10, 9 September 2019 (UTC)
  • One item should have one Wikidata item page, ie. the item page should link articles as well as categories of its item – as sitelinks, not as properties. That's the core of the problem. --ŠJů (talk) 15:57, 9 September 2019 (UTC)
  • Symbol keep vote.svg Keep read archives, not going to repeat myself. Multichill (talk) 16:57, 9 September 2019 (UTC)
    @Multichill: I've looked through the archives. At [8] you said "you would first need to change the notability policy before you can replace this template." - Wikidata:Notability has been changed to a certain extent, but further changes are still needed to match the policy with reality - which is a separate topic. You also mentioned phab:T49930, which has been resolved. In [9] you said "massive usage, not a good alternative" - sitelinks are that good alternative, as I've described above. I've also been working through the backlog of mismatches between enwp and wikidata sitelinks, where I've been finding many wrong P373 statements that have been imported from enwp and have been corrected in the sitelinks only, one example is this edit by your bot in 2009, which was imported to Wikidata in 2013, fixed via the sitelink on 2016, and I removed the P373 statement 2 days ago. Of course this is only one example, and of course I've cherry-picked it from my recent cleanup work since you were involved, but there do seem to be a lot of examples from a few years ago that are similar, which are being discovered by comparing the links with sitelinks. I hope that we can finally resolve this kind of issue by using the sitelinks, and if you are still opposed to that then I hope you can post the reasons here. Thanks. Mike Peel (talk) 20:12, 13 September 2019 (UTC)
    I don't think that changes to Wikidata:Notability can be ignored as a separate topic. The problem is that if you have an main Wikidata item which is sitelinked to a Commons gallery, and there's no existing category item, then there's nowhere to put a Commons sitelink. Wikidata:Notability forbids creating a new category item for Commons. Attempts have been made to change Wikidata:Notability but they have been unsuccessful. Ghouston (talk) 02:09, 14 September 2019 (UTC)
    I started another discussion at Wikidata talk:Notability about allowing certain category items for Commons. Ghouston (talk) 02:48, 14 September 2019 (UTC)
    I rather spend time on building things than on these destructive discussions. This deletion nomination is just negative energy. We're just wasting community time and energy here on something that hasn't been thought through properly. This discussion will just suck in more energy, come to a grinding halt at some point and some admin will close it as no consensus. What a waste. Multichill (talk) 19:09, 14 September 2019 (UTC)
  • Symbol keep vote.svg Keep. Nothing has changed nieither in Wikidata nor in Wikipedia nor in my opinions. We have namespaces: articles and categories. Now both items of categories (we apply for them "other sites") and articles (we apply for them Commons category (P373)) have connections with categories of Commons. Very often other sites are used in items of articles. But as soon as we make statement topic's main category (P910) in article item bot immediately moves commons category sitelink to category item. (See, for example, recent history of Vikulovsky District (Q1753812)). If Commons category (P373) wouldn't exist connection between article item and commons category would be lost. So Commons category (P373) is the only effective and visual way to keep connection of articles items and commons categories. Removing the property is just losing of such way. Property's benefit was discussed n project chat. And besides I can repeat myself: "In Russian Wikipedia we use Commons category (P373) in a great deal of temlates including crucial important ones. Removing the property right now just would break links to Commons in a huge number of articles and categories, spoiled their interface.". --Ksc~ruwiki (talk) 18:45, 9 September 2019 (UTC)
    @Ksc~ruwiki: In that example, topic's main category (P910) and Commons category (P373) appear next to each other - click on the topic's main category and you see the commons category. It is one step further away, which isn't good, but it's not that far away. In terms of P373 usage on ruwiki, could you look into using {{#invoke:WikidataIB|getCommonsLink|qid={{{qid|}}}|onlycat=True}} using commons:Module:WikidataIB instead? That will then use the sitelinks instead of P373, and is part of the transition during deprecation that I suggested above. Thanks. Mike Peel (talk) 06:19, 10 September 2019 (UTC)
    • if I call getCommonsLink without params and then pass "onlycat" will it return me gallery at first and category at second (both exist on commons)? Where does it get their names? --Igel B TyMaHe (talk) 07:31, 10 September 2019 (UTC)
      • @Igel B TyMaHe: If you don't set qid it will use the Wikidata item that the page is sitelinked to. It follows topic's main category (P910) or category related to list (P1754) to the connected Wikidata item if available. If you set "onlycat=False" or leave that parameter out then it will return the gallery if available, then the category if not - if you set "onlycat=True" then it will only return the category link. It currently falls back to P373 as a transition measure. (With thanks to @RexxS: for the code). Thanks. Mike Peel (talk) 07:46, 10 September 2019 (UTC)
        • It currently falls back to P373 as a transition measure — Certainly i'm asking how will it work without P373? (BTW P3722 (P3722) links to Commons the same way as P373 and "seems redundant with "Other sites" field. And we have no equivalents for other wikiprojects") --Igel B TyMaHe (talk) 08:20, 10 September 2019 (UTC)
          • @Igel B TyMaHe: In my experience on enwp, pretty well - although there are still cases to clean up there, see en:Category:Commons category Wikidata tracking categories (I was hoping to get a bit further with that cleanup there before nominating P373 for deletion, but here we are.). P3722 (P3722) is set up incorrectly and needs to be fixed, it should work like category for recipients of this award (P2517), which links to the category item here not directly to Commons. Thanks. Mike Peel (talk) 08:28, 10 September 2019 (UTC)
            • As I can see P373 will be replaced with [commons] link in "Other sites". But this one is for Commons gallery (P935). P935 should be deleted instead of P373, because P373 is link to the different item, P935 is to the same. [commons] link in "other sites" should be in Category item like in Category:G7 (Q17420469). P373 shoud link to item and through it to commons. This is nonsence to link in "Other sites" to something that is not directly belongs to the item. There shouldn't be linking to Walt Disney in Mickey Mouse in "Other sites" or vice versa. --Igel B TyMaHe (talk) 14:07, 10 September 2019 (UTC)
Symbol delete vote.svg Delete Per Mike Peel, I think some Dutchism discussions can be stopped, if the problem is one-per-one linking glitch, all the best thing we should and need to do is to break such a glitch, not use property to white-paint. --117.15.55.5 02:39, 10 September 2019 (UTC)
  • Symbol delete vote.svg Delete per Mike Peel or at least let's try to deprecate this property once and for all. It's about time that we fix this thing. Sannita - not just another it.wiki sysop 20:50, 10 September 2019 (UTC)
  • Symbol keep vote.svg Keep unless is Commons linking issue finally resolved (abandon commons galleries sitelinking - I am afraid it needs another lengthy RFC), then Symbol delete vote.svg Delete. --Jklamo (talk) 10:08, 11 September 2019 (UTC)
Whether or not this is eventually gotten rid of, please modify c:Module:Creator to stop using P373 if so desired. Also check for other templates or modules that still rely on it.--Roy17 (talk) 21:49, 12 September 2019 (UTC)
@Roy17: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)
Pictogram voting comment.svg Comment Voters should be aware that Commons category (P373) is currently used for sidebar ("In other projects") linking to Commons from Wikipedia articles. So deleting this property without a new technical solution will simply make the links disappear. --Matěj Suchánek (talk) 10:51, 14 September 2019 (UTC)
@Matěj Suchánek: That's a good point, that should be fixed during a deprecation stage before deletion. I've filed phab:T232927. Thanks. Mike Peel (talk) 18:17, 14 September 2019 (UTC)
A deprecation stage of a property means that it should not be added to items and should be removed there where possible. If that deprecation stage is present, the technical solutions to the sidebar (etc) ashould already have taken place. Again: first deprecation (= breaking) and then fixing is the wrong order. Romaine (talk) 07:53, 12 July 2020 (UTC)
  • Deprecate per Mike Peel. At Wikimania last month, Mike and I talked about this exact issue (P:P373 being a piece of necessary evil to deal with misalignment of category and topic items), and I'm persuaded that we should at least try to migrate towards a more elegant solution. Deryck Chan (talk) 16:35, 15 September 2019 (UTC)
  • Symbol keep vote.svg Keep Agree that the current situation is not the best, however I believe that 'other sites' is a ridiculous, kludgey solution that's even worse than this property. Gamaliel (talk) 20:19, 17 September 2019 (UTC)
  • Deprecate. I also agree with Mike Peel. --Tinker Bell 02:47, 20 September 2019 (UTC)
  • Pictogram voting question.svg Question If this property is deleted, who will update the Wikidata-linked Creator template which current uses P373 to populate the "homecat" parameter? - PKM (talk) 20:14, 20 September 2019 (UTC)
    @PKM: I've started a discussion/change request at commons:Module_talk:Creator#Using_sitelinks_rather_than_P373. Thanks. Mike Peel (talk) 10:43, 28 September 2019 (UTC)
  • Symbol keep vote.svg Keep Let's look at the practicalities. Suppose I have a large or large-ish set of items, and I want to identify which of them have Commons categories. With P373, I just need the following in my SPARQL query:
    ?item wdt:P373 ?commonscat
Without P373 I have to do something like the following:
    OPTIONAL {
      ?commonsCategoryFromItem schema:about ?item;
                               schema:isPartOf <https://commons.wikimedia.org/>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromItem), "https://commons.wikimedia.org/wiki/Category:"))
    }
    OPTIONAL {
      ?item wdt:P910 ?catItem .
      ?commonsCategoryFromCatItem schema:about ?catItem;
                                  schema:isPartOf <https://commons.wikimedia.org/>.
      FILTER(STRSTARTS(STR(?commonsCategoryFromCatItem), "https://commons.wikimedia.org/wiki/Category:"))
    }
    BIND(COALESCE(?commonsCategoryFromItem, ?commonsCategoryFromCatItem) AS ?commonsCategory)
Yes, it's possible (eg: https://w.wiki/8hM).
But (i) it's a hell of a lot to have to remember for quite a simple thing, especially for SPARQL newbies; and (ii) the code above is a real resource-hog and far more likely to time out, if one tries to apply it for groups of items of any size.
To start with there is the schema:about / schema:isPartOf join. This compares to P373 which is very specific. For each ?item the fragment above starts with in its solution set, P373 will typically identify only a single commonscat for each one, leading to a solution set going forward with about the same number of rows (or slightly smaller, as some items won't have commonscats). In contrast, schema:about connects the item to every article about it, in every Wikipedia. That may immediately expand the solution set by a factor of 20, before then a huge join with the set of all pages on Commons to reduce it down again; then a per-set-member string operation (a further notorious source of slowness) to filter out galleries etc and select just for categories; and then having to do the whole thing all over again, in case it's actually a parallel category-type item that is what is actually sitelinked to the Commons category. If the group of items is of any size (or if one's trying to do a COUNT query, such as how many churches have Commons categories), all this is slow-slow-slow-slow, so very likely to make the query time out without completing its execution.
I accept that maintaining all the P373 entries as a set of convenience statements is a pain. But it is something that bots can and do efficiently manage. The value of maintaining P373 is that it makes corresponding queries much easier to write, and makes a huge range of queries possible to successfully execute that would otherwise time out. I think that makes P373 worth keeping.
The other point is that currently almost all Wikipedias are using P373 to identify which Commons page should be linked to from the sidebar of an article page to give a category page rather than an article page; so, also, some modules on Commons. With P373 this is a very easy look-up. Yes, implementing the logic above is possible (I believe some Commons infoboxes may do it); but how big a job to implement this in the MediaWiki code?
So, for these two reasons, keep (and keep maintained). Jheald (talk) 21:27, 21 September 2019 (UTC)
Interestingly, actually running the numbers, the performance hit isn't quite as bad as I'd anticipated; but all the same it can be considerable. For quite a large dataset, I find the join using the sitelinks and additional P910 path is about six times slower than the join using P373 :
Count of the number of items in class church building (Q16970) https://w.wiki/8vi : 2.039 seconds. Count of corresponding commons categories using P373 https://w.wiki/8vj : 4.187 seconds. Count of corresponding commons categories using sitelinks, P910 etc https://w.wiki/8vk : 14.450 seconds.
Pinging search guru @Lucas Werkmeister (WMDE): to see whether he thinks the comparison is fair, and whether he has any thoughts/comments. Jheald (talk) 20:35, 26 September 2019 (UTC)
@Jheald: Well, that last query presupposes that the sitelinks stay as messy as they currently are, doesn’t it? I’m not sure what Mike Peel is proposing, but if for the sake of argument we assume that category pages are always linked to separate category items (which are created if necessary), then a simpler query becomes possible, which doesn’t perform that much worse than the P373 version (though it’s still somewhat slower). --Lucas Werkmeister (WMDE) (talk) 11:24, 27 September 2019 (UTC)
@Jheald, Lucas Werkmeister (WMDE): The sitelink query is messy, and it would be good if there was a better way, but I don't think Commons category (P373) is it. Having separate category items for all Commons categories would work with the current system, but that would need a different discussion. For now, I'm proposing that we just use the system as-is and follow topic's main category (P910) and category related to list (P1754) as needed.
Querying P373 may give you quick results, however it will also give you incorrect results as it's not 100% in sync with the sitelinks. See some of my recent edits here for bad P373 value that I've been removing - there are quite a few of them. As it currently stands, bots add new ones, and pi bot tries to fix obviously bad ones (e.g., non-existent or redirects to the sitelink), but more complex cases (like a link to a completely different Commons category than is in the sitelink) need human review, and that doesn't happen enough. We could program the bots to always keep P373 in sync with the sitelink, but that's a change from the status quo, and will probably cause friction as people mistakenly edit P373 instead of the sitelink.
In terms of implementation, I mentioned above that Module:WikidataIB's getCommonsLink function can be used to provide the sitelink, following topic's main category (P910) and category related to list (P1754) if needed, and I think that's started to be used in other language wikis to replace P373, but there is still a way to go. For the link within MediaWiki, I've posted phab:T232927 - I don't think it should be a big issue, but the developers haven't replied there yet. I'd hope that a 'deprecated' stage would help give time for the transition. Thanks. Mike Peel (talk) 10:37, 28 September 2019 (UTC)
An expression could presumably also be added to SPARQL to return the Commons category. Ghouston (talk) 01:43, 29 September 2019 (UTC)
For a shortcut to the heavy English module see w:ca:Module:WikidataCommonsCat. I agree with Mike that P373 should be the last option. --Vriullop (talk) 11:42, 14 December 2019 (UTC)
  • Symbol keep vote.svg Keep I was told that site links could link to whatever page on Commons. So if we can attach a commons category to the item, its important to describe it properly. More over, there are (an I guess they are attached to this property, not to the sitelinks (for common)) multiple technical reason, why it should be kept (so before potetional removal, these technicalities should be work out). E.g. interwiki links from Commons, to Wikipedia, category templates etc. --Juandev (talk) 10:21, 23 September 2019 (UTC)
  • Symbol keep vote.svg Keep It is now the only (simple) way to access the Commons category which belongs to an article or subject. --RolandUnger (talk) 06:03, 7 October 2019 (UTC)
  • Symbol delete vote.svg Delete Please deprecate and later delete this property once and for all, the commonscat links are sufficient for the intended purposes. Linking more than two commons categories is not useful and therefore no reason to keep this property. Steak (talk) 10:48, 10 October 2019 (UTC)
  • Symbol delete vote.svg Delete Per above, especially per Liuxinyu970226. T54971 might be a better solution to fix What Multichill concerns. --2409:8902:9301:F7F8:1FC0:6702:8454:4E37 02:13, 30 October 2019 (UTC)
Symbol delete vote.svg Delete Problemic property, should consider more smart ways instead. --2409:8902:9001:6CE0:5E2F:BCDA:B1D9:2A6F 00:22, 4 December 2019 (UTC)
  • Symbol keep vote.svg Keep Per above. + We will have problems with automatic cross-project linking without this property. --sasha (krassotkin) 14:13, 17 December 2019 (UTC)
  • Symbol keep vote.svg Keep Sitelinks have some advantages over P373. However they lack flexibility (unique values, etc.) and no standard seems to have finally settled the articles vs categories issue. Therefore, P373 is still a useful fallback.--Pere prlpz (talk) 11:14, 26 December 2019 (UTC)
    @Mike Peel: How do you think about Krassotkin's and Pere prlpz's comments? --Liuxinyu970226 (talk) 03:38, 20 June 2020 (UTC)
    @Liuxinyu970226: I think I've already answered the points by @Pere prlpz, Krassotkin: elsewhere in this discussion - primarily that there is a standard approach to using the sitelinks, and P373 is mostly just a duplication, or at best an indication of places where we need to improve our modelling here or the commons category structure. Thanks. Mike Peel (talk) 09:21, 21 June 2020 (UTC)
  • Symbol delete vote.svg Delete no reason to single out Commons, use topic's main category (P910) Michael FV (talk) 03:32, 9 January 2020 (UTC)
  • Symbol delete vote.svg Delete phab:T54971 solution should be enough, please also consider nominating Multichill for WD:RFP/R since that guy only keeps Wrong claims by themselves. --117.136.54.109 23:20, 20 January 2020 (UTC)
  • Symbol delete vote.svg Delete Redundancy must die. — Mike Novikoff 23:50, 10 February 2020 (UTC)

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

@Multichill: Oppose It looks like the currently vote is 13:13:1, which looks rather like neither way are fair, but at least 3 deletion rationales pointed phab:T54971 and phab:T232927, which is, although tricky, two better ways that can finally kill all the P373 functions, so unless if both are declined officially, "close as no consensus" is also unfair. --Liuxinyu970226 (talk) 08:17, 1 April 2020 (UTC)
  • Symbol delete vote.svg Delete Unnecessary and useless. -- MovieFex (talk) 04:32, 29 March 2020 (UTC)
  • Symbol delete vote.svg Delete Deprecate and later delete (redundant; a lot of people with no experience with Wikidata are very surprized to find out that we have such fundamental mess in linking to Commons categories) Vojtěch Dostál (talk) 08:11, 31 March 2020 (UTC)
  • Symbol delete vote.svg Delete Deprecate and delete. Two ways of linking is source for errors and confusion. MrProperLawAndOrder (talk) 17:44, 11 April 2020 (UTC)
  • Symbol delete vote.svg Delete Deprecate and delete. It is redundant and it was very confusing when I found out there were two properties doing essentially the same thing. Many of the keep votes say it is not ideal but that we should keep it until a proper solution is in place. Deprecating and deleting is a path towards that outcome. Kees08 (talk) 17:46, 12 April 2020 (UTC)
  • Symbol delete vote.svg Delete Deprecate and delete. Per Kees08 redundant and confusing. TechContribution (talk) 20:37, 30 April 2020 (UTC)
  • Symbol delete vote.svg Delete Deprecate and delete. Galleries can use Commons gallery (P935) if necessary. Commons could even be given its own Sitelink if needed. The RedBurn (ϕ) 20:46, 2 May 2020 (UTC)
Symbol delete vote.svg Delete There are ways to query better. --111.32.68.231 02:42, 9 May 2020 (UTC)
  • Symbol keep vote.svg Keep - So far I have only seen claims that this property is redunant but not the proof that it is 100% redunant. Sure there is certainly some redunancy but that does not take away that down the stream this is quaranteed always the case. To my feeling I read above here mostly about that it gives double work as when a category is created or changed it has to be updated in two ways. I read only a little about that this property is one of the most extensively used properties in the various Wikimedia platforms. This is big! The use of this prorty has been widely adopted in use in the various platforms and this is something that can't be simple marked as redunant as that would imply big consequences for the complete Wikimedia ecosphere. The implications are large as this property forms the foundation of interproject linking. First deprecating the foundation and then starting to think about alternatives is the wrong order. If it is really redunant, first a full inventory needs to be made of all the possible issues that come up. Also the sitelinking of Commons galleries needs to be made obsolete, as it is still common practise that these get priority over Commons categories! That common practise needs to be deprecated first. Then a solution needs to be invented/created for all the possible issues that come up. For example both the category as the article on Wikipedia about that subject link to the same category on Commons. What to do with cases with one category on Commons, two articles on Wikipedia. And so on. In the previous discussions about deleting this property various reasons have been given why it is a bad idea to delete this property, and above here these reasons have not or insufficiently been addressed. Romaine (talk) 05:17, 30 May 2020 (UTC)
    @Romaine: Over the last year or so I've worked through, and resolved, thousands of cases where P373 is different from the sitelink. I have yet to find a single one that is not due to mismodelling on a Wikipedia; on Commons; or here. That's not a big surprise, though, as P373 is designed to smooth over those cases of mismodeling, and to provide a temporary shortcut that lets you link two different topics with a single commons category. The only reason it is "one of the most extensively used properties" is because it pretends to be a sitelink - which I think is the most used aspect of Wikidata. We already have alternatives - use the Commons sitelinks, and use the Lua code linked to above to find the correct one through linking properties such as topic's main category (P910). This already handles the sitelinks to Commons galleries without needing a change of approach to sitelinking them from here. What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them. If you want to test this, please point out some tricky cases that need resolving! Thanks. Mike Peel (talk) 18:45, 5 June 2020 (UTC)
    Hi Mike Peel, Over the past years I also worked on resolving thousands of cases of issues with P373. So I am fully aware of the troubles with it. I agree that it is one of the most used properties because it pretends to be a sitelink, but I also disagree with that idea. The main principle of a sitelink is that there is a one to one an item on Wikidata and a category on Commons. For many subjects this is the case, but also for many subjects this is not the case. Over the past month (but also many times before that), I have come acros thousands of subjects that do not have a one to one Wikidata-Commons situation. So no, Commons sitelink is in many cases not an alternative. That is even worse than I thought before! I think it is even worth to investigate if it would be possible to abbolish Commons sitelinks in Wikidata (certainly for categories) (because sitelinks only allow a 1 to 1 support, all other data is not allowed), and move all the functionalitis that the Commons sitelinks provide to Commons/Wikipedia/etc, to the P373 property. Another alternative is that the Commons sitelinks are redesigned, but that is something I am hoping for more than a decade (as even before Wikidata existed this was already a problem to deal with in Wikipedia).
    "find the correct one through linking properties such as topic's main category (P910)" -> This is just one of the cases where this might be a solution, but there are various other situations to that have no solution. On this page I see no solutions offered to those, which is I think highly problematic. In Dutch we have a saying that people should not throw away shoes befre you got new ones. That is what is happening here.
    "What I'm proposing is that we remove all of the cases where P373 is the same as the sitelink (which is most of them, since most cases have only been added based on the sitelinks), and then we can look through the remainder - and while there will be tricky cases, I don't expect that there will be that many of them." -> Just alone for rijksmonuments in the Netherlands, almost every single municipality in the Netherlands has cases of for example even 18 items on Wikidata with only one category on Commons. So speaking about "not many of them", in percentages almost everything is small compared to millions.
    "If you want to test this, please point out some tricky cases that need resolving!" -> This is turning it around. You want to change something, then you need to come with the solutions. Most Wikidata uers have no idea that discussion is going on here, and will highly likely influence there work. Then expecting that the majority that is not present here comes with the tricky cases, that is not the way to work.
    What you are basically asking is just to go forward, without making sure you have the solutions in place first.
    Also that you minimalise the number of cases you think you would get, I would say underestimate, is a bad approach. With this kind of gigantic changes, decisions need to be based on facts and not on imagination. The simple thing that the number of cases involved is still not counted is troubling. In my previous message I wrote that as this property has usage in gigantic propertions, an inventory should be made. On this page I do not see such a thing happening (asking for examples is turning it around and is not an inventory). To me this feels like the issues that have brought up by various users are not taken seriously. The issues addressed concern situations that are not just simple (small) cases, but represent a large structural mismatch.
    I am also concerned about what has been done with my previous post from 30 May 2020. In there I made a first basic analysis of the situation. Also that has been ignored. As both the analysis and issues raised by users are not addressed first, this discussion is walking in a dead-end street and can only have one outcome: proposal rejected. Romaine (talk) 07:49, 12 July 2020 (UTC)
    @Romaine: From my experience, there are three types of items that need to link to the same Commons category - 'topic', 'list' and 'category' items (or maybe four, if you include 'categories of lists'). I think those are well modeled with the category/list linking properties. All of the other cases I've come across have been due to mis-modelling either here, on a Wikipedia, or on Commons - part of why I was asking for illustrative examples where this wasn't the case. Abolishing Commons sitelinks would be impossible now, as there is no other way to provide a bi-directional link between Commons and Wikidata, and copying QIDs around rather than using the sitelinks would create a maintenance nightmare that the auto-updating of commons categories avoids. For Rijksmonuments, I think having a container category for them works well, but if you're using Wikidata lists then you could automatically use the sitelinks the same as using P373 (also relevant to this point is the de-voy discussion below). I think the solutions already exist, otherwise I wouldn't be supporting this PfD so emphatically - and again, asking for cases where the solutions don't work. I hope that the Wikidata modelling is not so inflexible that a temporary fix introduced in 2013 *has* to continue into the future indefinitely. Thanks. Mike Peel (talk) 20:41, 13 July 2020 (UTC)
  • Symbol keep vote.svg Keep - I don't deny that this property is confusing (especially for newcomers) and it's an ugly kludge, but given the fact that it's virtually impossible to do proper SPARQL queries without it, many things will break if we remove it, and many other things mentioned above (like the gallery / category problem) we can't really remove this property. Husky (talk) 23:07, 4 June 2020 (UTC)
    @Husky: There are work-arounds for SPARQL queries that were described above, although they could definitely be made simpler to use. The gallery/category problem is already solved from a sitelink perspective. I'm proposing a period where the property is deprecated, can you help solve the issues that might be caused by the property being deleted, please? Thanks. Mike Peel (talk) 18:48, 5 June 2020 (UTC)
  • Symbol delete vote.svg Delete this property has always been an outlier and with the other sites link its now redundant and frankly highly confusing. EoRdE6(Come Talk to Me!) 03:53, 12 June 2020 (UTC)
  • Symbol keep vote.svg Keep Many uses, a lot of things would break and this is a really useful thing.--Ferdi2005[Mail] 11:25, 9 July 2020 (UTC)
  • Symbol keep vote.svg Keep causes too many problems for me to support deletion. Every issue needs to be addressed before deletion, as this is used a hell of a lot and will cause crosswiki issues. --IWI (talk) 17:14, 6 September 2020 (UTC)
  • Symbol keep vote.svg Keep There are many occasions where a pairing category item exists so the (re-)use of the interwiki is not possible as it is used elsewhere. It needs to remain, and it needs to remain active and undeprecated.  — billinghurst sDrewth 05:48, 14 September 2020 (UTC)
    @billinghurst: Can you give some examples, please? Thanks. Mike Peel (talk) 08:40, 14 September 2020 (UTC)
    @Mike Peel: Something like Category:United States (Q1410960). I regularly do a merge/cleanup where I move the Commons category interwiki to the Category: item from the topic-item, ensuring we have the CommonsCat on the topic-item and adding the Topic-Cat: property. And over time I have also seen numerous species and redundant species names (whatever they are called) where the CommonsCat is on both items. [I don't remember maintenance activities specifics].  — billinghurst sDrewth 14:48, 14 September 2020 (UTC)
    @billinghurst: I think the cases like Category:United States (Q1410960)/United States of America (Q30) are already solved by following the topic's main category (P910)/category's main topic (P301) links, if not then they normally just need cleanup so they are properly linked, they don't really need Commons category (P373) except as a convenience shortcut. Thanks. Mike Peel (talk) 15:42, 14 September 2020 (UTC)

Discussion (remaining issues)[edit]

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

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

Property:P3917[edit]

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

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

territory claimed by (P1336)[edit]

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

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

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

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

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

Property:P5105[edit]

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

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

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

Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)
Symbol keep vote.svg Keep Wikidata have lot of external identifiers, why need deletion? --B.Zsolt (talk) 13:31, 11 December 2019 (UTC)
Symbol delete vote.svg Delete@B.Zsolt: Because there's a more useful identifier as replacement. --Liuxinyu970226 (talk) 14:53, 11 December 2019 (UTC)
Symbol delete vote.svg Delete per Andy. This is an item property btw, not an external identifier property. Multichill (talk) 19:04, 12 December 2019 (UTC)
Symbol delete vote.svg Delete after data migration. Robin van der Vliet (talk) (contribs) 00:43, 16 December 2019 (UTC)
Symbol keep vote.svg Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:27, 16 December 2019 (UTC)
Symbol delete vote.svg Delete The specific property (P5105) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the operator can be inferred from the station category items, so including the operator as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)
  • Symbol keep vote.svg Keep per Thryduulf Michael FV (talk) 04:01, 9 January 2020 (UTC)
  • Symbol keep vote.svg Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 11:04, 20 January 2020 (UTC)
  • Symbol delete vote.svg Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. --117.136.54.109 23:22, 20 January 2020 (UTC)
  • Symbol keep vote.svg Keep per above Germartin1 (talk) 09:55, 2 April 2020 (UTC)
    @Jura1, Germartin1: "Enables reports with someone's bot" isn't a valid keep reason, we can ask them on Github to request cancelling their relative codes. --Liuxinyu970226 (talk) 00:49, 8 April 2020 (UTC)
Symbol delete vote.svg Delete As values are only items, merge em back won't hurt anything. --223.104.7.115 22:11, 9 May 2020 (UTC)
  • Symbol delete vote.svg Delete No need to fragment data into multiple properties. --Tinker Bell 01:55, 25 October 2020 (UTC)

Property:P5330[edit]

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

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

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

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

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

Property:P4587[edit]

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

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

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

Property:P4193[edit]

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

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

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

Scoresway soccer person ID (P3043)[edit]

Scoresway soccer person ID (P3043): (delete | history | links | entity usage | logs | discussion)

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

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

Scoresway volleyball person ID (P6066)[edit]

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

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

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

Scoresway rugby person ID (P6065)[edit]

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

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

  • A little Symbol keep vote.svg Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
  • Had never more than 50 uses .. I'd tend to delete this --- Jura 08:18, 10 April 2020 (UTC)

Scoresway handball person ID (P4451)[edit]

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

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

Scoresway tennis person ID (P6308)[edit]

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

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

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

Joconde IDs[edit]

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

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

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Marianne Casamance
Natou844
Nattes à chat
Pierre André
Bouzinac
Albertvillanovadelmoral
Jsamwrites
Baidax
LearnKnowGive1
Pictogram voting comment.svg Notified participants of WikiProject France --Liuxinyu970226 (talk) 01:23, 8 April 2020 (UTC)

  • Symbol keep vote.svg Keep: same as for Shonagon. Nomen ad hoc (talk) 06:56, 8 April 2020 (UTC).
  • Symbol neutral vote.svg Neutral both cases (unique property or separate properties) have advantages. For the records, there was a unique property P3905 (P3905) (created in 2017, Wikidata:Property proposal/Ginco id) but it has been deleted (in 2018) and split into these separate properties. I'm not keen to go back to the previous situation without a good reason. That said, to answer @ArthurPSmith: question, if we go back so a single property, the best would be to undelete P3905 (P3905). Cdlt, VIGNERON (talk) 08:13, 8 April 2020 (UTC)
  • Symbol keep vote.svg Keep Per Shonagon, Christelle Molinié and VIGNERON. There are edge cases that would be too far and wide to solve easily, seeing as some items can fall into two (or more ? ) categories, depending on the axis you want to reach them from, and it is actually sometimes interesting to search all items by one axis, which merging all properties would make a bit more complicated. As an aside, unlike what was said on Vladimir Alexiev's talk page, they aren't "UUIDs" as they're not 128-bit integers (even assuming the letters to be 8-bit) : unique identifiers aren't necessarily UUIDs… Alphos (talk) 09:14, 8 April 2020 (UTC)
  • I suggest you synthesis and maybe a unanimous exit will see the light of day. Above all, tell me if I write bullshit!
    1. I think ArthurPSmith votes {{Vd}} because he sees that it is technically possible. The identifiers of each property will always be linked to a part of http://data.culture.fr/, 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)
  • My first idea (before discussion with Vladimir Alexiev and this proposal) is to create a new property "Joconde UUID" and rename all other properties to "Joconde legacy xxx ID".--GZWDer (talk) 12:59, 8 April 2020 (UTC)
@Eihel: I'm sure I understand your position. You say « the return of this property should not be useful » and then « I agree with Symbol delete vote.svg Delete », but deletion of the separate properties is exactly the same as return to P3905 (P3905).
Plus, the analogy with IMDb ID (P345) is only partially relevant as each part is separate and disjoint (it's tt or - exclusive or - nm, which make it easier to manage and maintain) while here there is a lot of overlap between the thesauri (it's T69- and T96- for example) which may cause some trouble (including but not limited to the "single value" constraint as you pointed out; the "unique distinct value" constraint is still true though).
Cheers, VIGNERON (talk) 13:45, 8 April 2020 (UTC)
@Eihel: Yes that could have been a solution except that unfortunately the prefix is not reliable. It is a remnant of an old system for ancient entries. All new entries use UUID and are intentionally opaque. Example of artist Joconde with UUID: MASCAUX Claude Léon. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)
  • I have another point for deletion: there seems to be much more thesauri than Wikidata properties we have. Creating an property for each of them does not seems scalable.--GZWDer (talk) 13:48, 8 April 2020 (UTC)
@GZWDer: These vocabularies are all those of the Joconde database and are particularly important in France, used for hundreds of museum collections. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)
  • Pictogram voting comment.svg Comment This thus look rather un-coodinated. We also seem to have more properties than some of those properties have actual uses. How many more properties should there be created? --- Jura 08:13, 10 April 2020 (UTC)
  • Symbol keep vote.svg Keep See https://www.wikidata.org/wiki/Property_talk:P7844: @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 culture.fr people, @Christelle Molinié, Shonagon: can help with the last 3 bullets (the last 2 are the big-effort part) --Vladimir Alexiev (talk) 10:28, 23 April 2020 (UTC)
    • Relax regexes to just [\w-]+
    • Edit formatterURL to remove T69- (and the like)
    • Migrate existing values to put T69- (and the like) inside the value
    • Create a central page to describe all FR thesauri, with description, links to home page and prop, MnM catalog. A good place is a sub-page of Wikidata:WikiProject Visual arts
    • Import more of the thesauri to Mix-n-Match catalogs so they can be coreferenced
    • (when there is interest) Create more props and catalogs for more thesauri
Yes I see a point for doing so. I withdrew the deletion request but this should not be closed yet until others agree Vladimir Alexiev's proposal.--GZWDer (talk) 12:15, 23 April 2020 (UTC)
Vladimir Alexiev's proposal sounds fine to me. ArthurPSmith (talk) 20:44, 30 April 2020 (UTC)
  • I dont't think the id should be changed to include the database identifier if we keep separate properties. --- Jura 07:58, 2 May 2020 (UTC)
OTH, the format seems to be either "<database id><old id>" or "<uuid>" .. --- Jura 08:03, 2 May 2020 (UTC)

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

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

Thanks @Shonagon: that's great!

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

Symbol delete vote.svg Delete How do I add http://data.culture.fr/thesaurus/page/ark:/67717/T1-1187 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. 50.53.22.81 02:06, 13 September 2020 (UTC)

Nobel prize ID (P3188)[edit]

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

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

Why is it that when I click on the link at Nobel_prize_ID I get taken to a biography, and when I click on the new links I get an error message? This is the new link we are using for Marie Curie: Marie Curie This is the the old link Marie Curie. All three examples at Nobel Laureate API ID give error messages. What is going on? We should keep the old system in place until the new system is stable. --RAN (talk) 15:13, 6 May 2020 (UTC)
@Richard Arthur Norton (1958- ):  nobelprize.org had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 09:36, 13 May 2020 (UTC)
  • The problem appears to be fixed now. --RAN (talk) 05:04, 9 May 2020 (UTC)
 nobelprize.org had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 10:43, 17 May 2020 (UTC)
  • Symbol delete vote.svg Delete: sounds sensible. Nomen ad hoc (talk) 18:06, 10 May 2020 (UTC).
  • Symbol keep vote.svg Keep: decent coverage (100%?), seems to be stable (since 4 years), used by other WMF sites, and the other id redirects there too. --- Jura 20:45, 13 May 2020 (UTC)
Pictogram voting comment.svg Comment I guess every third Nobelprize link has en:Link rot in en:Wikipedia and Nobel prize ID (P3188) has been impossible to maintain as it has changed more times when Nobelprize.org has done a new webdesign. Now Nobelprize.org takes responsibility for maintain this and we just need to store the unique number in Wikidata - Salgo60 (talk) 10:51, 17 May 2020 (UTC)
We already do store it. There is no need to delete historic information. This is not Wikipedia. --- Jura 11:20, 17 May 2020 (UTC)
Pictogram voting comment.svg Comment@Jura:please explain. The IT people at Nobelprize.org also see the chaos with linking the old web and agree of this new approach
- Salgo60 (talk) 01:07, 18 May 2020 (UTC)
  • Wikidata isn't here for the IT people at Nobelprize.org. Identifiers here can be used outside the source database. If you find a database problematic, maybe you shouldn't propose storing (additional) identifiers for it. --- Jura 10:29, 18 May 2020 (UTC)
@Jura1: the discussion is about if we can delete Nobel prize ID (P3188) or not. I see no arguments why we shouldn't delete it
Just to update you on the background:
  1. Wikipedia has a lot of en:Linkrot to Nobelprize.org 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. Nobelprize.org 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. Nobelprize.org 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 Nobelprize.org people that Wikipedia thinks Nobelprize.org 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 Nobelprize.com Apr 15 2020
  6. Wed, Apr 29, 11:42 AM the new solution was implemented using Nobel Laureate API ID (P8024)
Nobel prize ID (P3188) is and has been obsolete the last years so I recommend to delete it if no one can explain who is using it
- 18:37, 21 May 2020 (UTC)
I think you explained your webdirectory approach in detail. There are various ways of maintaining such things in an automated way, without alienating all users and requiring them to use a redirect service. --- Jura 20:00, 21 May 2020 (UTC)
@Jura: "redirect service"?!=?! Nobelprize.org 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 Nobelprize.org has "one" landing page for every Nobelprize winner also if they have received more prizes...

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

  • A little support Symbol delete vote.svg Delete, as I'm confused that what "redirect service" that @Jura1: said is. --Liuxinyu970226 (talk) 22:39, 3 June 2020 (UTC)
I guess the redirect mentioned is that Albert Einstein (Q937) with Nobel Laureate API ID (P8024)
  • has the following pattern with an unique number 26 --> www.nobelprize.org/laureate/26 that gets an redirect to www.nobelprize.org/prizes/physics/1921/einstein/facts/
  • 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 Noibelprize.org. As they now has an API with unique numbers for every Nobelprize winner I guess this redirects will be easier to maintain for them and much easier for Wikidata as our link will be stable
- Salgo60 (talk) 09:35, 4 June 2020 (UTC)

opponent during disputation (P3323)[edit]

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

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

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

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

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

has edition or translation (P747)[edit]

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

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

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

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

mountain range (P4552)[edit]

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

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

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

Previous RFD: Wikidata:Requests_for_deletions/Archive/2014/Properties/1#P295
  • Symbol keep vote.svg Keep. It's just a way too important property for all sorts of items. Thierry Caro (talk) 08:45, 4 September 2020 (UTC)
  • Symbol keep vote.svg Keep until better ways of retrieving and filtering statements are developed on wikis Vojtěch Dostál (talk) 14:29, 5 November 2020 (UTC)

Property:P8531[edit]

Initial discussion[edit]

Second discussion (?)[edit]

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

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

Media Arts Database author ID (obsolete) (P3231)[edit]

Media Arts Database author ID (obsolete) (P3231): (delete | history | links | entity usage | logs | discussion)

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

Symbol delete vote.svg Delete as replaced. --Liuxinyu970226 (talk) 06:21, 1 September 2020 (UTC)
Symbol delete vote.svg Delete but we should first warn the wikis which seem to be using this property @Lockal: Vojtěch Dostál (talk) 14:27, 5 November 2020 (UTC)

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

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

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

Why delete a valid property? The data is potentially useful for joining to other databases or through archives. Keep but deprecate. BrokenSegue (talk) 17:09, 1 September 2020 (UTC)
Marked as Wikidata property for a discontinued website (Q60457486). --Liuxinyu970226 (talk) 23:04, 2 September 2020 (UTC)
  • Symbol keep vote.svg Keep It's useful to see which games that were available on Twitch vs Mixer.--Trade (talk) 20:51, 12 September 2020 (UTC)
What are you opposed to, Trade? Against deletion {{Vk}} or against property {{Vd}}. —Eihel (talk) 15:57, 14 September 2020 (UTC)
  • Pictogram voting comment.svg Comment @BrokenSegue, Liuxinyu970226, Trade: Please read the description of Wikidata property for a discontinued website (Q60457486). Your opinions leave me a little skeptical. —Eihel (talk) 01:06, 13 September 2020 (UTC)
    @Eihel: And why your comment isn't? I just added such a mark, if you think I did wrong, why not revert me? And I have no opinions on vd or not this. --Liuxinyu970226 (talk) 01:09, 13 September 2020 (UTC)
    @Eihel: The statement on that page re: deletion is bad and I doubt represents policy or concensus or even was the result of discussion. Don't delete possibly useful data. BrokenSegue (talk) 01:10, 13 September 2020 (UTC)
  • Symbol delete vote.svg Delete per nomination. See also a similar situation with YouTube Gaming shutdown. Regards Kirilloparma (talk) 01:31, 13 September 2020 (UTC)
    • @Kirilloparma: Would your opinion change if I told you a large amount of mixer is archived? BrokenSegue (talk) 20:38, 13 September 2020 (UTC)
      • Unfortunately, not really. Well, there are some incomprehensible links that you provided, I have opened them and nothing has changed, since there is no link to the archive itself, only some incomprehensible files that need to be downloaded to my PC ... What are they for and how can they help Wikidata? As for the site itself, Mixer (just like Youtube Gaming) simply offered the user nothing more than a streaming service. So the question is, why should we have empty links to defunct streaming service? I would understand if this happened to IGDB site, since archived links to it would contain a lot of useful information for Wikidata (see example), but in the case of Mixer on the contrary, just empty links which once led to a streaming service, but now they no longer work and are no longer needed, so yeah, I am not changing my opinion at this point and still think this property should be removed. Regards Kirilloparma (talk) 22:06, 14 September 2020 (UTC)
        • The files you didn't download are Web ARChive (Q7978505)s and the primary way websites are archived in bulk. Why should we have links to a dead site? We shouldn't. We should remove the links. But the identifiers remain meaningful (they provide meaning to those archives and allow us to join to other databases that may have stored Mixer game ids). Still nobody has explained what harm these identifiers are doing. I mean what value did you think having this identifier provided when the website was up? It's the same value now except you have to go to the WARC files. BrokenSegue (talk) 02:27, 15 September 2020 (UTC)
  • Symbol delete vote.svg Delete Why skeptical? Why is this property valid if it no longer fulfills the function for which it was created, BrokenSegue? Which database will use Wikidata IDs for a closed site, BrokenSegue? Can we still see games available on Mixer to compare them to another site, Trade? When a site is closed therefore the property attached to the site is obsolete: Label, P1630, Base URL… and Q60457486. Consensus and discussion are the basis of the preliminary debate to the creation of the property, and serve as a policy. What is rightly debated is whether the "data is possibly useful". As these are external ids, you need to have archives. The link to your archive.org page consists of meta-information and are not saved pages that can be used to replace property IDs. And although archives can be found, this was a site offering streaming… whose server is also on the SLD. So an archive will go to an empty page of interesting content, but filled with advertising. Clearly unnecessary. So deletion is the only solution, there is no mysterious utility. Cordially. —Eihel (talk) 16:49, 14 September 2020 (UTC)
    • @Eihel: Respectfully you are mistaken. The link to the archive.org data I provided is not just meta-information. It is saved pages. If anyone goes through those archives they will be glad we didn't delete this property. Further, I'm unclear what value deleting this property achieves or what harm keeping it does. The value of an external identifier is not merely the URL it takes you to (as evidenced by the identifiers that have no URL). BrokenSegue (talk) 16:56, 14 September 2020 (UTC)
  • Tend to Symbol keep vote.svg Keep since their values are archived by archive.org, which may give a way to replace its URL scheme. --Liuxinyu970226 (talk) 21:45, 27 September 2020 (UTC)
  • Pictogram voting comment.svg Comment There seems to be decent archiving in the Wayback machine, so I went ahead and added a formatter URL (P1630) accordingly. Jean-Fred (talk) 14:19, 29 September 2020 (UTC)
  • Symbol keep vote.svg Keep unless it shouldn't have been added in the first place --- Jura 07:20, 15 October 2020 (UTC)

Google Play Music artist ID (P4198)[edit]

Google Play Music artist ID (P4198): (delete | history | links | entity usage | logs | discussion)

Google Play Music shuts down in December 2020 and replaced by YouTube Music, and this property cannot be recycled in the same manner as Property P4199, which just needs renaming and changing the formatter URL.

This is because the Google Play Music artist ID uses a certain code string, while the new YouTube Music service simply uses YouTube autogenerated artist (Q72108010) channels to identify the artist, and it can be added as a statement with the Property P2397. —CrystallineLeMonde (talk) 16:51, 1 September 2020 (UTC)

Why delete a valid property? The data is potentially useful for joining to other databases or through archives. Keep but deprecate. BrokenSegue (talk) 17:04, 1 September 2020 (UTC)

Kicker.de player ID (former scheme) (P6615)[edit]

Kicker.de player ID (former scheme) (P6615): (delete | history | links | entity usage | logs | discussion)

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

many of the id's links are archived. e.g. this one. though the link format is broken at the moment. deprecate and mark as obsolete but keep. here's a list of archived entries. BrokenSegue (talk) 16:51, 16 September 2020 (UTC)
If this property is deleted, the non-numeric identifiers should be transferred to the new property prior to being removed. S.A. Julio (talk) 17:28, 27 October 2020 (UTC)

shrinkage (P7079)[edit]

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

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

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Pictogram voting comment.svg Notified participants of WikiProject Mathematics ^^ --Liuxinyu970226 (talk) 22:21, 13 October 2020 (UTC)

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

@Thibdx: (proposal creator) Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
Pictogram voting comment.svg Notified participants of WikiProject Physics (more appropriate than maths) author  TomT0m / talk page 06:53, 14 October 2020 (UTC)

  •  Support This isn't even used in the given example. --Mu301 (talk) 13:05, 14 October 2020 (UTC)
  • Symbol keep vote.svg Keep It certainly had support, no usage is not reason to delete it Germartin1 (talk) 19:30, 20 October 2020 (UTC)
    • @The-erinaceous-one, Mu301, Germartin1: As header:  Support or  Oppose what? Please, use Symbol keep vote.svg Keep or Symbol delete vote.svg Delete. —Eihel (talk) 20:17, 20 October 2020 (UTC)
    • @Germartin1: By that logic, we should never delete any property because they all had support at one point. But sometimes we are collectively mistaken on whether a particular property will be useful so we should be open to deleting unused properties. — The Erinaceous One 🦔 21:27, 20 October 2020 (UTC)
  • Symbol delete vote.svg Delete @Germartin1: Not really to be used due to hard technical challanges, if the technical problem is solved in the near future, this can be request-restored. --Liuxinyu970226 (talk) 09:50, 23 October 2020 (UTC)
  • Symbol delete vote.svg Delete Vojtěch Dostál (talk) 14:12, 5 November 2020 (UTC)

third-party formatter URL (P3303)[edit]

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

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

  • Is there some Wikibase code change that allows that? --- Jura 12:29, 24 October 2020 (UTC)
  • @IagoQnsi: Maybe the name should be modified, but I don't see the purpose of having multiple P1630's on a property. The Wikibase UI will only use one of them, and I'm not sure it currently correctly selects the preferred one (there's a delay in any case, so it's complex to check). The advantage of a separate P3303 is that it makes clear that the entity making use of it needs to do the formatting themselves, the Wikibase UI won't help. Merging with P1630 will confuse that. ArthurPSmith (talk) 22:26, 24 October 2020 (UTC)
  • If Wikibase can select the preferred format over multiple claims, I'll support it. --Tinker Bell 01:44, 25 October 2020 (UTC)
  • Symbol keep vote.svg Keep It is important to distinguish primary 'official' formatter and the third party formatters. But it would be nice to have a tool/gadget to display external links also from third-party formatters.--Jklamo (talk) 10:40, 27 October 2020 (UTC)
  • Symbol delete vote.svg Delete @Jklamo: No need to "distinguish", we should be neutral on every URL schemes. --Liuxinyu970226 (talk) 08:32, 30 October 2020 (UTC)