Wikidata:Properties for deletion/Archive/2021

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Property:P8960

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. No consensus for deletion. Multichill (talk) 18:38, 15 February 2021 (UTC)

Kunsthistorisches Museum Wien ID (P8960): (delete | history | links | entity usage | logs | discussion)

Discussion still ongoing --- Jura 11:04, 14 December 2020 (UTC)

 Keep as no one opposed the creation. The discussion can go on, e.g. on the talk page. Nomen ad hoc (talk) 12:41, 14 December 2020 (UTC).
 Keep Disruptive nominaton. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:13, 15 December 2020 (UTC)
 Keep. For the same reasons. Thierry Caro (talk) 15:54, 17 December 2020 (UTC)
  • We should have the information available before creating the property, especially as the discussion about that aspect was still ongoing. It seems that even after three days, the proposer wasn't able to provide it. There are just too many case on Wikidata:Bot requests where such items are missing. Anyways, seems that next time, one needs to oppose creation until the necessary is provided. --- Jura 09:24, 18 December 2020 (UTC)
What exactly seems to be the problem? Labels? --Emu (talk) 11:08, 20 December 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

father (P22)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. No consensus for deletion. Multichill (talk) 18:38, 15 February 2021 (UTC)

father (P22): (delete | history | links | entity usage | logs | discussion)

Redundant with child P40

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

mother (P25)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. No consensus for deletion. Multichill (talk) 18:34, 15 February 2021 (UTC)

mother (P25): (delete | history | links | entity usage | logs | discussion)

Redundant with child P40 The father/mother property seems to be duplicate with the child property, especially when using qualifiers, it creates lots of redundancy —Worldm99 (talk) 01:59, 21 December 2020 (UTC)

by this argument they are all redundant with "relative" plus qualifiers. BrokenSegue (talk) 02:31, 21 December 2020 (UTC)
Well relative is not used for immediate family, so no. Worldm99 (talk) 07:44, 22 December 2020 (UTC)
 Keep Given that Lua can't handle inverse property relationships yet, we need some of them and this seems a clearly useful case. Once the Lua issue is fixed then I'd definitely support cleaning up as many Wikidata inverse properties as we can. ArthurPSmith (talk) 18:20, 23 December 2020 (UTC)
 Keep Being a mother is one of the semantic primitives and the ability to query it easily is useful. ChristianKl ❪✉❫ 11:14, 26 December 2020 (UTC)
 Keep Note in SPARQL it is easy to query male-line all descendents via ?item wdt:P22* wd:Q### and it is impossible with only P40.--GZWDer (talk) 17:27, 29 December 2020 (UTC)
    • Star is impossible, but in a real world applications with some level of sanity you won't be able to fetch all descendants in a tree (I say this as an author of Wikidata Graph Builder: just try to load what you have suggested without limits and your browser tab will probably die or fail due to timeout). And as for limited iteration, is is still possible with .... UNION ... UNION {wd:Q### wdt:P40 [wdt:P21 wd:Q6581097; wdt:P40 [wdt:P21 wd:Q6581097; wdt:P40 ?item] ] }. Not pretty, but who cares, especially for such a specific usecase. --Lockal (talk) 16:23, 3 January 2021 (UTC)
Replace with parent (P8810) and  Delete. Reason is that father/mother does not match any existing vocab -> Wikidata should not invent bicycles and use "parent" as W3C/schema.org suggest. Do not forget: just recently we had brother, sister, stepfather, stepmother and after Wikidata:Requests for comment/Make family member properties gender neutral these properties were merged. I don't see a reason why we can merge stepfather+stepmother and can not merge mother/father. --Lockal (talk) 16:23, 3 January 2021 (UTC)
 Delete and replace with parent (P8810) and eventually delete that one once inverse properties are no longer needed. Lockal’s argument sticks: Even Agrelon just has parent. Most (albeit not all) arguments in the 2016 discussion are ideological/political in nature. --Emu (talk) 18:30, 4 January 2021 (UTC)
I could be convinced of this (especially if we had a qualifier for mother/father in the cases where it really matters). Especially with trans people it's unclear what to label a trans-male who gave birth (father v. mother is mainly useful to distinguish who gave birth but at least in English we lack the right words). BrokenSegue (talk) 19:10, 4 January 2021 (UTC)
kinship to subject (P1039) springs to mind, it’s already used as Lizzie Saltzman (Q98936012)mother (P25)Caroline Forbes (Q98791696)kinship to subject (P1039)surrogate mother (Q16547118). It’s conceivable (no pun intended) to create items like person who gave birth, person whose DNA was passed on, etc. if the need should arise. --Emu (talk) 20:32, 4 January 2021 (UTC)
  •  Keep Per GZWDer. Extracting the full patrilineal ancestry of a person (in order) is very much a real-world application. Modifying what GZWDer gave above, this is straightforward with a line like wd:Q### wdt:P22* ?item -- and impossible without P22. Even for queries that don't involve paths, having P22 can be a useful help for efficiency -- a generic 'parent' property would produce a solution set twice as large, taking longer to assemble; then having to do a join with ?item wdt:P21 wd:Q6581097 takes even longer. As somebody who spends a lot of time on queries that go right to the 60s limit, or have to be split into multiple separate runs, so each one can fit inside 60s, any additional inefficiency is something I really don't need. Finally 'father' and 'mother' are straightforward intuitive concepts. I don't see any benefit at all in abolishing them for something less concrete and less precise. So, a strong keep from me. Jheald (talk) 20:50, 24 January 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

PQ104664465 (PQ104664465)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

✓ Deleted, by User:ChristianKl. Creator error. —Eihel (talk) 17:26, 15 February 2021 (UTC)

PQ104664465 (PQ104664465): (delete | history | links | entity usage | logs)

Needs to be created as a property not qualifier —Sardinhapao (talk) 17:57, 4 January 2021 (UTC)

@Sardinhapao: Q104664465 was created by you but it's not a property, it's an item. To request a property please see Wikidata:Property proposal. If you are proposing a property for this, you can leave this item as is and use it for the "subject item" of the property in the proposal template. The statements on this item do need to be fixed though! ArthurPSmith (talk) 19:15, 4 January 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P9091

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. No consensus for deletion. Multichill (talk) 18:36, 15 February 2021 (UTC)

MNBAQ ID (P9091): (delete | history | links | entity usage | logs | discussion)

Premature creation, discussion still ongoing --- Jura 09:18, 27 January 2021 (UTC)

  1.  Keep All the remarks have been addressed. Nomen ad hoc (talk) 09:51, 27 January 2021 (UTC).
  2.  Keep The property is a main statement for 3,685 items, and is the sole external identifier for many of those creative works of cultural and other significance. ― Dcflyer (talk) 01:11, 3 February 2021 (UTC)
  3.  Keep Already used by more that 3000 items. --Fralambert (talk) 17:55, 15 February 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P9099 (P9099)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

✓ Deleted Duplicate Pamputt (talk) 09:48, 24 February 2021 (UTC)

P9099 (P9099): (delete | history | links | entity usage | logs)

Seems to be redundant to Property:P7900 —M2k~dewiki (talk) 10:00, 30 January 2021 (UTC)

  •  Delete It is redundant. For the three examples in the property proposal from P9099 the external link from P7900 doesn't work until now because the release of the monument map is not complete yet. --Looniverse (talk) 23:21, 30 January 2021 (UTC)
If no one opposes, I will delete this property at the end of the week. Pamputt (talk) 12:04, 3 February 2021 (UTC)
@M2k~dewiki, Looniverse: I tried to add Monument Atlas Lower Saxony Objekt-ID (P7900) on Burg Adelebsen (Q1010657) (id: 3523283) and Jewish Cemetery (Q1646878) (id: 32809496) but it leads to an error page. Does it mean they are not valid identifiers for P9099 (P9099) but valid for Monument Atlas Lower Saxony Objekt-ID (P7900)? Pamputt (talk) 06:36, 8 February 2021 (UTC)
The ids are correct, but the database "Denkmalatlas Niedersachsen" is not completely published, so you get an error page. I hope in the near future all monuments will be published. A few days ago I wrote an email to Niedersächsisches Landesamt für Denkmalpflege (Q1988639) and they confirmed that the ids are stable and valid. --Looniverse (talk) 21:33, 8 February 2021 (UTC)
@Looniverse: the related de-WP-user seems to be de:Benutzer:Niedersächsisches Landesamt für Denkmalpflege. --M2k~dewiki (talk) 14:10, 9 February 2021 (UTC)
I've deleted the property and removed it from the items where it was used. Pamputt (talk) 09:48, 24 February 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P9127 (P9127)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

✓ Deleted, by User:Fralambert. Creator error. —Eihel (talk) 17:26, 15 February 2021 (UTC)

P9127 (P9127): (delete | history | links | entity usage | logs)

Accidental duplicate of Naver VIBE artist ID (P7275). See Recent property proposal discussion. —Lectrician1 (talk) 20:51, 7 February 2021 (UTC)

Please @Lectrician1:, put {{Property for deletion}} on Property talk page next time —Eihel (talk) 05:06, 8 February 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Google Play Music artist ID (former scheme) (P4198)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

 Not deleted The existing data is still valid, and there is no consensus for deletion. Hazard-SJ (talk) 07:19, 1 April 2021 (UTC)

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

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

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

Why delete a valid property? The data is potentially useful for joining to other databases or through archives. Keep but deprecate. BrokenSegue (talk) 17:04, 1 September 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

writing language (P6886)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

 Not deleted, clear majority of supporter for keeping this property (15 vs 6). Pamputt (talk) 17:06, 27 April 2021 (UTC)

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

This property is being used by:

s:fr:Modèle:Auteur et s:fr:Modèle:Auteur2

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

This property is being used by:

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

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

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

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

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

WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. -- 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)
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)
 Keep No socalled conflicts here. --111.32.68.231 02:38, 9 May 2020 (UTC)

No edit for over a month, could we close this deletion request? I count 6  Delete and 15  Keep, there seems to be a clear consensus (as well as usefull comments that should be adressed - mainly around redundancy and defintion - but this is independant and can be dealt with later). Cheers, VIGNERON (talk) 08:23, 27 April 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

 Withdrawn —Eihel (talk) 05:49, 23 April 2021 (UTC)

CinemaRX title ID (archived) (P9204)

CinemaRX title ID (archived) (P9204): (delete | history | links | entity usage | logs | discussion)

This property has just been created, but the site has already been out of service for over a month. —Eihel (talk) 01:32, 3 April 2021 (UTC)

property proposal: @Coagulans: —Eihel (talk) 01:35, 3 April 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

 Withdrawn —Eihel (talk) 05:49, 23 April 2021 (UTC)

CinemaRX person ID (archived) (P7483)

CinemaRX person ID (archived) (P7483): (delete | history | links | entity usage | logs | discussion)

Idem P9204 : This property has just been created, but the site has already been out of service for over a month. —Eihel (talk) 01:39, 3 April 2021 (UTC) @Pintoch, Coagulans: —Eihel (talk) 01:41, 3 April 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P3231 (P3231)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

✓ Deleted Consensus for deletion. Pamputt (talk) 16:01, 20 September 2021 (UTC)

P3231 (P3231): (delete | history | links | entity usage | logs)

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

 Delete as replaced. --Liuxinyu970226 (talk) 06:21, 1 September 2020 (UTC)
 Delete but we should first warn the wikis which seem to be using this property @Lockal: Vojtěch Dostál (talk) 14:27, 5 November 2020 (UTC)
Last user (except for usage in comments with {{P}}) is arzwiki. I tried to notify them here, but this page is not very active, unfortunately. --Lockal (talk) 21:19, 5 December 2020 (UTC)
@Lockal: Not getting an immediate response does not mean the page is not active, waiting the nomination result, @علاء: Please advice, Thanks. HitomiAkane (talk) 22:42, 5 December 2020 (UTC)
 Delete per nom. --Jeanjung212 (talk) 01:38, 21 April 2021 (UTC)
 Delete per nom. User:Veracious^(•‿•)^ 08:44, 3 May 2021 (UTC)
@Lockal, Liuxinyu970226, Vojtěch Dostál, HitomiAkane, Veracious: I will delete this property if there is still no oposition. Good for you? Pamputt (talk) 16:36, 28 July 2021 (UTC)
But first, this property should be removed from all items that use it. Could it be done by a bot? Pamputt (talk) 16:38, 28 July 2021 (UTC)
Yes, no oposition. User:Veracious^(•‿•)^ 00:19, 29 July 2021 (UTC)
 Delete HitomiAkane (talk) 17:28, 28 July 2021 (UTC)
 Delete--Nostalgiacn (talk) 04:49, 30 July 2021 (UTC)
@Pamputt:, I completed the cleanup, you can now proceed with deletion. --Lockal (talk) 09:46, 24 August 2021 (UTC)
@Lockal: there are still 4 items that use this property. Pamputt (talk) 21:04, 24 August 2021 (UTC)
@Pamputt: cleaned remaining statements. --Lockal (talk) 14:03, 20 September 2021 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/Archive/2021&oldid=1576014200"