Open main menu

Wikidata:Properties for deletion

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

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

Properties for deletion may be used:

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

Properties for deletion should not be used:

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

Add a new request


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


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



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

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

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

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

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

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
@Autom: Do you have any specific place where this spcific property is used on svwiki? I see many potential problems with this property in the Swedish language, so at least I have never tried to use or even edit it. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:03, 19 April 2019 (UTC)
@Sextvå.tvånoll.ettsjunoll.sjufyra: It is used to display nationality in Faktamall biografi WD (via Wikidata2). In the article Bill Gates, the template does not return "USA" but "Amerikan", which is the value of demonym (P1549) [common gender (Q1305037), singular (Q110786)] of United States of America (Q30) (the country of citizenship (P27) of Bill Gates (Q5284)). /Autom (talk) 14:11, 20 April 2019 (UTC)
  •   Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)
  •   Delete The property demonym of (P6271) has been created. This one can now be deleted (first declare obsolete, move content, then delete).--Micru (talk) 17:30, 19 December 2018 (UTC)
  •   Comment If this property is being used in an infobox or by a Lua module, it will need to be retained and to go on having its values added to and extended, at least and until such time as inverse property values become obtainable via Lua - as at present they are not. Jheald (talk) 18:09, 19 December 2018 (UTC)
  •   On hold. I agree with Jheald that we need a place -> demonym property to keep infoboxes working. We should keep this property until we have a new Item -> Lexeme "demonym" property, migrate all existing uses and infoboxes, then delete P1549. Deryck Chan (talk) 15:52, 11 January 2019 (UTC)
  •   Delete Very barely used, and replacement is even available for these not more than 100 usages. --Liuxinyu970226 (talk) 12:44, 16 March 2019 (UTC)
  •   On hold. Until infoboxes (as happens in cawiki) can be transformed after have access via LUA module. Thanks, Amadalvarez (talk) 12:47, 26 March 2019 (UTC)
  •   Comment. As noted, 1) there is no wikibase client for lexemes, 2) there is no Lua function available for backlinks or API queries, pending of phab:T185313 that it seems silently declined for a year now. There is not any path from a wiki page like w:fr:Paris to reach parisien (L26359). If these blockers are solved, there are still some concerns. How to deal with parisien (L26359) or parisienne (L25620)? How to obtain the demonym for a given language and a lexical category? At the end, it will be one more, or several, arbitrary access and it is expensive in Lua time usage that has limitations in infoboxes powered by Wikidata. --Vriullop (talk) 07:52, 27 March 2019 (UTC)
  •   Keep Keep this property because with this property is very easy to add some data. --Manu1400 (talk) 21:43, 18 August 2019 (UTC)



Initial discussionEdit

Second discussion?Edit

incorrect closuresEdit

Repeating previous comment:

  • Given that it's a controversial property, I don't think a participating administrator should be closing this. Number of uses is irrelevant to reason for which this was listed. --- Jura 22:21, 1 June 2019 (UTC)

As Liux.. isn't an admin, there isn't much they can do about it either. --- Jura 22:41, 8 July 2019 (UTC)

3rd discussionEdit

  Keep Unless if Jura1 has a fresh new reason that this property should be deleted, I doubt if there's need to restart any discussions here. -- 07:49, 10 July 2019 (UTC)
  • Liuxinyu970226, this is about the closure(s), I don't understand why you start a 2nd or a 3rd discussion. --- Jura 10:53, 10 July 2019 (UTC)
    @Jura1: When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of WD:AGF. --Liuxinyu970226 (talk) 13:21, 10 July 2019 (UTC)
    Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- Jura 15:52, 10 July 2019 (UTC)
@Jneubert, Renamerr, Maqivi, Liridon, Epìdosis:@Renessaince, Urban 3th, ديفيد عادل وهبة خليل 2, Davidpar, Pintoch:@Romaine: Do you all still think that this property should be kept? --Liuxinyu970226 (talk) 22:06, 10 July 2019 (UTC)
  •   Keep, for the reasons given above. Jneubert (talk) 07:24, 11 July 2019 (UTC)
  •   Keep--Liridon (talk) 11:21, 12 July 2019 (UTC)

What on Earth is going on here? There has clearly been an improper closure of the original discussion, by an admin making a "super vote", rather than assessing consensus in the discussion. Then we have new discussions, rather than the original discussion being reopened; and a bunch of pings in which I, who called for "delete" in the original discussion, was not included, but those calling "keep", an others who did not participate, were. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 23 July 2019 (UTC)

I'm also wondering that why in our world does Jura1 want this property to be deleted, even they know that there are too many keep concerns, what's their "solutions"? I can't believe that any person that does never do things like Kyoto Animation arson attack (Q65640303) can frequently PFD a property for more than 3 times, just because they want that "to be deleted" even won't happen. --Liuxinyu970226 (talk) 14:34, 25 July 2019 (UTC)
Why this section is restored by you, @Jura1:? --Liuxinyu970226 (talk) 14:54, 4 September 2019 (UTC)
  Keep What a nonsense PFD. -- 02:41, 10 September 2019 (UTC)
  Keep, I don't see any reason to delete this… − Pintoch (talk) 06:03, 22 October 2019 (UTC)


Diffusion ENS ID (P5660): (delete | history | links | entity usage | logs | discussion)

The related site has been closed and the content was moved to Savoirs ENS ID (P5664) (see for instance, in the case of Michel Serres (Q364456), [1] and [2]). —Nomen ad hoc (talk) 15:46, 4 June 2019 (UTC)

Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Le Passant

Nattes à chat   Notified participants of WikiProject France. Nomen ad hoc (talk) 21:27, 4 June 2019 (UTC).

Daniel Mietchen DarTar Ppgardne Michael Cochez Alexander Doria Maximilianklein Renepick Lambert Heller Beat Estermann Cornelia Flavia Veja Tobias1984 Silvio Peroni Alastair Dunning Aubrey Snipre Andrew Su Karima Rafes Alen Vodopijevec Henry Rzepa Scott Edmunds Emw Matthiassamwald Missvain Vladimir Alexiev Petermr WiseWoman Jodi.a.schneider NavinoEvans Jan van Oort Andy Mabbett Konrad Foerstner Egon Willighagen Ben Moore Z. Ainali HLHJ Ale Abdo a.k.a. Solstag jibe-b GuZ-MPG Kristina Hettne Lilaroja Runner1928 Almondega lv_ra Finn Årup Nielsen (fnielsen) Rudy Patard ArthurPSmith Diana de la Iglesia Netha Pintoch OdileB YULdigitalpreservation Lozana Rossenova Jonathan Brier a.k.a. wolfgang8741 Jneubert econterms T0mpr1c3 Vladimir Alexiev Ivanhercaz Trilotat Benjamenta Nomen ad hoc Tris T7 TT meSimon Cobb Alessandro Marchetti sky Juliansteinb Maria zaos Josephguillaume Cavernia GoEThe

  Notified participants of WikiProject Wikidata for research. Nomen ad hoc (talk) 06:58, 15 June 2019 (UTC).

  •   DeletePintoch (talk) 20:20, 16 August 2019 (UTC)
    • The property is now not used anymore, so it can effectively be deleted. Edoderoo (talk) 05:55, 29 August 2019 (UTC)
  •   Delete as it's mostly gone by now. Personally, I'd have kept it. It's a different identifier for these people. It wasn't exactly high use though (ca. 350). --- Jura 14:54, 29 August 2019 (UTC)
    • If the links had worked, I would have kept them too. Edoderoo (talk) 18:43, 29 August 2019 (UTC)
      • Agree, but they're broken. Nomen ad hoc (talk) 18:47, 29 August 2019 (UTC).
        • Don't we usually just de-activate the formatter URL? --- Jura 20:51, 29 August 2019 (UTC)


lithography (P2157): (delete | history | links | entity usage | logs | discussion)

This property seems over-specialized. I had been using statements like Exynos 9820 (Q28859206) fabrication method (P2079) 8nm (Q25991737) and they seem adequate. The statements would be easy to convert. @MisterSanderson, Ruud Koot, Tobias1984: Ghouston (talk) 10:05, 26 June 2019 (UTC) —Ghouston (talk) 10:05, 26 June 2019 (UTC)

Aside from the point that there are numerous manufacturing techniques that apply to more things than semiconductors, and we don't really want properties for them all, it seems that these semiconductor techniques can be described more accurately. E.g., according to [3] there are processes like "8nm FinFET LPP (Low Power Plus)" and "7nm EUV (Extreme Ultra Violet)". The source for the Exynos 9820 says it uses 8nm FinFET LPP. If it was desired to group the semiconductor lithography processes together, that can be done by creating a subclass of manufacturing process (Q1408288). (that would probably be photolithography (Q622938), judging by its enwiki article). Ghouston (talk) 00:26, 27 June 2019 (UTC)

Ruud Koot
Daniel Mietchen
Tinker Bell
Jasc PL
Tris T7
Peb Aryan
  Notified participants of WikiProject Informatics

  • I would vote   Delete, but not without discussing its usage in templates. Over-simplifying Wikidata by removing properties in favour of qualifiers is not the best solution for those uses. Let discuss at the Spanish Wikipedia, and depending the consensus, this property should be deleted or kept. --Amitie 10g (talk) 23:32, 7 July 2019 (UTC)
  • Template use is a good question, I can see a link to ca:Plantilla:Infotaula equipament informàtic on the talk page, and it's visible on ca:Intel 8085, for example. My suggested alternative would be using a different property, not a qualifier, but it would have a wider range of possible values: any manufacturing process. Ghouston (talk) 07:56, 8 July 2019 (UTC)
Is it really that bad if there is a property that describes the production size of microprocessors? Should all information (eg. 8nm FinFET) really be stored in one property? Or would it be better to split it to production size (8nm) and production method (FinFET)? What if you know one, but not the other. In that case the provided entry would not be correct. However, there may is a better name other than lithography for that. Since I don't see any good other way I go with   Keep for now --D-Kuru (talk)
Unmentioned that this property (the microprocessors' structure size) is a very important information for all microprocessors and improves over time. I don't really care how the information is added, but it is an important piece of information. --D-Kuru (talk) 20:49, 20 August 2019 (UTC)
It seems that there's not a lot of enthusiasm for removing the property, or much interest in it all really. I suppose we should just leave the status-quo. Reading the original discussion for the creation of the property, it's clear the the items are supposed to represent fabrication processes, and the labels like "14 nanometer" are just inherited from the English Wikipedia. I don't think it would do any harm to change them to "14nm lithography process" and make them subclasses of photolithography (Q622938). It should also be fine to further distinguish fabrication techniques, e.g., 14LPE or 14LPP discussed at [4]. It can be clarified that the property P2157 is purely a subproperty of fabrication method (P2079) for semiconductor lithography. Ghouston (talk) 04:18, 25 August 2019 (UTC)


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

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

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

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

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

  •   Comment A big problem imho that also concerns student (P802) has been to establish an inverse property constraint. The property would be totally valid as a way to store the main students or Phd candidates of a teacher. Currently most of the student of (P1066)/doctoral advisor (P184) relationships that I have filled during the past years have been also reversed (either by bot or by well-meaning users attempting to "correct" an apparent error) making the student (P802)/doctoral student (P185) information meaningless. I would agree to keep this property along with student (P802) if the constraint is entirely lifted. Alexander Doria (talk) 18:40, 16 July 2019 (UTC)
    • @Alexander Doria: I tend to agree that student of (P1066) and student (P802) should be inverse properties. Importance can be marked using rank, rather than removing unimportant (but truthful) entries. Deryck Chan (talk) 15:32, 19 July 2019 (UTC)
      • Agree too. Only mentioning "notable" students is IMHO too arbitrary... especially if "notability" isn't properly defined. Nomen ad hoc (talk) 15:38, 19 July 2019 (UTC).
      • Agree tooLupin~frwiki (talk) 11:05, 29 July 2019 (UTC)
    • Consistency can be assured but some work is needed. We can get the same information without this property. Use this kind of property to distinguish some items of the set does not seem a good idea since the choice of each item can be discussed and different in every country, field, etc. This selection should be let to each wikipedia page imho. --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)
  • Delete as redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 23 July 2019 (UTC)
  •   Delete A Wikipedia that only wants notable students via reverse lookup can simply only display students for which they have an article. ChristianKl❫ 10:07, 8 August 2019 (UTC)
    • @ChristianKl: Reverse lookup is hideously difficult in Lua... It's better to have a property to curate a list of notable students separately. Many infoboxes (e.g. w:en:Template:Infobox academic) include a "notable students" field, which if implemented using Wikidata should be P185 with preferred rank. Deryck Chan (talk) 10:42, 29 August 2019 (UTC)
  •   Keep People that consider it is redundant with doctoral advisor (P184), may be doesn't know that is impossible to get information via backlinks from LUA module and, of course, from infoboxes and any kind of wiki templates. SPARQL is a partial solutions for the real uses of WD, nowadays. If I'm wrong and somebody has a solutions to make some kind of haswbstatement from wiki templates or LUA Modules, please just tell me. Thanks. Amadalvarez (talk) 16:16, 12 August 2019 (UTC)
Listeria can provide you with such lists. --- Jura 17:21, 17 October 2019 (UTC)
  Keep 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)
  •   Delete Redundant inverse. --Yair rand (talk) 19:46, 15 September 2019 (UTC)
  •   Neutral to   Keep As mentioned in the P802 deletion discussion below, I'm not so sure the breakage of "inverse" is a good idea based on any of the comments shared above. It was introduced once and I have a feeling it would be reintroduced. If the problem is that doctoral student (P185) is overused, relevance should be enforced harder. On the other hand, I think student (P802) is a better property for "famous apprentice". Jagulin (talk) 17:00, 17 October 2019 (UTC)
  •   Keep At least on zhwiki, the Listeria datas can't work well, it only pollutes with English-only text, and has no easy way to translate. --Liuxinyu970226 (talk) 03:40, 6 November 2019 (UTC)


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

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

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

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

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

Viswaprabha (talk)
Maximilianklein (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
PKM (talk) 19:58, 10 October 2014 (UTC)
Revi 16:54, 29 November 2014 (UTC)
Giftzwerg 88 (talk) 23:36, 1 January 2015 (UTC)
Almondega (talk) 00:17, 5 August 2015 (UTC)
Jura to help sort out issues with other projects
Skim (talk) 13:52, 24 June 2016 (UTC)
Marchitelli (talk) 12:29, 5 August 2016 (UTC)
BrillLyle (talk) 15:33, 26 August 2016 (UTC)
Alexmar983 (talk) 23:53, 28 August 2016 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 10:44, 29 August 2016 (UTC)
Chiara (talk) 14:15, 29 August 2016 (UTC)
Thibaut120094 (talk) 20:31, 14 September 2016 (UTC)
Ivanhercaz | Discusión   15:30, 31 October 2016 (UTC)
YULdigitalpreservation (talk) 17:35, 10 November 2016 (UTC)
PatHadley (talk) 21:51, 15 December 2016 (UTC)
Erica (ohmyerica) (talk) 19:26, 1 January 2017 (UTC)
Mauricio V. Genta (talk) 05:38, 12 March 2017 (UTC)
Sam Wilson 09:24, 24 May 2017 (UTC)
Sic19 (talk) 22:25, 12 July 2017 (UTC)
MartinPoulter (talk) 09:21, 20 July 2017 (UTC)
ThelmadatterThelmadatter (talk) 01:11, 13 September 2017 (UTC)
Zeroth (talk) 15:01, 16 September 2017 (UTC)
Beat Estermann (talk) 20:07, 12 November 2017 (UTC)
Shilonite - specialize in cataloging Jewish & Hebrew books
Elena moz
Oa01 (talk) 10:52, 3 February 2018 (UTC)
Maria zaos (talk) 11:39, 25 March 2018 (UTC)
Wikidelo (talk) 13:07, 15 April 2018 (UTC)
Mfchris84 (talk) 10:08, 27 April 2018 (UTC)
Mlemusrojas (talk) 3:36, 30 April 2018 (UTC)
salgo60 Salgo60 (talk) 12:42, 8 May 2018 (UTC)
Dick Bos (talk) 14:35, 16 May 2018 (UTC)
Marco Chemello (BEIC) (talk) 07:26, 30 May 2018 (UTC)
 徵國單  (討論 🀄) (方孔錢 💴) 14:35, 20 July 2018 (UTC)
Alicia Fagerving (WMSE)
Louize5 (talk) 20:05, 11 September 2018 (UTC)
Viztor (talk) 05:48, 6 November 2018 (UTC)
RaymondYee (talk) 21:12, 29 November 2018 (UTC)
Merrilee (talk) 22:14, 29 November 2018 (UTC)
Kcoyle (talk) 22:17, 29 November 2018 (UTC)
JohnMarkOckerbloom (talk) 22:58, 29 November 2018 (UTC)
Tris T7 TT me
Helmoony (talk) 19:49, 8 December 2018 (UTC)
Shooke (talk) 19:17, 12 January 2019 (UTC)
DarwIn (talk) 14:58, 14 January 2019 (UTC)
I am Davidzdh. 16:08, 18 February 2019 (UTC)
Juandev (talk) 10:03, 27 February 2019 (UTC)
Buccalon (talk) 15:51, 27 March 2019 (UTC)
MJLTalk 16:48, 8 April 2019 (UTC)
Rosiestep (talk) 20:26, 24 April 2019 (UTC)
Dcflyer (talk) 12:23, 7 May 2019 (UTC)
Susanna Giaccai (talk) 05:56, 29 July 2019 (UTC)
Asaf Bartov (talk) 19:03, 31 July 2019 (UTC)
Msuicat (talk) 17:58, 6 August 2019 (UTC)
SilentSpike (talk) 15:27, 12 August 2019 (UTC)
TheFireBender (talk) 12:40, 20 August 2019 (UTC)
Jumtist (talk) 21:45, 22 October 2019 (UTC)
  Notified participants of WikiProject Books -- Bodhisattwa (talk) 20:18, 23 July 2019 (UTC)

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

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


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

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

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


majority opinion by (P5826): (delete | history | links | entity usage | logs | discussion)

has part (P527) majority opinion (Q6738447) / author (P50) can be used instead. I brought this up at Property talk:P5826 a week ago, to no response. (If this is kept, I will request that "dissenting opinion by", "concurring opinion by", etc. be created, so that they can be modeled the same way; please ping me when this is closed.) —DannyS712 (talk) 03:25, 13 August 2019 (UTC)

  Comment Isn't has part (P527) the reverse of part of (P361)? Nomen ad hoc (talk) 07:16, 13 August 2019 (UTC).
  Keep A dedicated property seems justified. And connected properties for dissenting and concurring opinions too. Nomen ad hoc (talk) 14:37, 13 August 2019 (UTC).
I agree with Nomen ad hoc that has part (P527) doesn't seem to be appropriate here. has parts of the class (P2670) seems to be nearer to the intended meaning but seems to be a bit complex for this usecase. Given that there are lots of legal cases I vote   Keep and endorse creating additional properties for "dissenting opinion by" and "concurring opinion by". ChristianKl❫ 13:54, 13 August 2019 (UTC)
  Keep per both voters. Enivak (talk) 10:42, 27 August 2019 (UTC)
  • I disagree both with using this property and with the proposed solution of having has part (P527) point to a generic class with a author (P50) qualifier. We have thousands of pages on Wikisource associated with majority opinions of court cases. These pages should be linked to Wikidata items, given P50 statements, and linked to the cases. --Yair rand (talk) 23:23, 11 November 2019 (UTC)


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

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

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

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

  •   Delete until IDs aren't persistent. Nomen ad hoc (talk) 18:17, 2 September 2019 (UTC).
  • If this was just another property for an online version of an old encyclopedia (like various others we have), there wouldn't be a reason to delete it. Unfortunately, there are several problems surrounding this particular site. One is the lack of stability of the site/IDs, another is the user/person behind it. The slugs/IDs used by the sites are not consistent and prone to change at any given moment, with no persistent ID or redirects from old values available. The other problem is the person who has been working on adding these IDs. Who AFAIK has been globally banned from all Wikimedida projects and still continues editing via IPs and sock puppets. It also seems this user is the person (or one of the persons) maintaining the website in question - so it would seem he's the one who keeps changing the entries' slugs/"IDs" himself and causing the problems on Wikidata when editors here try to come up with solutions to these changes. And has even been posting rants about Wikidata and Wikidata/Wikipedia users on that website. Overall, while the property might have some - albeit small - value, I have my doubts that all the constant changes, arguments, rants, blocks of IPs and sock puppets, etc. behind the scenes on Wikidata and Wikipedia are worth the hassle of keeping it around. --Kam Solusar (talk) 17:44, 15 September 2019 (UTC)
  • @Edgars2007: who proposed the property in good faith. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 30 October 2019 (UTC)


commander of (P598): (delete | history | links | entity usage | logs | discussion)

Seems redundant with position held (P39). Wouldn't P39 commanding officer (Q11247470) statements (with qualifier of (P642)) suffice? —Nomen ad hoc (talk) 09:09, 7 September 2019 (UTC)

  •   Keep It's a summary of all the militar units commanded. Now is in use a ca:template:infotaula persona. The P39 shows the different position, but in military use to show only high ranks position, not one per one of its commanded units. Amadalvarez (talk) 11:38, 4 October 2019 (UTC)


Bursa Malaysia stock code (P7288): (delete | history | links | entity usage | logs | discussion)

Discussion still open --- Jura 18:42, 8 September 2019 (UTC)

  •   Keep as there was a consensus to create − Pintoch (talk) 06:00, 22 October 2019 (UTC)


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

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

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


Global Species ID (P6433): (delete | history | links | entity usage | logs | discussion)

All links yield "global species has been shutdown" —Lymantria (talk) 08:36, 11 September 2019 (UTC)


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

@Giovanni Alfredo Garciliano Diaz, ChristianKl: do you have any opinion? To me, I do not see why number is not the correct datatype. Do you mean it should be external identifier? If so, to which link? Or string? Or something else? Pamputt (talk) 06:19, 16 September 2019 (UTC)
We don't have a number datatype and the quantity type we do has it's +/- interval by default.
I don't have strong feelings but would be okay with migrating it to catalog code (P528). ChristianKl❫ 07:50, 16 September 2019 (UTC)
When I proposed P3917, I ignored many things about how Wikidata work. Now, I agree with migrating it to catalog code (P528). --Tinker Bell 02:21, 20 September 2019 (UTC)


digital representation of (P6243): (delete | history | links | entity usage | logs | discussion)

As far as I can tell, this property duplicates depicts (P180) within the context of Structured Data on Commons for the subtopic of digital reproductions. Despite what the property proposal said, commons:Template:Artwork should use depicts (P180)=Mona Lisa (Q12418) to replace the "wikidata=" parameter, and then fetch the depicts (P180) values from Mona Lisa (Q12418) to explain what the artwork depicts. It may need to use the 'preferred' rank to do that in cases where the image also depicts other things, such as the frame of the artwock, but that's technically straightforward to do. Note that I previously nominated this for deletion, which I withdrew as I thought it was only in use for copyright purposes (i.e., to auto-include commons:Template:PD-art on Commons), but further discussion seems to indicate that this is not the case. Thanks. Mike Peel (talk) 19:35, 20 September 2019 (UTC) Multichill (talk) 11:28, 8 August 2014 (UTC), focus on the Netherlands Husky (talk) 11:38, 8 August 2014 (UTC) - Cool, i'd like to focus on building tools to visualise progress. Spinster (talk) 07:00, 9 August 2014 (UTC) Happy to help with manual finetuning that can't be done by bots, and anything else on the 'soft/wet' side of this project. I'm dreaming of complete artists' oeuvres on Wikidata! Rich Farmbrough (talk) Time to learn2Wikidata Jheald (talk) 12:33, 17 August 2014 (UTC) Kippelboy (talk) 07:01, 21 August 2014 (UTC) (Focus on Catalan paintings (subdivision of Spain) Mushroom (talk) 12:27, 21 August 2014 (UTC) Jane023 (talk) 09:11, 3 October 2014 (UTC) work on Dutch 17th-century paintings and landscapes of Haarlem; Most recently, the sum of all "attributed" paintings by Frans Hals, which is nearly done Missvain (talk) 18:51, 18 October 2014 (UTC) (talk) 13:27, 15 November 2014 (UTC) Zolo (talk) 14:57, 23 November 2014 (UTC) Beat Estermann (talk) 10:33, 3 December 2014 (UTC) (Focus on Swiss heritage institutions) Vladimir Alexiev (talk) 15:07, 23 January 2015 (UTC) KRLS (talk) 11:26, 11 February 2015 (UTC) (Focus on Catalan area museums) DivadH (talk) 11:35, 1 March 2015 (UTC) ,happy to help out with any questions in regards to the Europeana API, how to best query it, and/or our metadata Xcia0069 (talk) 11:49, 8 March 2015 (UTC), Work on data related to Gianlorenzo Bernini and Artemisia Gentileschi. Work at Europeana too ! Susannaanas (talk) 07:29, 9 March 2015 (UTC) Wittylama (talk) 17:29, 20 March 2015 (UTC) Fabrice Florin (talk) 02:35, 26 June 2015 (UTC) I can help in California later this year. Vaughn88 (talk) 15:58, 15 July 2015 (UTC) I can help! Raymond Ellis (talk) 19:31, 17 August 2015 (UTC) Hsarrazin (talk) 14:11, 29 August 2015 (UTC) - will give a hand with Creators and AC :) louis-garden (talk) 14:21, 31 August 2015 (UTC) for italian paintings (XIIe-XVIIe) Olivier (talk) 21:46, 8 September 2015 (UTC) Kopiersperre (talk) 11:33, 20 November 2015 (UTC) ProtoplasmaKid (talk) 03:49, 23 February 2016 (UTC) Micru (talk) 11:19, 29 February 2016 (UTC) Stuart Prior (WMUK) (talk) 11:04, 28 April 2016 (UTC) Hannolans (talk) 23:14, 22 October 2016 (UTC) Geraki (talk) 09:52, 24 October 2016 (UTC) (Focus on Greece) PatHadley (talk) 12:16, 3 January 2017 (UTC) MartinPoulter (talk) 14:54, 11 January 2017 (UTC) Working to get data from the University of Oxford (Q34433) and its component institutions shared on Wikidata. Pablísima (talk) 18:07, 8 February 2017 (UTC) Carl Ha (talk) 22:10, 9 February 2017 (UTC) Marsupium (talk) 19:44, 22 May 2017 (UTC) Mauricio V. Genta (talk) 16:15, 26 June 2017 (UTC) Shani Evenstein (talk) 10:26, 26 July 2017 (UTC) Nasty nas (talk) 07:45, 24 August 2017 (UTC) Bodhisattwa (talk) 14:28, 28 October 2017 (UTC) Joalpe (talk) 18:39, 9 November 2017 (UTC) Fuzheado (talk) 18:33, 30 November 2017 (UTC) Sarasays (talk) 20:00, 1 December 2017 (UTC) Thierry Caro (talk) 07:30, 9 December 2017 (UTC) John Samuel 18:29, 21 December 2017 (UTC) Jklamo (talk) 12:06, 31 December 2017 (UTC) Reosarevok (talk) 10:28, 15 February 2018 (UTC), focus on Estonia Ambrosia10 (talk) 19:48, 19 February 2018 (UTC) Subsublibrary (talk) 03:17, 22 February 2018 (UTC) Martingggg (talk) 07:00, 22 February 2018 (UTC), focus on Argentine and Hispanic America Kruusamägi (talk) 16:42, 13 March 2018 (UTC), focus on Estonia SIryn (talk) 10:36, 9 June 2018 (UTC) Jarekt (talk) 13:49, 7 September 2018 (UTC), focus on moving metadata from Commons to Wikidata Walkuraxx (talk) 10:00, 30 November 2018 (UTC) Omotecho (talk) 22:11, 21 January 2019 (UTC), focus on Japan GualdimG (talk) 16:19, 19 February 2019 (UTC) Léna (talk) 08:57, 4 April 2019 (UTC) Yann (talk) 09:53, 9 June 2019 (UTC) Paul Cézanne (Q35548) for a start... Abbe98 (talk) 19:25, 18 June 2019 (UTC) Daniel Mietchen (talk) 15:36, 23 July 2019 (UTC) Have been doing small things here and there — especially improving items around what is depicted on paintings — so might as well sign up. Jbandrews (talk) 02:14, 16 October 2019 (UTC) Product Manager at the Art Institute of Chicago. Amadalvarez (talk) 06:19, 19 October 2019 (UTC) Meresquared (talk) 14:51, 22 October 2019 (UTC) I'm interested in adding depiction descriptions to paintings, and improving data around women and POC.   Notified participants of WikiProject sum of all paintings Mike Peel (talk) 19:39, 20 September 2019 (UTC)
Pinging editors that participated in the property proposal. @Jarekt, ArthurPSmith, Multichill, Jheald, Jura1, Spinster: Mike Peel (talk) 19:42, 20 September 2019 (UTC) Pinging editors that commented on the previous property deletion discussion, @Jdforrester, Emijrp, Jklamo, Jane023:, and those at Property talk:P6243, @Dominic, Tacsipacsi, Hannolans, Lokal Profil:, plus @SandraF (WMF), Keegan (WMF): from SDC. Thanks. Mike Peel (talk) 19:47, 20 September 2019 (UTC)

  Delete Convinced by Mike. Nomen ad hoc (talk) 19:38, 20 September 2019 (UTC).
  Comment I'm feeling very conflicted about this one. After giving it some thought, I'm much more in favor of 'clean' and separate copyright modeling as suggested by User:Lokal Profil on the property's talk page, mainly because that solution provides much more consistency in copyright modeling and provides more clear information to people unfamiliar with Wikimedia Commons policies (i.e. the majority of people out there). That said, faithful two-dimensional digital representations of two-dimensional documents and artworks (aka 'digital surrogates') are a special category of files, that would benefit from being clearly distinguishable as such. I'd be interested to hear input from experts familiar with this issue in GLAM data modeling whether a separate property indeed would make sense. I'll ask around and will post updates here when I succeed in receiving some feedback. Spinster 💬 20:07, 20 September 2019 (UTC)
Agree that we should not use this property for copyright hamndling. Files should have their own copyright status handling. What we want to know of a file in commons is if there is a artistic influence of the photographer and thus a claim for copyright or just a reproduction of an existing work (either PD or CC). As this evaluation differs per legislation and has several edge cases we should nog use this property for copyright related issues. Wha we would like to know of a file is that it is a 1:1 of the seizes of the artwork --Hannolans (talk) 09:03, 21 September 2019 (UTC)
  Keep When a cultural institution scans a historical document to make an exact digital reproduction of it, this relationship between the object and the media file is different in nature from what is described when anything displayed in the image can be added in a "depicts" statement. Absent further explanation, I don't understand the suggestion that a faithful digital representation is the same as a depiction. Dominic (talk) 20:02, 20 September 2019 (UTC)
And what to do if I make a picture of a work? And if I brighten the work? Or is this property for scans created following official ISO standards for scanning museum objects? But can't we derive that from the EXIF data? --Hannolans (talk) 20:13, 20 September 2019 (UTC)
I agree those questions should have answers. I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution. Dominic (talk) 20:20, 20 September 2019 (UTC)
The scope should definetely change to keep this porperty. --Hannolans (talk) 11:24, 22 September 2019 (UTC)
@Dominic: Scans of documents are a different case, which this property as-is doesn't seem to address. Thanks. Mike Peel (talk) 20:34, 20 September 2019 (UTC)
If you want to replace "document" for "artwork" in my first comment, I am not sure how that changes the point. A depiction is not the same as a digitization. Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have. Dominic (talk) 21:03, 20 September 2019 (UTC)
@Dominic: Can you give an example, please? The ones in the property proposal and documentation don't match this use case. Thanks. Mike Peel (talk) 21:10, 20 September 2019 (UTC)
@Mike Peel: I am pointing out that there is a substantive semantic difference between a "faithful digitized representation" of the Mona Lisa and a work that in some way "depicts" the Mona Lisa. I think the burden is supposed to be on you to make an argument. From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place. Dominic (talk) 21:17, 20 September 2019 (UTC)
@Dominic: Can you explain how the current property makes that difference, please? I can't see it myself, beyond the ranking of the depicts statement. I am "confused about the purpose of the property in the first place"! Mike Peel (talk) 21:51, 20 September 2019 (UTC)
The words do not mean the same thing. What are you even asking for here? Dominic (talk) 21:58, 20 September 2019 (UTC)
@Dominic: The words and the usage don't match. I'm asking for this property to either be deleted, or for its usage to be made significantly clearer. Thanks. Mike Peel (talk) 22:09, 20 September 2019 (UTC)
  Comment My understanding has been that the difference between depicts (P180) and digital representation of (P6243) is something like:

--Stevenliuyi (talk) 23:27, 20 September 2019 (UTC)

Broadly agree. IMO the image on the right of "Starry Night", including frame, and taken from a slightly oblique angle, should not have a digital representation of (P6243) statement, but should have depicts (P180) = The Starry Night (Q45585) at preferred level.
In the case of the Mona Lisa, only the Wikidata item Mona Lisa (Q12418) should have depicts (P180) = person depicted in Mona Lisa (Q11879536). IMO, the fact should not be in the structured data for the image itself, the fact should be inherited from Wikidata if the image has a digital representation of (P6243) or depicts (P180) statement pointing to Q12418. (This is the "depicts of depicts" functionality, which should be arriving for display and for search some time soon).
It's a slightly open question for me, how much "retouching" of an image should be allowable, and it still to be appropriate to use P6243. For example, an image of the Mona Lisa with colours digitally adjusted to how it might have looked at the time of Leonardo IMO probably should not carry a digital representation of (P6243) statement -- but it would be useful to know what others think on this. Jheald (talk) 17:19, 21 September 2019 (UTC)
  Comment My understanding is that P180 must have an associated Wikidata item that represents the thing that depicts. On Commons, use of P180 is only possible because other Wikidata items than the Commons file have depicted the thing selected. In this case, there may not be any associated Wikidata item except for the thing this file is a digital representation of. Because of the overwhelming majority of such cases on Commons I find this property highly useful. It gives Commons people at least an indication that the file shows the whole thing described by the associated Wikidata item, albeit in some old sepia print. This is useful in the case of photos of e.g. old paintings before theft,loss by fire, restoration etc, and e.g. buildings before expansion or demolition. These properties are by no means related in my view. Jane023 (talk) 06:19, 21 September 2019 (UTC)
But then we should rename this porperty. 'digital representation' could also mean the best colors etc, but that is not the case. Instead we could use a definition that states that the file covers exactly the dimensions of the artwork ('the whole thing described by the associated Wikidata item'). It would also mean that it is not only for 2d works, but also for songs and movies that covers exactly the whole movie and the whole song, and 3D files of monuments, that covers exactly that monument. --Hannolans (talk) 09:08, 21 September 2019 (UTC)
Confused as that discussion about is about 'When to use the PD-scan tag' is about the 'level of originality'. We should not use this property for evaluation of 'originality' as we now have Property:P6216 both for the file in commons as for depicts (P180) on Wikidata with qualifiers about the copyright evaluation. We could use this property when the dimensional overlap between the image and the object is 1:1. I think we have this discussion because this property is currently meant for copyright evalaution as well as 'is a scan of' --Hannolans (talk) 09:18, 21 September 2019 (UTC)
  •   Comment This is probably the first Commons-only property. As such, I think it should ultimately be determined on Commons if and how it should be used.
    Still, the use should somewhat be consistent with the label and initial description of the property here on Wikidata.
    If use should be limit to "copyright status" or "PD-copyright status" of the 2D artwork photographed or scanned, it should be labelled differently, meaning a property with a different label should be created and this deleted.
    Occasionally creating items for c:Category:Paintings_without_Wikidata_item, I think use of such items goes beyond that. Otherwise, I'd probably not bother creating them. Not really convinced that including that item in P180 would be helpful, but it seems that currently much of Commons modeling is limited to that. --- Jura 09:39, 21 September 2019 (UTC)
Kaart Figuratief Delft Tweede Staat
@Hannolans: It's a good question. A related one is: what sort of items should one be creating on Wikidata? In particular, if one wants to create an item on Wikidata corresponding to a map that one has a digitisation of, should one be creating an item that is instance of (P31) map edition (Q56753859) or one that is instance of (P31) individual copy of a map (Q63872468) ? I flip-flop backwards and forwards a bit on this question; but (unless there is important provenance information to record), my yardstick would be whether there are likely to be visible differences between different exemplars of the edition. If eg a particular map has hand-colouring, it may make sense to have its own item (and then for the image to be digital representation of (P6243) of that). But if the map is simply as printed, with nothing to apparently difference it from any other copy, then it may make sense to make a Wikidata item for the whole map edition (Q56753859) (and in such a case I think it would still make sense to use P6243, to indicate that the image is a representative digital representation of the whole map edition). Where I don't think one can use P6243 is if the map has hand-colouring that is specific to the individual copy, rather than the edition. Then I think the image is presenting something more that just a representative of the edition, and it probably makes sense to create a Wikidata item for the individual object (which is always a safe fall-back). Also, a particular identifiable state of a map or engraving should usually have its own Wikidata item, as it will correspond to an edition in its own right. A marginal case is where a map from an edition might have acquired particular stains, or perhaps a visible library ownership stamp. In such a case I believe it would be reasonable to regard such marks as not of particular consequence, and it would be acceptable to describe the image as just a generic representation of the edition; but on the other hand I wouldn't object or nominate the item for deletion, if somebody created a distinct Wikidata item for it. But it would be useful to know whether this conforms to what other people think and/or are doing in this area. Jheald (talk) 16:57, 21 September 2019 (UTC)
Every print in each museum is very unique. For digital representations as meant in this property I would be oppose to use this proprty for the concept and only use depicts. At the other hand, we could also use this property for manifestations of a concept. See the examples below --Hannolans (talk) 11:24, 22 September 2019 (UTC)
  •   Keep Because I suspect people are going to want to search for files that are digital representations of (classes of) artworks, rather than just files depicting them; having this property will make such searches far more efficient -- I suspect that just relying on depicts and then filtering would be likely to make corresponding SPARQL queries time out.
This property has a very specific meaning: it means that an image shows the whole of an 2D art object, all of it, faithfully, directly square-on, and nothing but the 2D art object (ie no frame, no adjacent wall, no surrounding gallery, no other work, etc). It's quite a common situation, encompassing eg works covered by the {{PD-Art}} tag (cf c:Commons:When_to_use_the_PD-Art_tag), with approaching 1.4 million transclusions; though of course that's only about 3% of Commons images. It is useful to have this property, to designate that an image has this nature.
I do not regard the property as a substitute for systematic standard copyright statements -- those should be present too. But in my view the fact that the image is a direct faithful representation of a particular 2d artwork is worth stating in its own right. It is also worth pointing out that the statement may apply in a few cases where {{PD-Art}} does not apply -- for example a faithful representation of an artwork that is still in copyright, but which has been released by the creator. P6243 is appropriate in this case too.
I am neutral as to whether an image should also have a parallel P180 statement. Ideally when "depicts of depicts" is implemented for search and display etc, statements would be inheritable via P6243 as well. That would make any parallel P180 statement redundant, but mostly harmless.
So, overall, keep -- to make it easier to extract images which are faithful reproductions; and also to facilitate the workflow for such images, and to facilitate automatic checking (eg constraint checking) of statements on them (eg copyright statements) against data from the indicated wikidata item. Jheald (talk) 16:32, 21 September 2019 (UTC)
@Jheald: Would it be possible to do a query for cases where there is only one depicts statement? E.g., to find cases where depicts (P180)=Mona Lisa (Q12418) that don't also have other depicts statements like depicts (P180)=picture frame (Q860792). I really don't like the data duplication inherent in this property (similar to P373!), nor the fact that it's somehow separate from P180. Another option might be a qualifier on P180 to say "is a faithful reproduction", which might also be easy to query? Thanks. Mike Peel (talk) 10:57, 28 September 2019 (UTC)
@Mike Peel: Is it not related to the copyrights of the depicted artworks? Christian Ferrer (talk) 20:48, 28 September 2019 (UTC)
@Christian Ferrer: That's what I thought, but see what I wrote in the deletion nomination above. Thanks. Mike Peel (talk) 07:31, 29 September 2019 (UTC)
  •   Keep I dont see, any argument in Mike Peel's proposal, its just about what he think. If I have a look on the description and proposals for depicts (P180) and digital representation of (P6243), I can see clear difference. Lets explain it by the example. You have a photograph or scan of a manuscript. What it depicts? It depicts laters/handscript/illustration. What it is a representation of? It is a representation of a manuscript/book, which may have its item on Wikidata.--Juandev (talk) 20:30, 21 September 2019 (UTC)
If you have a scan of a book page, we can't say it is a digital representstion of that book. Or do you propose to create an item for every book page? --Hannolans (talk) 11:26, 22 September 2019 (UTC)
No need to talk about hole books. We can stay with one paper maps, handscripts etc. --Juandev (talk) 10:28, 23 September 2019 (UTC)
Many artworks are printed in a book and heritage institutions have a lot of scanned books. So what is the situation for prints and books? Using depicts (P180), based on (P144) or digital representation of (P6243). Use digital representation of (P6243) if it is a PDF of the whole book? And whisch should mention the specific book, and which to the concept of the book? --Hannolans (talk) 10:40, 23 September 2019 (UTC)
Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one. Juandev (talk) 21:51, 23 September 2019 (UTC)
  Delete if the scope of this property stays unclear. If it used for copyright I am against it, as we have copyright status and the scope is now 2D whereas the new upcoming copyright directive of the EU will also include 3D files and 2D representations of 3D works that can't have copyright by the photograper. The property will work for paintings, but for logos, prints, books, coins, stamps, plates - all artworks that have multiple items, it is in the current definition unclear how to deal with it, if it is about the concept or the individual copy. Heritage institutions and professionals would expect it is linking ot the individual copy of that work as only then it is the digital reprensentation. And if it is about the concept, can we say a building plan drawing is a digital representation of a building? A weapon is a digital representation of a Coat of arms? And how about movies, digital born material? Is a music score a digital representation of that music? This property is created for old paintings but not well defined for other works of art. --Hannolans (talk) 11:41, 22 September 2019 (UTC)
@Hannolans: The EU directive only says there should be no copyright if there is no original creativity by the photographer. Following the U.S. jurisprudence, expect all photographs of 3D items to pass that creativity threshold. Also expect the mother of all legal battles as to under what circumstances art repro photographs of 2D works may embody sufficient creativity. I think it's a 100% certainty that this will be fought very hard by the photo agencies, both at the legislative drafting stages and in the courts, I would expect all the way to the CJEU. And never bet on the outcome of a court case, because they very seldom go the way you think they are going to.
This property was originally intended for faithful images of 2D artworks. That is how it should remain. It does a clear and useful job in that respect. Extending it and blurring its purpose will make it less useful, because query returns for uses of it will become less sharply defined and therefore less valuable. Jheald (talk) 12:34, 22 September 2019 (UTC)
Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have based on (P144) to declare if a file is a copy and copyright status (P6216) to declare both the copyright for the artwork as well as the photograph or scan. --Hannolans (talk) 17:53, 22 September 2019 (UTC)
@Hannolans: The relevance of digital representation of (P6243) for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright. P6243 is not a substitute nor a replacement for specific copyright statements on the image. But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata. Jheald (talk) 21:56, 23 September 2019 (UTC)
The copyright status is of a scan of a 2D work is based on a US case (Bridgeman Art Library v. Corel Corp. (Q1400715)) and not a worldwide ruling. In other countries it can be copyrighte for example in Germany. It was extended to 3d-works by Meshwerks, Inc. v. Toyota Motor Sales U.S.A., Inc. (Q19040164) and limited to exact representations only by Schiffer Publishing v. Chronicle Books (Q68351935). On Commons we voted to keep representations even when they are copyrighted in the source country. Using this property for a copyright status is therefore problematic. --Hannolans (talk) 14:20, 9 November 2019 (UTC)
  •   Keep But remove copyright from it's scope and broaden to go beyond just artworks. I'd also argue to broaden it to go beyond 2D. If I upload a 3D scan of an object then that file is "faithful" digital representation of the object (at least once Commons supports textures).
Will there be lots of edge cases? Of course! But if we stop focusing on those I believe that the distinction between depicts (P180) "the item is somewhere in this image/file" and subject lexeme (P6254) "the whole of this item (and nothing else) is in this image/file" is pretty clear. Every single image/file sharing a digital representation of (P6243) target will be extremely similar (close to identical) wheres there is no such guaranteed relation between images/files sharing a depicts (P180) target. /Lokal_Profil 21:04, 23 September 2019 (UTC)
  •   Keep As I have now outlined multiple times. Repeatedly nominating this for deletion and failing to engage with everyone else is pretty disrespectful. Please stop. James F. (talk) 14:48, 26 September 2019 (UTC)
    @Jdforrester: It seems unfair to say that I'm "failing to engage" - although perhaps I am failing to understand. I don't mean to be disrespectful at all, I want to see this murky situation made clearer at least. Thanks. Mike Peel (talk) 10:57, 28 September 2019 (UTC)
  • Very strong   Keep, after giving it more thought, and after meeting and brainstorming with Andrea Wallace who has researched digital surrogates in the cultural sector. Some thoughts and input below:
  • Faithful digital representations of creative works are definitely conceptually different from other depictions of artworks. Also having looked at GLAM files a lot over the years, I think a clear distinction between depicts (P180) and digital representation of (P6243) is a good way to address this.
  • depicts (P180) and digital representation of (P6243) indeed have structurally different repercussions, especially around authorship. A basic way in which digital surrogates are different: they are meant to be faithful 'surrogates' of a work in digital form, and there is arguably no 'creative act' involved in their creation (outside of 'sweat of the brow' and the expertise needed for doing a quality digitization). Hence authorship of digital surrogates needs to be described/displayed differently.
I accidentally found an illustrative example of this when looking at the Commons Tab Chrome browser extension by Slaporte. Compare these two cases:
My point with this example is that, in order to provide more refined and correct attribution data to be used by tool builders, the distinction certainly makes sense.
  • I would strongly advise to use the property for all faithful digital representations of creative works, including photographs, maps, but also potentially 3D scans, digitizations of films and music recordings, etc. Also use for faithful digital representations of works that are not PD yet but have been released under a Creative Commons or other free license. So no 1:1 replication of the PD-Art template on Wikimedia Commons. I recommend to use digital representation of (P6243) for all digital surrogates, if clearly intended to be 'precise and exact digitizations' of a document and creative work. Examples:
  • I personally advise to introduce even more clarity by making digital representation of (P6243) a subproperty of depicts (P180) and hence only using one of either depicts (P180) or digital representation of (P6243), so not both at the same time pointing to the same work (sorry @Multichill: this will involve undoing some of your existing edits; I'll be happy to help clean it up because it's for a good cause!). It will mean some extra complexity in terms of indexing for search, and in terms of building Lua-powered templates, but it is to the long-term benefit of much more consistency and clarity for partners and re-users.
Cheers, Spinster 💬 16:20, 31 October 2019 (UTC)
  • I 100% support Spinster's analysis (have already !voted keep above). Jheald (talk) 18:38, 31 October 2019 (UTC)
@Spinster: This is an interesting analysis, thanks for posting it. I'm still mulling it over, but a first thought is that you're making a distinction on the copyright side of things. Couldn't that be solved using copyright holder (P3931) vs. author (P50), or otherwise improving the attribution aspect of the file? A second thought is that perhaps instance of (P31)=digital representation (Q42396623) is an alternative way to do this (sorry James!!). As you know, I'm playing with commons:Template:Structured Data at the moment - that template doesn't use this property, and it already auto-invokes the Artwork template for paintings (the original purpose of this property), I'll continue playing with it to see how well it can cope with these examples too. Thanks. Mike Peel (talk) 19:19, 31 October 2019 (UTC)
@Mike Peel: I have indeed also mulled over the instance of (P31)=digital representation (Q42396623) scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than depicts (P180). I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed. So I stick with my insistence on keeping digital representation of (P6243) and making it a subproperty of depicts (P180). Cheers! Spinster 💬 08:44, 1 November 2019 (UTC)
+1 to have copyright modelled separately. I am also wondering if we with qualifiers can explain why and how it is a digital representation. For example the scan technology, colors and lighting used. And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work? For example Reproduction of a painting of Paul Klee. Is a black and white version a representation and if so how should we qualify that? --Hannolans (talk) 14:20, 9 November 2019 (UTC)



attributed to (P1773): (delete | history | links | entity usage | logs | discussion)

Should not be used per Wikidata talk:WikiProject Visual arts#Changing the way we handle attributed artworks. GZWDer (talk) 21:59, 5 October 2019 (UTC)

@Jheald, Jane023, PKM, Marsupium, Multichill: Do we have an agreed deprecation plan? I can try to adapt my qualifier migrator for this, but we need to agree on what qualifier-target combination to tag these statements with. Deryck Chan (talk) 19:11, 11 November 2019 (UTC)
There are some unusual usages - see Easter sonata (Q30594711) where “attributed to” is used to mean “credited to” or “as by” for whose name was given as the composer at a performance. I think we need to manually tweak some of these outliers. - PKM (talk) 19:31, 11 November 2019 (UTC)
Nevertheless, I think the "base case" migration might be:
Does that sound right? - PKM (talk) 19:54, 11 November 2019 (UTC)
Yes, sounds right to me! --Marsupium (talk) 20:07, 11 November 2019 (UTC)
Yes this soounds right to me too. Jane023 (talk) 20:09, 11 November 2019 (UTC)
  • Perhaps we should change the English label to "attributed to (DEPRECATED)" and accordingly for other languages? Perhaps that can reduce usage of the property. Or is there any reason not to do that? --Marsupium (talk) 23:28, 11 November 2019 (UTC)
    • Yes, a good first step. I suppose we should formally vote to delete the property here. - PKM (talk) 03:17, 12 November 2019 (UTC)
  •   Delete - deprecate, migrate, and delete. - PKM (talk) 03:17, 12 November 2019 (UTC)

P (P)Edit

iFixit repairability score (P7478)Edit

iFixit repairability score (P7478): (delete | history | links | entity usage | logs | discussion)

The property was created in a premature state where it didn't even had a property description. While the property description might be fixable, the data type isn't and there's no case made in the property discussion why the property should be created as a string property and not an item property the way properties like Filmiroda rating (P2747), ClassInd rating (P3216) or CERO rating (P853) are designed. —ChristianKl❫ 12:18, 30 October 2019 (UTC)

  •   Delete per above. --Tinker Bell 22:02, 1 November 2019 (UTC)
  • @ChristianKl: Ok for the deletion, but why a stringa datatype and not a numeric value ? Snipre (talk) 12:32, 4 November 2019 (UTC)
I didn't propose the string datatype. I think item makes more sense as it allows us to store information about what a given rating means (and which we do in other rating properties).ChristianKl❫ 07:57, 5 November 2019 (UTC)