Wikidata:Properties for deletion/P7859
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) or Library of Congress authority ID (P244), so it would be useful to see how they are handled in WorldCat Entities ID (P10832). We could mark the property as deprecated then compare WorldCat Identities ID (superseded) (P7859) and WorldCat Entities ID (P10832) periodically. From Hill To Shore (talk) 18:38, 24 March 2023 (UTC)
- 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)
- Delete 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)
- Comment Today (or yesterday) WorldCat Identities ceased to exist. Since all the "np" and "nc" IDs (4k here) are now resulting in "not found" pages, and their historical value and external use are both irrelevant, I'm going to remove them, if no objection is made. --Epìdosis 15:10, 27 March 2023 (UTC)
- 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)
- Comment: 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, Delete once a migration to P10832 have been set up. Per the use of VIAF or LC values in the construction of Identities IDs, I personnally see little point in storing them ad vitam now that the website is dead; on the authors I have worked on, I have never see Identities linked from others authorities files. However, I think that before taking any action we should have a bot run through the current P7859 and add P10832 when there is a redirection to it. Seeing the good workd Msynbot is doing, perhaps @MisterSynergy: could have a look at it? --Jahl de Vautban (talk) 07:06, 6 April 2023 (UTC)
- 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)
- Delete. Before deletion we need a bot to make sure that every item with a WorldCat Identities ID (superseded) (P7859) beginning 'viaf' or 'lccn' also has a corresponding VIAF ID (P214) or Library of Congress authority ID (P244). Normally I would prefer to keep old identifiers, especially if they redirect to new identifiers, but WorldCat Identities ID (superseded) (P7859) has a very high conflation rate. Of 488 values added to items on my watchlist, I deprecated 62 for conflation, which is 12.7%. Using redirects from WorldCat Identities ID (superseded) (P7859) to add WorldCat Entities ID (P10832) would result in many errors. I agree with Kolja24 that it would be better to find WorldCat Entities ID (P10832) using more reliable identifiers such as Library of Congress authority ID (P244).--DrGavinR (talk) 10:48, 6 April 2023 (UTC)
- 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)
- Delete, Worldcat Identities project is taken down.--Kadı Message 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)
- Delete, dubious quality, lack of sources. If derived from viaf or lccn use these instead. 77.191.135.37 03:08, 17 April 2023 (UTC)
- 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? Comment BTW: P7859 and P10832 should be displayed one below the other so that the comparison is easier. 2A02:2454:986D:F700:493E:E780:1887:62CE 03:38, 7 May 2023 (UTC)
- 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)
- Comment: May I be so bold as to venture that the evidence it overwhelming that P7859 is retained until P10832 is populated. There is then the question of what is using the P7859 value out of Wikidata? Is it only the authority control template or something else? While that debate may not be helpful a more productive approach might be to agree a roadmap on how P10832 is to be populated. There's bits of that spread throughout the above vote but it would be helpful to see an agreed way forward in one place. That is focus on getting P10832 populated rather than P7859 deleted. Thankyou. -- DeirgeDel tac 10:48, 1 June 2023 (UTC)
- Å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)
Migration to P10832
editenWikiQuote migration case
editAs 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. Done -- DeirgeDel tac 23:13, 30 May 2023 (UTC)
Removal of P7859 before consensus reached
editI 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
editI'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
editGiven 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 [1] 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
editNine 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-"
editIt 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
editI strongly object. Example:
ISNIplus (talk) 20:59, 15 May 2024 (UTC)
Stop the Twofivesixbot!
editYesterday 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
edit@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
edit@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
edit@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