Wikidata:Properties for deletion/P7859

From Wikidata
Jump to navigation Jump to search

Property:P7859[edit]

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

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

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

Migration to P10832[edit]

enWikiQuote migration case[edit]

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

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

Removal of P7859 before consensus reached[edit]

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

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

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

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

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

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

Pre-migration data cleansing of P7859[edit]

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

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

Practical way of migrating to P10832[edit]

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

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

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

@@Epìdosis:: I thank you for looking at this in a practical way and I must apologise for the limited time I can put in on this. My focus is on "can-do" of population of accurate P10832 values rather than the removal of other values that are potentially of some us/partial use in P10832 population. I acknowledge that work entities are more problematic in general and that where P7859 yields not found there is a high chance of issues with other identifiers as well, your identification of case 1 Museo di storia naturale di Rosignano (Q20009745) indicating an issue at a bigger level that P7859 and probably ought to be dealt with holistically. Equally an lccn-xxxxx-xxxx with two dashes while leading to not found is in case 1 but can sometimes be resolved by converting the second hyphen to a zero. In terms of your case two example Marco Zanetti (Q21542865) that links to a personal VIAF id and id like to spend time looking at that in detail but I am concerned that case does not extrapolate to every case in that identified group and that in some cases retention might help resolve difficulties. In terms of your example of exemplified removals I take the case of Leonard Lansink (Q100312) where the P7839 entry indicates a WorldCat Entity Id. record might exist. Doing a [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)[reply]

New proposed plan for migration to P10832[edit]

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

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

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

I like this series of steps! I am attempting to compile lists of values with respect to the first three steps, although I don't know how fast I can make this compilation happen. Mahir256 (talk) 18:54, 16 March 2024 (UTC)[reply]
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)[reply]
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)[reply]

Identifiers containing "viaf-"[edit]

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)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/P7859&oldid=2140336501"