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:

To merge a property to another, or request to deprecate a property in favor of another.
To change the data type of a property currently being used.
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:

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

Translate this header box!

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

Requests Edit

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

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

many of the id's links are archived. e.g. this one. though the link format is broken at the moment. deprecate and mark as obsolete but keep. here's a list of archived entries. BrokenSegue (talk) 16:51, 16 September 2020 (UTC)Reply[reply]

If this property is deleted, the non-numeric identifiers should be transferred to the new property prior to being removed. S.A. Julio (talk) 17:28, 27 October 2020 (UTC)Reply[reply]

Kicker.de player ID (actual scheme) (P8912) has been created. Pamputt (talk) 21:29, 4 December 2020 (UTC)Reply[reply]

I would love to say

Delete, @BrokenSegue: to me the scheme has been largely changed, results the former property can't compatible with the current scheme entirely, probably the core algorithm of this service has re-written. --Liuxinyu970226 (talk) 14:48, 10 December 2020 (UTC)Reply[reply]

Keep Even though the ID is not visible in the URL anymore, it is still present in the source code of the page and still works fine to redirect to the page (eg.). I added some Wikidata usage instructions within the property page in order to retrive the ID : "To find the Kicker ID, open the page source and look after "objectId: "spielersteckbrief: XXXXX"" where XXXXX is the ID". Therefore I think this property has no reason to be deleted Kwayst (talk) 16:22, 17 March 2021 (UTC)Reply[reply]
@Kwayst: in light of the comment by CennoxX are you happy to now support deletion? — Martin (MSGJ · talk) 10:36, 24 May 2022 (UTC)Reply[reply]
Delete I have added all IDs that were only in the old kicker format in the new kicker format to the Wikidata-Items. Therefore there shouldn’t be a need for the old property.–CENNOXX (talk) 10:13, 6 July 2021 (UTC)Reply[reply]
Delete, Notified participants of WikiProject Germany, Notified participants of WikiProject Sports —MasterRus21thCentury (talk) 17:14, 29 May 2022 (UTC)Reply[reply]
Keep, could still be potentially useful I think (and a static dump of the data before it was deleted wouldn’t be as easy to discover or use). With the current labels (“former scheme” and “actual scheme”) it seems okay to me to have both properties. —Galaktos (talk) 17:53, 29 May 2022 (UTC)Reply[reply]

Bashkir encyclopedia (Russian version) ID (former scheme) (P4211) Edit

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

This has currently 1057 uses as main statements. --- Jura 13:21, 8 January 2022 (UTC)Reply[reply]
Also https://mix-n-match.toolforge.org/#/catalog/271 seems to be based on this. --- Jura 13:24, 8 January 2022 (UTC)Reply[reply]

Notified participants of WikiProject Russia, Notified participants of WikiProject Authority control —MasterRus21thCentury (talk) 17:03, 6 April 2022 (UTC)Reply[reply]
There are still 1100+ statements. @Timur Rossolov: do you know if all data has been migrated to bashenc.online ID (P9222)? — Martin (MSGJ · talk) 20:33, 26 May 2022 (UTC)Reply[reply]
Ping with new username @MasterRus21thCentury: — Martin (MSGJ · talk) 07:45, 27 May 2022 (UTC)Reply[reply]
@MSGJ No, the data has not been migrated. Therefore, a special bot is needed here to transfer all identifiers before deleting the property. MasterRus21thCentury (talk) 08:29, 27 May 2022 (UTC)Reply[reply]
In Wikidata:Properties for deletion/P4210 the question was asked about how to map one to the other. Can you provide any detail on this? — Martin (MSGJ · talk) 20:59, 27 May 2022 (UTC)Reply[reply]
@MSGJ With regards to this, the Bashkir Encyclopedia used to have two different versions with different pages. Now there is one version with three languages - Russian, Bashkir and English. MasterRus21thCentury (talk) 04:48, 4 June 2022 (UTC)Reply[reply]
What is the problem? If it's discountinued project just modify url with archived version to Wayback Archive to property or just update to new url if project was just moved. Don't remove properties just becasuse they are unavailable - use archived version instead. Eurohunter (talk) 16:04, 4 August 2022 (UTC)Reply[reply]

Bashkir encyclopedia (Bashkir version) ID (former scheme) (P4210) Edit

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

There are currently 912 uses as main statements. There is also a separate Mix'n'match catalog for this: https://mix-n-match.toolforge.org/#/catalog/272

This in addition to the 1057 uses of Bashkir encyclopedia (Russian version) ID (former scheme) (P4211) mentioned above and its https://mix-n-match.toolforge.org/#/catalog/271 catalogue.

Oddly the two aren't kept in synch (maybe identifiers for both properties (or all three) could be added to these.

bashenc.online ID (P9222) is hardly used (45 uses almost a year after creeation) and doesn't have a Mix'n'match catalogue.

I don't think we should delete the properties before the Mix'n'match question is resolved. I don't have much of an opinion of any of the three properties are worth keeping.

@Visem, З. ӘЙЛЕ, Kareyac, Magnus Manske, Epìdosis: @Movses, Avatar6, Russian Rocky, SCIdude, Vesihiisi: @Saint Johann: who worked on either catalogue in MxM.

@putnik, ShinePhantom, Carn, Ghuron: @Wikisaurus, Сидик из ПТУ, Serhio Magpie, Arbnos: who participated in the proposal discussion for the new property. --- Jura 13:40, 8 January 2022 (UTC)Reply[reply]

It would be better if someone can change data for new version. --Visem (talk) 17:15, 8 January 2022 (UTC)Reply[reply]

Good afternoon! Bashwiki needs help :) We would like, if one of the programmers could help, to change all the old data to new ones with one click, if this is not possible, notify us so that we do everything manually. In the previous site, the index of articles in Russian and Bashkir was different, in the new site they are the same. We will be grateful for any help: practical or theoretical :) --З. ӘЙЛЕ (talk) 05:47, 20 January 2022 (UTC)Reply[reply]

@З. ӘЙЛЕ: If you can supply the mappings between the old ids and the new ones, you might want to make a request at Wikidata:Bot requests. These can then be added to Wikidata and Mixnmatch. --- Jura 18:34, 11 February 2022 (UTC)Reply[reply]

I recently made a catalogue for a new property on Mix-n-match and exported around 2k IDs from Bashkir (from a template used for encyclopaedia links) and Russian wikipedia (from direct links in the new format). But it still needs to replace somewhere around 800 identifiers. @З. ӘЙЛЕ: I can't think of anything better than manual work on them 1 by 1. So it will probably also require the help of the Bashkir community to sort out the mix-n-match catalogue to then automatically remove the old property. Solidest (talk) 11:05, 12 March 2023 (UTC)Reply[reply]

What is the problem? If it's discountinued project just modify url with archived version to Wayback Archive to property or just update to new url if project was just moved. Don't remove properties just becasuse they are unavailable - use archived version instead. Eurohunter (talk) 16:05, 4 August 2022 (UTC)Reply[reply]

The problem is that most of the archive links don't work, and the old articles have simply been moved to new IDs under new format - so it's better to be replaced rather than kept. Solidest (talk) 11:05, 12 March 2023 (UTC)Reply[reply]

English Vikidia ID (P7829) Edit

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

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

Notified participants of WikiProject Authority control Kethyga (talk) 14:29, 10 April 2022 (UTC)Reply[reply]

No ~~citable~~ reliable source ["zitierfähige Quelle" in German]. Please delete. --Kolja21 (talk) 14:34, 10 April 2022 (UTC)Reply[reply]
@Kolja21: What do you mean with "No citable source"? --Horcrux (talk) 07:40, 18 June 2022 (UTC)Reply[reply]
In the sence of en:WP:SOURCE. But merging is ok with me. --Kolja21 (talk) 11:56, 18 June 2022 (UTC)Reply[reply]
@Kolja21: We are not on Wikipedia, reliability is not a requirement for external identifiers (otherwise we should remove every property about social networks, other wiki websites, including Wikimedia Commons, etc.). --Horcrux (talk) 13:54, 18 June 2022 (UTC)Reply[reply]
Support Good idea, Fandom article ID (P6262) like solution makes sense. --Jklamo (talk) 00:19, 25 April 2022 (UTC)Reply[reply]
Support merging. --Tinker Bell ★ ♥ 22:55, 28 April 2022 (UTC)Reply[reply]
@Kethyga: do you propose to also merge 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)? If so, please can you tag them with {{Property for deletion}}? — Martin (MSGJ · talk) 10:30, 24 May 2022 (UTC)Reply[reply]
Yes, I proposed to merge all these properties. I will tag them soon. Kethyga (talk) 10:51, 24 May 2022 (UTC)Reply[reply]
@Kethyga: I've just did it. --Horcrux (talk) 07:40, 18 June 2022 (UTC)Reply[reply]
Support --Trade (talk) 01:34, 28 May 2022 (UTC)Reply[reply]
Support merging all the properties. --Horcrux (talk) 07:40, 18 June 2022 (UTC)Reply[reply]
Thank you for tagging the other properties Horcrux, which Kethyga promised to do but did not — Martin (MSGJ · talk) 20:59, 18 June 2022 (UTC)Reply[reply]

Property:P5176 Edit

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

Keep It's as much of an ID as all those other sites that use some form of a person's name as their ID's. ArthurPSmith (talk) 13:24, 16 June 2022 (UTC)Reply[reply]

The talk page include two unresolved disputes:

Should items like RSA-370 (Q15990672) have this property?
How should this property be labeled?

--GZWDer (talk) 19:54, 17 June 2022 (UTC)Reply[reply]

Actually, I don't see any unresolved dispute. The KIT Linked Open Numbers (Q51279230) website provides data about 999,999,999,999 natural numbers (from 1 to 999,999,999,999), so the answer to the first question is "no". The answer to the second question is "the current one": any label that aims to generalize the property would make the property itself coincide with numeric value (P1181).

I think the only question we should ask ourselves is: is KIT Linked Open Numbers a valid resource deserving to be linked? --Horcrux (talk) 20:58, 17 June 2022 (UTC)Reply[reply]

Property:P10692 Edit

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

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

Property:P6624 Edit

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

Property:P2263 Edit

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

Delete per nom. --GrandEscogriffe (talk) 17:41, 27 September 2022 (UTC)Reply[reply]

Property:P4547 Edit

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

Winterthur Glossar URL (DEPRECATED) (P6107) Edit

Deutsch: Es gibt mit Winterthur Glossar ID (P10677) eine Nachfolgeeigenschaft, die inzwischen überall vorhanden ist (ausser für gewisse Referenzen, die URL's sind eh nicht mehr gültig.)

English: With Winterthur Glossar ID (P10677) there is a successor-property, which is implemented anywhere by now (expect for some references, where the URL's aren't valid anymore, anyway.)

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

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

surrounds the enclave (P10613) Edit

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

Delete - Nikki (talk) 18:57, 7 November 2022 (UTC)Reply[reply]

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

Delete --Jklamo (talk) 16:18, 10 August 2023 (UTC)Reply[reply]

Property:P501 Edit

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

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

Property:P500 Edit

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

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

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

Property:P10724 Edit

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

There are 5 entries and all added on the same date by @C933103. That looks indeed like lack of notability. Mbch331 (talk) 15:13, 3 October 2022 (UTC)Reply[reply]

The intent of this property is to complement the main property of Moegirlpedia ID to achieve comprehensive correspondence, as this site function as a backdrop for content deported from the main Moegirlpedia site due to Chinese regulatory rules, however the uptime of the H-moe site have been far from best in recent months, hence it would be pretty difficult for anyone to try to add new entries for the site into Wikidata in the past few months, which explain its current relative low usage. C933103 (talk) 10:14, 5 October 2022 (UTC)Reply[reply]

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

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

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

Delete Gibberish contents with nothing given even small notabilities. --Liuxinyu970226 (talk) 07:03, 16 October 2022 (UTC)Reply[reply]
"gibberish" to people who do not want to see content against Chinese law I guess C933103 (talk) 17:47, 20 October 2022 (UTC)Reply[reply]
Delete barely used identifier of spin-off of user-generated narrowly focused database. --Jklamo (talk) 14:17, 19 October 2022 (UTC)Reply[reply]
narrowly focused? C933103 (talk) 17:46, 20 October 2022 (UTC)Reply[reply]
Question Do we really need to delete the subject item Q111607789? Wasn't it part of Moegirlpedia? Laftp0 (talk) 11:27, 25 October 2022 (UTC)Reply[reply]
That is for another discussion. After the site being made unavailable since earlier last month, and then earlier this month rumor on Twitter surfaced that claim contributors from China being taken away by Chinese government, Chinese Wikipedia judged the the Chinese Wikipedia article did not meet notability guideline despite expecting situation might change in short term, and hence deleted the article. With the Chinese Wikipedia article deleted, the Wikidata item no longer have any Wikipedia link and likely being deleted because of it not meeting notability criteria #1. Yet, as far as this Prperty P10724 remain in existence, I think it still meet notability criteria #3, and thus shouldn't be deleted.

It was not officially part of Moegirlpedia but more like a complementary site to it. In the early day HMoegirl shared account database and other resources with the main Moegirlpedia site, but such arrangement have been problematic as Moegirlpedia progressively move into Chinese server and subject the wiki to Chinese government regulation, while Hmoegirl continue to host content that are against Chinese law in multiple aspects. Hence as of summer of year 2022 the official stance is no official relationship between the two sites, despite editors and contents across the sites. C933103 (talk) 12:58, 26 October 2022 (UTC)Reply[reply]

Property:P10589 Edit

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.

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

Weak oppose Linking to a website doesn’t mean endorsing its practices. The question in this case would be whether the benefits of having this site linked outweigh the concerns about legal issues. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 10:12, 7 November 2022 (UTC)Reply[reply]

Delete in the past Japanese publisher sent cease and desist letters to aggregators for Scanlation. Having this property might essentially makes us an aggregator for Scanlation and thus opens up the possibility of legal threads against Wikimedia. I think it's ideal if your community can self regulate in this regard and delete the property without needing to interact with Wikimedia legal. ChristianKl ❪✉❫ 15:12, 7 November 2022 (UTC)Reply[reply]

(Japanese publishers having sent cease and desist letters for scanlation sounds … interesting given that it’s not their – arguably monetary – rights infringed upon, but those of the author, and in Japan itself it wasn’t possible until a few years ago to take legal actions on behalf of a third party against copyright violations. Just as an aside. --2A02:8108:50BF:C694:E0F2:7F6B:7EAD:26F9 15:53, 7 November 2022 (UTC))Reply[reply]

Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl ❪✉❫ 00:15, 10 November 2022 (UTC)Reply[reply]

Admittedly yes, therefore an aside (basically saying that they are taking advantage of another country’s legal provisions where this would not be possible in their own country – indeed not of interest here). --2A02:8108:50BF:C694:1432:F47C:55CC:B105 19:37, 12 November 2022 (UTC)Reply[reply]

Delete I created this property honestly not knowing it was a scanlation website or what scanlation was. Linking to a website that distributes copyrighted material is basically assisting in that distribution which is illegal. Lectrician1 (talk) 20:18, 7 November 2022 (UTC)Reply[reply]

Delete As for scanlation sites, Japanese and U.S. publishers declared in a joint statement in 2010 that they are illegal. By making them available for free, they are infringing on the financial benefits that copyright holders rightfully deserve. Afaz (talk) 04:01, 9 November 2022 (UTC)Reply[reply]

While this is undoubtedly true, there are no financial benefits for copyright holders anyway if nobody publishes their work commercially in a country. If there is no “official” translation that is sold in, e.g., the US, anyone who wants to read it (in English) there has to resort to “unofficial” translations, which have no choice but to infringe on copyright. I don’t want to endorse copyright violations, in no way, but the “financial” point of view doesn’t get us anywhere here. That said, what was the point of creating links to the specific site discussed here in the first place? What benefits were seen in linking it? --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 10:18, 9 November 2022 (UTC)Reply[reply]

As far as the laws are concerned people can import Japanese comics whether or not they are translated. The Berne convention exists to give mutual recognition of copyright and not require products to be marketed in a country to be protected in that country. ChristianKl ❪✉❫ 00:13, 10 November 2022 (UTC)Reply[reply]

That’s not the point. There are probably many people in the world who want to read Japanese comics, but cannot read Japanese. That’s the reason why scanlation (and regular translation) exists in the first place. Of course it would be better if they paid the original authors, but the author doesn’t get any money regardless of whether someone abroad reads their comic in scanlation form (without paying) or doesn’t read it at all. Hence the “financial” point of view doesn’t get us anywhere here. There’s more to copyright than remuneration (and the Berne convention presumably exists regardless of financial considerations). --2A02:8108:50BF:C694:E83C:EBFF:49AF:23CC 12:45, 10 November 2022 (UTC)Reply[reply]

Copyright is driven by actual laws. You might disagree with those laws but they exist. Scanlation clearly creates deriviative works of copyrighted works. In the US context where Wikimedia has it's legal home, that's forbidden by copyright law unless you have permission or can argue for fair use. Courts have made many rules on copyright and have developed a concept of financial interests in the process. You might not like it or disagree with it, but that's still the law of the land. ChristianKl ❪✉❫ 12:20, 12 November 2022 (UTC)Reply[reply]

Neither do I disagree with copyright laws (where did I claim that?) nor do I deny that scanlation violates them. All I’m saying is that it does not hurt the authors financially and that the claim by Afaz that they infringe on “the financial benefits that copyright holders rightfully deserve” is therefore misleading. Of course they have “financial interests” – they are selling their works in Japan, after all –, but that’s different from “financial benefits”. (Easy example: A greengrocer has a financial interest in getting vegetables sold, but no financial benefit if nobody buys them – a reason for which might be that all the people who would like to buy them live in another city. Does this make stealing the vegetables from the greengrocer and giving them away for free in that other city legal? Obviously not. Does the greengrocer have a financial damage? No, he doesn’t receive money for the vegetables anyway.) But let’s stop this pointless discussion here – both of us agree that scanlation is a copyright violation, while we seem to disagree on why it is (or maybe not; the deriviative work argument is independent of financial aspects, and I’m not sure the US context is actually necessary for it, but anyway). The reason why it derailed was probably my justification for the continuing widespread existence of scanlation despite its illegality – which is unnecessary for the point I wanted to make, I think (now). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:07, 12 November 2022 (UTC)Reply[reply]

The reason why I’m so nit-picky about this is that it often gets mixed up. If remuneration were the problem, scanlators could solve it by taking money from their “customers” and using it to pay the original authors – but in the absence of permission to do so this would still be a copyright violation. That there is more to copyright than remuneration can also be seen in the advent of Creative Commons licences, where copyright holders waive their right to remuneration without (necessarily) waiving other rights they deserve, such as proper attribution (a misconception many have: “It’s free, so I can use it any way I want”). --2A02:8108:50BF:C694:29E6:BE9C:1625:78C8 20:33, 12 November 2022 (UTC)Reply[reply]

Question I see questions of copyright here but if this was actually an issue of concern with wiki projects merely linking, then wouldn't this be a major issue with wiki projects linking to the Internet Archive (Internet Archive ID (P724) and the works there that are still under copyright? If there isn't an issue with that I dont see the issue here. -Jeanjung212 (talk) 20:51, 18 November 2022 (UTC)Reply[reply]

@Jeanjung212: Can you link any item there where the site infringes the copyright? On the first look, all the content looks like public domain and creative commons as well as previews. Also, not that copyright is not the problem. There are also links to Netflix. Copyright infringement is the problem. --Christian140 (talk) 07:58, 19 November 2022 (UTC)Reply[reply]

This website (linked from Tetris (Q71910)), for example, doesn’t seem to be public domain, so technically (ianal) the Internet Archive is infringing on the creator’s copyright by making a copy of it available. (It’s just that no one bothers to sue the Internet Archive, I think.) --Data Consolidation Officer (talk) 21:11, 21 November 2022 (UTC)Reply[reply]

Hmmm. But on all websites where every user can upload content, copyright infringement happens. On wikipedia and commons, too. Just, eventually it gets deleted. However, for mangadex, copyright infringement is the core of the website. For internet archive, they have this site: Rights – Internet Archive Help Center. So, you could report content you think that infringes copyright. But here, I am actually not sure if it is copyright infringement. A lot of old software is made available for free and you can download them from many serious websites. --Christian140 (talk) 08:01, 22 November 2022 (UTC)Reply[reply]

Internet Archive, or archiving in general, might even be covered by Fair Use (I simply don’t know). And given the large number of pages archived there, reporting copyright violations would be a Sisyphean task. As I stated below, I don’t think there’s a legal issue with mere linking, but P10589 is very dispensable anyway. --Data Consolidation Officer (talk) 20:23, 22 November 2022 (UTC)Reply[reply]

The Internet Archive is also recognised as a library by the US government. Thibaut (talk) 10:39, 13 February 2023 (UTC)Reply[reply]

Comment Linking doesn’t mean endorsing, afaik, so the site’s copyright violations alone wouldn’t be valid grounds for deletion of this property. Having a look at the property proposal discussion, however, it seems that the property was created without thorough discussion, basically because “I think properties for it would be useful”. Wikidata should, imho, be extremely restrictive with respect to which external databases it chooses to systematically link, given the considerable effort of maintaining such link collections, avoiding inconsistencies and so on. That’s why I’d tend to vote for deletion at the moment, unless someone provides a good reason why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 21:03, 21 November 2022 (UTC)Reply[reply]
It's 100% endorsing. You're exposing the copyrighted works to a wider audience by linking to them. You're clearly assisting in their distribution. Lectrician1 (talk) 21:30, 21 November 2022 (UTC)Reply[reply]
Sorry, I should have made clearer that I was specifically talking about legal issues. There can of course be ethical issues with linking (depending on intention), but afaik (and ianal, so please correct me if I’m wrong) courts in various contries have established that website operators cannot be held liable for criminal violations by other sites they merely link, so Wikimedia Foundation could not be (successfully) sued for those links or something like that. Anything else is a question of whether we, as a community, want those links, but as I said, I don’t really see any reason anyway why we should. --Data Consolidation Officer (talk) 20:12, 22 November 2022 (UTC)Reply[reply]

There's a difference between having a simple link to MangaDex and having a system on Wikidata that tells Wikidata users for every manga, the exact page where they can download a copyright violating copy of that manga. Having a link to every single manga, is like torrent websites that link to individual content and torrent websites do face legal problems. ChristianKl ❪✉❫ 11:12, 27 November 2022 (UTC)Reply[reply]
Which all the more raises the question why Wikidata would want such a system in the first place; a question the answer to which I still don’t see. Given that it took nine months (the property was created in early April) until someone noticed that there are copyright violations linked, I wouldn’t consider any claim about copyright infringement endorsement intentions plausible (in contrast to torrent sites; and indeed those links will have been created in good faith in most cases), but let’s the lawyers fight that out (or not). --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)Reply[reply]

Delete, as indicated, on the grounds that there has been no good reason given why having external identifier links to the site in question is essential. --Data Consolidation Officer (talk) 19:36, 27 November 2022 (UTC)Reply[reply]
As the property proposer, I have no objection to deletion based on the arguments provided. Tol (talk | contribs) @ 01:01, 30 November 2022 (UTC)Reply[reply]
Comment I won't comment on the actual scanlated content MangaDex works, but they are a gold mine of information, as they maintain links to many of the other manga databases on the internet. Maybe deletion can be waited on until my bot is able to copy as many of the external linkings as possible. In that case, there is another issue brewing, as whenever my bot pulls information from MangaDex it makes a reference and puts the full URL into the reference URL property, although I theorize it would be trivial to clean those up (SPARQL query for stated in MangaDex would bring them all up). RPI2026F1 (talk) 01:49, 9 December 2022 (UTC)Reply[reply]
Alternatively, would the problem not solve itself if the link was simply removed, rather than deleting the entire property? RPI2026F1 (talk) 01:51, 9 December 2022 (UTC)Reply[reply]

Comment Looks like the property is going to be removed. It seems reasonable however that the actual removal can be put on hold for a period of up to 3 months (or less) to allow for links to other sites to be extracted from this identifier. Infrastruktur (talk) 20:54, 9 December 2022 (UTC)Reply[reply]
Yes, I'm trying to get a whole bunch of properties created so I can extract maximal information from the source. I can see about 8 or 10 new properties being partially populated on top of what is already being extracted. RPI2026F1 (talk) 16:17, 21 December 2022 (UTC)Reply[reply]
Delete per the above copyright and legal concerns. ミラP@Miraclepine 19:47, 9 December 2022 (UTC)Reply[reply]
Keep Wikidata is neither a judge nor a police officer. Besides problematic links, the database contains other useful data as well (date of publication, artist, genres, alternative titles, even links to official shops). --Jklamo (talk) 18:30, 21 December 2022 (UTC)Reply[reply]
Keep per Jklamo. We shouldn't censor the identifier of this useful database unless we have clear evidence of law. Laftp0 (talk) 13:47, 22 December 2022 (UTC)Reply[reply]
Delete per the above copyright and legal concerns, we already have better manga/anime databases properties like ANN, MAL and Anilist that don't host illegal content, we don't need some random scanlation website. --Thibaut (talk) 14:30, 20 January 2023 (UTC)Reply[reply]

Weak oppose Linking isn't endorsement, and it's very useful for getting links to other manga services. Although, ultimately if it is deleted we can still use its API to grab links as long as one of AniList/MyAnimeList/Kitsu are linked, so it wouldn't be the end of the world. Ultimately, my opinion would be based on the opinion of the Wikidata team as to whether this kind of site should be linked to. FWIW, from what I can tell MangaDex does respect the wishes of copyright holders if they do request a takedown, although whether that redeems the site is debatable. Nicereddy (talk) 02:09, 21 January 2023 (UTC)Reply[reply]

Keep, Mangadex is just a platform (non-commercial and ad-free), which like other platforms like YouTube or Facebook could be used for publishing anything, but no evidence provided by nominator that this website opposes copyright holders in any way (other than "it is free, therefore it is illegal"). The rules are pretty restrictive there, cases when obtaining a license is required are mentioned. Lockal (talk) 04:51, 13 February 2023 (UTC)Reply[reply]

The “rules” are not that “restrictive”:

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

And even if there’s no official translation or it’s out of print, translating something that is copyright-protected and uploading it to the web is still illegal per the Berne convention (see above).

The difference with Facebook or YouTube is that they disallow illegal content and respond to DMCA requests. Thibaut (talk) 09:53, 13 February 2023 (UTC)Reply[reply]

A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)Reply[reply]

The website is literally designed to host illegal content, like Christian140 said above: it's at its core.

The mere fact that their domain reseller and/or Cloudflare had to kick them away because of the number of DMCA requests they were getting is a strong indicator ([1][2]). One of these requests was from VIZ Media, which is owned by two major Japanese publishing companies (Shueisha and Shogakukan).

Now, please enlighten me how a website hosting full manga releases translated in multiple languages without the copyright holders' permission doesn't infringe Japanese copyright law and therefore the Berne Convention? Thibaut (talk) 18:17, 12 March 2023 (UTC)Reply[reply]

My point was that there is a way to legally host a scanlate website (or any other types of derivative works). It is not difficult to receive a permission from copyright holder to publish your own translation under well defined conditions: non-commercial (optionally providing additional details to help copyright holder to verify that translator are not seeking profit with translation) and only on specific website. Actually, I did it multiple times (not for manga, but it does not matter). Consider that all mindful translators received a permission: it is called "presumption of innocence".

The links you provided mentions that some time ago a fan group that has been coloring the Boruto manga used official scanlation, which resulted in DCMA takedown. Such types of uploads are not allowed on MangaDex:

Scans of physical official releases or rips of digital official releases/webcomics from official sources, such as original releases (raws) or officially translated releases, are not allowed to be uploaded.

Lockal (talk) 10:58, 13 March 2023 (UTC)Reply[reply]

Delete - per legal concerns. Under Japanese copyright law, it is a violation of copyright law to link to a site that is known to copyvio. Links that may violate laws should not be kept. ~~The server for this site may not necessarily be located in Japan, but it should be sensitive to the law.~~ The server for this site is not necessarily located in Japan, but I think it should be as sensitive to the law as possible. Syunsyunminmin (talk) 10:15, 19 February 2023 (UTC);edit – The preceding unsigned comment was added by Syunsyunminmin (talk • contribs).Reply[reply]

Delete - Link to a site that is a violation of copyright law. --Fralambert (talk) 19:22, 12 March 2023 (UTC)Reply[reply]

Property:P4110 Edit

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

generally I like to preserve deprecated values if even a substantial number are archived by something like archive.org. Is that not the case here? Can you link me some examples that don't resolve at all? All the ones I clicked on still work so I would suggest just keeping this property around. BrokenSegue (talk) 18:39, 21 December 2022 (UTC)Reply[reply]

An example is Q624962. RPI2026F1 (talk) 22:03, 21 December 2022 (UTC)Reply[reply]

yeah that's in the archive [3] so i say

Keep BrokenSegue (talk) 20:51, 24 December 2022 (UTC)Reply[reply]

Keep Just because the identifier is deprecated doesn't mean it's not still useful. --Yirba (talk) 23:28, 2 February 2023 (UTC)Reply[reply]

Property:P1076 Edit

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

"Unused" is by itself not a valid reason of deletion. More research on this ID is needed (is this ID deprecated? succeeded by other scheme?) GZWDer (talk) 15:00, 23 December 2022 (UTC)Reply[reply]

It seems to have no URL formatter nor any related properties, which is weird. The URL for ICTV virus ID (P1076)source website for the property (P1896)http://ictvdb.bio-mirror.cn/Ictv/vc_code.htm seems to be invalid, although ICTV is still a thing from my google search. RPI2026F1 (talk) 19:04, 23 December 2022 (UTC)Reply[reply]

ICTV still has a database of viruses. It seems to be on their main site now. But the database includes all the different ICTV releases of the data. Luckily, it seems to follow a semi-predictable pattern. For example, SARSr-CoV (Q278567) has the IDs 202101868 and 202001868 for the 2021 and 2020 releases, respectively. It also has a bunch of other previous releases that seem to follow the same pattern of year+id. It seems to exist, but I'm not quite sure how to use it. DoublePendulumAttractor (talk) 01:36, 16 January 2023 (UTC)Reply[reply]

There have been about 375 objects with IDs, which had to be deleted again:

Now, this property is unused again. M2k~dewiki (talk) 11:17, 15 May 2023 (UTC)Reply[reply]

@DoublePendulumAttractor: 20162096 (=Hantaan orthohantavirus (Q29002506)) and 20152096 (=Tulare apple mosaic virus (Q7851962)). BTW:

Delete. --Succu (talk) 19:43, 15 May 2023 (UTC)Reply[reply]

Delete by arguments Succu. --Ыфь77 (talk) 19:16, 19 September 2023 (UTC)Reply[reply]

Property:P10241 Edit

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

Note that this was discussed last year at Wikidata:Properties for deletion/P10241. @ChristianKl: We do subpages for PfD now, have moved it over for you. Thanks. Mike Peel (talk) 07:14, 9 January 2023 (UTC)Reply[reply]

The link on the Watchlist page, that says this is a current discussion, points to the closed previous discussion. So, comments on this PfD will likely be a mess. --EncycloPetey (talk) 03:37, 7 February 2023 (UTC)Reply[reply]

Comment Personally I think this is helpful to keep so we don't have to make individual items for every single animal species, we have individual animal (Q26401003) right now and I think it would be way more messy if people started making "individual dog", "individual coati" etc.StarTrekker (talk) 20:25, 15 August 2023 (UTC)Reply[reply]
- Oppose As a mater of fact its also very helpful for fictional characters.StarTrekker (talk) 21:18, 15 August 2023 (UTC)Reply[reply]

Property:P4981 Edit

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

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

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

@Anvilaquarius I should have checked the wayback machine first before writting this deletion proposal. In this case, if it's not against Wikidata's policy I'm for keeping the property and adding "https://web.archive.org/web/" at the beginning of the formatter URL --FlocciNivis (talk) 08:21, 20 February 2023 (UTC)Reply[reply]

Does that make sense? The data in the Wayback Machine will eventually be outdated, for example the number of seats per room. Images are not available. New cinemas will not be added, closed cinemas will not be identified as such. I see that it was a lot of work to add the identifiers, but as the website is offline and it does not look like it will come back again, I assume that the deletion will be the best solution, unfortunately. Yellowcard (talk) 09:29, 20 February 2023 (UTC)Reply[reply]

@Yellowcard As historical data for someone wanting to write an article about one of those cinemas that might be still useful as a source. FlocciNivis (talk) 12:19, 20 February 2023 (UTC)Reply[reply]

This is a good point, I don't personally see what good it does to delete the property if archived links are avalable.StarTrekker (talk) 20:01, 15 August 2023 (UTC)Reply[reply]

Property:P6205 Edit

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

Property:P7164 Edit

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

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

Property:P7859 Edit

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

The proponent and the creator of the property have been contacted in their talk pages; this page has also been linked in the talk pages of the templates indicated in the {{ExternalUse}}. --Epìdosis 21:40, 2 March 2023 (UTC)Reply[reply]

I'm the original proponent and I agree to delete it down when the WorldCat Identities website is shut down. "either VIAF-based or LCCN-based" does not diminish its value since one cannot pick one of the two alternatives without having the WorldCat Identities data. But without the website, it's useless -- Vladimir Alexiev (talk) 06:35, 17 March 2023 (UTC)Reply[reply]

@Epìdosis: I don't see why it would need to be deleted. The "worth" is exactly historical purposes and it costs nothing, I'd assume. Cheers, Ederporto (talk) 14:41, 14 March 2023 (UTC)Reply[reply]

Keep I think we should retain it for a period of time after the data is deleted from the website. For one thing, it would be a useful reference to check on the rate of adoption of WorldCat Entities ID (P10832). There are many cases of WorldCat Identities ID (superseded) (P7859) without VIAF ID (P214) or Library of Congress authority ID (P244), so it would be useful to see how they are handled in WorldCat Entities ID (P10832). We could mark the property as deprecated then compare WorldCat Identities ID (superseded) (P7859) and WorldCat Entities ID (P10832) periodically. From Hill To Shore (talk) 18:38, 24 March 2023 (UTC)Reply[reply]
The comparison between As of now, out of 1.93 M items having WorldCat Identities ID, only nearly 6k items have no VIAF. The comparison between Entities and Identities can be interesting, of course, although I think it wouldn't be much different from the comparison between Entities and VIAF itself. --Epìdosis 20:20, 24 March 2023 (UTC)Reply[reply]
Delete Too many bot edits, too many errors. No chance of correction after shut down. --Kolja21 (talk) 23:36, 25 March 2023 (UTC)Reply[reply]
PS: Please take a look at Property:P7859#P1855: William Shakespeare (Not Found), Guillaume Caoursin (redirect: WorldCat Entities ID), William Verbeck (Not Found) etc. Mike Josef (Q115245491) (redirect: VIAF). --Kolja21 (talk) 20:52, 26 March 2023 (UTC)Reply[reply]
Interesting. They have now redirected many of the Worldcat Identities to the corresponding entry in Entities or VIAF. Some like William Shakespeare had a malformed ID in Wikidata property example (P1855) but the correct Identities ID on William Shakespeare (Q692) redirects correctly to Entities. From Hill To Shore (talk) 23:31, 26 March 2023 (UTC)Reply[reply]
I also thought that the ID for Shakespeare was malformed but WorldCat used the hyphenated spelling lccn-n78-95332 instead of lccn-n7895332 (now redirect). --Kolja21 (talk) 01:07, 27 March 2023 (UTC)Reply[reply]
Comment Today (or yesterday) WorldCat Identities ceased to exist. Since all the "np" and "nc" IDs (4k here) are now resulting in "not found" pages, and their historical value and external use are both irrelevant, I'm going to remove them, if no objection is made. --Epìdosis 15:10, 27 March 2023 (UTC)Reply[reply]

I'll object to that. The presence of the np and nc IDs indicate that there are library records related to the associated items. They are a big clue to users and editors that there will be relevant information in library catalogues to retrieve and link to that item. I'd recommend marking them as deprecated statements with reason for deprecated rank (P2241)withdrawn identifier value (Q21441764). From Hill To Shore (talk) 19:08, 27 March 2023 (UTC)Reply[reply]

@From Hill To Shore: Please keep it simple. If we have two WorldCat ids users need to know that identities are not entities or was it tentities? Now translate this into Arabic, Japanese, and Hindi. Many of the WorldCat ids are outdated or wrong. WorldCat ids have changed over the years. Leaving the mistakes and creating the opportunity for new ones is not a good solution. --Kolja21 (talk) 23:48, 27 March 2023 (UTC)Reply[reply]

I am not sure why you are concerned about translation. The whole premise of Wikidata is that statements are machine-readable and easily translated into any language. If reason for deprecated rank (P2241)withdrawn identifier value (Q21441764) is not translated into a particular language, simply add the relevant labels to the property and the item. Also, I have no idea why you are urging me to "keep it simple." Where do you draw the line on wiping deprecated information from our database in the interests of keeping things "simple"? I am objecting here because an editor is proposing unilateral action to delete ahead of this discussion being concluded. If more editors join the discussion and disagree with my position, then the consensus will be against me and deletion will proceed. From Hill To Shore (talk) 05:35, 28 March 2023 (UTC)Reply[reply]

There are already reason for deprecated rank (P2241)withdrawn identifier value (Q21441764) for withdrawn identifier values. So we can't use this qualifier for a project ceased to exist. --Kolja21 (talk) 13:19, 28 March 2023 (UTC)Reply[reply]

I'm sorry but I have absolutely no idea what point you are trying to make in your comment there. "Because the statement exists, we can't use the statement." From Hill To Shore (talk) 15:37, 28 March 2023 (UTC)Reply[reply]

It's not so difficult. withdrawn identifier value (Q21441764) is used for a single withdrawn identifier. If a project ceased to exist this is something else. If you have problems to understand this distinction you might understand why users will have problems distinguishing between six properties connected to WorldCat. This is what is meant with: "Keep it simple." --Kolja21 (talk) 17:13, 28 March 2023 (UTC)Reply[reply]

If you think withdrawn identifier value (Q21441764) is not the best description for this deprecation then simply create a new item with a deprecation reason you find suitable. "I don't like your choice of reason," is not an argument to delete instead of deprecate. As we have seen through the life of Worldcat Identities, many IDs have changed from "nc"/"np" prefixed IDs to "VIAF"/"LCCN" prefixed IDs. This is because the nc/np entries are for items in the library catalogue and libraries are likely to generate new IDs for them over time. There is a strong likelihood that this behaviour will continue and the residual nc/np items will gain WorldCat Entities ID (P10832) over a period of time. Keeping the nc/np entries as deprecated will make it easier to find matches later rather than have us repeat the identification process all over again. I have no problem with removing WorldCat Identities ID (superseded) (P7859) when we have a WorldCat Entities ID (P10832) present. Your focus is on preventing user confusion, which I don't see as an issue, unless you are advocating the removal of all deprecated information (what makes this case special compared to any other case of deprecation?). My focus is on preserving the useful curation work we have completed that may help us continue to match items to new library IDs. From Hill To Shore (talk) 07:45, 29 March 2023 (UTC)Reply[reply]

"My focus is on preserving the useful curation work we have completed" - which of the P7859 statements are result of such work and would you support that those that are not can be deleted? 77.191.135.37 03:18, 17 April 2023 (UTC)Reply[reply]

Comment: could we keep this property and change the identifiers' links to Archive.org links? Veverve (talk) 18:31, 2 April 2023 (UTC)Reply[reply]
The outcome is not convincing. Property:P7859#P1855:
- William Shakespeare: "XML-Verarbeitungsfehler: Syntax-Fehler"
- Guillaume Caoursin: OK
- William Verbeck (Id 1): "PLEASE NOTE: This Identity has been been retired and is no longer being kept current."
- William Verbeck (Id 2): OK
--Kolja21 (talk) 23:50, 2 April 2023 (UTC)Reply[reply]
Keep per From Hill to Shore at least until we've shifted to entities all the ones that we can. Gamaliel (talk) 14:03, 5 April 2023 (UTC)Reply[reply]
It would be counterproductive to generate WorldCat Entities ID (P10832) from outdated IDs. Better use Library of Congress authority ID (P244) as source. As Epìdosis suggested we don't need to delete all WorldCat Identities ID (superseded) (P7859) all a once. We should make a plan to work through them. --Kolja21 (talk) 20:29, 5 April 2023 (UTC)Reply[reply]
I agree. WorldCat Identities may reflect an outdated situation, so it's not the best option to mass-derive WorldCat Entities. I would prefer Library of Congress authority ID (P244) as Kolja21, or (probably worse) VIAF ID (P214), which was in fact the source from which our WorldCat Identities IDs have been derived in 99.9% cases. --Epìdosis 22:07, 5 April 2023 (UTC)Reply[reply]
I find this argument to be very strange. How would you "generate WorldCat Entities ID (P10832) from outdated IDs"? Of course you will need to make a comparison with other remaining IDs (or other identical statements) to verify a match before inserting WorldCat Entities ID (P10832). However, the key distinction that you appear to be proposing is to delete WorldCat Identities ID (superseded) (P7859) ahead of the work to migrate WorldCat Entities ID (P10832) and then attempt to repeat years of work to locate, match and insert the ID on 1.93M Wikidata items. The presence of WorldCat Identities ID (superseded) (P7859) allows us to target the migration work, so WorldCat Identities ID (superseded) (P7859) should not be removed until the migration is complete, though I am happy to support phased removal by removing WorldCat Identities ID (superseded) (P7859) when there is a WorldCat Entities ID (P10832) present on the same item. Once the migration of the easy matches are complete we will be left with some residual items that don't have WorldCat Entities ID (P10832) yet. It would be worth revisiting this discussion at that time (either as part of the current discussion on this page, if still open, or a replacement discussion) to agree what we should do with the residual entries (deprecate or delete). From Hill To Shore (talk) 00:41, 6 April 2023 (UTC)Reply[reply]
Keep for now, Delete once a migration to P10832 have been set up. Per the use of VIAF or LC values in the construction of Identities IDs, I personnally see little point in storing them ad vitam now that the website is dead; on the authors I have worked on, I have never see Identities linked from others authorities files. However, I think that before taking any action we should have a bot run through the current P7859 and add P10832 when there is a redirection to it. Seeing the good workd Msynbot is doing, perhaps @MisterSynergy: could have a look at it? --Jahl de Vautban (talk) 07:06, 6 April 2023 (UTC)Reply[reply]
This is doable and not too complex. However:
- For efficiency reasons, it would be great if someone could obtain a complete mapping table of redirects as the bot would otherwise have to request almost 2 million URLs from the source.
- There should be consensus to do this, which is apparently not the case at the moment (see above).
—MisterSynergy (talk) 09:48, 6 April 2023 (UTC)Reply[reply]

Keep and link to archived page. WorldCat identities indexed the names of entities in languages other than English, and as far as I can tell WorldCat entities is effectively English-only. Take a look, for example, at the item for محمّد سعد الله خان کھيتران: Muhammad Saad Ullah Khan Khetran (Q113960737) ; this person's name in their native language Saraiki was on their WorldCat identities page but not on the entities page. While it may be noted that the Library of Congress link lists 6 native labels, 5 out of 6 of them are incomplete and/or spelled incorrectly. Most writers of languages that are not one of a few widely spoken ones like English, French, etc. have erroneous information recorded throughout in their records in various databases. So we could really use any and all links to information which can be cross referenced to help determine the correct information. When and if this information is available via WorldCat entities is when the deletion of this property should be discussed.

عُثمان (talk) 18:24, 24 April 2023 (UTC)Reply[reply]

Delete. Before deletion we need a bot to make sure that every item with a WorldCat Identities ID (superseded) (P7859) beginning 'viaf' or 'lccn' also has a corresponding VIAF ID (P214) or Library of Congress authority ID (P244). Normally I would prefer to keep old identifiers, especially if they redirect to new identifiers, but WorldCat Identities ID (superseded) (P7859) has a very high conflation rate. Of 488 values added to items on my watchlist, I deprecated 62 for conflation, which is 12.7%. Using redirects from WorldCat Identities ID (superseded) (P7859) to add WorldCat Entities ID (P10832) would result in many errors. I agree with Kolja24 that it would be better to find WorldCat Entities ID (P10832) using more reliable identifiers such as Library of Congress authority ID (P244).--DrGavinR (talk) 10:48, 6 April 2023 (UTC)Reply[reply]
- I've rechecked the values that I deprecated for conflation. Now they all redirect to correct Worldcat Entities that are not conflated. Therefore I no longer oppose using the redirects to migrate from WorldCat Identities ID (superseded) (P7859) to WorldCat Entities ID (P10832), although Worldcat Entities usually already have Wikidata IDs on them, which might be a better way to migrate if we had access to the Worldcat data. I still don't think WorldCat Identities ID (superseded) (P7859) will be any use in the long term, but deletion can wait until after migration.--DrGavinR (talk) 19:11, 30 April 2023 (UTC)Reply[reply]

Delete, Worldcat Identities project is taken down.--Kadı Message 12:24, 7 April 2023 (UTC)Reply[reply]

weak keep, until migration is done. After it is done, another deletion discussion can take place. Veverve (talk) 13:27, 7 April 2023 (UTC)Reply[reply]
What migration? 77.191.135.37 03:10, 17 April 2023 (UTC)Reply[reply]
I'm clear here for keep. Keep --Gymnicus (talk) 21:35, 15 April 2023 (UTC)Reply[reply]
When you have time, consider providing a reason? 77.191.135.37 03:05, 17 April 2023 (UTC)Reply[reply]

Delete, dubious quality, lack of sources. If derived from viaf or lccn use these instead. 77.191.135.37 03:08, 17 April 2023 (UTC)Reply[reply]

Keep Worldcat Identities redirects in most cases to Worldcat Entities. Absolutely essential. Grimes2 (talk) 22:07, 17 April 2023 (UTC)Reply[reply]

@Grimes2: A rar visitor. How did you find this discussion?

Comment BTW: P7859 and P10832 should be displayed one below the other so that the comparison is easier. 2A02:2454:986D:F700:493E:E780:1887:62CE 03:38, 7 May 2023 (UTC)Reply[reply]

Keep: Certain until P10832 is populated following a migration strategy. Especially uaeful when the p7859 refirects to the new P10832 entity. -- DeirgeDel^t_a^c 20:30, 29 May 2023 (UTC)Reply[reply]
Comment: May I be so bold as to venture that the evidence it overwhelming that P7859 is retained until P10832 is populated. There is then the question of what is using the P7859 value out of Wikidata? Is it only the authority control template or something else? While that debate may not be helpful a more productive approach might be to agree a roadmap on how P10832 is to be populated. There's bits of that spread throughout the above vote but it would be helpful to see an agreed way forward in one place. That is focus on getting P10832 populated rather than P7859 deleted. Thankyou. -- DeirgeDel^t_a^c 10:48, 1 June 2023 (UTC)Reply[reply]
Åma (Q21477069): mountain in Antarctica, P7859 = https://worldcat.org/identities/viaf-168989993/ = 5 IDs = many things, but no mountain in Antarctica. Most WorldCat Identities IDs were imported through other IDs and never checked. The only thing that is overwhelming is bad quality of this property. Taking a secondary source for migration while Wikidata has the original source (LCAuth etc.) would be counterproductive. It's a basic rule: Use citable and original sources! --Kolja21 (talk) 17:22, 1 June 2023 (UTC)Reply[reply]
P7859's which redirrect to viaf and not worldcat entities are of no/limited use in determine P10832. P7859 which redirect to worldcat entries are more useful. I have no clue about any P7859 value not directing to a worldcat entity. And I'd love to look at this more but I've not got the resource. Thankyou. -- DeirgeDel^t_a^c 23:07, 1 June 2023 (UTC)Reply[reply]

Migration to P10832 Edit

enWikiQuote migration case Edit

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

Due to an unexpected need to clear some of my to-do list I've boldy gone ahead and added the P10832's needed by the set 90 artcles needed it in Wikiquote. I had to do a handful manually and a frequent reason was the Wolrdcat entity not having an English Label.

Done -- DeirgeDel^t_a^c 23:13, 30 May 2023 (UTC)Reply[reply]

Removal of P7859 before consensus reached Edit

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

Hi @DeirgeDel:, the removals I performed today of a few thousands of values (which are BTW concluded) where based on 3 criteria: 1) IDs which, due to botched format, were invalid or anyway unusable to get new P10832 values (https://editgroups.toolforge.org/b/QSv2T/1685691070809/ + https://editgroups.toolforge.org/b/QSv2T/1685691187036/); 2) IDs which were present in items not containing a VIAF ID (P214) ID (https://editgroups.toolforge.org/b/QSv2/207071/) - on the basis of the reasoning that, in many cases, it could have happened that the VIAF ID from which the WorldCat ID was copied could have been removed because of a mismatch or a conflation and thus the WorldCat ID could be itself a mismatch or a conflation; 3) IDs which were referenced with a VIAF ID (P214) ID which is not present anymore in the item (all the other batches of today) - on the basis of the reasoning that, in many cases, it could have happened that the VIAF ID from which the WorldCat ID was copied could have been removed because of a mismatch or a conflation and thus the WorldCat ID could be itself a mismatch or a conflation. If we want to adopt caution in the import of WorldCat Entities IDs from WorldCat Identities IDs, I though that the above cases are doubtful enough to be excluded from the conversion, and thus were to be removed (this is especially true for cases 1 and 3). --Epìdosis 13:45, 2 June 2023 (UTC) P.S. and https://editgroups.toolforge.org/b/QSv2/207093/ removes only deprecated values, which are surely not suitable for conversion to P10832. --Epìdosis 14:02, 2 June 2023 (UTC)Reply[reply]

I think you might consider what it says in Help:Deprecation. Speficially deprecating but not deleting properties that are "now known to be wrong, but were once thought correct". What is your reason why your deletions are distinguishable from the general rule? --William Graham (talk) 16:55, 2 June 2023 (UTC)Reply[reply]

The usefullness of keeping as deprecated the IDs which are obsolete or inexact because of a conflation lies mainly in avoiding that they are readded with normal rank; since here the database is defunct, there is no risk of readdition. Since the discussion above is mainly centered on the need of keeping these IDs only because they are useful for finding new P10832 values, it follows that the IDs which cannot be used for this aim, or that would be harmful if used for this aim (because they could lead to adding mismatched IDs), should be deleted, IMHO. --Epìdosis 20:14, 2 June 2023 (UTC)Reply[reply]

@Epìdosis: you shouldn't be removing this property while this deletion request is still open. That's really bad practice and as an administrator on this project you should lead by example.

What you should do is apologize for being to early, undo your batches and wait for a not involved administrator to close the deletion request. Multichill (talk) 14:12, 3 June 2023 (UTC)Reply[reply]

Hi @Multichill:, I partially agree. I apologize for the batch numbered 2 (https://editgroups.toolforge.org/b/QSv2/207071/), which removed the IDs which were present in items not containing a VIAF ID (P214) ID, and I'm now undoing it; although I'm still convinced that some percentage of these IDs is surely there because a VIAF was previously present, then was removed because it was perceived as imprecise or conflated, but the WorldCat Identities ID still remained there, I have effectively no precise clue of how high this percentage is, so I think it is reasonable restoring the entire batch. However, for the other batches I personally don't agree, for the following reason: leaving aside the fact that the property is being deleted, I am still convinced for the above motivations that the IDs removed in the batches 1 and 3 have never been pertinent to the item containing them and thus had to be removed simply because they were mismatched; restoring them and using them for copying new P10832 values could lead to worse conflations, as I (and others) have explained above. For more context, I have recently also removed a batch of 13k VIAFs which were conflated (per this discussion) and I have received no complaint so far; I repeat, it is not a matter of removing values of a identifier proposed for deletion, it is a matter of removing IDs which are mismatched (an operation which is commonly done for identifiers not proposed for deletion). Of course, if you have evidence that my reasoning is wrong and that the IDs removed in batches 1 and 3 are not mismatched, I will apologize also for them and I will immediately undo them. Thanks, --Epìdosis 15:15, 3 June 2023 (UTC)Reply[reply]

That's fine with me. Multichill (talk) 15:22, 3 June 2023 (UTC)Reply[reply]

::::Before talking about migration we need think about how to improve P7859. The removal of wrong IDs is part of the maintenance work. Let's start with Q6243526#P7859: 6 IDs: 5x VIAF, 1x LCCN. After this work is done there are 1.918.337 IDs left to be checked. When all IDs have been checked, we can talk about migration. --Kolja21 (talk) 17:56, 3 June 2023 (UTC) {{Small|I'm boldly suggesting this good faith has in some ways drifted from the topic Removal of P7859 before consensus reached and I've boldly forked it to a new section where that might be moved to in more detail. I hope that OK with everyone. -- DeirgeDel^t_a^c 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^t_a^c 23:40, 3 June 2023 (UTC)Reply[reply]

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

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

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

Pre-migration data cleansing of P7859 Edit

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

In this case (as for every other case) we look at the LCCN value, "lccn-no2012115736". That links to a Worldcat identities record that is redirected to the WorldCat Identity Record E39PCjD79fj4FJ7m3KHHvFBWrC. Thus P10832 is a candidate for the value of P10832 and quite frankly The fact that the WorldCat Identity record says it is associated with Wikidata item id Q6243526. Thus I have every confidence P10832 could be rightfully set to the value of "E39PCjD79fj4FJ7m3KHHvFBWrC]" for Q6243526 regards of any mess with state of P7859. In many ways it is easier to focus on getting a value P10832 set rather than migrating it from P7859. P7859 is simply one method that might allow this to happen eeficiently. – The preceding unsigned comment was added by DeirgeDel (talk • contribs).

I fear the case of Q6243526#P7859 is bit more intricate, because also "viaf-" IDs can be used sometimes to get valid P10832; in this case, 2 out of 5 "viaf-" IDs pointed to presently valid P10832 (so, in fact, P10832 is at least triple for this person presently). In fact: viaf-4896153063221319320008 = viaf-288715031 = viaf-306425053 = https://viaf.org/viaf/306425053/; but lccn-no2012115736 = https://id.oclc.org/worldcat/entity/E39PCjD79fj4FJ7m3KHHvFBWrC.html + viaf-1792159474074827660233 = https://id.oclc.org/worldcat/entity/E39PCjJVGdCdwDVyXRMrJbfd6X.html + viaf-610152636065020050681 = https://id.oclc.org/worldcat/entity/E39PCjF3G4jYpmVQvrJWvhGMbm.html. --Epìdosis 16:50, 4 June 2023 (UTC)Reply[reply]

Practical way of migrating to P10832 Edit

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

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

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

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

Property:P6077 Edit

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

Any issue with making it a redirect?

(assuming that's applicable here, which I realize may not be the case) DS (talk) 23:20, 15 June 2023 (UTC)Reply[reply]

Property:P10725 Edit

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

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

@BellaYunita, MasterRus21thCentury: (proposer and creator); @GZWDer, Sagotreespirit, Jura1, Arbnos, ArthurPSmith:, @BrokenSegue, Vahurzpu, AntisocialRyan, Trade, Nepalicoi, Germartin1: who commented on the deletion discussion; @Multichill, VIGNERON: who I also discussed this with. Andrew Gray (talk) 13:34, 25 June 2023 (UTC)Reply[reply]
Delete bad quality to start with (junk), questionably if it should even have been created in the first place. 2 out of 5 examples deleted. Used less than 100 times. This property is not making Wikidata a better place. Not something to waste any more time on. Multichill (talk) 13:38, 25 June 2023 (UTC)Reply[reply]
Comment notifying the top 5 users of this property @Буквы, Susmuffin, Elyaqim, Everywiki, Back ache: (according to NavelGazer). Cheers, VIGNERON (talk) 13:55, 25 June 2023 (UTC)Reply[reply]
Oppose partially covered by archive.org. also archive.is and probably others. not hurting anything. BrokenSegue (talk) 16:25, 25 June 2023 (UTC)Reply[reply]
Delete Yeah, if it's used less than 100 times and 80+%-ish are bad links already maybe there's not much point. Yes we could add the archive.org link but what does that add, really? ArthurPSmith (talk) 14:21, 26 June 2023 (UTC)Reply[reply]
Delete This site was a SEO spam magnet. Adding archive.org links does not add anything of value. --Trade (talk) 18:47, 26 June 2023 (UTC)Reply[reply]
Delete I agree with the deletion proposal. –– Yahya (talk) 19:23, 26 June 2023 (UTC)Reply[reply]
Delete RIP in peace. –MJL ‐Tauk‐^☖ 19:03, 14 July 2023 (UTC)Reply[reply]
Delete Gamaliel (talk) 17:23, 8 August 2023 (UTC)Reply[reply]
Delete Jamie7687 (talk) 16:50, 16 September 2023 (UTC)Reply[reply]

Property:P5301 Edit

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

Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).Reply[reply]

Notified participants of WikiProject Podcasts. Nomen ad hoc (talk) 09:17, 27 May 2022 (UTC).Reply[reply]

@Nomen ad hoc: I do not understand why this is happening, and the property proposal likewise gives no explanation at Wikidata:Property proposal/Radio France person ID. If this deletion is to proceed can someone add an explanation to the original property proposal about why the new property was created to replace this one? Bluerasberry (talk) 12:44, 27 May 2022 (UTC)Reply[reply]
- @Bluerasberry: it is extremely simple; IDs from this prop have been retrieved by the new prop (whose formatter URL has changed). Nomen ad hoc (talk) 13:52, 27 May 2022 (UTC).Reply[reply]

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

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

Wait: there are several entities where the URL given by this property does not work. Examples: Bernard Baas (Q2897472), Sophie Pujas (Q68587627), see also fr:Catégorie:Page utilisant P5301 (in each section Liens externes). I do not know how to migrate them ? Eric-92 (talk) 00:46, 18 July 2023 (UTC)Reply[reply]
The P5301 ID concerning Q2897472 (Bernard Baas) and Q68587627 (Sophie Pujas) have strictly no reasons to work: seems "fake ID", these people are not listed in the database! As you can see, they are not in https://www.radiofrance.fr/personnes?startsWith=B and https://www.radiofrance.fr/personnes?startsWith=P&p=16... --YANN92340 (talk) 10:03, 6 August 2023 (UTC)Reply[reply]

Property:P7662 Edit

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

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

Keep The property was updated by User:Blz 2049 with URL https://app.scilit.net/sources/$1. The identifiers simply need to be updated. In the example International Journal of Climate Change Strategies and Management (Q15816386) of Scilit journal ID (P7662), the ID is no longer 687103, but 19668. So this property is fully operational, no need to delete it, see this. Cordially. ―Eihel (talk) 23:14, 4 August 2023 (UTC)Reply[reply]
Info The problem has already been raised in May 2022, and resolved. Cordially. ―Eihel (talk) 23:35, 4 August 2023 (UTC)Reply[reply]
Changing the formatter URL did not resolve the problem, as the IDs currently in Wikidata are still invalid with the new URL. Haansn08 (talk) 21:12, 14 August 2023 (UTC)Reply[reply]

Property:P6712 Edit

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

Property:P7335 Edit

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

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

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

Sigh, all that wasted effort really hurts Trade (talk) 14:13, 4 September 2023 (UTC)Reply[reply]

Comment. The property was already proposed for deletion 3 years ago and I already said back then that it was completely pointless to keep such a property. I still don't understand why it was decided to keep it. Even if we have archive links, they are, as it is correctly pointed out here, almost useless. It is one thing to have a database like USgamer, which is well archived and still useful, but it is quite another to have a database like Mixer, which does not really contain any useful information for Wikidata. With such a property, we have only accumulated a great number of constraint violations. How to address them without being able to find at least some good archived copy is not clear at all. archive.today, the only site that archives JavaScript sites properly, has almost nothing (see [5] or [6], that is certainly not enough). Wayback Machine is not an option at all, as it saved a lot of links with a 404 error. The only thing left to do here is to set a deprecated rank for all values of this property with withdrawn identifier value qualifier or delete property.

By the way, we have a similar property that also experiences a lack of archive links, but here we have a completely different story. This database unlike Mixer (which has only a game title, a logo and a low-resolution cover/screenshot) has at least some basic and more or less useful information. Regards Kirilloparma (talk) 02:46, 5 September 2023 (UTC)Reply[reply]

Comment I’m usually all for keeping properties for dead websites (indeed, I am planning to propose properties for websites that are already dead! ;-) ; but this is a bit of a different case. Reading back through the last deletion discussion, I do see the point of having Wikidata serving as index to the full WARC archive ; but I was never impressed with our coverage: we have hundreds of cases where the same ID is assigned to different games that happen to share the same name − for example 97266 (that 404s, oh the irony) associated with both the 1992 Flashback (Q1001925) and the 2013 Flashback (Q16267660). Not convinced this helps anyone. Jean-Fred (talk) 07:50, 5 September 2023 (UTC)Reply[reply]
Delete Above discussion seems convincing, particularly if this property was poorly matched to items to begin with. ArthurPSmith (talk) 14:24, 5 September 2023 (UTC)Reply[reply]
+ Notified participants of WikiProject Video games. Regards Kirilloparma (talk) 01:07, 6 September 2023 (UTC)Reply[reply]
Delete as it was a service with daily updated information, not suitable for archive search. Matthias M. (talk) 13:55, 6 September 2023 (UTC)Reply[reply]
Delete In this case I think deletion is definitely warranted based on the above arguments. Nicereddy (talk) 22:21, 6 September 2023 (UTC)Reply[reply]
Delete per Jean-Fred and Kirilloparma. —Tomodachi94 (he/him · talk) 23:38, 6 September 2023 (UTC)Reply[reply]
Delete as in the comments above. Sir Lothar (talk) 14:21, 11 September 2023 (UTC)Reply[reply]

On hold Edit

These discussions have been closed but are awaiting deletion.

IPA number order (BEING DELETED) (P3917) Edit

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

Consensus to migrate to catalog code (P528) and delete — Martin (MSGJ · talk) 21:44, 13 February 2022 (UTC)Reply[reply]

This is an external identifier, but has the wrong datatype ("Quantity"). We could create a property, with the correct datatype, and migrate values. However, as there are only 173 of them, perhaps migrating to catalog code (P528), suitably qualified, would be better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:14, 15 September 2019 (UTC)Reply[reply]

@Giovanni Alfredo Garciliano Diaz, ChristianKl: do you have any opinion? To me, I do not see why number is not the correct datatype. Do you mean it should be external identifier? If so, to which link? Or string? Or something else? Pamputt (talk) 06:19, 16 September 2019 (UTC)Reply[reply]

We don't have a number datatype and the quantity type we do has it's +/- interval by default.

I don't have strong feelings but would be okay with migrating it to catalog code (P528). ChristianKl ❪✉❫ 07:50, 16 September 2019 (UTC)Reply[reply]

When I proposed P3917, I ignored many things about how Wikidata work. Now, I agree with migrating it to catalog code (P528). --Tinker Bell ★ ♥ 02:21, 20 September 2019 (UTC)Reply[reply]

Delete a number is not a quantity, store information in a new property with the correct datatype: external identifier. Michael FV (talk) 03:42, 9 January 2020 (UTC)Reply[reply]

Keep Used by some MediaWiki extensions, Please consult MediaWiki.org before deletions. --111.32.68.231 02:45, 9 May 2020 (UTC)Reply[reply]

@Krenair: ^^ Is this really? ^^ --Liuxinyu970226 (talk) 23:45, 9 May 2020 (UTC)Reply[reply]

I have no idea but I haven't been able to find references to P3917 myself, on mediawiki.org or in a search of most MediaWiki extension repositories. --Krenair ^{(talk • contribs)} 00:34, 10 May 2020 (UTC)Reply[reply]

Delete Agree with migration to P528. --SilentSpike (talk) 21:41, 15 June 2020 (UTC)Reply[reply]

Keep In use at Módulo:Ficha de fonema at the Spanish Wikipedia. Please discuss at the Village Pump first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)Reply[reply]
I will make sure the module is updated before deleting the property — Martin (MSGJ · talk) 21:44, 13 February 2022 (UTC)Reply[reply]

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

Implementation notes Edit

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

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

Templates to update:

Property:P1996 Edit

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

Delete — Martin (MSGJ · talk) 11:45, 18 May 2022 (UTC)Reply[reply]

This property has a part of the website link, not only ID. And after website scheme changes it became obsolete. There is new property parliament.uk member ID (P10428), which has ID only and can be used for correct links. The existing data has been migrated to the new property. —putnik 13:54, 5 April 2022 (UTC)Reply[reply]

Notified participants of WikiProject Russia. —putnik 17:31, 5 April 2022 (UTC)Reply[reply]

Notified participants of WikiProject Authority control. —putnik 17:31, 5 April 2022 (UTC)Reply[reply]

Delete --Newt713 (talk) 19:12, 5 April 2022 (UTC)Reply[reply]
Delete --Epìdosis 20:20, 5 April 2022 (UTC)Reply[reply]
Delete- PKM (talk) 20:25, 5 April 2022 (UTC)Reply[reply]
Delete--Pierre Tribhou (talk) 20:53, 5 April 2022 (UTC)Reply[reply]
Delete--Princess Rosalina🍹 497377 09:27, 8 April 2022 (UTC)Reply[reply]
Delete —MasterRus21thCentury (talk) 19:45, 17 April 2022 (UTC)Reply[reply]

pinging @Andrew Gray: Okay with you? Jheald (talk) 18:07, 19 April 2022 (UTC)Reply[reply]

If these have all been migrated over, I think this looks great. Much cleaner than the old property. Andrew Gray (talk) 14:24, 21 April 2022 (UTC)Reply[reply]

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

Notes Edit

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

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

Thank you for clarifying — Martin (MSGJ · talk) 12:39, 18 May 2022 (UTC)Reply[reply]

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

Property:P8981 Edit

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

Delete and replace with coordinate location (P625) Multichill (talk) 15:41, 17 October 2022 (UTC)Reply[reply]

We normally use coordinate location (P625) for coordinates on multiple globes, and this is how the use of coordinates is implemented on multiple Wikimedia projects. Having a separate property for Lunar coordinates just confuses things, and it isn't necessary. The main issue about not being able to select the coordinate globe via the UI is at phab:T56097 - and supporting work on that ticket would be much more useful than having a separate property for this. I can offer bot support to migrate existing uses of this property over to coordinate location (P625) with the correct globe. Thanks. —Mike Peel (talk) 20:42, 23 July 2022 (UTC)Reply[reply]

Delete per nom. Furthermore, it seems that the only support the proposal received was from editors that the nominator blatantly canvassed. And that proposal was only made after Wikidata:Property proposal/planetary coordinates was rejected with only a single supporter. The objectors on the original proposal were not pinged when the second one was made; and neither were the relevant projects (who were pinged for the first proposal). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 24 July 2022 (UTC)Reply[reply]
~~Keep~~ See above on Martian coordinates. I don't recall any of the details Andy mentions, but really, property proposals are announced every week in the newsletter, is pinging so critical? ArthurPSmith (talk) 16:39, 25 July 2022 (UTC)Reply[reply]
- Also see my reply at Wikidata:Properties for deletion/P10628. Looking back at the newsletter, this was buried amongst other proposals and was very easy to miss (I completely missed it). Thanks. Mike Peel (talk) 20:12, 26 July 2022 (UTC)Reply[reply]
- All of the details I mentioned are gleanable from the pages mentioned, which is where I found them on the 24th. The issue in this case was the partisan pinging. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:19, 27 July 2022 (UTC)Reply[reply]

Delete. With the creation of Bamyer's globe tool (see discussion at Wikidata:Properties_for_deletion/P10628) and a bot being created to convert incorrect uses of coordinate location (P625) (see Wikidata:Requests for permissions/Bot/Pi bot 26), there is no need for this property or P10628 (P10628) anymore. — Huntster (t @ c) 16:13, 5 August 2022 (UTC)Reply[reply]
Ok, no longer voting to keep. Fine if it's deleted with the coordinates moved to P625. ArthurPSmith (talk) 16:43, 5 August 2022 (UTC)Reply[reply]

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

Replace Edit

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

Thanks for closing it. I should be able to migrate values over soon. Thanks. Mike Peel (talk) 17:48, 18 October 2022 (UTC)Reply[reply]

@Mike Peel: reminder ^ Multichill (talk) 12:58, 25 June 2023 (UTC)Reply[reply]

@Multichill: As I said at Wikidata:Properties for deletion/P10628, this is currently stuck as I don't have an easy way to migrate them while keeping the reference. Thanks. Mike Peel (talk) 14:57, 13 August 2023 (UTC)Reply[reply]

Property:P9788 Edit

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

Delete Multichill (talk) 16:03, 17 October 2022 (UTC)Reply[reply]

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

This is an ill-thought through property, which purports to serve to list the venues at which artists have played. Many artists have performed at hundreds or thousands of venues. Many have performed multiple times at any single venue. To the extent that it is useful to know the venues at which an artist has played, that need can be met by an event/gig item, which serves to link the artist to the venue, and provides for a date for the occasion.

An easy rule of thumb on wikidata is that if a property has the capacity to take hundreds or thousands of values on a single item, and the information can instead be stored in a series of discrete items, then it is always more sensible to model the ontology to use discrete items - here, events, gigs - than to seek to replicate a list within a single item. —Tagishsimon (talk) 01:40, 24 July 2022 (UTC)Reply[reply]

Delete per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 24 July 2022 (UTC)Reply[reply]
Delete per nom. Also pinging people involved in the property proposal: @William C. Minor, NMaia, ChristianKl, Yotwen, Arbnos, Lectrician1:. — Envlh (talk) 16:44, 24 July 2022 (UTC)Reply[reply]
Delete per nom. NMaia (talk) 00:30, 25 July 2022 (UTC)Reply[reply]
Delete – I can only agree with the nomination here. --Gymnicus (talk) 20:08, 15 August 2022 (UTC)Reply[reply]
Delete per nom.--Estopedist1 (talk) 04:26, 24 August 2022 (UTC)Reply[reply]

Usage needs to be removed Edit

Usage needs to be removed. You can ping me when that's done so the property can be deleted. Multichill (talk) 16:03, 17 October 2022 (UTC)Reply[reply]

@Multichill all usage removed. —‍Mdaniels5757 (talk • contribs) 18:07, 31 May 2023 (UTC)Reply[reply]

Done thanks for the clean up and the ping. Multichill (talk) 14:15, 3 June 2023 (UTC)Reply[reply]

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