Wikidata:Properties for deletion

Latest comment: 1 day ago by Pallor in topic Property:P6989

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/2024/3.

Requests edit

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

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

Kicker changed its website, and all the IDs that we have stored are invalid now. Therefore this property is not useful anymore. Steak (talk) 15:38, 16 September 2020 (UTC)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
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
Kicker.de player ID (actual scheme) (P8912) has been created. Pamputt (talk) 21:29, 4 December 2020 (UTC)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

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

@Jura1, MSGJ, Butko, Eurohunter, Kirilloparma, Putnik: There are no Wikidata items left that have this property. Please check further to make a decision on permanent deletion. MasterRus21thCentury (talk) 18:11, 14 November 2023 (UTC)Reply

You're a bit late to the party. Since all properties from the old version have already been moved to the new property and the old ones have been deleted. I think that in this case there is no need to keep two (three) different properties for two versions of the same site, given that the material on the site itself has not changed. The same articles now have a new sequential numeric system of identifiers, which required manual replacement. And as I have already said in the discussion of the Bashkir version, I feel that no more than 10% of the articles have been preserved in the archive. The Bashkir version is also almost done, having ~100 left. Solidest (talk) 22:11, 14 November 2023 (UTC)Reply
@Solidest In the near future I will finish analyzing the identifiers of the Bashkir version and from this it will be possible to raise the question of the final removal of properties. MasterRus21thCentury (talk) 16:29, 15 November 2023 (UTC)Reply
@MasterRus21thCentury: I have already prepared the lists for making quick replacements:
So it just needs some gradual work to find titles and update ids on WD. Solidest (talk) 16:47, 15 November 2023 (UTC)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

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
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
@З. ӘЙЛЕ: 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
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
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
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
@Solidest, Eurohunter, Jura1, З. ӘЙЛЕ, putnik, Epidosis:, @Carn, Сидик из ПТУ, Arbnos, Wikisaurus, Visem: removed all existing values in Wikidata elements, replacing the old identifier with a new one. At the same time, some identifiers are only in the Bashkir language. MasterRus21thCentury (talk) 08:34, 7 January 2024 (UTC)Reply
It's not Wikidata problem that ID isn't available anymore. Once it existed should be kept as outdated ID. Eurohunter (talk) 08:38, 7 January 2024 (UTC)Reply

English Vikidia ID (P7829) edit

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

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) — Haseeb (talk) 13:10, 4 August 2023 (UTC) 13:26, 15 November 2023 (UTC)Reply
Notified participants of WikiProject Authority controlKethyga (talk) 14:29, 10 April 2022 (UTC)Reply

Property:P5176 edit

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

 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
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
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

Property:P10692 edit

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

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

Property:P2263 edit

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

The formatter URL (P1630) syntax seems to have changed? The isocat.org webserver seems to have moved to https://datcatinfo.net/. Seems to be a defined, active ISO project, if unhealthy, per the talk page - Property_talk:P2263. The ISO does important work. https://en.wikipedia.org/wiki/Linguistic_categories#ISO_12620_(ISO_TC37_Data_Category_Registry,_ISOcat) explains what ISOCAT is. Maybe hold on or move, since " DatCatInfo is the Data Category Repository (DCR) that replaces the former ISOcat "? RudolfoMD (talk) 23:15, 23 October 2023 (UTC)Reply

Property:P4547 edit

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

Winterthur Glossar URL (DEPRECATED) (P6107) edit

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

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

Property:P10724 edit

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

Lacking notability. 10:26, 3 October 2022 (UTC)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
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

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

  •  Delete Gibberish contents with nothing given even small notabilities. --Liuxinyu970226 (talk) 07:03, 16 October 2022 (UTC)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
  •  Delete barely used identifier of spin-off of user-generated narrowly focused database. --Jklamo (talk) 14:17, 19 October 2022 (UTC)Reply
    narrowly focused? C933103 (talk) 17:46, 20 October 2022 (UTC)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
    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

Wikidata item of this property (P1629) Q111607789 has been deleted for lacking notability. This property should also be deleted. -- 12:09, 10 December 2023 (UTC)Reply

Property:P10589 edit

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

 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. ChristianKl15:12, 7 November 2022 (UTC)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
Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl00:15, 10 November 2022 (UTC)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
 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
 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
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
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. ChristianKl00:13, 10 November 2022 (UTC)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
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. ChristianKl12:20, 12 November 2022 (UTC)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
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
  •  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
@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
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
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
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
The Internet Archive is also recognised as a library by the US government. Thibaut (talk) 10:39, 13 February 2023 (UTC)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
    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
    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
    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. ChristianKl11:12, 27 November 2022 (UTC)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
     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
  • 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
  •  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
    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
     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
    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
  •  Delete per the above copyright and legal concerns. ミラP@Miraclepine 19:47, 9 December 2022 (UTC)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
  •  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
  •  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
 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
 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
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
A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)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
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
 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
 Delete - Link to a site that is a violation of copyright law. --Fralambert (talk) 19:22, 12 March 2023 (UTC)Reply
 Keep As far as I am aware:
1. MangaDex acts in full compliance with U.S. law under the DMCA act
2. MangaDex has never faced charges for hosting what they do. (they have been subpoenaed once, but that's very much not the same thing) Binarycat32 (talk) 00:52, 31 January 2024 (UTC)Reply
@Binarycat32: One of their staff literally says that "Mangadex doesn’t adhere to DMCA requests".
Speaking of DMCA, see also above. Thibaut (talk) 06:06, 31 January 2024 (UTC)Reply
  •  Delete the copyright problem alone is enough to delete (in itself and because this make this website less likely to be perennial). In addition to that, I see that this property is use only on ~2800 items and ~25000 references, plus in most cases there is other identifiers and others references. It's maybe a "gold mine of information" but it's clearly not the only one, deleting these data would mean only a negligible lack of information in the end. Cheers, VIGNERON (talk) 15:30, 1 February 2024 (UTC)Reply
    "in most cases there is other identifiers"
    a lot of those identifiers have been imported from mangadex. as far as i'm aware, mangadex is the only site other than wikidata that maintains links to other manga sites in this way. Binarycat32 (talk) 22:05, 2 February 2024 (UTC)Reply
    It is possible to correlate titles with their MangaDex IDs but it would require maintaining a database of MD ids and other IDs linked to MD and then regularly updating this database both with new titles and if existing titles change their IDs. RPI2026F1 (talk) 02:39, 3 February 2024 (UTC)Reply
    There's already a bot that does all of that, besides changing IDs, which happens approximately never. Binarycat32 (talk) 00:09, 5 February 2024 (UTC)Reply
    Yea, that's me, I wrote the bot that does that RPI2026F1 (talk) 01:26, 5 February 2024 (UTC)Reply
    Yeah I wondered as much, but I figured someone wouldn't write a bot then act like it didn't exist. Binarycat32 (talk) 18:30, 5 February 2024 (UTC)Reply
    The current problem with said bot is that it only adds stuff from given properties. Basically, it won't try to approximate a MangaDex ID from just the MAL ID, but it will add a MAL ID if there is a MangaDex ID because MangaDex lists a MAL ID for that entry. RPI2026F1 (talk) 13:19, 6 February 2024 (UTC)Reply
    finding the mangadex id is fairly easy with animanga-db-matcher[3]. however, this tool does not work well (or at all) for several other sites that often have their identifiers listed on MangaDex. Binarycat32 (talk) 18:51, 8 February 2024 (UTC)Reply
    Yea that would be my bad, I wrote that tool as well but I had a very limited understanding of React and I found it easier to work on the auto-import bot than the finder. The reason it's not as effective is because I designed it for items that had no identifiers whatsoever, and at that point title searching was the only way to find potential IDs. I could make a future update that looks up other identifiers as well. RPI2026F1 (talk) 21:03, 8 February 2024 (UTC)Reply

Property:P1076 edit

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

"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
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
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
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
@DoublePendulumAttractor: 20162096 (=Hantaan orthohantavirus (Q29002506)) and 20152096 (=Tulare apple mosaic virus (Q7851962)). BTW:  Delete. --Succu (talk) 19:43, 15 May 2023 (UTC)Reply
 Delete by arguments Succu. --Ыфь77 (talk) 19:16, 19 September 2023 (UTC)Reply

Property:P10241 edit

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. ChristianKl14:00, 7 January 2023 (UTC)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
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

Property:P4981 edit

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

@Anvilaquarius, what do you (as the proposer) think about the further usage of this property? Yellowcard (talk) 15:38, 17 February 2023 (UTC)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
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
@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
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
 Keep historic data can be useful. ChristianKl15:59, 26 December 2023 (UTC)Reply

Property:P6205 edit

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

 Delete because it's unused. ChristianKl15:58, 26 December 2023 (UTC)Reply

Property:P7859 edit

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

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
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
@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
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
@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
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
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
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
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
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
"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
  •  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
@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
  •  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
  •  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
    Å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
    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

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

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

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

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
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
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
@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
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
That's fine with me. Multichill (talk) 15:22, 3 June 2023 (UTC)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

  • 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
  • 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

Apologies if I've got the wrong end of the stick. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)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

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

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

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

@@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

New proposed plan for migration to P10832 edit

Nine months after my previous plan, I would like to draft a second, more detailed one, articulated in the following 5 ordered steps:

  1. find P10832 through Library of Congress authority ID (P244): use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/NOsygr to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)Library of Congress Authorities (Q13219454) + Library of Congress authority ID (P244)id + retrieved (P813)retrieval date
  2. find P10832 through VIAF ID (P214): use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/rktIZX to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)Virtual International Authority File (Q54919) + VIAF ID (P214)id + retrieved (P813)retrieval date
  3. find P10832 through P7859: use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/TbOMjH to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)WorldCat Identities (Q76630151) + retrieved (P813)retrieval date
  4. delete P7859 values in main statements (query: https://qlever.cs.uni-freiburg.de/wikidata/Zi6JSH) and references containing P7859 values (query: https://qlever.cs.uni-freiburg.de/wikidata/i1e1mT)
  5. delete P7859

Any comments are welcome! --Epìdosis 18:01, 16 March 2024 (UTC)Reply

I like this series of steps! I am attempting to compile lists of values with respect to the first three steps, although I don't know how fast I can make this compilation happen. Mahir256 (talk) 18:54, 16 March 2024 (UTC)Reply

Property:P6077 edit

British Museum bioID (superseded) (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

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
I'm not sure if it's technically possible but given the fact that some IDs now redirect to others persons I fear that this will only create confusion. As of today I have again removed any use of this property as main statements and references and have also modified the labels and description of the property to reflect that it shouldn't be used. --Jahl de Vautban (talk) 20:00, 12 March 2024 (UTC)Reply

Property:P5301 edit

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

Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).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) Egon Willighagen (talk) 16:48, 13 January 2024 (UTC) User:Jrubashk (talk) 9:50, 11 February 2024 (UTC)Reply
Notified participants of WikiProject Podcasts. Nomen ad hoc (talk) 09:17, 27 May 2022 (UTC).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

@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

 Delete I have imported the Radio France ID. In these cases, I deleted the obsolete identifiers. There are probably still some Radio France and France Culture identifiers (duplicate items, one with Radio France, the other with France Culture), but these cases should be rare. --Hamuli (talk) 19:44, 4 October 2023 (UTC)Reply

Property:P7662 edit

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

Property:P1129 edit

national team appearances (P1129): (delete | history | links | entity usage | logs | discussion)

We have number of matches played/races/starts (P1350) to express the number of games for any team as a qualifier. This is used currently more than 700,000 times, also for national teams – as number of matches played/races/starts (P1350) is generic, it can be used for all kinds of teams, from youth teams to national teams. There is no need for national team appearances (P1129) besides number of matches played/races/starts (P1350), but the co-existence and mixture creates problems when using the data outside of Wikidata. Therefore, I propose to change the 5,000 usages of national team appearances (P1129) to number of matches played/races/starts (P1350) and then delete national team appearances (P1129). —Yellowcard (talk) 18:24, 10 October 2023 (UTC)Reply

Property:P2650 edit

interested in (P2650): (delete | history | links | entity usage | logs | discussion)

This is a follow-up of Wikidata:Project chat#Interested in vs. Field of work (opened by @Daask: on 18 October): as argumented by many users there, the difference between interested in (P2650) (with 17k uses in main statements) and the older field of work (P101) (with 938k uses in main statements) is not clear enough; whilst it has been said that P101 is for professional areas and P2650 for non-professional areas, it seems that presently both properties have been used for both fields, and there is a high probability that this confusion will worsen in the future; thus, following the proposal of @Vojtěch Dostál:, I agree that we can "merge the duplicates and start a new proposal if required for some other (or perhaps the originally intended) use case". So I'm proposing to delete P2650, bot-transferring all its values to P101; I'm not fully convinced that we need another property besides P101, but if someone wants to propose it in the future, this deletion wouldn't hinder them from doing it. Otherwise, if we choose not to delete P2650, I think we need to 1) state much more clearly how it differs from P101 and 2) find effective methods to move wrong uses of P2650 to P101 and viceversa (note: wrong according to the clearer definition of P2650 foreshadowed at point 1). —Epìdosis 19:20, 25 October 2023 (UTC)Reply

There is possible merit in it for people's hobbies (as was argued for fictional characters where field of work (P101) read oddly), but I can see no merit for organisations, all uses there should be transferred. Vicarage (talk) 21:23, 25 October 2023 (UTC)Reply
 Weak support P2650 is hardly used at all in the arts domain (artists with P2650). P2650 does not meet any need in this domain that P101 or inspired by (P941) cannot meet. But I cannot speak for other domains... Fjjulien (talk) 19:57, 1 December 2023 (UTC)Reply

Before deletion we need an analysis of the current uses so we can inform people. Since it was originally proposed for WikiProjects I assume it was in use for a few, but could never have been many, because I would have seen it pop up in the proposal discussions for on focus list of Wikimedia project (P5008). Jane023 (talk) 08:36, 27 October 2023 (UTC)Reply

@Jane023: A quick SPARQL query indicates that it is currently in use on 18 WikiProject items. Daask (talk) 13:43, 27 October 2023 (UTC)Reply
Thanks! It's interesting to see the minimal information for such projects on Wikidata - the first page I looked at, Wikidata:WikiProject Moravian Knowledge Network Research, doesn't even point to any external site in the wikiverrse or otherwise. It's probably a good idea to start a larger campaign to clean this up. Jane023 (talk) 14:11, 27 October 2023 (UTC)Reply

Property:P8895 edit

All the Tropes ID (P8895): (delete | history | links | entity usage | logs | discussion)

Now that Property:P11250 exists this identifer is redundant. All we have to do is to move all instances of this identifier to Miraheze article ID (P11250) and add a allthetropes: in front of the original value (All the Tropes ID (P8895) > Future_Diary/Characters#Yuno_Gasai_-_The_2nd becomes Miraheze article ID (P11250) > allthetropes:Future_Diary/Characters#Yuno_Gasai_-_The_2nd and etc) Trade (talk) 14:29, 7 October 2023 (UTC)Reply

@Shisma, Lockal, MJL:--Trade (talk) 22:27, 7 October 2023 (UTC)Reply
Would your bot have time to move the identifiers if necessary? @BrokenSegue:--Trade (talk) 01:35, 8 October 2023 (UTC)Reply
 Support after migration is completed Shisma (talk) 07:55, 19 October 2023 (UTC)Reply
I changed my mind. –Shisma (talk) 08:00, 8 November 2023 (UTC)Reply
 Support Arlo Barnes (talk) 16:03, 12 October 2023 (UTC)Reply
 Oppose. Sorry, I don't understand the reason. When All the Tropes identifier was originally created, I did not even know that it was a Mirahese project. It is a problem of discoverability: other editors also won't know that to add "All the Tropes" they need to add Mirahese. Calling it obsolete is like calling all prefix-based redirectors like identifiers.org, DOI or even Special:GoToInterwiki/wikia:Projectname:Article_name superior to original websites. Lockal (talk) 10:10, 16 October 2023 (UTC)Reply
don't you think the discoverability problem can be solved by adding "All the Tropes ID" as an alias to the Miraheze article ID (P11250) property? Shisma (talk) 08:14, 19 October 2023 (UTC)Reply
@Lockal, MJL, Trade: a seperate property has the advantage of being more stable. Should the All the Tropes community should decide to migrate away from Mirahese (migrations in and out of wiki farms happen, I hear), this property can be changed to resolve to a different url: problem solved. I propose: lets  Keep this property and consider it a more precise subproperty of Miraheze article ID (P11250). Furthermore, lets avoid redundancy by using the more precise property where possible, employing constraints. this approach can be applied going forward with new properties pointing to wiki farms or wiki networksShisma (talk) 08:23, 8 November 2023 (UTC)Reply
I dont see the advantage. If ATT moves farm, we can simply migrate the ID'a to the new farm identifier Trade (talk) 16:05, 21 November 2023 (UTC)Reply
 Keep per Shisma. Lewis Hulbert (talk) 22:37, 8 November 2023 (UTC)Reply

Property:P6096 edit

FLOW ID (P6096): (delete | history | links | entity usage | logs | discussion)

The property was created without addressing concerns on its proposal page. In general I support the creation of the property, but I'm not sure what to do in this case. —Tomodachi94 (he/him · talk) 04:49, 8 October 2023 (UTC)Reply

@Pintoch: could you elaborate on why this property was created without addressing Lymantria's concern? —Tomodachi94 (he/him · talk) 04:49, 8 October 2023 (UTC)Reply
@Tomodachi94: since it was marked as a "comment" and not as an "oppose" I probably did not see it as being a blocker. By the way, I would recommend restoring the state of the property proposal page: someone removed the comments there about the property being created, which gives a rather confusing log I would say… I would recommend restoring the page in its previous state. − Pintoch (talk) 17:55, 8 October 2023 (UTC)Reply

Property:P4830 edit

SvFF national player ID (archived) (P4830): (delete | history | links | entity usage | logs | discussion)

Branches only to the archive version of the database, for running url there is Schwedische Fußballassoziation ID (P1238), see Property_talk:P4830 without an answer; verzweigt nur auf die Archivversion der Datenbank, für laufende url gibt es Schwedische Fußballassoziation ID (P1238), siehe Property_talk:P4830 ohne Antwort --Nordprinz (talk) 18:53, 24 October 2023 (UTC)Reply

Property:P5400 edit

GeoNLP ID (obsolete) (P5400): (delete | history | links | entity usage | logs | discussion)

Following the upgrade of GeoNLP to version 2.0 on July 8, 2021, the existing GeoNLP IDs have been invalidated and replaced with new identifiers called GeoLOD IDs. Due to the lack of compatibility between GeoNLP IDs and GeoLOD IDs, which no longer function as identifiers for the same entities, it is necessary to delete the GeoNLP ID property from Wikidata and create a new property corresponding to GeoLOD IDs. This request is based on official announcements from GeoNLP ('Release of GeoNLP Version 2.0' and 'About the major renewal of GeoNLP'). Therefore, I request the deletion of the GeoNLP ID property. —Likibp (talk) 10:14, 5 November 2023 (UTC)Reply

GeoLOD ID (P12170) has now been created. Jonathan Groß (talk) 20:00, 22 November 2023 (UTC)Reply

Property:P6989 edit

Hungarian National Namespace organisation ID (old) (P6989): (delete | history | links | entity usage | logs | discussion)

The property IDs and the formatting URL have also changed. A new property (Hungarian National Namespace organisation ID (new) (P11685)) was created, which was added to all old (P6989) data with the new identifier. This property is deprecated and can be deleted. (Control query: https://w.wiki/8JmT) —Pallor (talk) 18:21, 28 November 2023 (UTC)Reply

  •  Keep It is still valuable information. While the official website (abcd.hu) is no longer available, these statements can still help match IDs found elsewhere to Wikidata items (and through them, even to new MNN IDs). —Tacsipacsi (talk) 15:16, 2 December 2023 (UTC)Reply
Tacsipacsi Can you list the data that is available on the old form with the old ID but not on the new ABCD? (otherwise the abcd.hu site is available). So what data would be lost if we delete the identifier? Pallor (talk) 17:25, 2 December 2023 (UTC)Reply
@Pallor: What we would lose is the fact that the MNN ID of the National Assembly (Q648716) using the old scheme is 204006. External identifiers are pieces of information themselves, not only references for other pieces of information. It may happen that third-party data reusers (or even ourselves) find a reference to an organization that uses this old scheme. Removing these statements would make it impossible to process that reference (at least without digging into item histories, which is probably not something one would want to do or want to write a program for). —Tacsipacsi (talk) 19:55, 2 December 2023 (UTC)Reply
@Tacsipacsi: By this argument, I think we could completely eliminate the deletion of external IDs for property IDs, since you argue that, whatever the topic, each ID carries information. But the practice is not: if the IDs do not lead to information that would be lost without them, then feel free to delete them. And these IDs do not carry any information, since everything that was on the page accessed with the previous ID is also on the page accessed with the new ID. Pallor (talk) 22:03, 2 December 2023 (UTC)Reply
Indeed, I generally don’t agree with the deletion of external ID properties unless creating them has never been a good idea (e.g. it is, and has always been, totally useless), or for technical reasons (including cases when a new property was created after a schema change for technical reasons, but the old ID can be algorithmically determined from the new one). I may be in minority with this opinion, though; if the vast majority of users who comment in this discussion are in favor of the deletion, I’ll accept the community decision. —Tacsipacsi (talk) 01:26, 3 December 2023 (UTC)Reply
I second all that Tacsipacsi wrote.  Keep! I don't see the value in deleting defunct IDs either. – Máté (talk) 20:51, 28 January 2024 (UTC)Reply
Both opinions represent a point of view that could be added to virtually all properties for deletion ("keep it because it's valuable"), but they don't explain what the value is in an unused and unrecoverable identifier. Such a belief essentially makes cancellation discussions impossible, since it is too general and elusive to be considered as an argument and to respond to it in a meaningful way.
As additional information, I describe that the database currently consists of 62,060 items, of which 35 items have been transferred to Wikidata. No data can be read back from any of them, on the other hand, the new identifier makes all data available. I still maintain my deletion proposal. Pallor (talk) 21:43, 17 March 2024 (UTC)Reply

Property:P2123 edit

YerelNet village ID (P2123): (delete | history | links | entity usage | logs | discussion)

Yerelnet website was a government-supported website in Turkey. There was an identifier id for every village in Turkey and it had an index about all villages. However, this project was terminated by a law in 2018. The domain name of the site (https://www.yerelnet.org.tr) is currently used for personal purposes and the site does not currently serve as a database. Also, all id numbers added to wikidata pages are currently not working. For these reasons, it would be appropriate to delete Property:P2123. —Sadrettin (talk) 15:34, 3 December 2023 (UTC)Reply

 Delete It seems that this site is currently not working. It is better to make it stop. Mereyü 💬/✉️ 16:06, 3 December 2023 (UTC)Reply
 Delete Right. Yerelnet is not working anymore. We don't need this property. --Kurmanbek💬 16:23, 6 December 2023 (UTC)Reply
@Sadrettin: Have you exported the current IDs (for historical purposes)?--Geverkshaft (talk) 10:18, 17 December 2023 (UTC)Reply
 Delete Looks reasonable. Nanahuatl (talk) 18:54, 27 December 2023 (UTC)Reply
 Keep for now, as it's the only way to find villages (or places that were villages until recently) in a district (although now several years out of date). Many have been archived or included in an archived list from which the identifier can be found. It was mostly accurate, although because places could be added it had a few (around 5-10) additions that were not part of the data originally added to the site that were probably neighbourhoods or other locations (although I'm not sure if any of these are in Wikidata). Otherwise the P31 can be vague (Erikli, Bozüyük (Q1155400) for example, which otherwise only has a GeoNames ID). Wikidata:Property proposal/Tüik number needs proposing as separate properties, including one for village; when approved and added to items, it can replace this. Peter James (talk) 21:03, 4 February 2024 (UTC)Reply
I also noticed most instances of mahalle (Q17051044) were changed to neighborhood (Q123705) (which seems incorrect, as is the statement that Q123705 is a subclass of designation for an administrative territorial entity (Q15617994) - and in most countries Q123705 isn't an instance of that either). Instances of village in Turkey (Q1529096) would then become village (Q532) to be consistent, although I prefer more specific administrative units for Wikidata - at least make it clear whether something is an administrative unit or not. Adding statements such as that in Q123705 (or quarter (Q2983893), where the claim to be a subclass of administrative territorial entity (Q56061) is wrong in some countries and conflicts with the description) is not the correct way to clarify this, or to fix constraint violations, or whatever was intended. Peter James (talk) 01:38, 18 February 2024 (UTC)Reply

Property:P3809 edit

YerelNET district ID (P3809): (delete | history | links | entity usage | logs | discussion)

YerelNet website was a government-supported website in Turkey. There was an identifier id for every district in Turkey and it had an index about all district. However, this project was terminated by a law in 2018. The domain name of the site (https://www.yerelnet.org.tr) is currently used for personal purposes and the site does not currently serve as a database. Also, all id numbers added to wikidata pages are currently not working. For these reasons, it would be appropriate to delete Property:P3809. —Sadrettin (talk) 15:44, 3 December 2023 (UTC)Reply

 Delete It seems that this site is currently not working. It is better to make it stop. Mereyü 💬/✉️ 16:07, 3 December 2023 (UTC)Reply
 Delete Right. Yerelnet is not working anymore. We don't need this property. --Kurmanbek💬 16:23, 6 December 2023 (UTC)Reply
 Delete Looks reasonable. Nanahuatl (talk) 18:54, 27 December 2023 (UTC)Reply

player properties for Japan Rugby Football Union edit

I'd like to propose deletion of these 3 properties in order to unify them into Japan Rugby Football Union player ID (P4937). Please see Property_talk:P4937#Note_about_this_property for prior discussion. All these 4 properties share the ID namespace, and are accessible with the same generic URL. I think this distinction is needless and these 4 properties should be unified. Please note that nobody uses after the creation of P4938, P4940, and P4941. French Wikipedia has tracking categories for these 3, but no pages are included. ― Mzaki (talk) 10:28, 23 January 2024 (UTC)Reply

@Mzaki:, I am not sure to understand. You're telling that the mentioned properties should be deleted because Japan Rugby Football Union player ID (P4937) fits for all them? -- Blackcat 19:30, 23 January 2024 (UTC)Reply
Yes, as already mentioned by @Daxipedia. Mzaki (talk) 03:53, 2 February 2024 (UTC)Reply

Possible stakeholders:

  1.  Support In favor of merger : as explained, as the four properties have now a shared URL structure, they can be merged (or, I guess in other words, 3 of them can be deleted in order to keep a unique one). For exemple, with the update of the federation website, en.rugby-japan.jp/sevens-womens/member/detail/$1 can now be replaced by rugby-japan.jp/player/$1, which includes men/women category and rugby union/sevens code in one unique URL. After that, P4937 can be renamed Japan Rugby Football Union ID instead of Japan Rugby Football Union men's player ID. - Daxipedia - 達克斯百科 (talk) 20:04, 23 January 2024 (UTC)Reply
  2.  Support if it's like descripted by Daxipedia. -- Blackcat 22:27, 23 January 2024 (UTC)Reply

Deeming the agreement reached without objection for almost a month, I have moved existing statements of P4938, P4940, and P4941 into that of P4937 in this edit.--Mzaki (talk) 14:08, 20 February 2024 (UTC)Reply

Property:P10863 edit

Springer Nature article ID (P10863): (delete | history | links | entity usage | logs | discussion)

It was suggested back in April that this property be deleted due to the source for these now being dead and these values merely duplicating DOIs (which are already present as DOI (P356) statements).

@BeLucky, Trade, Pamputt, AdamSeattle: from the property's proposal, and @Bean49, Lockal, Egon Willighagen: from the property's talk page. Mahir256 (talk) 03:32, 29 January 2024 (UTC)Reply

 Support - BeLucky (talk) 14:15, 29 January 2024 (UTC)Reply
 Support --Egon Willighagen (talk) 06:53, 30 January 2024 (UTC)Reply
 Support Samoasambia 21:25, 21 February 2024 (UTC)Reply
 Support --Konstantina07 (talk) 00:06, 26 February 2024 (UTC)Reply

Property:P11456 and Property:P11457 edit

The Macmillan Dictionary website closed in June 2023.

(While I must note that both sites have many of their entries listed in the Internet Archive, I personally am not a fan of identifiers which are, in large part, reproductions or trivial modifications to the lemma of a lexeme.)

@AdamSeattle, Prburley, Metadataguy, Wd-Ryan, Clements.UWLib, Emwille: from the property proposal, and @Akaibu: who brought this to my attention initially. Mahir256 (talk) 15:56, 1 February 2024 (UTC)Reply

  •  Support deletion
AdamSeattle (talk) 02:27, 2 February 2024 (UTC)Reply


Property:P2490 edit

page at OSTIS Belarus Wiki (P2490): (delete | history | links | entity usage | logs | discussion)

Created 2016-01-17 but only 18 main statements, target not usefull CV213 (talk) 16:54, 10 February 2024 (UTC)Reply

Property:P4001 edit

Latvian Protected Nature Territory URL (P4001): (delete | history | links | entity usage | logs | discussion)

Created 2017-05-30 but only 2 main statements, wrong datatype as noted 2022-02-25 on talk page CV213 (talk) 17:11, 10 February 2024 (UTC)Reply

if somebody could change datatype, I could fill the property for relevant items. Edgars2007 (talk) 15:41, 15 March 2024 (UTC)Reply

Property:P593 edit

HomoloGene ID (P593): (delete | history | links | entity usage | logs | discussion)

Not a single link seems to work, no verification of correctness possible, notably the first example in the propertiy examples is a protein, but Domain is defined as Gene CV213 (talk) 19:13, 12 February 2024 (UTC)Reply

Property:P2488 edit

Belarus Globe URL (P2488): (delete | history | links | entity usage | logs | discussion)

Recreate as external-id. Wrong datatype, base url changed from http://globus.tut.by to https://globustut.by/ - with type external-id the switch would have been easy, currently 2158 main statements, no easy check which URLs are broken which not CV213 (talk) 17:57, 21 February 2024 (UTC)Reply

support BrokenSegue (talk) 22:47, 21 February 2024 (UTC)Reply

Property:P4997 edit

National Governors Association biography URL (P4997): (delete | history | links | entity usage | logs | discussion)

Recreate with datatype external-id - out of 2435 values 2431 follow the pattern https://www.nga.org/governor/-some-id-/ - of the other 4 one is a spouse, and three are broken CV213 (talk) 19:15, 21 February 2024 (UTC)Reply

support BrokenSegue (talk) 22:47, 21 February 2024 (UTC)Reply

Property:P5178 edit

glossary entry at Wikipedia URL (P5178): (delete | history | links | entity usage | logs | discussion)

Created 2018-05-20, below 100 to enwiki, one to itwiki, no other, proposal has motivation "Sitelinks aren't possible." but they are. No enforcement of uniqueness or control whether link still valid. All this is possible in the Wikipedias themselves and should be no business of Wikidata CV213 (talk) 14:14, 22 February 2024 (UTC)Reply

Since we now support sitelinks to redirects, support deletion but first replace all occurences with redirects (if there are no such redirects, create one).--GZWDer (talk) 11:33, 23 February 2024 (UTC)Reply

Property:P12270 edit

Flora of the Hawaiian Islands URL (P12270): (delete | history | links | entity usage | logs | discussion)

Wrong datatype, should be external-id, each species has an id https://naturalhistory2.si.edu/botany/hawaiianflora/speciesdescr.cfm?species=tetragonioides, the re-purposing of the property after creation should not be counted as a reason against, genera can go into a separate external-id property, URL-properties waste space. "https://naturalhistory2.si.edu/botany/hawaiianflora/speciesdescr.cfm?species=" can go into the formatter. CV213 (talk) 14:24, 22 February 2024 (UTC)Reply

Property:P9748 edit

Wikimedia Incubator URL (P9748): (delete | history | links | entity usage | logs | discussion)

Recreate with datatype external-id, "https://incubator.wikimedia.org/wiki/" can go into the formatter. CV213 (talk) 14:32, 22 February 2024 (UTC)Reply

Property:P12273 edit

Montana Plant Life URL (P12273): (delete | history | links | entity usage | logs | discussion)

Recreate as external id, the base-url changed from http to https, if the property would have been created as external-id the switch would be easy. https://montana.plant-life.org/cgi-bin/ can go into the formatter CV213 (talk) 20:11, 22 February 2024 (UTC)Reply

No strong opinion here, but it should be easy for a bot to switch these values from http to https. From the talk page there are only 152 uses. ArthurPSmith (talk) 11:30, 27 February 2024 (UTC)Reply

Property:P3553 edit

Zhihu topic ID (P3553): (delete | history | links | entity usage | logs | discussion)

The website Zhihu (知乎) is listed as deprecated source on Chinese Wikipedia. Edit filter is triggered when relavent link is added. --EleniXDD (talk) 11:53, 26 February 2024 (UTC)Reply

Wikipedia and Wikidata are totally different websites.--GZWDer (talk) 10:55, 27 February 2024 (UTC)Reply

Property:P8350 edit

Singapore Infopedia ID (former scheme) (P8350): (delete | history | links | entity usage | logs | discussion)

The URIs of Singapore Infopedia articles had been amended. For example, the URI for the article of Siva Choy https://eresources.nlb.gov.sg/infopedia/articles/SIP_1665_2010-04-28.html is replaced by https://www.nlb.gov.sg/main/article-detail?cmsuuid=8709468f-f41f-44b4-9e8a-ef6ac25accfe. We would like to propose a new property of the same name Singapore Infopedia ID to replace the current property P8350. The request for a new property was made at Wikidata:Property proposal/Singapore Infopedia ID (new scheme). The label of P8350 had been renamed Singapore Infopedia ID (former scheme). —Nlbkos (talk) 05:38, 26 February 2024 (UTC)Reply

Property:P4454 edit

Argentine Chamber of Deputies ID (P4454): (delete | history | links | entity usage | logs | discussion)

Initially discovered because the ID's links were timing out. Looking at the spanish webpage (https://www.hcdn.gob.ar/diputados/index.html) it appears that only current politicians have a profile, but ideally an extra set of eyeballs would be nice for a confirmation. Anyways, since the identifiers are unstable, there is no point in a property and so it shall be deleted. —Infrastruktur (talk) 15:33, 10 March 2024 (UTC)Reply

 Keep Unless the IDs are entirely transient (i.e. get re-used for someone else) that only seems like a reason to update or remove the links, not to remove the property entirely. Not having a current profile page doesn't mean that the IDs aren't used elsewhere on the site, or won't be included in future if the person is re-elected or the site is redesigned, or that these IDs aren't in use in historic data-dumps etc. I don't understand why we would want to throw that information away. Oravrattas (talk) 16:08, 10 March 2024 (UTC)Reply
If the site does not employ a scheme to prevent reuse of identifiers then reuse is a distinct possibility. The identifier seems to be based on one letter for given names and the whole surname. And surnames are reused all the time, making ID collisions fairly likely. Infrastruktur (talk) 17:00, 10 March 2024 (UTC)Reply
Do you have examples of this ever happening? The idea that an identifier might get reused seems pretty thin as a rationale for deleting a well-used property. Oravrattas (talk) 01:17, 13 March 2024 (UTC)Reply

On hold edit

These discussions have been closed but are awaiting deletion.

IPA number order (BEING DELETED) (P3917) edit

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

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

Templates to update:

Property:P1996 edit

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

@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
Thank you for clarifying — Martin (MSGJ · talk) 12:39, 18 May 2022 (UTC)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

Property:P8981 edit

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

Thanks for closing it. I should be able to migrate values over soon. Thanks. Mike Peel (talk) 17:48, 18 October 2022 (UTC)Reply
@Mike Peel: reminder ^ Multichill (talk) 12:58, 25 June 2023 (UTC)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
@Multichill, Mike Peel: Manual replacement has been completed. Sourced from Gazetteer of Planetary Nomenclature (Q24033439). --Bamyers99 (talk) 23:53, 20 December 2023 (UTC)Reply