Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to navigation Jump to search

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

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

Properties for deletion may be used:

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

Properties for deletion should not be used:

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

Edit

On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Wikidata:Properties for deletion/Archive/2023/10.

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

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

many of the id's links are archived. e.g. this one. though the link format is broken at the moment. deprecate and mark as obsolete but keep. here's a list of archived entries. BrokenSegue (talk) 16:51, 16 September 2020 (UTC)Reply[reply]
If this property is deleted, the non-numeric identifiers should be transferred to the new property prior to being removed. S.A. Julio (talk) 17:28, 27 October 2020 (UTC)Reply[reply]
Kicker.de player ID (actual scheme) (P8912) has been created. Pamputt (talk) 21:29, 4 December 2020 (UTC)Reply[reply]
I would love to say  Delete, @BrokenSegue: to me the scheme has been largely changed, results the former property can't compatible with the current scheme entirely, probably the core algorithm of this service has re-written. --Liuxinyu970226 (talk) 14:48, 10 December 2020 (UTC)Reply[reply]

Bashkir encyclopedia (Russian version) ID (former scheme) (P4211): (delete | history | links | entity usage | logs | discussion)

In 2019 Bashkin Encyclopedia opened a new websize bashenc.online, opened a new website, where versions in Russian, Bashkir and English were combined under a single code (Property:P9222). When switching to the old version of the site, there is a notification that the Bashkir Encyclopedia has moved to a new address. Therefore, I ask the Wikidata administrators to remove both properties — Timur Rossolov (talk) 17:40, 27 July 2021 (UTC)Reply[reply]

Bashkir encyclopedia (Bashkir version) ID (former scheme) (P4210): (delete | history | links | entity usage | logs | discussion)

In 2019 Bashkin Encyclopedia opened a new websize bashenc.online, opened a new website, where versions in Russian, Bashkir and English were combined under a single code (Property:P9222). When switching to the old version of the site, there is a notification that the Bashkir Encyclopedia has moved to a new address. Therefore, I ask the Wikidata administrators to remove both properties —Timur Rossolov (talk) 17:39, 27 July 2021 (UTC)Reply[reply]

This in addition to the 1057 uses of Bashkir encyclopedia (Russian version) ID (former scheme) (P4211) mentioned above and its https://mix-n-match.toolforge.org/#/catalog/271 catalogue.
Oddly the two aren't kept in synch (maybe identifiers for both properties (or all three) could be added to these.
bashenc.online ID (P9222) is hardly used (45 uses almost a year after creeation) and doesn't have a Mix'n'match catalogue.
I don't think we should delete the properties before the Mix'n'match question is resolved. I don't have much of an opinion of any of the three properties are worth keeping.
@Visem, З. ӘЙЛЕ, Kareyac, Magnus Manske, Epìdosis: @Movses, Avatar6, Russian Rocky, SCIdude, Vesihiisi: @Saint Johann: who worked on either catalogue in MxM.
@putnik, ShinePhantom, Carn, Ghuron: @Wikisaurus, Сидик из ПТУ, Serhio Magpie, Arbnos: who participated in the proposal discussion for the new property. --- Jura 13:40, 8 January 2022 (UTC)Reply[reply]
  • It would be better if someone can change data for new version. --Visem (talk) 17:15, 8 January 2022 (UTC)Reply[reply]
Good afternoon! Bashwiki needs help :) We would like, if one of the programmers could help, to change all the old data to new ones with one click, if this is not possible, notify us so that we do everything manually. In the previous site, the index of articles in Russian and Bashkir was different, in the new site they are the same. We will be grateful for any help: practical or theoretical :) --З. ӘЙЛЕ (talk) 05:47, 20 January 2022 (UTC)Reply[reply]
@З. ӘЙЛЕ: If you can supply the mappings between the old ids and the new ones, you might want to make a request at Wikidata:Bot requests. These can then be added to Wikidata and Mixnmatch. --- Jura 18:34, 11 February 2022 (UTC)Reply[reply]
I recently made a catalogue for a new property on Mix-n-match and exported around 2k IDs from Bashkir (from a template used for encyclopaedia links) and Russian wikipedia (from direct links in the new format). But it still needs to replace somewhere around 800 identifiers. @З. ӘЙЛЕ: I can't think of anything better than manual work on them 1 by 1. So it will probably also require the help of the Bashkir community to sort out the mix-n-match catalogue to then automatically remove the old property. Solidest (talk) 11:05, 12 March 2023 (UTC)Reply[reply]
What is the problem? If it's discountinued project just modify url with archived version to Wayback Archive to property or just update to new url if project was just moved. Don't remove properties just becasuse they are unavailable - use archived version instead. Eurohunter (talk) 16:05, 4 August 2022 (UTC)Reply[reply]
The problem is that most of the archive links don't work, and the old articles have simply been moved to new IDs under new format - so it's better to be replaced rather than kept. Solidest (talk) 11:05, 12 March 2023 (UTC)Reply[reply]

English Vikidia ID (P7829): (delete | history | links | entity usage | logs | discussion)

Several Non-French article ids (P7829, Italian Vikidia ID (P7822), Spanish Vikidia ID (P7827), Basque Vikidia ID (P7832), Armenian Vikidia ID (P7841), German Vikidia ID (P7843), Catalan Vikidia ID (P9123), Russian Vikidia ID (P9124)) can be merged to French Vikidia ID (P7818), like Fandom article ID (P6262). Take Vikidia (Q3051048) as an example, its French Vikidia ID (P7818) is Vikidia, it can also be refered to as en:Vikidia which in fact points to the English Vikidia.

@Tinker Bell, Pintoch, Jura1, Trade, Eihel: What's your idea? —Kethyga (talk) 09:04, 10 April 2022 (UTC)Reply[reply]

Vladimir Alexiev (talk) 11:59, 13 March 2017 (UTC) Jonathan Groß (talk) 17:52, 26 March 2017 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits Jneubert (talk) 13:47, 29 April 2017 (UTC) Sic19 (talk) 20:42, 12 July 2017 (UTC) Wikidelo (talk) 21:15, 8 May 2018 (UTC) ArthurPSmith (talk) 19:52, 22 August 2018 (UTC) PKM (talk) 19:40, 23 August 2018 (UTC) Ettorerizza (talk) 06:44, 8 October 2018 (UTC) Fuzheado (talk) 03:47, 19 December 2018 (UTC) Daniel Mietchen (talk) 16:30, 7 April 2019 (UTC) Iwan.Aucamp (talk) 21:48, 3 October 2019 (UTC) Epìdosis (talk) 23:49, 22 November 2019 (UTC) Sotho Tal Ker (talk) 00:52, 1 May 2020 (UTC) Bargioni (talk) 09:48, 02 May 2020 (UTC) Carlobia (talk) 14:34, 11 May 2020 (UTC) Pablo Busatto (talk) 03:22, 23 June 2020 (UTC) Matlin (talk) 10:53, 6 July 2020 (UTC) Msuicat (talk) 21:57, 27 August 2020 (UTC) Uomovariabile (talk) 10:04, 27 October 2020 (UTC) Silva Selva (talk) 17:21, 30 November 2020 (UTC) 1-Byte (talk) 15:52, 14 December 2020 (UTC) Alessandra.Moi (talk) 17:26, 16 February 2021 (UTC) CamelCaseNick (talk) 21:20, 20 February 2021 (UTC) Songceci (talk) 18:45, 24 February 2021 (UTC)]] moz (talk) 10:48, 8 March 2021 (UTC) AhavaCohen (talk) 14:41, 11 March 2021 (UTC) Kolja21 (talk) 17:37, 13 March 2021 (UTC) RShigapov (talk) 14:34, 19 September 2021 (UTC) Jason.nlw (talk) 15:15, 30 September 2021 (UTC) MasterRus21thCentury (talk) 20:22, 18 October 2021 (UTC) Newt713 (talk) 08:42, 13 March 2022 (UTC) Pierre Tribhou (talk) 08:00, 20 March 2022 (UTC) Powerek38 (talk) 17:21, 14 April 2022 (UTC) Ahatd (talk) 08:34, 4 August 2022 (UTC) JordanTimothyJames (talk) 00:54, 31 August 2022 (UTC) --Silviafanti (talk) 17:07, 14 September 2022 (UTC) Back ache (talk) 02:03, 1 November 2022 (UTC) AfricanLibrarian (talk) M.roszkowski (talk) 10:44, 4 January 2023 (UTC) Rhagfyr (talk) 19:36, 9 January 2023 (UTC) MaximeHaseeb (talk) 13:10, 4 August 2023 (UTC) Notified participants of WikiProject Authority controlKethyga (talk) 14:29, 10 April 2022 (UTC)Reply[reply]

KIT Linked Open Numbers ID (P5176): (delete | history | links | entity usage | logs | discussion)

Per Property_talk:P5176, this is not really an ID. —GZWDer (talk) 09:05, 16 June 2022 (UTC)Reply[reply]

 Keep It's as much of an ID as all those other sites that use some form of a person's name as their ID's. ArthurPSmith (talk) 13:24, 16 June 2022 (UTC)Reply[reply]
The talk page include two unresolved disputes:
  1. Should items like RSA-370 (Q15990672) have this property?
  2. How should this property be labeled?
--GZWDer (talk) 19:54, 17 June 2022 (UTC)Reply[reply]
Actually, I don't see any unresolved dispute. The KIT Linked Open Numbers (Q51279230) website provides data about 999,999,999,999 natural numbers (from 1 to 999,999,999,999), so the answer to the first question is "no". The answer to the second question is "the current one": any label that aims to generalize the property would make the property itself coincide with numeric value (P1181).
I think the only question we should ask ourselves is: is KIT Linked Open Numbers a valid resource deserving to be linked? --Horcrux (talk) 20:58, 17 June 2022 (UTC)Reply[reply]

DBLP event ID (P10692): (delete | history | links | entity usage | logs | discussion)

dblp computer science bibliography (Q1224715) does not have such an external identifier. This was brought up in the creation proposal by MRA but went on to be ignored. It seems they are considering and working on something like that but it currently does not exist. The formatter URL (P1630) for this property currently can link to a whole host of different things are that not in fact events, e.g., ACM Inroads, Volume 13, The dblp Advisory Board. Further, the things it was envisioned to link to are conference events but instead the links are to proceedings contents which can be sticky as they frequently are not one-to-one with the events themselves, not to mention proceedings are often published as parts of journals and books series so the "identifiers" for such an event might not match DBLP venue ID (P8926), e.g., Conference on Philosophy and Theory of Artificial Intelligence (Q105698572) -> DBLP venue ID (P8926) conf/ptai is great but Philosophy and Theory of Artificial Intelligence, PT-AI 2011, Thessaloniki, Greece, October 3-4, 2011 (Q106332070) DBLP event ID (P10692) series/sapere/sapere5 does not really match since the proceeding is published in a book series. —Uzume (talk) 02:43, 22 June 2022 (UTC)Reply[reply]

@Florian.Reitz: FYI. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 24 July 2022 (UTC)Reply[reply]

FSkate.ru skater ID (P6624): (delete | history | links | entity usage | logs | discussion)

From December 1, 2019, the Internet project about figure skating in Russia is closed. The skaters' pages have also been removed. So I'm making a request to remove this property with its Wikidata child. —MasterRus21thCentury (talk) 23:02, 6 August 2022 (UTC)Reply[reply]

ISOCAT ID (P2263): (delete | history | links | entity usage | logs | discussion)

The external links for this property have been broken for over a year, and it is not clear what these identifiers referred to or if they will ever be resolveable. Middle river exports (talk) 18:43, 7 August 2022 (UTC)Reply[reply]

Olympic Committee of Serbia athlete ID (archived) (P4547): (delete | history | links | entity usage | logs | discussion)

Currently, a property has been created to replace the one being removed - Olympic Committee of Serbia athlete ID (new) (P10978). Since 2020, the above site has stopped working and now all identifiers are not in the form of numbers, but in the form of a first and last name. —MasterRus21thCentury (talk) 14:57, 26 August 2022 (UTC)Reply[reply]

Winterthur Glossar URL (DEPRECATED) (P6107): (delete | history | links | entity usage | logs | discussion)

Deutsch: Es gibt mit Winterthur Glossar ID (P10677) eine Nachfolgeeigenschaft, die inzwischen überall vorhanden ist (ausser für gewisse Referenzen, die URL's sind eh nicht mehr gültig.)
English: With Winterthur Glossar ID (P10677) there is a successor-property, which is implemented anywhere by now (expect for some references, where the URL's aren't valid anymore, anyway.)

Fundriver (talk) 09:00, 8 September 2022 (UTC)Reply[reply]

Fundriver (talk) 14:03, 9 March 2023 (UTC)Reply[reply]

surrounds the enclave (P10613): (delete | history | links | entity usage | logs | discussion)

See Wikidata:Property proposal/surrounds the enclave. I was the proponent, but before the property was accepted I figured out a better modelling: I use direction relative to location (P654) with qualifier inside (Q109810863). Nobody uses this property. The one use on emirate seat (Q111668946) is aberrent; it should be has part(s) (P527) instead. —GrandEscogriffe (talk) 17:10, 27 September 2022 (UTC)Reply[reply]

 Delete - Nikki (talk) 18:57, 7 November 2022 (UTC)Reply[reply]
 Delete - I agree that the one use on emirate seat (Q111668946) was erroneous, so I removed that claim. I do not see how has part(s) (P527) would apply there, so I did not add that. RainerBlome (talk) 18:04, 17 December 2022 (UTC)Reply[reply]
 Delete --Jklamo (talk) 16:18, 10 August 2023 (UTC)Reply[reply]

enclave within (P501): (delete | history | links | entity usage | logs | discussion)

Also RFD this too as the same information can be expressed using shares border with (P47). —GZWDer (talk) 17:57, 27 September 2022 (UTC)Reply[reply]

 Keep I disagree that shares border with (P47) provides an adequate replacement for this property. —‍Mdaniels5757 (talk • contribs) 18:46, 31 May 2023 (UTC)Reply[reply]

exclave of (P500): (delete | history | links | entity usage | logs | discussion)

As long as located in the administrative territorial entity (P131) is correctly interpeted as "located in and part of" (e.g. Llívia (Q13745) located in the administrative territorial entity (P131) Cerdanya (Q12787) and not Llívia (Q13745) located in the administrative territorial entity (P131) Pyrénées-Orientales (Q12709)), we does not need another property to cover the same information. Previous request: Wikidata:Properties_for_deletion/Archive/2017#Property:P500GZWDer (talk) 18:05, 27 September 2022 (UTC)Reply[reply]

 Comment I can't see how located in the administrative territorial entity (P131) is enough. For example, both Llívia (Q13745) and Puigcerdà (Q13765) have located in the administrative territorial entity (P131) Cerdanya (Q12787), none of them has located in the administrative territorial entity (P131) Pyrénées-Orientales (Q12709)), and both have shares border with (P47) with several parts of Pyrénées-Orientales (Q12709)). However, Llívia (Q13745) is an enclave and Puigcerdà (Q13765) isn't. How are we supposed to tell the difference without exclave of (P500) and related properties?--Pere prlpz (talk) 17:35, 4 September 2023 (UTC)Reply[reply]

 Comment Why do you try again with no new arguments to respond to "keep votes" in Wikidata:Properties_for_deletion/Archive/2017#Property:P500 ?. Thanks, Amadalvarez (talk) 12:13, 16 September 2023 (UTC)Reply[reply]

Hmoegirl ID (P10724): (delete | history | links | entity usage | logs | discussion)

Lacking notability. 10:26, 3 October 2022 (UTC)Reply[reply]

There are 5 entries and all added on the same date by @C933103. That looks indeed like lack of notability. Mbch331 (talk) 15:13, 3 October 2022 (UTC)Reply[reply]
The intent of this property is to complement the main property of Moegirlpedia ID to achieve comprehensive correspondence, as this site function as a backdrop for content deported from the main Moegirlpedia site due to Chinese regulatory rules, however the uptime of the H-moe site have been far from best in recent months, hence it would be pretty difficult for anyone to try to add new entries for the site into Wikidata in the past few months, which explain its current relative low usage. C933103 (talk) 10:14, 5 October 2022 (UTC)Reply[reply]

Situation update: It is now commonly believed that (no official proofs), members, editors, and other persons related to Hmoe pedia are starting to be taken by Chinese polices starting from roughly July this year, and starting from September the site is rendered totally inaccessible until now, and many on Chinese internet estimated that this likely mean the site is not going to return, although archive of the site remain available on like Internet Archive. Chinese Wikipedia have voted to delete their article covering this site on notability ground on September 10 while speculating the site's fate.

I think for the time being it might make more sense to edit the property so that it link to internet archive instead, and to complete the collection of pages that have been archived by the internet archive engine.

C933103 (talk) 15:58, 9 October 2022 (UTC)Reply[reply]

  •  Delete Gibberish contents with nothing given even small notabilities. --Liuxinyu970226 (talk) 07:03, 16 October 2022 (UTC)Reply[reply]
    "gibberish" to people who do not want to see content against Chinese law I guess C933103 (talk) 17:47, 20 October 2022 (UTC)Reply[reply]
  •  Delete barely used identifier of spin-off of user-generated narrowly focused database. --Jklamo (talk) 14:17, 19 October 2022 (UTC)Reply[reply]
    narrowly focused? C933103 (talk) 17:46, 20 October 2022 (UTC)Reply[reply]
  •  Question Do we really need to delete the subject item Q111607789? Wasn't it part of Moegirlpedia? Laftp0 (talk) 11:27, 25 October 2022 (UTC)Reply[reply]
    That is for another discussion. After the site being made unavailable since earlier last month, and then earlier this month rumor on Twitter surfaced that claim contributors from China being taken away by Chinese government, Chinese Wikipedia judged the the Chinese Wikipedia article did not meet notability guideline despite expecting situation might change in short term, and hence deleted the article. With the Chinese Wikipedia article deleted, the Wikidata item no longer have any Wikipedia link and likely being deleted because of it not meeting notability criteria #1. Yet, as far as this Prperty P10724 remain in existence, I think it still meet notability criteria #3, and thus shouldn't be deleted.
    It was not officially part of Moegirlpedia but more like a complementary site to it. In the early day HMoegirl shared account database and other resources with the main Moegirlpedia site, but such arrangement have been problematic as Moegirlpedia progressively move into Chinese server and subject the wiki to Chinese government regulation, while Hmoegirl continue to host content that are against Chinese law in multiple aspects. Hence as of summer of year 2022 the official stance is no official relationship between the two sites, despite editors and contents across the sites. C933103 (talk) 12:58, 26 October 2022 (UTC)Reply[reply]

MangaDex title ID (P10589): (delete | history | links | entity usage | logs | discussion)

The website MangaDex is a website for scanlation (Q557923) and therefore gives people access to copyright protected works for free without holding a license to publish it or consent of the copyright holder. The website infringes copyrights and I don't see any reason why wikidata should link items to such a website.

See also: Wikidata:Project chat/Archive/2022/11#Mangadex?

Christian140 (talk) 07:58, 7 November 2022 (UTC)Reply[reply]

  •  Weak oppose Linking to a website doesn’t mean endorsing its practices. The question in this case would be whether the benefits of having this site linked outweigh the concerns about legal issues. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 10:12, 7 November 2022 (UTC)Reply[reply]
 Delete in the past Japanese publisher sent cease and desist letters to aggregators for Scanlation. Having this property might essentially makes us an aggregator for Scanlation and thus opens up the possibility of legal threads against Wikimedia. I think it's ideal if your community can self regulate in this regard and delete the property without needing to interact with Wikimedia legal. ChristianKl❫ 15:12, 7 November 2022 (UTC)Reply[reply]
(Japanese publishers having sent cease and desist letters for scanlation sounds … interesting given that it’s not their – arguably monetary – rights infringed upon, but those of the author, and in Japan itself it wasn’t possible until a few years ago to take legal actions on behalf of a third party against copyright violations. Just as an aside. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 15:53, 7 November 2022 (UTC))Reply[reply]
Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl❫ 00:15, 10 November 2022 (UTC)Reply[reply]
Admittedly yes, therefore an aside (basically saying that they are taking advantage of another country’s legal provisions where this would not be possible in their own country – indeed not of interest here). --2A02:8108:50BF:C694:1432:F47C:55CC:B105 19:37, 12 November 2022 (UTC)Reply[reply]
 Delete I created this property honestly not knowing it was a scanlation website or what scanlation was. Linking to a website that distributes copyrighted material is basically assisting in that distribution which is illegal. Lectrician1 (talk) 20:18, 7 November 2022 (UTC)Reply[reply]
 Delete As for scanlation sites, Japanese and U.S. publishers declared in a joint statement in 2010 that they are illegal. By making them available for free, they are infringing on the financial benefits that copyright holders rightfully deserve. Afaz (talk) 04:01, 9 November 2022 (UTC)Reply[reply]
While this is undoubtedly true, there are no financial benefits for copyright holders anyway if nobody publishes their work commercially in a country. If there is no “official” translation that is sold in, e.g., the US, anyone who wants to read it (in English) there has to resort to “unofficial” translations, which have no choice but to infringe on copyright. I don’t want to endorse copyright violations, in no way, but the “financial” point of view doesn’t get us anywhere here. That said, what was the point of creating links to the specific site discussed here in the first place? What benefits were seen in linking it? --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 10:18, 9 November 2022 (UTC)Reply[reply]
As far as the laws are concerned people can import Japanese comics whether or not they are translated. The Berne convention exists to give mutual recognition of copyright and not require products to be marketed in a country to be protected in that country. ChristianKl❫ 00:13, 10 November 2022 (UTC)Reply[reply]
That’s not the point. There are probably many people in the world who want to read Japanese comics, but cannot read Japanese. That’s the reason why scanlation (and regular translation) exists in the first place. Of course it would be better if they paid the original authors, but the author doesn’t get any money regardless of whether someone abroad reads their comic in scanlation form (without paying) or doesn’t read it at all. Hence the “financial” point of view doesn’t get us anywhere here. There’s more to copyright than remuneration (and the Berne convention presumably exists regardless of financial considerations). --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 12:45, 10 November 2022 (UTC)Reply[reply]
Copyright is driven by actual laws. You might disagree with those laws but they exist. Scanlation clearly creates deriviative works of copyrighted works. In the US context where Wikimedia has it's legal home, that's forbidden by copyright law unless you have permission or can argue for fair use. Courts have made many rules on copyright and have developed a concept of financial interests in the process. You might not like it or disagree with it, but that's still the law of the land. ChristianKl❫ 12:20, 12 November 2022 (UTC)Reply[reply]
Neither do I disagree with copyright laws (where did I claim that?) nor do I deny that scanlation violates them. All I’m saying is that it does not hurt the authors financially and that the claim by Afaz that they infringe on “the financial benefits that copyright holders rightfully deserve” is therefore misleading. Of course they have “financial interests” – they are selling their works in Japan, after all –, but that’s different from “financial benefits”. (Easy example: A greengrocer has a financial interest in getting vegetables sold, but no financial benefit if nobody buys them – a reason for which might be that all the people who would like to buy them live in another city. Does this make stealing the vegetables from the greengrocer and giving them away for free in that other city legal? Obviously not. Does the greengrocer have a financial damage? No, he doesn’t receive money for the vegetables anyway.) But let’s stop this pointless discussion here – both of us agree that scanlation is a copyright violation, while we seem to disagree on why it is (or maybe not; the deriviative work argument is independent of financial aspects, and I’m not sure the US context is actually necessary for it, but anyway). The reason why it derailed was probably my justification for the continuing widespread existence of scanlation despite its illegality – which is unnecessary for the point I wanted to make, I think (now). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:07, 12 November 2022 (UTC)Reply[reply]
The reason why I’m so nit-picky about this is that it often gets mixed up. If remuneration were the problem, scanlators could solve it by taking money from their “customers” and using it to pay the original authors – but in the absence of permission to do so this would still be a copyright violation. That there is more to copyright than remuneration can also be seen in the advent of Creative Commons licences, where copyright holders waive their right to remuneration without (necessarily) waiving other rights they deserve, such as proper attribution (a misconception many have: “It’s free, so I can use it any way I want”). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:33, 12 November 2022 (UTC)Reply[reply]
  •  Question I see questions of copyright here but if this was actually an issue of concern with wiki projects merely linking, then wouldn't this be a major issue with wiki projects linking to the Internet Archive (Internet Archive ID (P724) and the works there that are still under copyright? If there isn't an issue with that I dont see the issue here. -Jeanjung212 (talk) 20:51, 18 November 2022 (UTC)Reply[reply]
@Jeanjung212: Can you link any item there where the site infringes the copyright? On the first look, all the content looks like public domain and creative commons as well as previews. Also, not that copyright is not the problem. There are also links to Netflix. Copyright infringement is the problem. --Christian140 (talk) 07:58, 19 November 2022 (UTC)Reply[reply]
This website (linked from Tetris (Q71910)), for example, doesn’t seem to be public domain, so technically (ianal) the Internet Archive is infringing on the creator’s copyright by making a copy of it available. (It’s just that no one bothers to sue the Internet Archive, I think.) --Data Consolidation Officer (talk) 21:11, 21 November 2022 (UTC)Reply[reply]
Hmmm. But on all websites where every user can upload content, copyright infringement happens. On wikipedia and commons, too. Just, eventually it gets deleted. However, for mangadex, copyright infringement is the core of the website. For internet archive, they have this site: Rights – Internet Archive Help Center. So, you could report content you think that infringes copyright. But here, I am actually not sure if it is copyright infringement. A lot of old software is made available for free and you can download them from many serious websites. --Christian140 (talk) 08:01, 22 November 2022 (UTC)Reply[reply]
Internet Archive, or archiving in general, might even be covered by Fair Use (I simply don’t know). And given the large number of pages archived there, reporting copyright violations would be a Sisyphean task. As I stated below, I don’t think there’s a legal issue with mere linking, but P10589 is very dispensable anyway. --Data Consolidation Officer (talk) 20:23, 22 November 2022 (UTC)Reply[reply]
The Internet Archive is also recognised as a library by the US government. Thibaut (talk) 10:39, 13 February 2023 (UTC)Reply[reply]
  •  Comment Linking doesn’t mean endorsing, afaik, so the site’s copyright violations alone wouldn’t be valid grounds for deletion of this property. Having a look at the property proposal discussion, however, it seems that the property was created without thorough discussion, basically because “I think properties for it would be useful”. Wikidata should, imho, be extremely restrictive with respect to which external databases it chooses to systematically link, given the considerable effort of maintaining such link collections, avoiding inconsistencies and so on. That’s why I’d tend to vote for deletion at the moment, unless someone provides a good reason why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 21:03, 21 November 2022 (UTC)Reply[reply]
    It's 100% endorsing. You're exposing the copyrighted works to a wider audience by linking to them. You're clearly assisting in their distribution. Lectrician1 (talk) 21:30, 21 November 2022 (UTC)Reply[reply]
    Sorry, I should have made clearer that I was specifically talking about legal issues. There can of course be ethical issues with linking (depending on intention), but afaik (and ianal, so please correct me if I’m wrong) courts in various contries have established that website operators cannot be held liable for criminal violations by other sites they merely link, so Wikimedia Foundation could not be (successfully) sued for those links or something like that. Anything else is a question of whether we, as a community, want those links, but as I said, I don’t really see any reason anyway why we should. --Data Consolidation Officer (talk) 20:12, 22 November 2022 (UTC)Reply[reply]
    There's a difference between having a simple link to MangaDex and having a system on Wikidata that tells Wikidata users for every manga, the exact page where they can download a copyright violating copy of that manga. Having a link to every single manga, is like torrent websites that link to individual content and torrent websites do face legal problems. ChristianKl❫ 11:12, 27 November 2022 (UTC)Reply[reply]
    Which all the more raises the question why Wikidata would want such a system in the first place; a question the answer to which I still don’t see. Given that it took nine months (the property was created in early April) until someone noticed that there are copyright violations linked, I wouldn’t consider any claim about copyright infringement endorsement intentions plausible (in contrast to torrent sites; and indeed those links will have been created in good faith in most cases), but let’s the lawyers fight that out (or not). --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)Reply[reply]
     Delete, as indicated, on the grounds that there has been no good reason given why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)Reply[reply]
  • As the property proposer, I have no objection to deletion based on the arguments provided. Tol (talk | contribs) @ 01:01, 30 November 2022 (UTC)Reply[reply]
  •  Comment I won't comment on the actual scanlated content MangaDex works, but they are a gold mine of information, as they maintain links to many of the other manga databases on the internet. Maybe deletion can be waited on until my bot is able to copy as many of the external linkings as possible. In that case, there is another issue brewing, as whenever my bot pulls information from MangaDex it makes a reference and puts the full URL into the reference URL property, although I theorize it would be trivial to clean those up (SPARQL query for stated in MangaDex would bring them all up). RPI2026F1 (talk) 01:49, 9 December 2022 (UTC)Reply[reply]
    Alternatively, would the problem not solve itself if the link was simply removed, rather than deleting the entire property? RPI2026F1 (talk) 01:51, 9 December 2022 (UTC)Reply[reply]
     Comment Looks like the property is going to be removed. It seems reasonable however that the actual removal can be put on hold for a period of up to 3 months (or less) to allow for links to other sites to be extracted from this identifier. Infrastruktur (talk) 20:54, 9 December 2022 (UTC)Reply[reply]
    Yes, I'm trying to get a whole bunch of properties created so I can extract maximal information from the source. I can see about 8 or 10 new properties being partially populated on top of what is already being extracted. RPI2026F1 (talk) 16:17, 21 December 2022 (UTC)Reply[reply]
  •  Delete per the above copyright and legal concerns. ミラP@Miraclepine 19:47, 9 December 2022 (UTC)Reply[reply]
  •  Keep Wikidata is neither a judge nor a police officer. Besides problematic links, the database contains other useful data as well (date of publication, artist, genres, alternative titles, even links to official shops). --Jklamo (talk) 18:30, 21 December 2022 (UTC)Reply[reply]
  •  Keep per Jklamo. We shouldn't censor the identifier of this useful database unless we have clear evidence of law. Laftp0 (talk) 13:47, 22 December 2022 (UTC)Reply[reply]
  •  Delete per the above copyright and legal concerns, we already have better manga/anime databases properties like ANN, MAL and Anilist that don't host illegal content, we don't need some random scanlation website. --Thibaut (talk) 14:30, 20 January 2023 (UTC)Reply[reply]
 Weak oppose Linking isn't endorsement, and it's very useful for getting links to other manga services. Although, ultimately if it is deleted we can still use its API to grab links as long as one of AniList/MyAnimeList/Kitsu are linked, so it wouldn't be the end of the world. Ultimately, my opinion would be based on the opinion of the Wikidata team as to whether this kind of site should be linked to. FWIW, from what I can tell MangaDex does respect the wishes of copyright holders if they do request a takedown, although whether that redeems the site is debatable. Nicereddy (talk) 02:09, 21 January 2023 (UTC)Reply[reply]
 Keep, Mangadex is just a platform (non-commercial and ad-free), which like other platforms like YouTube or Facebook could be used for publishing anything, but no evidence provided by nominator that this website opposes copyright holders in any way (other than "it is free, therefore it is illegal"). The rules are pretty restrictive there, cases when obtaining a license is required are mentioned. Lockal (talk) 04:51, 13 February 2023 (UTC)Reply[reply]
The “rules” are not that “restrictive”:

Any scanlated release is allowed to be uploaded regardless of the existence of official translations […]

And even if there’s no official translation or it’s out of print, translating something that is copyright-protected and uploading it to the web is still illegal per the Berne convention (see above).
The difference with Facebook or YouTube is that they disallow illegal content and respond to DMCA requests. Thibaut (talk) 09:53, 13 February 2023 (UTC)Reply[reply]
A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)Reply[reply]
The website is literally designed to host illegal content, like Christian140 said above: it's at its core.
The mere fact that their domain reseller and/or Cloudflare had to kick them away because of the number of DMCA requests they were getting is a strong indicator ([1][2]). One of these requests was from VIZ Media, which is owned by two major Japanese publishing companies (Shueisha and Shogakukan).
Now, please enlighten me how a website hosting full manga releases translated in multiple languages without the copyright holders' permission doesn't infringe Japanese copyright law and therefore the Berne Convention? Thibaut (talk) 18:17, 12 March 2023 (UTC)Reply[reply]
My point was that there is a way to legally host a scanlate website (or any other types of derivative works). It is not difficult to receive a permission from copyright holder to publish your own translation under well defined conditions: non-commercial (optionally providing additional details to help copyright holder to verify that translator are not seeking profit with translation) and only on specific website. Actually, I did it multiple times (not for manga, but it does not matter). Consider that all mindful translators received a permission: it is called "presumption of innocence".
The links you provided mentions that some time ago a fan group that has been coloring the Boruto manga used official scanlation, which resulted in DCMA takedown. Such types of uploads are not allowed on MangaDex:
Scans of physical official releases or rips of digital official releases/webcomics from official sources, such as original releases (raws) or officially translated releases, are not allowed to be uploaded.
Lockal (talk) 10:58, 13 March 2023 (UTC)Reply[reply]
 Delete - per legal concerns. Under Japanese copyright law, it is a violation of copyright law to link to a site that is known to copyvio. Links that may violate laws should not be kept. The server for this site may not necessarily be located in Japan, but it should be sensitive to the law. The server for this site is not necessarily located in Japan, but I think it should be as sensitive to the law as possible. Syunsyunminmin (talk) 10:15, 19 February 2023 (UTC);edit  – The preceding unsigned comment was added by Syunsyunminmin (talk • contribs).Reply[reply]
 Delete - Link to a site that is a violation of copyright law. --Fralambert (talk) 19:22, 12 March 2023 (UTC)Reply[reply]

Crunchyroll ID (deprecated) (P4110): (delete | history | links | entity usage | logs | discussion)

Replaced by Crunchyroll series ID (P11330) and I added all changed values wherever possible. Not all values of Crunchyroll ID (deprecated) (P4110) have been moved since some of them are now invalid and 404. —RPI2026F1 (talk) 16:15, 21 December 2022 (UTC)Reply[reply]

generally I like to preserve deprecated values if even a substantial number are archived by something like archive.org. Is that not the case here? Can you link me some examples that don't resolve at all? All the ones I clicked on still work so I would suggest just keeping this property around. BrokenSegue (talk) 18:39, 21 December 2022 (UTC)Reply[reply]
An example is Q624962. RPI2026F1 (talk) 22:03, 21 December 2022 (UTC)Reply[reply]
yeah that's in the archive [3] so i say  Keep BrokenSegue (talk) 20:51, 24 December 2022 (UTC)Reply[reply]
 Keep Just because the identifier is deprecated doesn't mean it's not still useful. --Yirba (talk) 23:28, 2 February 2023 (UTC)Reply[reply]

ICTV virus ID (P1076): (delete | history | links | entity usage | logs | discussion)

All of the property's values were deleted sometime in 2022 and currently has 0 uses (see query). —RPI2026F1 (talk) 12:02, 23 December 2022 (UTC)Reply[reply]

"Unused" is by itself not a valid reason of deletion. More research on this ID is needed (is this ID deprecated? succeeded by other scheme?) GZWDer (talk) 15:00, 23 December 2022 (UTC)Reply[reply]
It seems to have no URL formatter nor any related properties, which is weird. The URL for ICTV virus ID (P1076)source website for the property (P1896)http://ictvdb.bio-mirror.cn/Ictv/vc_code.htm seems to be invalid, although ICTV is still a thing from my google search. RPI2026F1 (talk) 19:04, 23 December 2022 (UTC)Reply[reply]
ICTV still has a database of viruses. It seems to be on their main site now. But the database includes all the different ICTV releases of the data. Luckily, it seems to follow a semi-predictable pattern. For example, SARSr-CoV (Q278567) has the IDs 202101868 and 202001868 for the 2021 and 2020 releases, respectively. It also has a bunch of other previous releases that seem to follow the same pattern of year+id. It seems to exist, but I'm not quite sure how to use it. DoublePendulumAttractor (talk) 01:36, 16 January 2023 (UTC)Reply[reply]
There have been about 375 objects with IDs, which had to be deleted again:
Now, this property is unused again. M2k~dewiki (talk) 11:17, 15 May 2023 (UTC)Reply[reply]
@DoublePendulumAttractor: 20162096 (=Hantaan orthohantavirus (Q29002506)) and 20152096 (=Tulare apple mosaic virus (Q7851962)). BTW:  Delete. --Succu (talk) 19:43, 15 May 2023 (UTC)Reply[reply]
 Delete by arguments Succu. --Ыфь77 (talk) 19:16, 19 September 2023 (UTC)Reply[reply]

individual of taxon (P10241): (delete | history | links | entity usage | logs | discussion)

This property doesn't do anything that can't be done with instance of (P31). It's needless couplication, from the discussion it seems to exist due to a misunderstand of taxon (Q16521) being a second-order class (Q24017414). If taxon (Q16521) would be a normal class it would be understandable but it being a second-order class (Q24017414) makes instance of (P31) work for the usecases. ChristianKl❫ 14:00, 7 January 2023 (UTC)Reply[reply]

Note that this was discussed last year at Wikidata:Properties for deletion/P10241. @ChristianKl: We do subpages for PfD now, have moved it over for you. Thanks. Mike Peel (talk) 07:14, 9 January 2023 (UTC)Reply[reply]
The link on the Watchlist page, that says this is a current discussion, points to the closed previous discussion. So, comments on this PfD will likely be a mess. --EncycloPetey (talk) 03:37, 7 February 2023 (UTC)Reply[reply]
  • Comment Personally I think this is helpful to keep so we don't have to make individual items for every single animal species, we have individual animal (Q26401003) right now and I think it would be way more messy if people started making "individual dog", "individual coati" etc.StarTrekker (talk) 20:25, 15 August 2023 (UTC)Reply[reply]
    • Oppose As a mater of fact its also very helpful for fictional characters.StarTrekker (talk) 21:18, 15 August 2023 (UTC)Reply[reply]

Kinoliste ID (P4981): (delete | history | links | entity usage | logs | discussion)

The homepage kinoliste doesn't exist anymore. Linking to ids of it therefore probably doesn't make sense anymore —FlocciNivis (talk) 23:47, 8 February 2023 (UTC)Reply[reply]

@Anvilaquarius, what do you (as the proposer) think about the further usage of this property? Yellowcard (talk) 15:38, 17 February 2023 (UTC)Reply[reply]

It's a pity the website doesn't exist anymore and the matching work was in vain. It's probably not good enough for the archived versions to be linked forever, but there are some at least: my first search resulted in https://web.archive.org/web/20060207083728/https://www.kinoliste.com/kinoliste/kinoliste.php?kino=214 I don't know about Wikidata policies about such things, so I don't really want to weigh in. --21:49, 19 February 2023 (UTC)

@Anvilaquarius I should have checked the wayback machine first before writting this deletion proposal. In this case, if it's not against Wikidata's policy I'm for keeping the property and adding "https://web.archive.org/web/" at the beginning of the formatter URL --FlocciNivis (talk) 08:21, 20 February 2023 (UTC)Reply[reply]
Does that make sense? The data in the Wayback Machine will eventually be outdated, for example the number of seats per room. Images are not available. New cinemas will not be added, closed cinemas will not be identified as such. I see that it was a lot of work to add the identifiers, but as the website is offline and it does not look like it will come back again, I assume that the deletion will be the best solution, unfortunately. Yellowcard (talk) 09:29, 20 February 2023 (UTC)Reply[reply]
@Yellowcard As historical data for someone wanting to write an article about one of those cinemas that might be still useful as a source. FlocciNivis (talk) 12:19, 20 February 2023 (UTC)Reply[reply]
This is a good point, I don't personally see what good it does to delete the property if archived links are avalable.StarTrekker (talk) 20:01, 15 August 2023 (UTC)Reply[reply]

Defined Term ID (P6205): (delete | history | links | entity usage | logs | discussion)

This property is not used anywhere (other than on the property itself), the site no longer works, and very few entries (of the thousands claimed on its index pages) are retrievable from the Internet Archive, so that even a quasi-complete record of its identifiers for posterity is quite difficult, if impossible, to achieve. —Mahir256 (talk) 17:46, 12 February 2023 (UTC)Reply[reply]

Raptekster.dk ID (P7164): (delete | history | links | entity usage | logs | discussion)

Website is completely broken. I do not see any use for this anymore--Trade (talk) 01:04, 14 February 2023 (UTC)Reply[reply]

  •  Delete 66 uses only, no external use (like wikitemplate), no need to preserve. --Jklamo (talk) 09:24, 17 March 2023 (UTC)Reply[reply]
  •  Delete Not important to link to Replayful (talk) 17:58, 1 May 2023 (UTC)Reply[reply]

WorldCat Identities ID (superseded) (P7859): (delete | history | links | entity usage | logs | discussion)

As recently announced by a banner in WorldCat Identities website, "The WorldCat Identities web application will be retired and shut down in the coming months and the data is no longer being updated. The most recent version of the data is from July of 2022. As OCLC continues to build out the WorldCat Entities ecosystem, please use it as a source for persistent Person identifiers. https://id.oclc.org/worldcat/entity" (note: WorldCat Entities is represented here by WorldCat Entities ID (P10832)). Whilst I usually support keeping the values of obsolete external IDs for historical purposes, I think in this case keeping it's not worth: the great majority of 1.93 M IDs are either VIAF-based or LCCN-based and the very few "np" and "nc" IDs (4k) have often a dubious identification value. My proposal is deleting the property as soon as the website will effectively go offline (while the website is still online, I would keep it), so probably before the end of 2023. —Epìdosis 21:20, 2 March 2023 (UTC)Reply[reply]

The proponent and the creator of the property have been contacted in their talk pages; this page has also been linked in the talk pages of the templates indicated in the {{ExternalUse}}. --Epìdosis 21:40, 2 March 2023 (UTC)Reply[reply]
I'm the original proponent and I agree to delete it down when the WorldCat Identities website is shut down. "either VIAF-based or LCCN-based" does not diminish its value since one cannot pick one of the two alternatives without having the WorldCat Identities data. But without the website, it's useless -- Vladimir Alexiev (talk) 06:35, 17 March 2023 (UTC)Reply[reply]
@Epìdosis: I don't see why it would need to be deleted. The "worth" is exactly historical purposes and it costs nothing, I'd assume. Cheers, Ederporto (talk) 14:41, 14 March 2023 (UTC)Reply[reply]
I'll object to that. The presence of the np and nc IDs indicate that there are library records related to the associated items. They are a big clue to users and editors that there will be relevant information in library catalogues to retrieve and link to that item. I'd recommend marking them as deprecated statements with reason for deprecated rank (P2241)withdrawn identifier value (Q21441764). From Hill To Shore (talk) 19:08, 27 March 2023 (UTC)Reply[reply]
@From Hill To Shore: Please keep it simple. If we have two WorldCat ids users need to know that identities are not entities or was it tentities? Now translate this into Arabic, Japanese, and Hindi. Many of the WorldCat ids are outdated or wrong. WorldCat ids have changed over the years. Leaving the mistakes and creating the opportunity for new ones is not a good solution. --Kolja21 (talk) 23:48, 27 March 2023 (UTC)Reply[reply]
I am not sure why you are concerned about translation. The whole premise of Wikidata is that statements are machine-readable and easily translated into any language. If reason for deprecated rank (P2241)withdrawn identifier value (Q21441764) is not translated into a particular language, simply add the relevant labels to the property and the item. Also, I have no idea why you are urging me to "keep it simple." Where do you draw the line on wiping deprecated information from our database in the interests of keeping things "simple"? I am objecting here because an editor is proposing unilateral action to delete ahead of this discussion being concluded. If more editors join the discussion and disagree with my position, then the consensus will be against me and deletion will proceed. From Hill To Shore (talk) 05:35, 28 March 2023 (UTC)Reply[reply]
There are already reason for deprecated rank (P2241)withdrawn identifier value (Q21441764) for withdrawn identifier values. So we can't use this qualifier for a project ceased to exist. --Kolja21 (talk) 13:19, 28 March 2023 (UTC)Reply[reply]
I'm sorry but I have absolutely no idea what point you are trying to make in your comment there. "Because the statement exists, we can't use the statement." From Hill To Shore (talk) 15:37, 28 March 2023 (UTC)Reply[reply]
It's not so difficult. withdrawn identifier value (Q21441764) is used for a single withdrawn identifier. If a project ceased to exist this is something else. If you have problems to understand this distinction you might understand why users will have problems distinguishing between six properties connected to WorldCat. This is what is meant with: "Keep it simple." --Kolja21 (talk) 17:13, 28 March 2023 (UTC)Reply[reply]
If you think withdrawn identifier value (Q21441764) is not the best description for this deprecation then simply create a new item with a deprecation reason you find suitable. "I don't like your choice of reason," is not an argument to delete instead of deprecate. As we have seen through the life of Worldcat Identities, many IDs have changed from "nc"/"np" prefixed IDs to "VIAF"/"LCCN" prefixed IDs. This is because the nc/np entries are for items in the library catalogue and libraries are likely to generate new IDs for them over time. There is a strong likelihood that this behaviour will continue and the residual nc/np items will gain WorldCat Entities ID (P10832) over a period of time. Keeping the nc/np entries as deprecated will make it easier to find matches later rather than have us repeat the identification process all over again. I have no problem with removing WorldCat Identities ID (superseded) (P7859) when we have a WorldCat Entities ID (P10832) present. Your focus is on preventing user confusion, which I don't see as an issue, unless you are advocating the removal of all deprecated information (what makes this case special compared to any other case of deprecation?). My focus is on preserving the useful curation work we have completed that may help us continue to match items to new library IDs. From Hill To Shore (talk) 07:45, 29 March 2023 (UTC)Reply[reply]
"My focus is on preserving the useful curation work we have completed" - which of the P7859 statements are result of such work and would you support that those that are not can be deleted? 77.191.135.37 03:18, 17 April 2023 (UTC)Reply[reply]
  •  Keep and link to archived page. WorldCat identities indexed the names of entities in languages other than English, and as far as I can tell WorldCat entities is effectively English-only. Take a look, for example, at the item for محمّد سعد الله خان کھيتران: Muhammad Saad Ullah Khan Khetran (Q113960737) ; this person's name in their native language Saraiki was on their WorldCat identities page but not on the entities page. While it may be noted that the Library of Congress link lists 6 native labels, 5 out of 6 of them are incomplete and/or spelled incorrectly. Most writers of languages that are not one of a few widely spoken ones like English, French, etc. have erroneous information recorded throughout in their records in various databases. So we could really use any and all links to information which can be cross referenced to help determine the correct information. When and if this information is available via WorldCat entities is when the deletion of this property should be discussed.
عُثمان (talk) 18:24, 24 April 2023 (UTC)Reply[reply]
  •  Delete, dubious quality, lack of sources. If derived from viaf or lccn use these instead. 77.191.135.37 03:08, 17 April 2023 (UTC)Reply[reply]
  •  Keep Worldcat Identities redirects in most cases to Worldcat Entities. Absolutely essential. Grimes2 (talk) 22:07, 17 April 2023 (UTC)Reply[reply]
@Grimes2: A rar visitor. How did you find this discussion?  Comment BTW: P7859 and P10832 should be displayed one below the other so that the comparison is easier. 2A02:2454:986D:F700:493E:E780:1887:62CE 03:38, 7 May 2023 (UTC)Reply[reply]
  •  Keep: Certain until P10832 is populated following a migration strategy. Especially uaeful when the p7859 refirects to the new P10832 entity. -- DeirgeDel tac 20:30, 29 May 2023 (UTC)Reply[reply]
  •  Comment: May I be so bold as to venture that the evidence it overwhelming that P7859 is retained until P10832 is populated. There is then the question of what is using the P7859 value out of Wikidata? Is it only the authority control template or something else? While that debate may not be helpful a more productive approach might be to agree a roadmap on how P10832 is to be populated. There's bits of that spread throughout the above vote but it would be helpful to see an agreed way forward in one place. That is focus on getting P10832 populated rather than P7859 deleted. Thankyou. -- DeirgeDel tac 10:48, 1 June 2023 (UTC)Reply[reply]
    Åma (Q21477069): mountain in Antarctica, P7859 = https://worldcat.org/identities/viaf-168989993/ = 5 IDs = many things, but no mountain in Antarctica. Most WorldCat Identities IDs were imported through other IDs and never checked. The only thing that is overwhelming is bad quality of this property. Taking a secondary source for migration while Wikidata has the original source (LCAuth etc.) would be counterproductive. It's a basic rule: Use citable and original sources! --Kolja21 (talk) 17:22, 1 June 2023 (UTC)Reply[reply]
    P7859's which redirrect to viaf and not worldcat entities are of no/limited use in determine P10832. P7859 which redirect to worldcat entries are more useful. I have no clue about any P7859 value not directing to a worldcat entity. And I'd love to look at this more but I've not got the resource. Thankyou. -- DeirgeDel tac 23:07, 1 June 2023 (UTC)Reply[reply]

Migration to P10832[edit]

enWikiQuote migration case[edit]

As spin-off from Worldcat changes I've been exploring maintaining some functionality from loss of the "Worldcat id" template by replacing with authority control collecting P10832 from the associated wikidata item. There's only about 90 articles/Wikidata items involved with just over a handful having P10832 already populated. So I have been looking as getting the rest of 90 populated with P7859. I have kluged up a program which uses P7859 from wikidata to look up the P10832 via the redirect in a number of cases and produces Wikitable output as well as quickstatements input ( it avoids producing QS if P10832 is already populated). I've run in quickstatements batch 206942 a small batch of 5 if anyone wishes to make any comments. There's a little more information at q:en:User:DeirgeDel/xpop2 and q:en:Wikiquote:Village pump#P10832 population task plan F. Thankyou. -- DeirgeDel tac 12:12, 30 May 2023 (UTC)Reply[reply]

Due to an unexpected need to clear some of my to-do list I've boldy gone ahead and added the P10832's needed by the set 90 artcles needed it in Wikiquote. I had to do a handful manually and a frequent reason was the Wolrdcat entity not having an English Label. ✓ Done -- DeirgeDel tac 23:13, 30 May 2023 (UTC)Reply[reply]

Removal of P7859 before consensus reached[edit]

I observe P7859 vales are being removed. I believe this is before consensus has been reached in the above discussion. In particular there is the interesting use-case of Joseph M. Crofts (Q115943526), an item created by myself when my DeirgeDel account was named Deirge Ó Dhaoinebeaga. @Epìdosis: removed the P7859 statement at Special:Diff/1906578499. I recovered that statement, the P7859 value I had set was "lccn-nb2002-21760" and unfortunately that linked to this Worldcat identity URL which redirected to notfound. However I remembered a "trick" "rule of thumb" from work on Wikiquote that is a Worldcat Identity has two hyphens sometimes changing the second hyphen to a zero would produce a worldcat identity that would redirect to an URL that would identify the required P10832 Worldcat Entity Id value. Thus from this change the link was generated which Worldcat sent to the redirect target URL which exposed the Worldcat Entity ID "E39PCjG8wDQPxYPBqJMgkxRvQC" for P10832 as well as links to the VIAF ID and the Library of Congress Name Authority File ID. While Epìdosis has been helpful adding additional identifiers I am concerned that removal of P7859 makes it difficult to locate the P10832 and suggest these removals need to be stopped and possibly even reverted. -- DeirgeDel tac 13:35, 2 June 2023 (UTC)Reply[reply]

Hi @DeirgeDel:, the removals I performed today of a few thousands of values (which are BTW concluded) where based on 3 criteria: 1) IDs which, due to botched format, were invalid or anyway unusable to get new P10832 values (https://editgroups.toolforge.org/b/QSv2T/1685691070809/ + https://editgroups.toolforge.org/b/QSv2T/1685691187036/); 2) IDs which were present in items not containing a VIAF ID (P214) ID (https://editgroups.toolforge.org/b/QSv2/207071/) - on the basis of the reasoning that, in many cases, it could have happened that the VIAF ID from which the WorldCat ID was copied could have been removed because of a mismatch or a conflation and thus the WorldCat ID could be itself a mismatch or a conflation; 3) IDs which were referenced with a VIAF ID (P214) ID which is not present anymore in the item (all the other batches of today) - on the basis of the reasoning that, in many cases, it could have happened that the VIAF ID from which the WorldCat ID was copied could have been removed because of a mismatch or a conflation and thus the WorldCat ID could be itself a mismatch or a conflation. If we want to adopt caution in the import of WorldCat Entities IDs from WorldCat Identities IDs, I though that the above cases are doubtful enough to be excluded from the conversion, and thus were to be removed (this is especially true for cases 1 and 3). --Epìdosis 13:45, 2 June 2023 (UTC) P.S. and https://editgroups.toolforge.org/b/QSv2/207093/ removes only deprecated values, which are surely not suitable for conversion to P10832. --Epìdosis 14:02, 2 June 2023 (UTC)Reply[reply]
I think you might consider what it says in Help:Deprecation. Speficially deprecating but not deleting properties that are "now known to be wrong, but were once thought correct". What is your reason why your deletions are distinguishable from the general rule? --William Graham (talk) 16:55, 2 June 2023 (UTC)Reply[reply]
The usefullness of keeping as deprecated the IDs which are obsolete or inexact because of a conflation lies mainly in avoiding that they are readded with normal rank; since here the database is defunct, there is no risk of readdition. Since the discussion above is mainly centered on the need of keeping these IDs only because they are useful for finding new P10832 values, it follows that the IDs which cannot be used for this aim, or that would be harmful if used for this aim (because they could lead to adding mismatched IDs), should be deleted, IMHO. --Epìdosis 20:14, 2 June 2023 (UTC)Reply[reply]
@Epìdosis: you shouldn't be removing this property while this deletion request is still open. That's really bad practice and as an administrator on this project you should lead by example.
What you should do is apologize for being to early, undo your batches and wait for a not involved administrator to close the deletion request. Multichill (talk) 14:12, 3 June 2023 (UTC)Reply[reply]
Hi @Multichill:, I partially agree. I apologize for the batch numbered 2 (https://editgroups.toolforge.org/b/QSv2/207071/), which removed the IDs which were present in items not containing a VIAF ID (P214) ID, and I'm now undoing it; although I'm still convinced that some percentage of these IDs is surely there because a VIAF was previously present, then was removed because it was perceived as imprecise or conflated, but the WorldCat Identities ID still remained there, I have effectively no precise clue of how high this percentage is, so I think it is reasonable restoring the entire batch. However, for the other batches I personally don't agree, for the following reason: leaving aside the fact that the property is being deleted, I am still convinced for the above motivations that the IDs removed in the batches 1 and 3 have never been pertinent to the item containing them and thus had to be removed simply because they were mismatched; restoring them and using them for copying new P10832 values could lead to worse conflations, as I (and others) have explained above. For more context, I have recently also removed a batch of 13k VIAFs which were conflated (per this discussion) and I have received no complaint so far; I repeat, it is not a matter of removing values of a identifier proposed for deletion, it is a matter of removing IDs which are mismatched (an operation which is commonly done for identifiers not proposed for deletion). Of course, if you have evidence that my reasoning is wrong and that the IDs removed in batches 1 and 3 are not mismatched, I will apologize also for them and I will immediately undo them. Thanks, --Epìdosis 15:15, 3 June 2023 (UTC)Reply[reply]
That's fine with me. Multichill (talk) 15:22, 3 June 2023 (UTC)Reply[reply]

::::Before talking about migration we need think about how to improve P7859. The removal of wrong IDs is part of the maintenance work. Let's start with Q6243526#P7859: 6 IDs: 5x VIAF, 1x LCCN. After this work is done there are 1.918.337 IDs left to be checked. When all IDs have been checked, we can talk about migration. --Kolja21 (talk) 17:56, 3 June 2023 (UTC) {{Small|I'm boldly suggesting this good faith has in some ways drifted from the topic Removal of P7859 before consensus reached and I've boldly forked it to a new section where that might be moved to in more detail. I hope that OK with everyone. -- DeirgeDel tac 23:40, 3 June 2023 (UTC) Template:Deindent I've had and and having a few pretty busy RL days and I can't spend as much time on this as I'd like. Can I place some comment here in simple form, and I apologise if I'm being stupid. Some of the above discussion can be really hard to read if not read very carefully. If I'm correct @Epìdosis: wishes to run data cleansing batches: -- DeirgeDel tac 23:40, 3 June 2023 (UTC)Reply[reply]

  • P7859 elements will be removed when they refer to "viaf values" ... "viag*. These appears to provide no additional help in identify a P10832 value that the P214 value itself does not already provide. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)Reply[reply]
  • P7859 values that are of the form "lccn*" are not being removed, certainly at this stage, even if they do not currently provide a link a WorldCat Entity Id. -- 23:40, 3 June 2023 (UTC)
  • VIAF itself at times requires data cleansing; I think VIAF sometimes has duplicate Id's that need to be merged. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)Reply[reply]

Apologies if I've got the wrong end of the stick. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)Reply[reply]

@DeirgeDel: of course I confirm that unfortunately VIAF has a lot of duplications (and conflations, more worryingly); regarding the two previous points, it's not exactly what I meant in point 3, I try to explain it differently: nearly all WorldCat Identities values have been imported from VIAF values - so, in cases where the VIAF value A used to import a WorldCat Identities value X isn't present anymore in item Z, my batches just removed the WorldCat Identities value X (whichever form it had, either "viaf-" or "lccn-"), on the basis of the high risk that X was probably a residuate of a conflation of item Z with VIAF value A representing different entities. --Epìdosis 16:50, 4 June 2023 (UTC)Reply[reply]

Pre-migration data cleansing of P7859[edit]

I've felt @Kolja21:'s comment in the Removal of P7859 before consensus reached has moved slightly away and I'd like to look at this use case specifically and perhaps migration / P10832 population separately. I hope to respond detail to this particular use case and I'd not want that wrapped in the above discussion:- Before talking about migration we need think about how to improve P7859. The removal of wrong IDs is part of the maintenance work. Let's start with Q6243526#P7859: 6 IDs: 5x VIAF, 1x LCCN. After this work is done there are 1.918.337 IDs left to be checked. When all IDs have been checked, we can talk about migration. --Kolja21 (talk) 17:56, 3 June 2023 (UTC)Reply[reply]

In this case (as for every other case) we look at the LCCN value, "lccn-no2012115736". That links to a Worldcat identities record that is redirected to the WorldCat Identity Record E39PCjD79fj4FJ7m3KHHvFBWrC. Thus P10832 is a candidate for the value of P10832 and quite frankly The fact that the WorldCat Identity record says it is associated with Wikidata item id Q6243526. Thus I have every confidence P10832 could be rightfully set to the value of "E39PCjD79fj4FJ7m3KHHvFBWrC]" for Q6243526 regards of any mess with state of P7859. In many ways it is easier to focus on getting a value P10832 set rather than migrating it from P7859. P7859 is simply one method that might allow this to happen eeficiently.  – The preceding unsigned comment was added by DeirgeDel (talk • contribs).
I fear the case of Q6243526#P7859 is bit more intricate, because also "viaf-" IDs can be used sometimes to get valid P10832; in this case, 2 out of 5 "viaf-" IDs pointed to presently valid P10832 (so, in fact, P10832 is at least triple for this person presently). In fact: viaf-4896153063221319320008 = viaf-288715031 = viaf-306425053 = https://viaf.org/viaf/306425053/; but lccn-no2012115736 = https://id.oclc.org/worldcat/entity/E39PCjD79fj4FJ7m3KHHvFBWrC.html + viaf-1792159474074827660233 = https://id.oclc.org/worldcat/entity/E39PCjJVGdCdwDVyXRMrJbfd6X.html + viaf-610152636065020050681 = https://id.oclc.org/worldcat/entity/E39PCjF3G4jYpmVQvrJWvhGMbm.html. --Epìdosis 16:50, 4 June 2023 (UTC)Reply[reply]

Practical way of migrating to P10832[edit]

Given the above discussion, I would try to outline a possible path of migrating present P7859 values (WorldCat Identities) to P10832 values (WorldCat Entities). I would start dividing P7859 values in 3 parts:

  1. IDs leading to "Not Found" page (e.g. https://www.wikidata.org/w/index.php?title=Q20009745&oldid=1907624955#P7859)
  2. IDs leading to a VIAF cluster (e.g. https://www.wikidata.org/w/index.php?title=Q21542865&oldid=1908131483#P7859)
  3. IDs leading to a WorldCat Entities entity (e.g. https://www.wikidata.org/w/index.php?title=Q314447&oldid=1890759824#P7859)

I would firstly propose that IDs of the first two parts should be removed; for the third part, they should remain there until the migration is completed. Secondly, if we consider safe adding new P10832 values on the basis of P7859 values (I personally have some doubts, especially for non-human items, but there seems to be consensus for this operation), the migration could simply consist in adding new P10832 on the basis of the redirects of P7859 values (if judged useful, with some sort of reference; otherwise, simply with no reference). I have exemplified the proposed removal here and the proposed migration here (for the proposed migration, we could also decide to use references, as I said). If there is consensus for these two operations, I can perform them through QuickStatements slowly in the next weeks. --Epìdosis 16:50, 4 June 2023 (UTC)Reply[reply]

@@Epìdosis:: I thank you for looking at this in a practical way and I must apologise for the limited time I can put in on this. My focus is on "can-do" of population of accurate P10832 values rather than the removal of other values that are potentially of some us/partial use in P10832 population. I acknowledge that work entities are more problematic in general and that where P7859 yields not found there is a high chance of issues with other identifiers as well, your identification of case 1 Museo di storia naturale di Rosignano (Q20009745) indicating an issue at a bigger level that P7859 and probably ought to be dealt with holistically. Equally an lccn-xxxxx-xxxx with two dashes while leading to not found is in case 1 but can sometimes be resolved by converting the second hyphen to a zero. In terms of your case two example Marco Zanetti (Q21542865) that links to a personal VIAF id and id like to spend time looking at that in detail but I am concerned that case does not extrapolate to every case in that identified group and that in some cases retention might help resolve difficulties. In terms of your example of exemplified removals I take the case of Leonard Lansink (Q100312) where the P7839 entry indicates a WorldCat Entity Id. record might exist. Doing a [4] person search for WorldCat Entities] yields The Worldcat Identity Id record E39PBJtmpJmHRBf7MYHXXWM9Dq Its then important to verify the data in E39PBJtmpJmHRBf7MYHXXWM9Dq matches what is held in the Wikidata item record, e.g. (VIAF ID="303829074", GND ID="115196137" ...) and it is safe to set P10832 to "E39PBJtmpJmHRBf7MYHXXWM9Dq". And that comes on the references to set for P18032. It is possibly useful to set a value to indicate P10832 wwas derived from a WorldCar redirect (on a particualr date), but it would also be useful to indicate that the contents of the WorldCat Entity Id.record contains referneces that indicate corresoonds to the Wikidata Item Id. This is not a reference of the form the GND database has a reference to WorldCat Entity Id (which would be nice but at least isn't happening for the moment) but rather that WorldCat Entity Id record confirms it correspond to GND ID which the Wikidata Id also confirms in relates to. In summary I will b opposing removals certainly for the moment but will be supporting proceeding with case (3) for person entities especially if referencing is agreed and ideally if a method of automation validation can be agreeed. Thankyou. -- DeirgeDel tac 22:24, 4 June 2023 (UTC)Reply[reply]

British Museum bioID (P6077): (delete | history | links | entity usage | logs | discussion)

@ديفيد عادل وهبة خليل 2, YULdigitalpreservation, Pigsonthewing, Cwf97, Jheald, Pintoch: The URL of this property is deprecated since 2020; when resolved anyway, it points to the same URL as British Museum person or institution ID (P1711). I have therefore migrated all uses (120 main, 44 refs) to this property, but it should be noted that for about half of the the 120ish cases as main value the identifiers had changed and pointed to another person, which could have resulted in confusion should this identifier had been kept. Now P6077 isn't used anymore, save for the three examples on the property itself. As it's a de facto duplicate of P1711, I propose that we delete it. —Jahl de Vautban (talk) 08:25, 2 June 2023 (UTC)Reply[reply]

Any issue with making it a redirect?
(assuming that's applicable here, which I realize may not be the case) DS (talk) 23:20, 15 June 2023 (UTC)Reply[reply]

Everipedia ID (P10725): (delete | history | links | entity usage | logs | discussion)

This site has now more or less been shut down - w:Everipedia lists it as "becoming a static archive" but the majority of pages now seem to go to 404s - I sampled 30 of the 94 items, and 11 were still valid. All five of the examples in the original property proposal are also 404s (and two of the items were deleted here as not meeting our own notability proposal).

Disclosure: I opposed this in the original discussion, but I think it has become substantially less useful since then so I am bringing it up as a deletion proposal. —Andrew Gray (talk) 13:33, 25 June 2023 (UTC)Reply[reply]

France Culture person ID (DEPRECATED) (P5301): (delete | history | links | entity usage | logs | discussion)

Replaced by P10780 Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).Reply[reply]

VIGNERON
Mathieudu68
Ayack
Benoît Prieur
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Alphos
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Marianne Casamance
NTranchant
Hyruspex
Pierre André
Bouzinac
Albertvillanovadelmoral
Jsamwrites
Baidax
LearnKnowGive1
Mathieu Kappler
Daieuxetdailleurs
Archives nationales DJI
Jmax
LearnKnowGive1
Koxinga
Maxime
Framawiki
Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).Reply[reply]

Jean-Fred (talk) 22:13, 29 October 2019 (UTC) Ki7sun3 (talk) 22:15, 29 October 2019 (UTC) Battleofalma (talk) 22:36, 29 October 2019 (UTC) Husky (talk) 23:42, 29 October 2019 (UTC) Fuzheado (talk) 02:34, 30 October 2019 (UTC) Ainali (talk) 06:21, 30 October 2019 (UTC) Informatom (talk) 07:48, 30 October 2019 (UTC) Shisma (talk) 07:30, 30 October 2019 (UTC) Richard Nevell (talk) 22:59, 4 November 2019 (UTC) Nickw25 (talk) 07:54, 6 November 2019 (UTC) ElanHR (talk) 18:35, 8 November 2019 (UTC) Vahurzpu (talk) 23:31, 13 April 2020 (UTC) Matlin (talk) 09:39, 11 August 2020 (UTC) Arlo Barnes (talk) 22:50, 21 May 2021 (UTC) Blue Rasberry (talk) 16:16, 22 June 2021 (UTC) Mathieu Kappler (talk) 11:33, 6 September 2021 (UTC) Kristbaum (talk) 23:39, 24 October 2021 (UTC) Germartin1 (talk) 16:53, 3 November 2021 (UTC) RogueScholar (talk) 22:09, 14 October 2022 (UTC) Waldyrious (talk) 12:04, 1 January 2023 (UTC) Trivialist (talk) 02:35, 23 January 2023 (UTC) Maxime (talk) 08:54, 12 July 2023 (UTC) Back ache (talk) 15:33, 22 September 2023 (UTC) Notified participants of WikiProject Podcasts. Nomen ad hoc (talk) 09:17, 27 May 2022 (UTC).Reply[reply]

 Delete : after, of course, migration of all the pages using this "old" property France Culture, to "new" property Radio France... Problem: a contributor of Wikidata is adding since some days this P5301 on many pages!... That will complicating the work of cleaning pages. Maybe a bot could be use to do that? --YANN92340 (talk) 14:15, 10 July 2023 (UTC)Reply[reply]

@YANN92340 , Nomen ad hoc: Is it only fetching the 307 url used in P5301 to set P10780 according to the redirection? -Framawiki (please notify !) (talk) 23:20, 13 July 2023 (UTC)Reply[reply]

Scilit journal ID (P7662): (delete | history | links | entity usage | logs | discussion)

The source website does not keep permanent identifiers for journals. After a website update, all IDs seem to have changed. All (?) IDs in Wikidata seem now either to resolve to a 404 page (Scilit journal ID (P7662) of Journal of inorganic and general chemistry (Q186776), Scilit journal ID (P7662) of Intel Technology Journal (Q130945), Scilit journal ID (P7662) of IEEE Transactions on Mobile Computing (Q129122), ...) or refer to completely different entities now (Scilit journal ID (P7662) of Nucleic Acids Research (Q135122), Scilit journal ID (P7662) of Journal of Chemometrics (Q127755), Scilit journal ID (P7662) of Microscopy Research and Technique (Q59757), ...).

@GZWDer, Eihel: Ping as property creators. --Haansn08 (talk) 21:49, 4 August 2023 (UTC)Reply[reply]

precedes word-initial (P6712): (delete | history | links | entity usage | logs | discussion)

This property may be superseded by a combination of appears before phonological feature (P11950), which is more general with regard to the specification of phonological context, and appears before lexeme form (P11952), which is more specific with regard to specific combinations of forms. Both do not specifically rely on the existence of lexemes with lexical category letter (Q9788) either. —Mahir256 (talk) 19:25, 14 August 2023 (UTC)Reply[reply]

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

Mixer is a streaming service that was closed 4 years ago.

  1. It's useless for external users because all the links are dead
  2. It's useless for us because Mixer basically contained no relevant information about the game (take SMITE as an example: there's game title, game logo, viewer count at random moment of time, and random lowres stream screenshots; nothing can be used in our other properties)
  3. The values we currently have were matched poorly with quite a few false positives. There're hundreds of constraint violations, and most of them are vurtually unsolvable because even the archived versions of the links are usually dead. For instance, both Street Racer (Q7622905) and Street Racer (Q2059628) are linked with the same 404 page

Perhaps I'm missing some services with the same ID scheme that are still alive? In this case we should probably re-arrange the property. Otherwise I don't see a good reason to keep it. —Facenapalm (talk) 12:58, 4 September 2023 (UTC)Reply[reply]

Sigh, all that wasted effort really hurts Trade (talk) 14:13, 4 September 2023 (UTC)Reply[reply]
  •  Comment. The property was already proposed for deletion 3 years ago and I already said back then that it was completely pointless to keep such a property. I still don't understand why it was decided to keep it. Even if we have archive links, they are, as it is correctly pointed out here, almost useless. It is one thing to have a database like USgamer, which is well archived and still useful, but it is quite another to have a database like Mixer, which does not really contain any useful information for Wikidata. With such a property, we have only accumulated a great number of constraint violations. How to address them without being able to find at least some good archived copy is not clear at all. archive.today, the only site that archives JavaScript sites properly, has almost nothing (see [5] or [6], that is certainly not enough). Wayback Machine is not an option at all, as it saved a lot of links with a 404 error. The only thing left to do here is to set a deprecated rank for all values of this property with withdrawn identifier value qualifier or delete property.
By the way, we have a similar property that also experiences a lack of archive links, but here we have a completely different story. This database unlike Mixer (which has only a game title, a logo and a low-resolution cover/screenshot) has at least some basic and more or less useful information. Regards Kirilloparma (talk) 02:46, 5 September 2023 (UTC)Reply[reply]


On hold[edit]

These discussions have been closed but are awaiting deletion.

Implementation notes[edit]

Data has been migrated to catalog code (P528) qualified by IPA number (Q110910334). A few templates need to be updated to use the new format. — Martin (MSGJ · talk) 22:38, 13 February 2022 (UTC)Reply[reply]

@Amitie 10g: please check my edit to es:Plantilla:Ficha de fonema. Thanks — Martin (MSGJ · talk) 22:49, 13 February 2022 (UTC)Reply[reply]

Templates to update:

Notes[edit]

@putnik: parliament.uk biography pages (BEING DELETED) (P1996) has 2045 statements but parliament.uk member ID (P10428) only has 1935. Are you sure all useful data has been migrated? — Martin (MSGJ · talk) 11:49, 18 May 2022 (UTC)Reply[reply]

@MSGJ, yes. parliament.uk biography pages (BEING DELETED) (P1996) has only 1934 unique values. Everything else are duplicate IDs with different links, e.g. commons/mr-nigel-dodds/1388 and commons/nigel-dodds/1388. —putnik 12:36, 18 May 2022 (UTC)Reply[reply]
Thank you for clarifying — Martin (MSGJ · talk) 12:39, 18 May 2022 (UTC)Reply[reply]

All main statements removed. There are about 85 references using this property still remaining — Martin (MSGJ · talk) 21:20, 23 May 2022 (UTC)Reply[reply]

Replace[edit]

I see clear consensus to delete lunar coordinates (BEING REPLACED) (P8981) and replace it with coordinate location (P625). @Mike Peel: do you have a bot to do that? Multichill (talk) 15:41, 17 October 2022 (UTC)Reply[reply]

Thanks for closing it. I should be able to migrate values over soon. Thanks. Mike Peel (talk) 17:48, 18 October 2022 (UTC)Reply[reply]
@Mike Peel: reminder ^ Multichill (talk) 12:58, 25 June 2023 (UTC)Reply[reply]
@Multichill: As I said at Wikidata:Properties for deletion/P10628, this is currently stuck as I don't have an easy way to migrate them while keeping the reference. Thanks. Mike Peel (talk) 14:57, 13 August 2023 (UTC)Reply[reply]