Wikidata:Requests for deletions/All
Pages tagged with {{Delete}}
if this list is out of date.
Properties
MangaDex title ID (P10589): (delete | history | links | entity usage | logs | discussion)
The website MangaDex is a website for scanlation (Q557923) and therefore gives people access to copyright protected works for free without holding a license to publish it or consent of the copyright holder. The website infringes copyrights and I don't see any reason why wikidata should link items to such a website.
See also: Wikidata:Project chat/Archive/2022/11#Mangadex?
—Christian140 (talk) 07:58, 7 November 2022 (UTC)
- 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)
- Löschen 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)
- (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))
- Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl ❪✉❫ 00:15, 10 November 2022 (UTC)
- 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)
- Scanlation websites are seldomly located in Japan, so the details of Japanese law don't matter here. ChristianKl ❪✉❫ 00:15, 10 November 2022 (UTC)
- (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))
- Löschen 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)
- Löschen 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Both Afaz's financial argument and your rebuttal are political in nature and a distraction from the merits or deficiencies of the proposal. Let's not derail the discussion into general arguments about intellectual property vs. free culture and questions of artist rights and compensation. The fact that the website is in fact illegal in at least some if not most Wikimedia jurisdictions is a relevant consideration. Anon20240724 (talk) 04:38, 21 July 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- The Internet Archive is also recognised as a library by the US government. Thibaut (talk) 10:39, 13 February 2023 (UTC)
- 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)
- 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)
- 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)
- @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)
- 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)
- Kommentar 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)
- 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)
- 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)
- 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)
- 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)
- Löschen, 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)
- 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)
- As the property proposer, I have no objection to deletion based on the arguments provided. Tol (talk | contribs) @ 01:01, 30 November 2022 (UTC)
- Kommentar 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)
- 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)
- Kommentar 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)
- 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)
- Löschen per the above copyright and legal concerns. ミラP@Miraclepine 19:47, 9 December 2022 (UTC)
- 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)
- 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)
- Löschen 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)
- 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)
- 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)
- 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)
- A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)
- 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)
- 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:
Lockal (talk) 10:58, 13 March 2023 (UTC)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.
- A single proof that Mangadex hosts illegal content and does not respond to DMCA requests? Lockal (talk) 16:04, 12 March 2023 (UTC)
- Löschen - 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). - Löschen - Link to a site that is a violation of copyright law. --Fralambert (talk) 19:22, 12 March 2023 (UTC)
- Keep As far as I am aware:
- 1. MangaDex acts in full compliance with U.S. law under the DMCA act
- 2. MangaDex has never faced charges for hosting what they do. (they have been subpoenaed once, but that's very much not the same thing) Binarycat32 (talk) 00:52, 31 January 2024 (UTC)
- @Binarycat32: One of their staff literally says that "Mangadex doesn’t adhere to DMCA requests".
- Speaking of DMCA, see also above. Thibaut (talk) 06:06, 31 January 2024 (UTC)
- Löschen the copyright problem alone is enough to delete (in itself and because this make this website less likely to be perennial). In addition to that, I see that this property is use only on ~2800 items and ~25000 references, plus in most cases there is other identifiers and others references. It's maybe a "gold mine of information" but it's clearly not the only one, deleting these data would mean only a negligible lack of information in the end. Cheers, VIGNERON (talk) 15:30, 1 February 2024 (UTC)
- "in most cases there is other identifiers"
- a lot of those identifiers have been imported from mangadex. as far as i'm aware, mangadex is the only site other than wikidata that maintains links to other manga sites in this way. Binarycat32 (talk) 22:05, 2 February 2024 (UTC)
- It is possible to correlate titles with their MangaDex IDs but it would require maintaining a database of MD ids and other IDs linked to MD and then regularly updating this database both with new titles and if existing titles change their IDs. RPI2026F1 (talk) 02:39, 3 February 2024 (UTC)
- There's already a bot that does all of that, besides changing IDs, which happens approximately never. Binarycat32 (talk) 00:09, 5 February 2024 (UTC)
- Yea, that's me, I wrote the bot that does that RPI2026F1 (talk) 01:26, 5 February 2024 (UTC)
- Yeah I wondered as much, but I figured someone wouldn't write a bot then act like it didn't exist. Binarycat32 (talk) 18:30, 5 February 2024 (UTC)
- The current problem with said bot is that it only adds stuff from given properties. Basically, it won't try to approximate a MangaDex ID from just the MAL ID, but it will add a MAL ID if there is a MangaDex ID because MangaDex lists a MAL ID for that entry. RPI2026F1 (talk) 13:19, 6 February 2024 (UTC)
- finding the mangadex id is fairly easy with animanga-db-matcher[3]. however, this tool does not work well (or at all) for several other sites that often have their identifiers listed on MangaDex. Binarycat32 (talk) 18:51, 8 February 2024 (UTC)
- Yea that would be my bad, I wrote that tool as well but I had a very limited understanding of React and I found it easier to work on the auto-import bot than the finder. The reason it's not as effective is because I designed it for items that had no identifiers whatsoever, and at that point title searching was the only way to find potential IDs. I could make a future update that looks up other identifiers as well. RPI2026F1 (talk) 21:03, 8 February 2024 (UTC)
- finding the mangadex id is fairly easy with animanga-db-matcher[3]. however, this tool does not work well (or at all) for several other sites that often have their identifiers listed on MangaDex. Binarycat32 (talk) 18:51, 8 February 2024 (UTC)
- The current problem with said bot is that it only adds stuff from given properties. Basically, it won't try to approximate a MangaDex ID from just the MAL ID, but it will add a MAL ID if there is a MangaDex ID because MangaDex lists a MAL ID for that entry. RPI2026F1 (talk) 13:19, 6 February 2024 (UTC)
- Yeah I wondered as much, but I figured someone wouldn't write a bot then act like it didn't exist. Binarycat32 (talk) 18:30, 5 February 2024 (UTC)
- Yea, that's me, I wrote the bot that does that RPI2026F1 (talk) 01:26, 5 February 2024 (UTC)
- There's already a bot that does all of that, besides changing IDs, which happens approximately never. Binarycat32 (talk) 00:09, 5 February 2024 (UTC)
- It is possible to correlate titles with their MangaDex IDs but it would require maintaining a database of MD ids and other IDs linked to MD and then regularly updating this database both with new titles and if existing titles change their IDs. RPI2026F1 (talk) 02:39, 3 February 2024 (UTC)
- Keep it is just a platform, its not obvious if or when copyright is broken, it a grey area, I'm inclined to give benefit of doubt, and consider it legit. Simonc8 (talk) 10:27, 22 July 2024 (UTC)
- Keep per Lockal & Simonc8. Additionally, as mentioned by VIGNERON, there are currently over 2800 items with the property, but I unlike VIGNERON I would not discount it as "gold mine of information", the metadata available is quite robust. They have their own API you can use with the ID and unique info such as an independent scoring system. IntensionalLogican (talk) 03:12, 4 August 2024 (UTC)
- Keep it's still a useful database. –Shisma (talk) 12:25, 3 September 2024 (UTC)
WorldCat Identities ID (superseded) (P7859): (delete | history | links | entity usage | logs | discussion)
As recently announced by a banner in WorldCat Identities website, "The WorldCat Identities web application will be retired and shut down in the coming months and the data is no longer being updated. The most recent version of the data is from July of 2022. As OCLC continues to build out the WorldCat Entities ecosystem, please use it as a source for persistent Person identifiers. https://id.oclc.org/worldcat/entity" (note: WorldCat Entities is represented here by WorldCat Entities ID (P10832)). Whilst I usually support keeping the values of obsolete external IDs for historical purposes, I think in this case keeping it's not worth: the great majority of 1.93 M IDs are either VIAF-based or LCCN-based and the very few "np" and "nc" IDs (4k) have often a dubious identification value. My proposal is deleting the property as soon as the website will effectively go offline (while the website is still online, I would keep it), so probably before the end of 2023. —Epìdosis 21:20, 2 March 2023 (UTC)
- 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)- 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)
- @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)
- 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) oder 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)
- 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)
- Löschen Too many bot edits, too many errors. No chance of correction after shut down. --Kolja21 (talk) 23:36, 25 March 2023 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- Kommentar 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- Kommentar: could we keep this property and change the identifiers' links to Archive.org links? Veverve (talk) 18:31, 2 April 2023 (UTC)
- 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)
- The outcome is not convincing. Property:P7859#P1855:
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Keep for now, Löschen 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)
- 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)
- This is doable and not too complex. However:
- 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)
- Löschen. 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) oder 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)
- 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)
- Löschen, Worldcat Identities project is taken down.--Kadı Nachricht 12:24, 7 April 2023 (UTC)
- weak keep, until migration is done. After it is done, another deletion discussion can take place. Veverve (talk) 13:27, 7 April 2023 (UTC)
- What migration? 77.191.135.37 03:10, 17 April 2023 (UTC)
- I'm clear here for keep. Keep --Gymnicus (talk) 21:35, 15 April 2023 (UTC)
- When you have time, consider providing a reason? 77.191.135.37 03:05, 17 April 2023 (UTC)
- Löschen, dubious quality, lack of sources. If derived from viaf or lccn use these instead. 77.191.135.37 03:08, 17 April 2023 (UTC)
- Keep Worldcat Identities redirects in most cases to Worldcat Entities. Absolutely essential. Grimes2 (talk) 22:07, 17 April 2023 (UTC)
- @Grimes2: A rar visitor. How did you find this discussion? Kommentar 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)
- Keep: Certain until P10832 is populated following a migration strategy. Especially uaeful when the p7859 refirects to the new P10832 entity. -- DeirgeDel tac 20:30, 29 May 2023 (UTC)
- Kommentar: May I be so bold as to venture that the evidence it overwhelming that P7859 is retained until P10832 is populated. There is then the question of what is using the P7859 value out of Wikidata? Is it only the authority control template or something else? While that debate may not be helpful a more productive approach might be to agree a roadmap on how P10832 is to be populated. There's bits of that spread throughout the above vote but it would be helpful to see an agreed way forward in one place. That is focus on getting P10832 populated rather than P7859 deleted. Thankyou. -- DeirgeDel tac 10:48, 1 June 2023 (UTC)
- Å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)
- P7859's which redirrect to viaf and not worldcat entities are of no/limited use in determine P10832. P7859 which redirect to worldcat entries are more useful. I have no clue about any P7859 value not directing to a worldcat entity. And I'd love to look at this more but I've not got the resource. Thankyou. -- DeirgeDel tac 23:07, 1 June 2023 (UTC)
- Å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)
- Keep as per previous comments. I think it's of high importance for archival use and it could simply be modified to use a "Depreciated rank" instead of being removed (like many of the old Google-related IDs). Also noticed a user has been gung ho on deleting these before a consensus has been reached. I hope he's as motivated to restore them if the decision is made to keep.--Bricks&Wood (talk) 04:14, 4 September 2024 (UTC)
Migration to P10832
enWikiQuote migration case
As spin-off from Worldcat changes I've been exploring maintaining some functionality from loss of the "Worldcat id" template by replacing with authority control collecting P10832 from the associated wikidata item. There's only about 90 articles/Wikidata items involved with just over a handful having P10832 already populated. So I have been looking as getting the rest of 90 populated with P7859. I have kluged up a program which uses P7859 from wikidata to look up the P10832 via the redirect in a number of cases and produces Wikitable output as well as quickstatements input ( it avoids producing QS if P10832 is already populated). I've run in quickstatements batch 206942 a small batch of 5 if anyone wishes to make any comments. There's a little more information at q:en:User:DeirgeDel/xpop2 and q:en:Wikiquote:Village pump#P10832 population task plan F. Thankyou. -- DeirgeDel tac 12:12, 30 May 2023 (UTC)
- 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. Erledigt -- DeirgeDel tac 23:13, 30 May 2023 (UTC)
Removal of P7859 before consensus reached
I observe P7859 vales are being removed. I believe this is before consensus has been reached in the above discussion. In particular there is the interesting use-case of Joseph M. Crofts (Q115943526), an item created by myself when my DeirgeDel account was named Deirge Ó Dhaoinebeaga. @Epìdosis: removed the P7859 statement at Special:Diff/1906578499. I recovered that statement, the P7859 value I had set was "lccn-nb2002-21760" and unfortunately that linked to this Worldcat identity URL which redirected to notfound. However I remembered a "trick" "rule of thumb" from work on Wikiquote that is a Worldcat Identity has two hyphens sometimes changing the second hyphen to a zero would produce a worldcat identity that would redirect to an URL that would identify the required P10832 Worldcat Entity Id value. Thus from this change the link was generated which Worldcat sent to the redirect target URL which exposed the Worldcat Entity ID "E39PCjG8wDQPxYPBqJMgkxRvQC" for P10832 as well as links to the VIAF ID and the Library of Congress Name Authority File ID. While Epìdosis has been helpful adding additional identifiers I am concerned that removal of P7859 makes it difficult to locate the P10832 and suggest these removals need to be stopped and possibly even reverted. -- DeirgeDel tac 13:35, 2 June 2023 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- That's fine with me. Multichill (talk) 15:22, 3 June 2023 (UTC)
- 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)
::::Before talking about migration we need think about how to improve P7859. The removal of wrong IDs is part of the maintenance work. Let's start with Q6243526#P7859: 6 IDs: 5x VIAF, 1x LCCN. After this work is done there are 1.918.337 IDs left to be checked. When all IDs have been checked, we can talk about migration. --Kolja21 (talk) 17:56, 3 June 2023 (UTC) {{Small|I'm boldly suggesting this good faith has in some ways drifted from the topic Removal of P7859 before consensus reached and I've boldly forked it to a new section where that might be moved to in more detail. I hope that OK with everyone. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)
Template:Deindent
I've had and and having a few pretty busy RL days and I can't spend as much time on this as I'd like. Can I place some comment here in simple form, and I apologise if I'm being stupid. Some of the above discussion can be really hard to read if not read very carefully. If I'm correct @Epìdosis: wishes to run data cleansing batches: -- DeirgeDel tac 23:40, 3 June 2023 (UTC)
- P7859 elements will be removed when they refer to "viaf values" ... "viag*. These appears to provide no additional help in identify a P10832 value that the P214 value itself does not already provide. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)
- P7859 values that are of the form "lccn*" are not being removed, certainly at this stage, even if they do not currently provide a link a WorldCat Entity Id. -- 23:40, 3 June 2023 (UTC)
- VIAF itself at times requires data cleansing; I think VIAF sometimes has duplicate Id's that need to be merged. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)
Apologies if I've got the wrong end of the stick. -- DeirgeDel tac 23:40, 3 June 2023 (UTC)
- @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)
Pre-migration data cleansing of P7859
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)
- 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)
Practical way of migrating to P10832
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)
- @@Epìdosis:: I thank you for looking at this in a practical way and I must apologise for the limited time I can put in on this. My focus is on "can-do" of population of accurate P10832 values rather than the removal of other values that are potentially of some us/partial use in P10832 population. I acknowledge that work entities are more problematic in general and that where P7859 yields not found there is a high chance of issues with other identifiers as well, your identification of case 1 Museo di storia naturale di Rosignano (Q20009745) indicating an issue at a bigger level that P7859 and probably ought to be dealt with holistically. Equally an lccn-xxxxx-xxxx with two dashes while leading to not found is in case 1 but can sometimes be resolved by converting the second hyphen to a zero. In terms of your case two example Marco Zanetti (Q21542865) that links to a personal VIAF id and id like to spend time looking at that in detail but I am concerned that case does not extrapolate to every case in that identified group and that in some cases retention might help resolve difficulties. In terms of your example of exemplified removals I take the case of Leonard Lansink (Q100312) where the P7839 entry indicates a WorldCat Entity Id. record might exist. Doing a [4] person search for WorldCat Entities] yields The Worldcat Identity Id record E39PBJtmpJmHRBf7MYHXXWM9Dq Its then important to verify the data in E39PBJtmpJmHRBf7MYHXXWM9Dq matches what is held in the Wikidata item record, e.g. (VIAF ID="303829074", GND ID="115196137" ...) and it is safe to set P10832 to "E39PBJtmpJmHRBf7MYHXXWM9Dq". And that comes on the references to set for P18032. It is possibly useful to set a value to indicate P10832 wwas derived from a WorldCar redirect (on a particualr date), but it would also be useful to indicate that the contents of the WorldCat Entity Id.record contains referneces that indicate corresoonds to the Wikidata Item Id. This is not a reference of the form the GND database has a reference to WorldCat Entity Id (which would be nice but at least isn't happening for the moment) but rather that WorldCat Entity Id record confirms it correspond to GND ID which the Wikidata Id also confirms in relates to. In summary I will b opposing removals certainly for the moment but will be supporting proceeding with case (3) for person entities especially if referencing is agreed and ideally if a method of automation validation can be agreeed. Thankyou. -- DeirgeDel tac 22:24, 4 June 2023 (UTC)
New proposed plan for migration to P10832
Nine months after my previous plan, I would like to draft a second, more detailed one, articulated in the following 5 ordered steps:
- find P10832 through Library of Congress authority ID (P244): use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/NOsygr to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)Library of Congress Authorities (Q13219454) + Library of Congress authority ID (P244)id + retrieved (P813)retrieval date
- find P10832 through VIAF ID (P214): use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/rktIZX to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)Virtual International Authority File (Q54919) + VIAF ID (P214)id + retrieved (P813)retrieval date
- find P10832 through P7859: use the links in the third column of https://qlever.cs.uni-freiburg.de/wikidata/TbOMjH to find P10832 values and add them with references constructed in this way: matched by identifier from (P11797)WorldCat Identities (Q76630151) + retrieved (P813)retrieval date
- delete P7859 values in main statements (query: https://qlever.cs.uni-freiburg.de/wikidata/Zi6JSH) and references containing P7859 values (query: https://qlever.cs.uni-freiburg.de/wikidata/i1e1mT)
- delete P7859
Any comments are welcome! --Epìdosis 18:01, 16 March 2024 (UTC)
- I like this series of steps! I am attempting to compile lists of values with respect to the first three steps, although I don't know how fast I can make this compilation happen. Mahir256 (talk) 18:54, 16 March 2024 (UTC)
- So preparation of Step 1 is almost done: the bot code is ready to be tested and the list of P244 values is almost done being checked against WorldCat, so I hope that within the next few days I can start that part of the migration. (Thanks @Epìdosis: for doing some early QS runs for that step!) Mahir256 (talk) 19:47, 25 April 2024 (UTC)
- Alright, for those P7859 values containing "lccn-" that resolve to P10832 values, step 1 and step 4 (with respect to main statements) have begun. Mahir256 (talk) 16:32, 29 April 2024 (UTC)
- As part of point 3 the above plan, of which points 1 and 2 have now been completed, I will tomorrow start a batch removing nearly 4.5k "nc" and "np" values, which cannot be converted into WorldCat Entities ID (P10832). I will link it here. Epìdosis 18:47, 24 June 2024 (UTC) This is the batch.
Identifiers containing "viaf-"
It appears that for many P7859 values based on a VIAF ID (P214), the P7859 value now merely redirects to viaf.org, rather than to oclc.org as might have happened before. Given that the path to migrate to P10832 is therefore removed for those values which merely redirect to viaf.org, should the values in question be simply removed? Mahir256 (talk) 16:53, 29 April 2024 (UTC)
- Imho the VIAF based IDs should be removed since VIAF is a cluster which also contains namesakes. --Kolja21 (talk) 21:50, 20 May 2024 (UTC)
- Mahir, can your bot detect when viaf-something redirects to viaf.org? I would favor a deletion in these cases, if the viaf id is present in P214. ISNIplus (talk) 13:43, 29 August 2024 (UTC)
Continued batch removal of IDs that can be replaced
I strongly object. Example:
ISNIplus (talk) 20:59, 15 May 2024 (UTC)
Stop the Twofivesixbot!
Yesterday I had already called for the bot to be stopped immediately on the discussion page of Mahir256, who runs the Twofivesixbot. Both he and Epìdosis rejected this request and Epìdosis justified this by saying that no one had spoken out against the migration. However, this statement is incorrect because I, for example, as a clear supporter of keeping the property, was not informed of the new discussion, for example via a ping.
In my view, it was more the case that the supporters of deletion looked for a new way to delete the property without contacting the supporters of keeping the property, even though there is no consensus. That is why I am again calling for the bot to be stopped immediately and for a vote on whether these edits should be carried out or not. --Gymnicus (talk) 16:29, 13 June 2024 (UTC)
- As a precisation, in User talk:Mahir256#Twofivesixbot deletes statements I meant that no one had spoken out against the migration after the bot run had started; you are right observing that I did not specify explicitly "after the bot run had started". For the remainder, I am still convinced of what I wrote there. --Epìdosis 19:27, 13 June 2024 (UTC)
- But now I have spoken out against this bot run and therefore I continue to demand that this run be stopped immediately and that a proper vote be held on whether this migration is wanted or not. If Mahir256 does not stop the bot run within 24 hours, I will post a complaint on the administrator board. --Gymnicus (talk) 21:28, 13 June 2024 (UTC)
- There was a thorough discussion and the bot does a good job. No reason to stop it because of a single user. --Kolja21 (talk) 01:23, 29 June 2024 (UTC)
- There was no discussion, at least none in which the opposing side, which was clearly against any deletion, was even heard. As already mentioned, the deletion advocates are looking for a way around this so that the deletion can be carried out without consensus. The fact that this is being done by two administrators is, in my view, outrageous. Based on my experience, I am used to nothing less from Mahir256, but I am more than disappointed with Epìdosis. And the fact that the other administrators on the admin board did not even ask for a statement from the two of them is beyond audacity and shows once again that administrators are favored here and are seen as infallible. Gymnicus (talk) 15:26, 29 June 2024 (UTC)
- There was a thorough discussion and the bot does a good job. No reason to stop it because of a single user. --Kolja21 (talk) 01:23, 29 June 2024 (UTC)
- But now I have spoken out against this bot run and therefore I continue to demand that this run be stopped immediately and that a proper vote be held on whether this migration is wanted or not. If Mahir256 does not stop the bot run within 24 hours, I will post a complaint on the administrator board. --Gymnicus (talk) 21:28, 13 June 2024 (UTC)
2024-08
@Epìdosis: can you post statistics:
- ids starting viaf-
- ids starting lccn-
- ids starting with something else
? Recently each viaf- based id that I found redirected to viaf org. Would be nice to have these removed soon. ISNIplus (talk) 13:48, 29 August 2024 (UTC)
- Presently, out of 530901 values of P7859, 338759 with viaf- and 192142 with lccn-. Epìdosis 14:04, 29 August 2024 (UTC)
- Thank you. The first query restricted to humans and those where the part of the id after viaf- is also present in P214 https://w.wiki/B3zL : 244280 results. ISNIplus (talk) 10:49, 30 August 2024 (UTC)
2024-09
@Epìdosis, Kolja21: I only found the following results when clicking on IDs starting with:
- viaf- : redirect to viaf
- lccn- : not found
Regarding presence of the corresponding value in P214 and P244:
- present: P7859 can be removed
- not present:
- in case of VIAF - remove, since it is only a cluster ID
- in case of LC
- test if the value exists in WD somewhere else
- if not in WD, test if it exists in source
- if in source, test if it could be added to an existing item
If those "present" are removed it will be visible how many are "not present" and how many belong to humans or have a WorldCat Entities ID.
Opinions? ISNIplus (talk) 12:50, 1 September 2024 (UTC)
- I agree, IMHO you can proceed removing all the "present" ones. Epìdosis 16:23, 1 September 2024 (UTC)
- +1. No use to keep redirects to VIAF. --Kolja21 (talk) 16:42, 1 September 2024 (UTC)
VIAF - 2024-09
@Epìdosis, Kolja21: "present" for viaf- yields only one result https://w.wiki/B5LW : Q86431843 - the page is protected, Epìdosis, can you remove? The remaining P7859 "viaf-" items can be split into two groups:
- some P214 exists https://w.wiki/B5Lb : 1592 results
- the first result is "Paul Oskar Kristeller (Q63895)" - https://worldcat.org/identities/viaf-1504155044720972520000/ redirects to http://viaf.org/viaf/56612115 - that value is "present" in P214.
- 1354 are humans https://w.wiki/B5M4 - of these 859 have a GND https://w.wiki/B5M7, 1068 an ISNI https://w.wiki/B5MA, 680 a LC https://w.wiki/B5MC and 559 WorldCat Entities https://w.wiki/B5ML
- I suggest to remove the P7859 values - P214 is probably better maintained, P7859 could be 1) redirect to a value "present" in P214 2) wrong, 3) be another value or a redirect to another value - but when several values for the same item exist, the cluster is maybe more likely to be merge later - opinion? remove? who would check these otherwise?
- no P214 exists https://w.wiki/B5Lf : 344 results
- of these 295 are humans https://w.wiki/B5MP - none has WorldCat Entities https://w.wiki/B5Mk
- for the first two (Emilio Rúa (Q112898516), Jens G. Nørby (Q112942988)) the link redirected to WorldCat Entities, I added that value and added the viaf- value to P214 and in VIAF an ISNI was present which I added too.
- in case of the former two and others ("Jan Skiba" (Q97143763), "Dimitris Kavroudakis" (Q97467354)) the value had been removed by Epidosis but the removal undone by him https://editgroups.toolforge.org/b/EG/98011a0/
- several that I checked never had P214 before, so someone added these directly from WorldCat, so they probably have at least one work there, the accuracy could be higher than from normal P214-name-matches
- the 295 values could probably be copied to P214 and have the same error rate or lower as when humans normally add a value to P214
- I started reviewing the 295 manually, down to 263 now.
ISNIplus (talk) 13:48, 2 September 2024 (UTC)
- I agree about the need of checking manually the point 2 (fortunately not many items), thanks for doing it @ISNIplus:. For point 1, I agree that in the great great majority of cases we should expect the value of P214 to be correct, or at least more correct than P7859, so I would support removing them. Epìdosis 16:08, 2 September 2024 (UTC)
- BTW: There are also two types of errors:
- Lucie Guérin (Q3265277) with viaf-183149717630410952230 = IdRef 20006035X, other person.
- Demmin (Q559530); https://worldcat.org/identities/lccn-n88079667/ is a redirect but with the result "Entity not found" (see User talk:Mahir256#WorldCat Entities ID P10832).
- --Kolja21 (talk) 16:10, 2 September 2024 (UTC)
- Sorry, I made more clear what my comment from today referred to, by adding in front of it "VIAF - 2024-09" - so I will not respond to Demmin here as it is lccn- based, lccn- analysis expected earliest tomorrow, since the removal of the "present" values will last until then, but not sure if I will have time tomorrow.
- Regarding Lucie Guerín, thank you, I also saw such errors. Sometimes I created a new item, so that the error is less likely to be made again, for L. Guerín too, there is now Q130220212. ISNIplus (talk) 16:36, 2 September 2024 (UTC)
- BTW: There are also two types of errors:
- some P214 exists https://w.wiki/B5Lb : 0 results
- no P214 exists https://w.wiki/B5Lf : 196 results - should be visible at Wikidata:Database reports/Complex constraint violations/P7859#Value doesn't match P214 if the page is updated
ISNIplus (talk) 03:08, 3 September 2024 (UTC)
- viaf- on non-humans https://w.wiki/B5u5 : 0 results
- viaf- on humans https://w.wiki/B5$F : 89 results (value already copied to P214, but some redirect to WorldCat - manual verification ongoing)
- ISNIplus (talk) 20:05, 3 September 2024 (UTC)
- down to 39 ISNIplus (talk) 00:48, 4 September 2024 (UTC)
@Epìdosis, Kolja21: the manual review has ended. No more viaf- in P7859 ( https://w.wiki/B6Cd ). Actions frequently taken:
- new items created, because P7859 was misplaced
- corresponding P214 was deprecated and marked conflated - value deleted
- corresponding P214 claim created, and from VIAF, if present added ISNI, GND, IDref, BnF, LC, BNE, sometimes PLWABN
ISNIplus (talk) 08:26, 4 September 2024 (UTC)
LCCN - 2024-09-03
I think something went wrong: ISNIplus started deleting P214 properties that have P10832 associated with them, but it is not specified. In the case of manual follow-up care, this has been 100 percent so far (e.g.: Virág Judit Gallery, Budapest (Q105735314), Arcanum Adatbázis (Q56415347), Albert Szent-Györgyi University of Medicine (Q61052428)) Maybe. that the stick should be stopped and thought about. Pallor (talk) 09:07, 3 September 2024 (UTC)
- Thank you! Each of these cases belongs to the batches named "not q5 -P7859 lccn- if corresponding lc value in P244". I added a section headline before your comment. Will respond more later. ISNIplus (talk) 10:37, 3 September 2024 (UTC)
- @Pallor: Sorry for the delay, but I wanted to finish the work on viaf- first.
- I am an opponent of removal without adding P10832
- see my comment above from 2024-05-15 in section "Continued batch removal of IDs that can be replaced".
- I reviewed more than 295 human items manually, it was tedious and no pleasure, see above searching for 295.
- Regarding lccn- :
- I did check dozens of lccn- manually before, and only found redirects to viaf.org that resulted in "not found".
- Mahir (see above) had a bot running following these redirects and adding P10832
- The three cases you provided (thanks again!) indicate, that possibly more P10832 exist for none-human items that had a P7859 value. Since the removal was done by QS batches the removal statements could be downloaded and the P7859 values be looked up by a bot. Each batch is named "not q5 -P7859 lccn- if corresponding lc value in P244". ISNIplus (talk) 08:49, 4 September 2024 (UTC)
- The truth is that we have known before that many LCCN IDs have a Worldcat Entity even if the redirection does not work. For example, I only deal with elements related to Hungary, and within that, only those that are on my watch list, that is, a very small part of the entire stock, but I had a WCE record for 90 percent of the elements that I just reviewed, and if we look at public administrative units, then 100 percent. All I could do was manually add the WCE record for the 19 Hungarian counties, with quickstatements for the 175 districts, but I don't want to retrieve the IDs deleted from the settlements. This would be followed by the organizations of which I have listed three here, but approx. there were ten that I checked and found a WCE record for nine (regardless of whether the redirection worked or not).
- And I emphasize that these are only on the margins of the data mass, what about the rest? My suspicion is that now hundreds of thousands of values have been deleted that would have helped us to see which elements might have a WCE record. Pallor (talk) 10:27, 4 September 2024 (UTC)
- Re "The truth is that we have known before that many LCCN IDs have a Worldcat Entity even if the redirection does not work." - who is this group of "we", why wasn't I included?
- Re "My suspicion is that now hundreds of thousands of values have been deleted that would have helped us to see which elements might have a WCE record." - What is the basis of your "suspicion"? The batches named "not q5 -P7859 lccn- if corresponding lc value in P244" included 119173 commands for removal, with a bit over 100 not done due to "ERROR".
- Please 1) give an example where the redirection didn't work 2) say were was that mentioned before 3) explain how P7859 could be helpful. From your mentioned batch of district https://quickstatements.toolforge.org/#/batch/237079 I looked at the first, namely Ajka District Q554544 and P7859 seems to have never been present [5] - so I don't understand why you mention these here (same for 2nd and 3rd, didn't check any further).
- ISNIplus (talk) 12:29, 4 September 2024 (UTC)
- 1; Epidosis must have known about it, I'm sorry if you didn't inform me about it. Please don't delete more identifiers for now, let's develop a concept together first.
- 2; You're probably right, not hundreds of thousands, but "only" a hundred thousand (119173), but that's a lot, because we've lost so many potential connections. I'm not saying that every deleted LCCN P7859 had a P10832 counterpart, but I'm definitely saying that the ones that did have a connection, the deletion was a bad decision.
- 1; I don't understand this now: why do I have to give an example of what you yourself wrote about "I did check dozens of lccn- manually before, and only found redirects to viaf.org that resulted in "not found"." Now shall I give you an example of what you found?
- 2; P7859 is useful because it points out that this element may have a P10832 counterpart. If we delete this (P7859), the item becomes average, no one will think to look in the WorldCat Entities database to see if there is a record there.
- 3; This was probably misunderstood: I did not claim that there was a P7859 cancellation in relation to the Hungarian districts, but that I myself am trying to participate in the data cleaning/matching with my modest means. But it is still true that in the case of Hungarian counties and cities, P7859 was deleted from several places where P10832 would have been, but was not entered. It is unfortunate, but I can only assume that this may be true in relation to the administrative units of all other countries. (If you haven't checked the districts any further, can I trust that your check will be complete in the case of the deleted settlements?) Pallor (talk) 00:29, 5 September 2024 (UTC)
- Hope this addresses all (numbers don't correspond to the above numbers):
- Re the 119173 non-humans ("not q5 -P7859 lccn- if corresponding lc value in P244"): All I checked redirected to https://worldcat.org/identities/notfound. Their placement could have been right or wrong - but there was no reference and no way to see if they were right. External IDs come mostly without references, since they are the reference itself, but if they lead to https://worldcat.org/identities/notfound then there isn't even that kind of reference. - It is not clear how many had a redirect to a content page, despite my assumption none would have one. But since nothing is lost, first of all the value is still in P244, a bot could be run to check the redirects.
- A bot could check all P244 not only those that had P7859 against "https://worldcat.org/identities/lccn-<P244>/". So many more can potentially be found. For a start, the bot could check the 119173. Results could be:
- redirect to a value for P10832 exists: the value can be added
- redirect to a value for P10832 does not exist: how the presence of P7859 would help? You wrote "that many LCCN IDs have a Worldcat Entity even if the redirection does not work. For example, I only deal with elements related to Hungary, and within that, only those that are on my watch list, that is, a very small part of the entire stock, but I had a WCE record for 90 percent of the elements that I just reviewed, and if we look at public administrative units, then 100 percent." - please give an example. For the districts you found WCE without P7859.
- Last but not least, for several human items I don't understand the value of WCE at all, e.g. Talk:Q25930834#WorldCat Entities as a copy of Wikidata .
- ISNIplus (talk) 03:35, 5 September 2024 (UTC)
- Hope this addresses all (numbers don't correspond to the above numbers):
- ISNIplus: my combined answer:
- The significance of the presence of P7859 is that it indicates that this item may have a record in the WCE database. Whether the redirection works and it is easy to determine which is the related P10832 record, or the redirection does not work and only a unique search to determine the P10832 record is irrelevant. P7859 is a signal. When you delete P7859 without P10832 in the element, we lose a potential connection.
- I see that the WCE database is also developing. I have also been dealing with pairing for months, but only on the marginal line I mentioned earlier. My view is definitely that there are more and more items in WCE that weren't there before, or were there under different names. I couldn't find them before, now I can. You see that a name appears in "text" format (eg: X. Y.'s letter to W. Z.), but before there was no record for X. Y., now there is. Or there is no record now, but there will be later.
- We will only find them if we look back from time to time at the previously unpaired elements. The existence of P7859 is a big help for this, which is why I consider the recent deletions to be a serious mistake. Pallor (talk) 21:30, 6 September 2024 (UTC)
- P.s.: Most of what you see here was placed by me (before you note: I was not consistent in using "novalue" and "somevalue"). These indications indicate that there was P7859, so presumably there is (or will be) P10832, but when I checked this it wasn't. This mark is like a Wikidata item where you left P7859 in even though you didn't find P10832. Pallor (talk) 21:36, 6 September 2024 (UTC)
- Köszönöm szépen. In the WCE link one can substitute .html with .json and get structured data, this can help to check correctness of existing IDs. Today I counted humans that have P10832, it's over a 1309241, from VIAF only ISNI and GND have more and LC has a bit less. Regarding the signal I agree, deletion end of August (?) was not considering that items in WCE might exist, even if link is broken. I tried to find a download link for my QS, but couldn't find, maybe it is in editgroups which was broken, when I looked, will check again. Maybe the signal can be brought back using P10832, e.g. value unknown and a lccn- reference, similar to what you did. Unfortunately I have no software to mass check IDs, but if no one else is doing it, I *may* try to do it. ISNIplus (talk) 23:31, 6 September 2024 (UTC)
- P.s.: Most of what you see here was placed by me (before you note: I was not consistent in using "novalue" and "somevalue"). These indications indicate that there was P7859, so presumably there is (or will be) P10832, but when I checked this it wasn't. This mark is like a Wikidata item where you left P7859 in even though you didn't find P10832. Pallor (talk) 21:36, 6 September 2024 (UTC)
LCCN - 2024-09-04 AM
Statistics for items having P7859 with "lccn-":
- https://w.wiki/B6Dr all : 64181
- https://w.wiki/B6Du human : 44766
- https://w.wiki/B6Dv P244 exists : 6229
- https://w.wiki/B6Dx P244 is the same : 140
- https://w.wiki/B6Dy P244 is the same and P10832 exists : 29
- https://w.wiki/B6E3 part after lccn- contains "-" : 723
- https://w.wiki/B6E6 part after lccn- contains "-" and P244 exists : 685
- https://w.wiki/B6E8 part after lccn- contains "-" and P244 is the same when "-" removed : 541
- https://w.wiki/B6EA part after lccn- contains "-" and P244 is the same when "-" removed and P10832 exists : 341
- https://w.wiki/B6KK part after lccn- contains "-" and P244 is the same when "-" replaced with "0" : 117
- https://w.wiki/B6KC part after lccn- contains "-" and P244 is the same when "-" replaced with "0" and P10832 exists : 70
- https://w.wiki/B6Lj part after lccn- contains "-" and P244 is the same when "-" replaced with "00" : 22
- https://w.wiki/B6Ln part after lccn- contains "-" and P244 is the same when "-" replaced with "00" and P10832 exists : 16
- https://w.wiki/B6JJ no P244 and no P10832 : 57543
ISNIplus (talk) 09:39, 4 September 2024 (UTC)
Regarding 'part after lccn- contains "-"'
- Removal
- I checked four of the 341 - in each case redirect didn't work with "-" but did work without "-" and lead to the existing P10832. ISNIplus (talk) 13:13, 4 September 2024 (UTC)
- The remaining 337 processed via https://quickstatements.toolforge.org/#/batch/237125 ISNIplus (talk) 13:22, 4 September 2024 (UTC)
- I checked four of the 70 - in each case redirect didn't work with "-" but did work with "0" instead and lead to the existing P10832. Remaining 68 processed via https://quickstatements.toolforge.org/#/batch/237127 ISNIplus (talk) 13:44, 4 September 2024 (UTC)
- 16 removed https://quickstatements.toolforge.org/#/batch/237134 ISNIplus (talk) 14:21, 4 September 2024 (UTC)
- I checked four of the 341 - in each case redirect didn't work with "-" but did work without "-" and lead to the existing P10832. ISNIplus (talk) 13:13, 4 September 2024 (UTC)
- Keep but adjust
- 199 items: adjust P7859 to P244 by removing "-" https://quickstatements.toolforge.org/#/batch/237130 ISNIplus (talk) 14:09, 4 September 2024 (UTC)
- 47 items: adjust P7859 to P244 by replacing "-" with "0" https://quickstatements.toolforge.org/#/batch/237131 ISNIplus (talk) 14:09, 4 September 2024 (UTC)
- 6 items: adjust P7859 to P244 by replacing "-" with "00" https://quickstatements.toolforge.org/#/batch/237135 ISNIplus (talk) 14:26, 4 September 2024 (UTC)
- 723 down to 38 and no P244 is present. ISNIplus (talk) 14:55, 4 September 2024 (UTC)
- 723 down to 0. ISNIplus (talk) 16:33, 4 September 2024 (UTC)
LCCN - 2024-09-04 PM
Statistics for items having P7859 with "lccn-":
- https://w.wiki/B6Dr all : 63681
- https://w.wiki/B6Du human : 44271
- https://w.wiki/B6Dv P244 exists : 5775
- https://w.wiki/B6Dx P244 is the same : 369 (link with ext. URLs https://w.wiki/B6S4)
- https://w.wiki/B6Dy P244 is the same and P10832 exists : 0
- https://w.wiki/B6JJ no P244 and no P10832 : 57501
- https://w.wiki/B6Sw no P244 exists : 57906
ISNIplus (talk) 16:42, 4 September 2024 (UTC)
@Mahir256: can you run your bot again on these items to find values for P10832? @Epìdosis, Kolja21: opinion about how to proceed? ISNIplus (talk) 12:50, 4 September 2024 (UTC)
- @ISNIplus: Thanks for your good work. I just stumbled across the ceb issue:
- LCAuth was missing in Romano d'Ezzelino (Q46277) since it was already added to the ceb item Romano d'Ezzelino (Q30029548). [6]
- --Kolja21 (talk) 15:42, 4 September 2024 (UTC)
- https://w.wiki/B6Dy "P244 is the same and P10832 exists" increased to 180 due to copying the lccn- value to P244, first that I checked is Rheinfelden, like the Romano d'Ezzelino example. https://www.wikidata.org/w/index.php?title=Q269667&diff=2243669242&oldid=2179408808 ISNIplus (talk) 03:45, 5 September 2024 (UTC)
@Epìdosis, Kolja21: there are ~63000 lccn- for which no P244 is present (57906 items without any P244). I cannot judge the quality of the LC within P7859, but when cleaning those that contained "-" in the string after lccn- I found several that were - in adjusted form - good for insertion into P244. So, maybe it is best to copy these values to P244, a property which is much better maintained and where people will find inconsistencies and duplicates. If the LC value is preserved that way, one could even delete P7859.
@Bargioni: could you check which P7859 lccn-links are resolving to "not found"? Could moreIdentifiers be extended to look for WCE if P244 exists but not P10832? ISNIplus (talk) 17:29, 4 September 2024 (UTC)
- Thanks very much for your manual checks.
- Copying values to Library of Congress authority ID (P244) (I would suggest to leave a reference matched by identifier from (P11797)WorldCat Identities (Q76630151) to these IDs to make it easier checking them afterwards) seems reasonable to me.
- I'm sure moreIdentifiers cannot "be extended to look for WCE if P244 exists but not P10832", since it is based exclusively on VIAF and VIAF presently doesn't take into account WCE. For P7859 lccn-links resolving to not found, maybe the program already used by @Mahir256: can be readapted to do it with not much work. Epìdosis 17:44, 4 September 2024 (UTC)
- Batches running for 57948 claims including ref as suggested by you, they are named "+P244,S11797=Q76630151".
- moreIdentifiers would just need a call to another URI and work with the response(s), but probably better to have a bot running, could be too many useless calls to WCE. I could create an account ISNIplusBot, and maybe adjust and run existing code. Or maybe I use a local programm, and add results via QS later. ISNIplus (talk) 19:56, 4 September 2024 (UTC)
LCCN - 2024-09-05 adding WCE but not removing WCI
@Pallor:, two minutes after I added P244 (LC) you added P10832, but didn't remove P7859 [7] - can you explain why? Others then will have to look at the item again. With a longer distance between my edit and yours: Q62075614, Q66361504. ISNIplus (talk) 18:55, 5 September 2024 (UTC)
- I don't delete P7859, which has two reasons:
1; deletions can be done extremely efficiently with a stick when we get to the end of the project and every item P7859 is assigned P10832. 2; the community's support for the cancellation was not clear. I read that P7859 should not be deleted for the time being. Pallor (talk) 00:39, 6 September 2024 (UTC)
- 1) "every item P7859 is assigned P10832" - so you don't care if a specific P7859 redirects to a specific P10832? In two of the cases above the redirects from P7859 pointed to https://worldcat.org/identities/notfound . 2) "the community's support for the cancellation was not clear" - For 2a: P7859 for which the P10832 has been added? 2b: P7859 pointing to https://worldcat.org/identities/notfound ? ISNIplus (talk) 00:45, 6 September 2024 (UTC)
LCCN - 2024-09-06 AM
Statistics for items having P7859 with "lccn-":
- https://w.wiki/B6Dr all : 61685
- https://w.wiki/B6Du human : 42478
- https://w.wiki/B6Dv P244 exists : 61605
- https://w.wiki/B6Dx P244 is the same : 57713 (link with ext. URLs https://w.wiki/B6S4)
- https://w.wiki/B6Dy P244 is the same and P10832 exists : 0
- https://w.wiki/B6JJ no P244 and no P10832 : 80
- https://w.wiki/B6Sw no P244 exists : 80
ISNIplus (talk) 03:13, 6 September 2024 (UTC)
- I reviewed the 80 manually, now down to 0. ISNIplus (talk) 15:19, 6 September 2024 (UTC)
LCCN - 2024-09-06 PM
Statistics for items having P7859 with "lccn-":
- https://w.wiki/B6Dr all : 61590
- https://w.wiki/B6Du human : 42421
- https://w.wiki/B6Dv P244 exists : 61590
- https://w.wiki/B6Dx P244 is the same : 57699 (link with ext. URLs https://w.wiki/B6Ru)
- ?? P244 is not the same : 61590-57699=3891 (see also: Wikidata:Database reports/Complex constraint violations/P7859)
- https://w.wiki/B6Dy P244 is the same and P10832 exists : 0
- https://w.wiki/B6JJ no P244 and no P10832 : 0
- https://w.wiki/B6Sw no P244 exists : 0
ISNIplus (talk) 15:20, 6 September 2024 (UTC)
For "P244 is the same : 57699" one could remove P7859, the P244 value is tagged with "matched by identifier from : WorldCat Identities" - so no data is lost, just duplication removed. @Epìdosis, Kolja21: Opinion? ISNIplus (talk) 15:35, 6 September 2024 (UTC)
- I agree that we can remove them. Epìdosis 15:59, 6 September 2024 (UTC)
- +1. --Kolja21 (talk) 19:21, 6 September 2024 (UTC)
France Culture person ID (DEPRECATED) (P5301): (delete | history | links | entity usage | logs | discussion)
Replaced by P10780 Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).
Notified participants of WikiProject France. Nomen ad hoc (talk) 08:18, 25 May 2022 (UTC).
- @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)
- @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).
Löschen : 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)
- @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)
- 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)
- 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)
Löschen I have imported the Radio France ID. In these cases, I deleted the obsolete identifiers. There are probably still some Radio France and France Culture identifiers (duplicate items, one with Radio France, the other with France Culture), but these cases should be rare. --Hamuli (talk) 19:44, 4 October 2023 (UTC)
Scilit journal ID (P7662): (delete | history | links | entity usage | logs | discussion)
The source website does not keep permanent identifiers for journals. After a website update, all IDs seem to have changed. All (?) IDs in Wikidata seem now either to resolve to a 404 page (Scilit journal ID (P7662) of Journal of inorganic and general chemistry (Q186776), Scilit journal ID (P7662) of Intel Technology Journal (Q130945), Scilit journal ID (P7662) of IEEE Transactions on Mobile Computing (Q129122), ...) or refer to completely different entities now (Scilit journal ID (P7662) of Nucleic Acids Research (Q135122), Scilit journal ID (P7662) of Journal of Chemometrics (Q127755), Scilit journal ID (P7662) of Microscopy Research and Technique (Q59757), ...).
@GZWDer, Eihel: Ping as property creators. --Haansn08 (talk) 21:49, 4 August 2023 (UTC)
- 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)
- Info The problem has already been raised in May 2022, and resolved. Cordially. ―Eihel (talk) 23:35, 4 August 2023 (UTC)
- 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)
national team appearances (P1129): (delete | history | links | entity usage | logs | discussion)
We have number of matches played/races/starts (P1350) to express the number of games for any team as a qualifier. This is used currently more than 700,000 times, also for national teams – as number of matches played/races/starts (P1350) is generic, it can be used for all kinds of teams, from youth teams to national teams. There is no need for national team appearances (P1129) besides number of matches played/races/starts (P1350), but the co-existence and mixture creates problems when using the data outside of Wikidata. Therefore, I propose to change the 5,000 usages of national team appearances (P1129) to number of matches played/races/starts (P1350) and then delete national team appearances (P1129). —Yellowcard (talk) 18:24, 10 October 2023 (UTC)
- Support This has bugged me for a long time as well. I see no reason to make a difference between games played for a national team and games played for a club. Jssfrk (talk) 21:00, 9 June 2024 (UTC)
- As a national player in my sport, I have to say that these are two different issues. Take the example of today's announcement that Manuel Neuer, the German goalkeeper, has retired as a national player after 124 games for Germany (which is a record call-up to the German national soccer team). In many sports codes, it is common to count the number of national team caps, and it is often shown in the Wikipedia info box.
- Please consider this. Tank you. Detlef Pfeifer (talk) 15:32, 22 August 2024 (UTC)
- We have been doing this in the German Wikipedia for a long time. That is exactly what qualifiers are for. You do not need a separate property for doing that. See de:Kategorie:Wikipedia:Infobox Fußballspieler mit Daten aus Wikidata for a list of the players with infobox data from Wikidata, many of them are national players and have their numbers of national games in the infobox as well. From a technical point of view, there is no real difference to show the appearances in the several clubs the player played for, and the (maybe several) national team(s). Random example: de:Rasheedat Ajibade. In Rasheedat Ajibade (Q50082738) you will see that national team appearances (P1129) was not used or needed here, but we are showing his appearances for the Nigerian national team as well as his club appearances. All this information comes from Wikidata. Regards, Yellowcard (talk) 06:48, 27 August 2024 (UTC)
interested in (P2650): (delete | history | links | entity usage | logs | discussion)
This is a follow-up of Wikidata:Project chat#Interested in vs. Field of work (opened by @Daask: on 18 October): as argumented by many users there, the difference between interested in (P2650) (with 17k uses in main statements) and the older field of work (P101) (with 938k uses in main statements) is not clear enough; whilst it has been said that P101 is for professional areas and P2650 for non-professional areas, it seems that presently both properties have been used for both fields, and there is a high probability that this confusion will worsen in the future; thus, following the proposal of @Vojtěch Dostál:, I agree that we can "merge the duplicates and start a new proposal if required for some other (or perhaps the originally intended) use case". So I'm proposing to delete P2650, bot-transferring all its values to P101; I'm not fully convinced that we need another property besides P101, but if someone wants to propose it in the future, this deletion wouldn't hinder them from doing it. Otherwise, if we choose not to delete P2650, I think we need to 1) state much more clearly how it differs from P101 and 2) find effective methods to move wrong uses of P2650 to P101 and viceversa (note: wrong according to the clearer definition of P2650 foreshadowed at point 1). —Epìdosis 19:20, 25 October 2023 (UTC)
- There is possible merit in it for people's hobbies (as was argued for fictional characters where field of work (P101) read oddly), but I can see no merit for organisations, all uses there should be transferred. Vicarage (talk) 21:23, 25 October 2023 (UTC)
- That's how I used it, because "field of work" sounded a bit odd for something that is usually seen as an opposite to work. If it had "hobby" (occupation (P106) comes up for this in a search because of a French alias) or "pastime" as an alias that might make me more confident in using it. GreenReaper (talk) 20:38, 5 June 2024 (UTC)
- Weak support P2650 is hardly used at all in the arts domain (artists with P2650). P2650 does not meet any need in this domain that P101 or inspired by (P941) cannot meet. But I cannot speak for other domains... Fjjulien (talk) 19:57, 1 December 2023 (UTC)
Before deletion we need an analysis of the current uses so we can inform people. Since it was originally proposed for WikiProjects I assume it was in use for a few, but could never have been many, because I would have seen it pop up in the proposal discussions for on focus list of Wikimedia project (P5008). Jane023 (talk) 08:36, 27 October 2023 (UTC)
- @Jane023: A quick SPARQL query indicates that it is currently in use on 18 WikiProject items. Daask (talk) 13:43, 27 October 2023 (UTC)
- Thanks! It's interesting to see the minimal information for such projects on Wikidata - the first page I looked at, Wikidata:WikiProject Moravian Knowledge Network Research, doesn't even point to any external site in the wikiverrse or otherwise. It's probably a good idea to start a larger campaign to clean this up. Jane023 (talk) 14:11, 27 October 2023 (UTC)
Support Move all uses to P101 and delete.Vojtěch Dostál (talk) 12:47, 25 June 2024 (UTC)
SvFF national player ID (archived) (P4830): (delete | history | links | entity usage | logs | discussion)
Branches only to the archive version of the database, for running url there is Schwedische Fußballassoziation ID (P1238), see Property_talk:P4830 without an answer; verzweigt nur auf die Archivversion der Datenbank, für laufende url gibt es Schwedische Fußballassoziation ID (P1238), siehe Property_talk:P4830 ohne Antwort --Nordprinz (talk) 18:53, 24 October 2023 (UTC)
- Notified participants of WikiProject Sweden Notified participants of WikiProject Association football --Ameisenigel (talk) 12:27, 7 July 2024 (UTC)
GeoNLP ID (obsolete) (P5400): (delete | history | links | entity usage | logs | discussion)
Following the upgrade of GeoNLP to version 2.0 on July 8, 2021, the existing GeoNLP IDs have been invalidated and replaced with new identifiers called GeoLOD IDs. Due to the lack of compatibility between GeoNLP IDs and GeoLOD IDs, which no longer function as identifiers for the same entities, it is necessary to delete the GeoNLP ID property from Wikidata and create a new property corresponding to GeoLOD IDs. This request is based on official announcements from GeoNLP ('Release of GeoNLP Version 2.0' and 'About the major renewal of GeoNLP'). Therefore, I request the deletion of the GeoNLP ID property. —Likibp (talk) 10:14, 5 November 2023 (UTC)
- GeoLOD ID (P12170) has now been created. Jonathan Groß (talk) 20:00, 22 November 2023 (UTC)
Hungarian National Namespace organisation ID (old) (P6989): (delete | history | links | entity usage | logs | discussion)
The property IDs and the formatting URL have also changed. A new property (Hungarian National Namespace organisation ID (new) (P11685)) was created, which was added to all old (P6989) data with the new identifier. This property is deprecated and can be deleted. (Control query: https://w.wiki/8JmT) —Pallor (talk) 18:21, 28 November 2023 (UTC)
- Keep It is still valuable information. While the official website (abcd.hu) is no longer available, these statements can still help match IDs found elsewhere to Wikidata items (and through them, even to new MNN IDs). —Tacsipacsi (talk) 15:16, 2 December 2023 (UTC)
- Tacsipacsi Can you list the data that is available on the old form with the old ID but not on the new ABCD? (otherwise the abcd.hu site is available). So what data would be lost if we delete the identifier? Pallor (talk) 17:25, 2 December 2023 (UTC)
- @Pallor: What we would lose is the fact that the MNN ID of the National Assembly (Q648716) using the old scheme is 204006. External identifiers are pieces of information themselves, not only references for other pieces of information. It may happen that third-party data reusers (or even ourselves) find a reference to an organization that uses this old scheme. Removing these statements would make it impossible to process that reference (at least without digging into item histories, which is probably not something one would want to do or want to write a program for). —Tacsipacsi (talk) 19:55, 2 December 2023 (UTC)
- @Tacsipacsi: By this argument, I think we could completely eliminate the deletion of external IDs for property IDs, since you argue that, whatever the topic, each ID carries information. But the practice is not: if the IDs do not lead to information that would be lost without them, then feel free to delete them. And these IDs do not carry any information, since everything that was on the page accessed with the previous ID is also on the page accessed with the new ID. Pallor (talk) 22:03, 2 December 2023 (UTC)
- Indeed, I generally don’t agree with the deletion of external ID properties unless creating them has never been a good idea (e.g. it is, and has always been, totally useless), or for technical reasons (including cases when a new property was created after a schema change for technical reasons, but the old ID can be algorithmically determined from the new one). I may be in minority with this opinion, though; if the vast majority of users who comment in this discussion are in favor of the deletion, I’ll accept the community decision. —Tacsipacsi (talk) 01:26, 3 December 2023 (UTC)
- I second all that Tacsipacsi wrote. Keep! I don't see the value in deleting defunct IDs either. – Máté (talk) 20:51, 28 January 2024 (UTC)
- Indeed, I generally don’t agree with the deletion of external ID properties unless creating them has never been a good idea (e.g. it is, and has always been, totally useless), or for technical reasons (including cases when a new property was created after a schema change for technical reasons, but the old ID can be algorithmically determined from the new one). I may be in minority with this opinion, though; if the vast majority of users who comment in this discussion are in favor of the deletion, I’ll accept the community decision. —Tacsipacsi (talk) 01:26, 3 December 2023 (UTC)
- @Tacsipacsi: By this argument, I think we could completely eliminate the deletion of external IDs for property IDs, since you argue that, whatever the topic, each ID carries information. But the practice is not: if the IDs do not lead to information that would be lost without them, then feel free to delete them. And these IDs do not carry any information, since everything that was on the page accessed with the previous ID is also on the page accessed with the new ID. Pallor (talk) 22:03, 2 December 2023 (UTC)
- @Pallor: What we would lose is the fact that the MNN ID of the National Assembly (Q648716) using the old scheme is 204006. External identifiers are pieces of information themselves, not only references for other pieces of information. It may happen that third-party data reusers (or even ourselves) find a reference to an organization that uses this old scheme. Removing these statements would make it impossible to process that reference (at least without digging into item histories, which is probably not something one would want to do or want to write a program for). —Tacsipacsi (talk) 19:55, 2 December 2023 (UTC)
- Both opinions represent a point of view that could be added to virtually all properties for deletion ("keep it because it's valuable"), but they don't explain what the value is in an unused and unrecoverable identifier. Such a belief essentially makes cancellation discussions impossible, since it is too general and elusive to be considered as an argument and to respond to it in a meaningful way.
- As additional information, I describe that the database currently consists of 62,060 items, of which 35 items have been transferred to Wikidata. No data can be read back from any of them, on the other hand, the new identifier makes all data available. I still maintain my deletion proposal. Pallor (talk) 21:43, 17 March 2024 (UTC)
YerelNet village ID (P2123): (delete | history | links | entity usage | logs | discussion)
Yerelnet website was a government-supported website in Turkey. There was an identifier id for every village in Turkey and it had an index about all villages. However, this project was terminated by a law in 2018. The domain name of the site (https://www.yerelnet.org.tr) is currently used for personal purposes and the site does not currently serve as a database. Also, all id numbers added to wikidata pages are currently not working. For these reasons, it would be appropriate to delete Property:P2123. —Sadrettin (talk) 15:34, 3 December 2023 (UTC)
- Löschen It seems that this site is currently not working. It is better to make it stop. Mereyü 💬/✉️ 16:06, 3 December 2023 (UTC)
- Löschen Right. Yerelnet is not working anymore. We don't need this property. --Kurmanbek 💬 16:23, 6 December 2023 (UTC)
- @Sadrettin: Have you exported the current IDs (for historical purposes)?--Geverkshaft (talk) 10:18, 17 December 2023 (UTC)
- Löschen Looks reasonable. Nanahuatl (talk) 18:54, 27 December 2023 (UTC)
- Keep for now, as it's the only way to find villages (or places that were villages until recently) in a district (although now several years out of date). Many have been archived or included in an archived list from which the identifier can be found. It was mostly accurate, although because places could be added it had a few (around 5-10) additions that were not part of the data originally added to the site that were probably neighbourhoods or other locations (although I'm not sure if any of these are in Wikidata). Otherwise the P31 can be vague (Erikli, Bozüyük (Q1155400) for example, which otherwise only has a GeoNames ID). Wikidata:Property proposal/Tüik number needs proposing as separate properties, including one for village; when approved and added to items, it can replace this. Peter James (talk) 21:03, 4 February 2024 (UTC)
- I also noticed most instances of mahalle (Q17051044) were changed to neighborhood (Q123705) (which seems incorrect, as is the statement that Q123705 is a subclass of administrative territorial entity type (Q15617994) - and in most countries Q123705 isn't an instance of that either). Instances of village in Turkey (Q1529096) would then become village (Q532) to be consistent, although I prefer more specific administrative units for Wikidata - at least make it clear whether something is an administrative unit or not. Adding statements such as that in Q123705 (or quarter (Q2983893), where the claim to be a subclass of administrative territorial entity (Q56061) is wrong in some countries and conflicts with the description) is not the correct way to clarify this, or to fix constraint violations, or whatever was intended. Peter James (talk) 01:38, 18 February 2024 (UTC)
- YerelNet links were added years ago and the website closed 8 years ago. If you believe that you can rely on these links and find villages in Turkey, this list will be very incomplete. Frankly, I can't find a single concrete benefit for not deleting YerelNet connections. Sadrettin (talk) 19:18, 17 June 2024 (UTC)
- Löschen per nom. --Wüstenspringmaus talk 11:48, 3 June 2024 (UTC)
- Keep The Wayback Machine has over 35,000 archived pages (see IDs starting with 23, 24, 25, 26 and 3). We have 35,691 IDs, so almost all of them should have an archived version.
- The pages I looked at had information such as population history, altitude and a map showing the location. There are at least 10,000 pages linking to the pages on other wikis, according to the Global Search tool.
- - Nikki (talk) 12:53, 21 August 2024 (UTC)
Zhihu topic ID (P3553): (delete | history | links | entity usage | logs | discussion)
The website Zhihu (知乎) is listed as deprecated source on Chinese Wikipedia. Edit filter is triggered when relavent link is added. --EleniXDD (talk) 11:53, 26 February 2024 (UTC)
- Wikipedia and Wikidata are totally different websites.--GZWDer (talk) 10:55, 27 February 2024 (UTC)
@GZWDer: I agree the nomination is confused about the purpose of this property. We have topic ID properties for other knowledge forum websites too e.g. Quora topic ID (P3417) so I think it's acceptable to have an external identifier property for Zhihu. However, EleniXDD makes a good point that Zhihu (as with any other crowd Q&A websites) are not reliable sources. For that reason, I recommend changing the constraint to remove property scope (P5314)as reference (Q54828450) to discourage editors from using Zhihu as a reference. Deryck Chan (talk) 17:19, 30 May 2024 (UTC)
- Keep, same as GZWDer. And it's ok to remove QA websites as references. Kethyga (talk) 12:43, 6 June 2024 (UTC)
Singapore Infopedia ID (former scheme) (P8350): (delete | history | links | entity usage | logs | discussion)
The URIs of Singapore Infopedia articles had been amended. For example, the URI for the article of Siva Choy https://eresources.nlb.gov.sg/infopedia/articles/SIP_1665_2010-04-28.html is replaced by https://www.nlb.gov.sg/main/article-detail?cmsuuid=8709468f-f41f-44b4-9e8a-ef6ac25accfe. We would like to propose a new property of the same name Singapore Infopedia ID to replace the current property P8350. The request for a new property was made at Wikidata:Property proposal/Singapore Infopedia ID (new scheme). The label of P8350 had been renamed Singapore Infopedia ID (former scheme). —Nlbkos (talk) 05:38, 26 February 2024 (UTC)
Argentine Chamber of Deputies ID (P4454): (delete | history | links | entity usage | logs | discussion)
Initially discovered because the ID's links were timing out. Looking at the spanish webpage (https://www.hcdn.gob.ar/diputados/index.html) it appears that only current politicians have a profile, but ideally an extra set of eyeballs would be nice for a confirmation. Anyways, since the identifiers are unstable, there is no point in a property and so it shall be deleted. —Infrastruktur (talk) 15:33, 10 March 2024 (UTC)
- Keep Unless the IDs are entirely transient (i.e. get re-used for someone else) that only seems like a reason to update or remove the links, not to remove the property entirely. Not having a current profile page doesn't mean that the IDs aren't used elsewhere on the site, or won't be included in future if the person is re-elected or the site is redesigned, or that these IDs aren't in use in historic data-dumps etc. I don't understand why we would want to throw that information away. Oravrattas (talk) 16:08, 10 March 2024 (UTC)
- If the site does not employ a scheme to prevent reuse of identifiers then reuse is a distinct possibility. The identifier seems to be based on one letter for given names and the whole surname. And surnames are reused all the time, making ID collisions fairly likely. Infrastruktur (talk) 17:00, 10 March 2024 (UTC)
- Do you have examples of this ever happening? The idea that an identifier might get reused seems pretty thin as a rationale for deleting a well-used property. Oravrattas (talk) 01:17, 13 March 2024 (UTC)
- If the site does not employ a scheme to prevent reuse of identifiers then reuse is a distinct possibility. The identifier seems to be based on one letter for given names and the whole surname. And surnames are reused all the time, making ID collisions fairly likely. Infrastruktur (talk) 17:00, 10 March 2024 (UTC)
statistical unit (P2353): (delete | history | links | entity usage | logs | discussion)
I propose deleting statistical unit (P2353) since its current use differs greatly from the original idea, both of which could be better modelled through other existing properties.
Most of the P2353 statements are to my understanding essensially duplicates of instance of (P31), except only for telling that the item is an instance of some sort of statistical unit. For example, on one of the example items of the property, Bni Gmil (Q1942317) has a statement statistical unit (P2353)rural commune of Morocco (Q17318027) meanwhile P31 has the exactly same value. On the second example item, Orchard Ridge (Q23137124), there is a statement statistical unit (P2353)Neighborhood Statistical Area of Baltimore (Q111902602) but P31 doesn't have that value, even though it clearly should. The property is currently stated on 246 items, of which 173 are located in Baltimore, United States.
If I understood correctly, the original purpose of P2353 presented in the property proposal was to model what kind of units populate a dataset or database. I can find only 13 items where P2353 is used this way, all of which originate in France, for example ASPIC (Q101086386) and Fichier des personnes décédées (Q80900474). In my opinion these cases could be better modelled through existing properties has part(s) (P527) oder has part(s) of the class (P2670) as is done in most items about databases. —Samoasambia ✎ 20:04, 13 April 2024 (UTC)
- I've suggested to create the property because I needed to describe datasets or database. The idea is that some datasets describe countries, some datasets describe organization, etc. See Q3509449#P2353 for a good example.
- has part(s) (P527) doesn't work for my use case
- has part(s) of the class (P2670) is better than has part(s) (P527) but not precise enough.
- The most precise description would be "the subject describes entities of this class". Until I find another property matching this definition, I'm not in favour of the deletion of P2353. PAC2 (talk) 22:02, 15 April 2024 (UTC)
Swedish Environmental Protection Agency Amenity OBJECTID (P8409): (delete | history | links | entity usage | logs | discussion)
As discussed in Property talk:P8409#Why keeping this property?, this property appears to be unusable. --Horcrux (talk) 14:45, 16 May 2024 (UTC)
- I have no intention of using this property at the moment, the data is valuable, but so far there has not been much interest from the community in neither https://www.wikidata.org/wiki/Wikidata:WikiProject_Campsites/Sweden nor https://www.wikidata.org/wiki/Wikidata:WikiProject_Svenska_Grillplatser from where the data could be linked using this and other properties.
- I updated the property with the new source for the data, part of which could be imported if anyone wanted to. So9q (talk) 06:17, 17 May 2024 (UTC)
Fossilworks taxon ID (P842): (delete | history | links | entity usage | logs | discussion)
The website has been down for a very long time and all its contents were moved to Paleobiology Database taxon ID (P10907): identifier for a fossil taxon in the Paleobiology Database. The IDs were kept the same across both databases, so a bot could theoretically just chance one for the other. —Trooper57 (talk) 17:23, 29 May 2024 (UTC)
- It does look like fossilworks is no more. It did go down for a while before (months?) and returned, but this seems terminal. The two sites ran in parallel for many years, supposedly using the same database with the fossilworks mirror updated daily (according to the fossilworks FAQS). The records were not exactly the same, with some occasional differences in the ecology and number of collections.
- For some reason the Paleobiology Database taxon ID (P10907) only has about 11,000 entries on Wikidata, whereas fossilworks has over 100k.
- The taxonbar on English Wikipedia still uses Fossilworks taxon ID (P842). When fossilworks went down we changed it to get the ID from Fossilworks taxon ID (P842) and then link it to PBDB. Obviously this workaround wouldn't be necessary if Paleobiology Database taxon ID (P10907) was fully populated. Jts1882 (talk) 13:57, 2 June 2024 (UTC)
Fossilworks reference ID (P7720): (delete | history | links | entity usage | logs | discussion)
Fossilworks (Q796451) has been dead for some time now; Fossilworks reference ID (P7720) has been superseded by Paleobiology database reference ID (P12793) and all the instances of its use copied across (they in fact matched 1:1); thank you, Maculosae tegmine lyncis (talk) 06:00, 7 June 2024 (UTC)
- Question Are we used to delete properties on the basis that they are instances of Wikidata property for a discontinued website (Q60457486) (currently we have 127 of such properties)? --Horcrux (talk) 10:42, 2 July 2024 (UTC)
iTunes genre (P10150): (delete | history | links | entity usage | logs | discussion)
Is there a compelling reason why we can't just use genre (P136) instead ? Trade (talk) 15:18, 23 May 2024 (UTC) (moved to this subpage from Wikidata:Properties for deletion) —Ameisenigel (talk) 15:25, 12 June 2024 (UTC)
- Löschen - genre (P136) with a reference linking to iTunes seems sufficient to say what the genre is according to iTunes. - Nikki (talk) 13:04, 21 August 2024 (UTC)
Charity Navigator ID (P4861): (delete | history | links | entity usage | logs | discussion)
The source no longer uses these identifiers, and no longer provides a way to access or search for entities by using this identifier. Some prior related discussion is at Property talk:P4861#New Scheme Daask (talk) 17:38, 18 June 2024 (UTC)
@Ringbang, Newt713, BrokenSegue, Problemsmith, Pintoch: Courtesy ping to editors who have worked on this item. Daask (talk) 17:45, 18 June 2024 (UTC)
- accessible via internet archive do not delete. https://web.archive.org/web/20221204131344/https://www.charitynavigator.org/index.cfm?ein=200049703&bay=search.results BrokenSegue (talk) 18:01, 18 June 2024 (UTC)
- Support No longer existing. There are currently ~110 entries that have an Charity Navigator ID (P4861) but no IRS Employer Identification Number (P1297) (-> Query). Perhaps we can work on that. I exported it. I also made sure, that all entries with Charity Navigator ID (P4861) are marked as a Nonprofit and have a value for country. --Newt713 (talk) 18:22, 18 June 2024 (UTC)
- Charity Navigator only rates large nonprofits that have been around for several years. It should be possible to get all of those charities' EINs from the charities, as one of the CN criteria is that the IRS form 990 is accessible from the charity's website, and the EIN will be in the 990. The Squirrel Conspiracy (talk) 06:52, 26 July 2024 (UTC)
(Moved from Wikidata:Properties for deletion —Ameisenigel (talk) 09:08, 19 June 2024 (UTC))
Facebook page ID (P4003): (delete | history | links | entity usage | logs | discussion)
Redundant to Facebook numeric ID (P11705). The page’s ID is actually only the number at the end. —MSMST1543 (talk) 15:54, 4 July 2024 (UTC)
TGbus ID (P10996): (delete | history | links | entity usage | logs | discussion)
Website is not available, response status codes 503 —Rainsday (talk) 06:36, 6 July 2024 (UTC)
- Notified participants of WikiProject Video games Rainsday (talk) 06:44, 6 July 2024 (UTC)
- Changed the formatter URL to Wayback Machine (Q648266). Matthias M. (talk) 10:53, 6 July 2024 (UTC)
- Keep Yeah, archived links will be fine here. By the way, it is not said that the site is completely dead, it may still appear online. This is what the error 503 "Service Temporarily Unavailable" says itself. Regards Kirilloparma (talk) 00:42, 7 July 2024 (UTC)
Objectif Gard topic ID (P6277): (delete | history | links | entity usage | logs | discussion)
Plus aucune page ne semble fonctionner. Elles ne semblent pas non plus accessible via une version archivée...
Notified participants of WikiProject France. Maxime 11:59, 26 August 2024 (UTC)
- Le site semble fonctionner normalement. -Ash Crow (talk) 13:00, 26 August 2024 (UTC)
- Bonjour, Ash Crow ! J'ai dû mal m'exprimer. Le site fonctionne en effet, mais les pages des mots-clés sont désormais vides (et donc inutiles, il me semble). Je pense que le système a été fichu en l'air lors de la refonte du site, il y a un an ou deux. Bel été, Maxime 13:52, 26 August 2024 (UTC)
- @Maxime Ravel: es-tu sûr ? chez moi (j'ai testé sur deux navigateurs : Firefox et Chrome au cas où) les pages ne sont pas vides et listent bien des articles en liens avec le mot-clef. Cdlt, VIGNERON (talk) 14:01, 26 August 2024 (UTC)
- Idem pour moi. Legonin (talk) 15:10, 26 August 2024 (UTC)
- @Maxime Ravel : les pages ne sont pas vides de mon côté non plus. Ce sont uniquement des mots clés pour référencer les articles, il n'y a pas de fiches explicatives associées pour ces entrées. — Baidax 💬 09:43, 4 September 2024 (UTC)
- Bonjour Baidax, c'est vrai ! Au temps pour moi, je m'étais fondé sur un certain nombre de pages qui ont effectivement été supprimées, mais j'ai omis d'effectuer une vérification plus large. Comment puis+je annuler ma proposition ? Bien à toi, Maxime 15:21, 6 September 2024 (UTC)
- @Maxime Ravel : les pages ne sont pas vides de mon côté non plus. Ce sont uniquement des mots clés pour référencer les articles, il n'y a pas de fiches explicatives associées pour ces entrées. — Baidax 💬 09:43, 4 September 2024 (UTC)
- Idem pour moi. Legonin (talk) 15:10, 26 August 2024 (UTC)
- @Maxime Ravel: es-tu sûr ? chez moi (j'ai testé sur deux navigateurs : Firefox et Chrome au cas où) les pages ne sont pas vides et listent bien des articles en liens avec le mot-clef. Cdlt, VIGNERON (talk) 14:01, 26 August 2024 (UTC)
- Bonjour, Ash Crow ! J'ai dû mal m'exprimer. Le site fonctionne en effet, mais les pages des mots-clés sont désormais vides (et donc inutiles, il me semble). Je pense que le système a été fichu en l'air lors de la refonte du site, il y a un an ou deux. Bel été, Maxime 13:52, 26 August 2024 (UTC)
Géopatronyme ID (P3370): (delete | history | links | entity usage | logs | discussion)
Website related to it seems to redirect and is no longer relevant to what the property was created for. —Akaibu (talk) 14:50, 31 August 2024 (UTC)