User talk:MisterSynergy

Babel user information
de-N Dieser Benutzer spricht Deutsch als Muttersprache. en-4 This user has near native speaker knowledge of English.
Users by language

This page uses the Structured Discussions extension of MediaWiki (SD, formerly known as “Flow”). I think that we really need something like this instead of the classical discussion approach, but I am also aware of the fact that not everything works smoothly yet in SD.

If you struggle to use this discussion page perfectly, do not worry and just leave a messy or broken comment for me. You do not need to figure out how to write a perfectly formatted comment with lots of trial-and-error edits. I am hopefully going to figure out what is on, otherwise I am going to ask you. Thanks!

Btw. SD comments do not need to be signed, since the software manages all contributions and puts user names and timestamps above them. Experienced users might also like the wikitext mode of SD, to be actived in the lower right corner of the input field.

Previous discussion was archived at User talk:MisterSynergy/Archive 1 on 2015-11-09.

Hello! I wanted to discuss the list generated by your bot, specifically the Wikidata:Database reports/Sitelink to redirect with unconnected target. First and foremost, thank you for your valuable work on this project! I have a query regarding certain items that appear on this list despite being deleted quite some time ago. Examples include Q109284827, Q21789694, Q21789728, Q20650307, Q21789732, Q19530760. As a developer myself, I'm curious to know if this issue is related to a cache problem, considering that these items were deleted back in 2022, which is a significant amount of time. I've been reviewing your code on GitHub, but I haven't been able to identify the reason behind this "failure". I apologize for my curiosity, and I hope you don't mind my inquiry. Wishing you a fantastic weekend!

Hey Laxeril, the relevant code is actually here. The reason why these long-deleted cases are in the results is that I am querying from a secondary data source, specifically from the page_props table of client wikis. Consider Q109284827 with redirect sitelink commons:Slums in Jakarta for instance (first result from the current list), which is listed with a redirect at Wikimedia Commons:

MariaDB [commonswiki_p]> SELECT page_id, page_namespace, page_title, page_is_redirect, pp_propname, pp_value FROM page JOIN page_props ON page_id=pp_page WHERE pp_propname='wikibase_item' AND pp_value='Q109284827';
+-----------+----------------+------------------+------------------+---------------+------------+
| page_id   | page_namespace | page_title       | page_is_redirect | pp_propname   | pp_value   |
+-----------+----------------+------------------+------------------+---------------+------------+
| 122452632 |              0 | Slums_in_Jakarta |                1 | wikibase_item | Q109284827 |
+-----------+----------------+------------------+------------------+---------------+------------+

This should not be there since the item Q109284827 has been deleted long time ago (October 2022), but the page_props table in client wikis is not always up to date. What helps in these cases is to touch (null-edit) the page on client wikis so that the page_props table is being refreshed.

The bot is actually supposed to do that, but for some reason it does not get to this point in some cases. This needs some investigation, probably at around this part of the source code: https://github.com/MisterSynergy/redirect_sitelink_badges/blob/10e25168b026a9f12d537a24f57e6c069c1a8dfa/main.py#L631. It's not a major issue, however, since there are only a few cases on the entire report (for all Wikimedia projects).

Okay, line 631 is not relevant for sitelinks to redirects with an unconnected sitelink target (as in these cases). The filter in line 624 prevents this (particularly the df['target_qid'].notna() condition).

In order to make the bot touch such pages on client wikis, I would need to add another check in the write_unconnected_redirect_target_report function where this report is being written. It does not really fit there logically, but it would be the most efficient place to perform this check (and to touch pages if necessary).

Thank you for clarifying. I now understand.

Hallo MisterSynergy, das Q1374463 ist mir auf RAT durchgerutscht. Daher habe ich den artikel erst jetzt in den ANR verschoben. Kannst du mir bitte ihn auch auf WD wiederherstellen. Danke K@rl (talk) 10:15, 17 May 2023 (UTC)

Klar, ist erledigt!

Sorry, ist aber doch noch ein Rotlink, oder versteh ich da etwas falsch? ;-) --lg K@rl (talk) 14:59, 18 May 2023 (UTC)

War von mir ein Gedankenfehler d:Q1374463 gibts eh wieder, danke K@rl (talk) 15:07, 18 May 2023 (UTC)

Hi, the page with this reference is getting linked to the pages Chucho in different languages, could it be avoided? Neither of them refer to that person (who seems to try to promote himself. I tried to undo the bots edits, but it replaced them. Thanks. :)

No, those sitelinks are correct. Recently some had tried to repurpose this item from "disambiguation page" to some human individual, which is not allowed. I have restored the correct version (from March this year). If someone needs an item for the human, a new one needs to be created in compliance with the Wikidata:Notability policy.

Oh, perfect. Thanks. I didn't notice the repurposing.

I was taking a preliminary look at the sources for Deltabot. It doesn't say how it is deployed. Do every script get its own Kubernetes pod or do they share a pod? Some of the scripts doesn't do a lot of error checking so they should at the very least provide some sort of traceback that can be inspected retroactively after a crash. If the scripts all run in the same pod, how are they spun up? I would be interested in helping instrumenting this bot if I knew more. I haven't looked into Toolforge yet.

Okay a couple of comments:

• DeltaBot and PLbot have both been created by User:Pasleim, and both have similar characteristics.
• Bot run on Toolforge (tool accounts deltabot and pltools).
• Since Pasleim pretty much inactive, I have volunteered last November to co-maintain his bots to troubleshoot problems. Most actions have been minor code fixes and job management until now, but there is indeed some need to optimize bot management in pretty much every aspect.
• There are roughly 50 Python scripts running under these two bot accounts with varying frequency (every 10 minutes to monthly). Both bots have a virtual environment with a couple of required modules. Both use pywikibot to edit.
• The code is old, up to ~8 years; Pasleim's style is to keep things simple, but this is not always that helpful if something goes wrong; there is some basic logging, but it is often not helpful to analyze a problem.
• There is a code repo for DeltaBot, but not for PLbot. However, I do not have write access (yet?), so the actual code for Deltabot on Toolforge is kinda different from the Github repo since I have to change code on the Toolforge console.
• Both bots run a couple of shell scripts in a Python3.9 container. Each shell script just runs a sequence of Python scripts; if a Python script crashes, it usually continues with the next one in the shell script. See https://k8s-status.toolforge.org/namespaces/tool-deltabot/ am https://k8s-status.toolforge.org/namespaces/tool-pltools/ for details regarding the job status.
• As much as I am aware, memory constraints on Toolforge are occasionally an issue.

I have very recently contacted Pasleim regarding the situation, in order to see whether and what he thinks about a modernization. I would be willing and able to fix many of the issues, in order to make these bots more robust and future-proof. However, Pasleim seems pretty busy and has not responded yet.

Thanks for the explanation, that clears things up a lot.

For starters you should edit the shell script started by the cronjobs so that every bot-task gets its stdout and stderr redirected to a separate logfile. e.g.:

/home/botuser/useful-bot >> /var/log/useful-bot.log 2>&1

the user account the script runs under needs to have write access to the folder where the logs are stored.

If something throws, the backtraces should now go into the logfiles.

Then you should set up logrotate, hopefully that's installed on the system. This will keep the harddrive from filling up.

https://linuxconfig.org/logrotate

If the system doesn't have logrotate, it can be emulated by using the day of the month as part of the filename.

Rotating the logs daily and keeping a months worth of logs makes it easier to see if something crashed.

Now that logging is set up, all that remains is keeping an eye on them to look for problems. Grepping the logs for the word "Traceback" is one way to do that.

Feel free to send me some tracebacks. I'll see if I can make a fix and send back, but no guarantees.

It is possible that due to the lack of error checking some of the scripts that assumes well-formed wikitext such as the ones that deal with the property proposals might be vulnerable to locking up or produce bad output if you give them bad input. If this happens it might be useful to manually log which wikipage and revision is being parsed to make it possible to recreate the condition that led to the issue.

Let's see if and when Pasleim responds. I have addressed related issues in the email, and I am waiting for his input. At this point I am not aware how much interest/time he still has in these bots, but I am reluctant to make significant setup changes without his approval. If he does not respond, changes will inevitable come at some point, but probably after some major failure. The status quo is not ideal, but it is not a drama either.

If he approves, there are several options and I am not 100% sure which way to go. For my own bot (~15 tasks), there are individual Github repos per task, each task has its own Python venv, and each one its own cronjob via k8s. Logging is done based on necessity, usually from within Python's logging module. However, all tasks in my own bot tool account use a central pywikibot configuration (which itself relies on Toolforge's shared pywikibot).

The reason Pasleim's bot's configuration has not been changed yet is that I have considered my co-maintainer role as a troubleshooter in case of complaints, not as a redesigner of this entire thing. I am just in the process to expand my involvement here…

I believe that you deleted the "shadowhunter" entity and definition that I created (Q115103335) by mistake, apparently because it is not "notable" enough. This is inconsistent with several Wikidata entries for the films. The films are notable, the noun is notable, and it belongs in Wikidata. Please, restore "shadowhunter".

This item needs external sources in order to have a clear definition. Can you provide such a source?

Sure. Sources are all the automatic options for "shadowhunter" that will autocomplete while typing. The definition itself was redacted by me, based on one of the official trailers. See "THE MORTAL INSTRUMENTS: CITY OF BONES - Official Trailer" by Sony Pictures Entertainment in Youtube. I cannot post the link because of an automatic spam filter.

This needs some sort of an external source. It is not obvious to others what this is about.

Technically, the item needs to comply with the notability policy at Wikidata:Notability.

This statement is incorrect: "This needs some sort of an external source." Only two of the three criteria in the notability policy need to be fulfilled. An entity can be added even if it has no external sources. Still, this one has external sources, like the trailer for example, which could be better referred if the link wasn't automatically blocked. A Google search for "shadowhunter" and the definition would have also provided relevant results. And Wikidata is meant to be co-curated. No one person needs to add everything. If someone adds a term, that is already a win, a term and a definition is a double win. Instead of deleting, better to leave the wiki spirit of co-curation and co-contribution to follow its course and others to add more data and links.

The term itself *is notable* as I explained above. It will definitely enhance the knowledge base, it refers to a clearly identifiable entity with plenty of public references, and will make statements in other items more useful. For example:

"Katherine McNamara as Clary Fairchild, a *shadowhunter* raised among mundanes (humans) who finds out her true heritage on her 18th birthday." https://en.wikipedia.org/wiki/Shadowhunters#Main

I hope that now it is clear that the term was correctly added and incorrectly deleted. I do not understand why the item was deleted before checking these things within Wikipedia first and why all the documentation burden to restore an item that was correctly added in the first place should fall upon me. If correctly adding just one term will take so much struggle, then I better give up.

I'm still not convinced, but at this point I think it would be the best to just give it a try.

Re. "And Wikidata is meant to be co-curated.": sure, but this is also a fallacy. Particularly content with notability issues and a lack of external resources are usually not being edited by anyone else. In the current condition, you are the only one to improve the item.

Hallo, ich habe gesehen, dass du eine größere Anzahl von Datenobjekten wiederhergestellt hast, die offenbar aufgrund ihrer Verwendung im SDC relevant sein sollen. Gibt es dazu neue Erkenntnisse? Selbst Mike Peel schien das im September anders zu sehen: Wikidata:Requests for deletions/Archive/2022/09/17#Q113542801 …

Hallo Emu, "neue Erkenntnisse" gibt es dazu nicht im Allgemeinen, aber für mich persönlich schon. Ich habe bisher Datenobjekte gelöscht, ohne die Nutzung über SDC zu prüfen – das ist einfach irre aufwändig nur über den WCQS-Service zu machen.

Jetzt habe ich mir die Zeit genommen und systematisch nachgeprüft, was ich da so gelöscht habe … und dann gleich mal 1138 von mir gelöschte Datenobjekte gefunden, die in SDC noch in Benutzung sind. Weil ich die selbst gelöscht habe, habe ich sie ohne Einzelfallprüfung wieder hergestellt, da ich hier "structural need" sehe und ich sie aus heutiger Sicht nicht hätte löschen sollen. Es ist korrekt, dass in einigen Fällen sicherlich der entsprechende Inhalt bei Commons löschwürdig ist und damit das Wikidata-Objekt ebenfalls, aber das wäre ggf. später zu prüfen. Die Situation bei Commons ist allerdings auch nicht so großartig, dass ich dort jetzt mit individuellen Löschanträgen aufräumen wollte.

Es gibt ungefähr noch einmal so viele Datenobjekte mit gleichem Zustand, die von anderen Administratoren gelöscht worden sind. Ich werde zeitnah dazu was auf dem Adminboard schreiben, weil ich das nicht ohne Diskussion einfach overrulen möchte. Die Sache ist wohl vor allem in jüngerer Zeit durch verstärkte SDC-Nutzung ein Thema geworden, und ich glaube viele haben das nicht wirklich auf dem Schirm.

Hm. Ich habe das schon auf dem Schirm und ich habe auch deine Erklärung zur Relevanz von Commons-Kategorien am Ende zähneknirschend akzeptiert, aber bei der Structured Data gibt es nicht einmal wirklich einen Ansatzpunkt in WD:N, weil sich #3 nur auf “statements made in other items” bezieht.

Bei aller Wertschätzung für die Kollegen auf Commons muss man sehen, dass es sich um ein letztlich um ein Sorgenprojekt handelt, das keinen letztlich funktionierenden Löschprozess kennt – ein Zustand, der ja auch vielerorts wortreich beklagt wird und, wenn ich @Marcus Cyron hier richtig verstanden habe, auch keine zeitnahe Besserung erwarten lässt. SDC gilt zudem nach meiner Wahrnehmung weithin als gescheitert (was mich nicht wundert, wenn man sich die Oberfläche von Commons anschaut).

Aber es ist sicher sinnvoll, das in einem größeren Forum zu diskutieren.

Och, es gibt schonen einen funktionierenden Löschprozess. Es dauert halt alles nicht selten recht lange, weil es zu viel Arbeit für zu wenige Leute ist. Wobei immerhin die Schnelllöschungen für die schlimmsten Sachen meist recht schnell vonstatten gehen. Commons funktioniert schon. Irgendwie. Niemand weiß so recht wie. Aber es geht schon. Dieses "schlurfen" ist aber nicht wirklich ein befriedigender Prozess.

Ich habe da wenig handfesten Einblick über den Zustand bei Commons, bloß ein bisschen oberflächliche Wahrnehmung. Demnach wird nominierter Content durchaus langsam, aber dann irgendwann doch abgearbeitet. Schwierig ist der Teil, der erst gar nicht nominiert wird und dauerhaft unter dem Radar fliegt. Soweit ich verstehe, ist das vor allem mit werbenden Inhalten ein Problem.

Bei Wikidata mit bloß ~60 Administratoren läuft es im Übrigen nicht anders – viele neue Datenobjekte bekommen überhaupt kein Relevanz-Review, selbst von IPs erstellter Content nicht. Die meisten Löschungen hier laufen ganz ohne Nominierung und Diskussion durch die Community ab; Admins suchen sich Fälle und löschen ohne Vorwarnung, wenn die Datenobjekte nicht den entscheidenen Richtlinien (im Wesentlichen Wikidata:Deletion policy und Wikidata:Notability) genügen. "Relevanz" ist hier demnach eine ziemlich technische Bewertung über den Ist-Zustandes von Datenobjekten.

Ich sehe *jede* (legitime) Nutzung in irgendeinem Wikimedia-Projekt erstmal als "structural need" an. Das steht nicht ganz so explizit in der Richtlinie, aber wird von vielen Administratoren so gehandhabt. Das gefällt mir auch nicht wirklich; ich halte es aber eben nicht für sinnvoll, tatsächlich genutzte Datenobjekte einfach wegzulöschen, oder in anderen Projekten entfernend inhaltlich einzugreifen weil der Inhalt hier bei Wikidata vermeintlich stört. Wenn ein Datenobjekt in einem Projekt legitim genutzt wird, dann ist das eben so und wir behalten das hier.

Nutzung/"structural need" im Zusammenhang mit Commons sehe ich ebenfalls sehr kritisch, und ich war mehrfach einer der lautesten Advokaten gegen eine automatische Relevanz für Datenobjekte zu Commons-Kategorien in verschiedenen Diskussionen hier in den letzten Jahren. Commons kommt mit dem Löschen fragwürdiger Inhalte einfach nicht hinterher; es ist außerdem im Metadaten-Bereich (Kategorisierungen) im Wesentlichen ein Riesenhaufen unbequellter Informationen, die viele gern einfach hier importieren möchten.

Ein weiteres Problem mit Commons im Speziellen ist die ebenfalls zentrale Sonderrolle von Commons. Ich habe dort schon Löschdiskussionen ablehnend beschieden gesehen mit dem Verweis auf ein Wikidata-Objekt welches Commons-Dateien nutzt (quasi auch "structural need", aber andersherum), obwohl wir hier entsprechenden Content auch löschen wollten und eigentlich auf die Löschung bei Commons gewartet haben. Es wäre sinnvoll, eine Art gemeinsames Lösch-Noticeboard für Wikidata und Commons zu haben, mit einem definierten Prozess zur Einigung ob in beiden Projekten nominierter Content gelöscht werden soll oder nicht. Das gibt es bisher aber leider nicht.

SDC ist IMO ein wichtiger Schritt zur Rettung von Commons. Soweit ich das sehe, haben ziemlich viele Dateien mittlerweile strukturierte Daten. Nach meiner Meinung sollten sie dort ihre Kategorien schnellstens weitgehend abschaffen und stattdessen ausschließlich auf SDC setzen. Es bräuchte aber wohl einiges an Optimierungen an der Benutzeroberfläche sowie der Suchfunktion in Commons betreffend SDC. Auch wird wohl in der Community einiges an Widerstand zu erwarten sein.

Soweit ich das sehe ist Structured Commons tot. Wie so oft hat die WMF nicht durch gehalten.

Was siehst Du denn, dass Du das so bewertest? Übersehe ich was?

Ich sehe, dass es nicht weiter geht - und das schon eine sehr lange Zeit. All die angekündigten Ideen passieren nicht. Bislang wurde nur der erste Schritt gegangen. In Anbetracht, dass man schon so lange daran sitzt und so viel Kohle hat und dennoch nichts passiert, kann man nur davon ausgehen, dass das Projekt tot ist. Was mir von Leuten mit mehr Ahnung auch in etwa so zurück gespiegelt wurde. Es passiert derzeit nichts.

Also ich hätte ja auch gern mehr Fortschritt in der Vergangenheit gesehen, sowohl auf Seiten der Foundation als auch der (Commons-)Community.

Soweit ich den Jahresplan der Foundation verstehe, schauen sie es sich nun aber mal genauer an – wenngleich da offenbar noch nicht so viel bei herausgekommen ist. Durch den Wechsel von CEO (und indirekt damit wohl auch CTO) ist bei der Foundation irgendwie eine Weile lang nichts passiert und die neuen Akteure arbeiten sich anscheinend noch ein. Soweit ich das verstehe, haben strukturierte Daten (bei Wikidata und Commons) beim neuen Management jedenfalls eine hohe Priorität.

Das wäre zu hoffen. Besser spät als nie.

Siehe auch

• User_talk:Karl_Gruber#Löschung_von_Objekt_mit_Regio-Wiki-AT-ID
• Wikidata:Report_a_technical_problem#Depicts_on_Commons_versus_What_links_here_at_Wikidata
• https://phabricator.wikimedia.org/T334352 Usage in SDC should be shown when deleting items on Wikidata
• de:Benutzer:M2k~dewiki/FAQ#Deletion_of_Wikidata_objects_and_effect_on_structured_data_on_Commons_(SDC)

I created the Turkish article “Demir Haç'a Toka Eklentisi", but I can't link this article to the Q1754284. Can you help me?

Already done by someone else: https://www.wikidata.org/w/index.php?title=Q1754284&diff=prev&oldid=1885004148

Hi {{ping|MisterSynergy}} I can fill this item with good data if you restore it. Regards, Antoine2711 (talk) 07:38, 30 April 2023 (UTC)

Done, Q64437943 is restored.

Hallo MisterSynergy, ich hatte eben wieder den Fall: ORCID vorhanden ↔ GND 1249863368 (mit ORCID-ID) fehlte: Q92328325#P496. Kannst du deinem großen Bot-Import noch einen kleinen folgen lassen, der die GNDs von Wissenschaftlern nachträgt?

Ja das sieht machbar aus. Ich bin zurzeit etwas knapp was meine Zeit für Wikidata angeht; deshalb sieh es mir bitte nach, dass ich keinen Termin dafür angeben kann ;-)

Kein Problem. Es eilt nicht. Danke für die schnelle Rückmeldung.

Kurze Nachfrage: das betrifft nur Personen, richtig?

Genau. Es betrifft nur Personen (Wissenschaftler des 20. und 21. Jhs.).

Müssen wir hier noch Abgleiche zur Sicherheit einfügen, oder können wir den Daten in der GND soweit trauen, dass die reine Präsenz einer ORCID-Kennung im GND-Datensatz ausreicht für einen Import? Eine entsprechende Fundstelle wird natürlich beigefügt, so dass der Import nachvollziehbar bleibt.

Das ganze geht doch recht einfach, weil ich im Grunde ähnliches wie zuvor mache und nur ein paar Zeilen Code ergänzen musste. Das Skript läuft noch, aber es hat schon durchaus was zum Importieren gefunden.

Ich gehe gerne einen Testsatz durch, aber die Zuordnungen müssten korrekt sein. Bislang habe ich nur eine Vermischung gefunden, bei der entsprechend auch die Titel von der beigemengten Person im DNB-Katalog verknüpft waren.

Ich habe nun fast 50.000 GND gefunden, die ich basierend auf diesem Abgleich importieren könnte. Vorher lege ich eine zufällige Stichprobe von ~50 Fällen vor, damit wir eine Fehlerrate abschätzen können. Das schaffe ich aber gerade nicht mehr.

50 per Zufall ausgewählte Fälle:

item	ORCID	GND (to import)
Ichiro Terashima (Q43119760)	0000-0001-7680-9867	1171011504
Corinde Elsenoor Wiers (Q56961447)	0000-0002-2934-8794	1053946872
Moritz Kronlage (Q88325055)	0000-0001-8648-9350	1027093531
Natalia Dudareva (Q50662406)	0000-0003-0777-7763	1053056036
Sarah A Schnitker (Q91651685)	0000-0002-2403-9765	1052441718
Thilo Witsch (Q96164263)	0000-0003-4003-1269	1185194290
Xiang Song (Q58151737)	0000-0003-0235-3734	134130014
Andreas Tittl (Q84856733)	0000-0003-3191-7164	1075296978
Siddhant Prakash Goyal (Q99604915)	0000-0001-6177-7057	1189932687
Sophia Terwiel (Q95840491)	0000-0002-0278-4609	1081690267
Tanja Groten (Q90106873)	0000-0003-3553-4056	11819187X
Jenny Mecking (Q100395632)	0000-0002-1834-1845	1271258978
Jana Baumgartner (Q104112001)	0000-0001-9231-6683	1057922080
Guy Fiti Sinclair (Q115003818)	0000-0002-5978-5143	1138289787
Yi Yu (Q59862666)	0000-0001-6104-3010	1256053961
Dominik Röhr (Q104288153)	0000-0002-9711-0809	122574945X
Simon Pollard (Q38804575)	0000-0001-8188-3324	138929238
Sven Wiessner (Q61886012)	0000-0003-0967-4557	138952671
Ana Mae Barbosa (Q11679823)	0000-0002-4966-2043	136284205
Clemens Kunz (Q57884953)	0000-0001-5820-2770	1216275548
Claudio O. Delang (Q67210619)	0000-0002-1360-6293	1228451370
Víctor M Hernández-Guzmán (Q86450561)	0000-0002-7016-2561	1268454168
Stephen Morley (Q56453105)	0000-0003-2972-7396	1151134058
Sergio Vilches (Q91802310)	0000-0001-6457-3084	1209072599
Gustavo Garcia (Q97426443)	0000-0002-1649-9251	1233743759
Efstathios Paparoditis (Q114655737)	0000-0003-1958-781X	170008711
Joep Sonnemans (Q59695942)	0000-0001-7545-7409	170887111
Daniel Villanova (Q92557765)	0000-0002-4746-3155	1204943621
Yangke Ding (Q91587235)	0000-0002-4072-8077	1241189900
Krzysztof Fleszar (Q92908913)	0000-0002-1129-3289	1174772131
Alexander Marx (Q91730405)	0000-0001-9722-2483	122478258
Barathi Viswanathan (Q89250197)	0000-0002-8857-7271	112885004
Chrystele Sanloup (Q57941836)	0000-0003-2412-6073	1177725479
Tino Hausotte (Q91727639)	0000-0002-2923-3217	1017738211
Andrew Meadows (Q57423104)	0000-0002-7334-9057	140127291
Charles Craddock (Q59149713)	0000-0001-5041-6678	1208708767
Xiaobing Luo (Q80844098)	0000-0002-6423-9868	1050546431
Brigitte Schlegelberger (Q91518407)	0000-0001-5256-1270	133666115
Corinna Hoose (Q58086510)	0000-0003-2827-5789	138655804
Matteo Valsecchi (Q88168812)	0000-0003-3242-2112	1137288000
Sabine L. Flitsch (Q41558895)	0000-0003-3974-646X	1261169166
Jovita Brüning (Q57103460)	0000-0002-9554-4179	1223488950
Florian Wendler (Q96272885)	0000-0001-7305-637X	1070537128
Kenneth G Huang (Q84678123)	0000-0002-4811-5638	138068917
Marinella Marmo (Q89736623)	0000-0003-2999-3280	1052242448
Maxim Bykov (Q54130443)	0000-0003-0248-1728	1163831999
Mirko Moser (Q61115300)	0000-0002-1936-984X	142617172
Thomas Pölzler (Q91473261)	0000-0002-4311-0897	1164083880
Marcus-Sebastian Martens (Q83111267)	0000-0003-1917-8493	138477000
Eldiiar Duulatov (Q64863344)	0000-0001-5978-2762	123273957X

Die ersten zehn Personen bin ich durch. Die Liste ist eine wahre Goldgrube. Da die ORCID-Forscher oft nur über die verlinkten Publikationen individualisiert sind, findet man erst über die GNDs die genaue Tätigkeit und in einigen Fällen auch das Geburtsjahr heraus. Die ORIC-IDs, wie übrigens auch die Wissenschaflter mit einer Mathematics Genealogy Project ID (P549), wurden offenbar weitgehend ohne Abgleich mit den bestehenden Datensätzen eingespielt. Nach dem Botlauf werden sich vermutlich etliche ORCID-Forscher als Dubletten herausstellen. Ich melde mich, wenn ich die restlichen Testsätze überprüft habe.

Unabhängig von der Liste: Kannst du Peter Wells (Q96052019) löschen? Ein ORCID-Import von LargeDatasetBot ohne verlinkte Aufsätze (4. Juni 2020). Bei ORCID 0000-0002-7261-4373 steht nur ein Name und "No public information available". VIAF hat 86 "Peter Wells" im Angebot. --~~~~

Erledigt, das Datenobjekt ist gelöscht.

Wie sieht es ansonsten mit der Liste aus? Müssen wir noch mehr abgleichen, oder ist die Fehlerrate so gering dass wir das so importieren können? Wie gesagt, es geht um fast 50.000 Datenobjekte. Viele Grüße!

Die ersten 30 Personen bin ich durch. Bei einer GND liegt eine Vermischung vor:

• Die ORCID-ID für Simon Pollard (Q38804575), Risikoanalyst, wurde fälschlich mit Simon Pollard (Q27440698#P227), Kinderbuchautor, vermischt.

Aber selbst in diesen Fällen ist es kein Fehler, wenn der Bot die GND importiert. Analog zu den Weiterleitungen oder Namenssätzen kann man die GND später als Vermischung markieren und auf WP:GND/F melden.

Außer der einen Vermischung sind alle 50 Testfälle unproblematisch. Ich habe bereits ein paar Daten ergänzt und Dubletten zusammengeführt. Imho kann der Botlauf starten.

Ich bin einmal mit ~1600 importierten GNDs angefangen, sie sind hier zu finden. Wenn in den nächsten Tagen keine ernsthaften Probleme auf den üblichen Wartungslisten auftauchen und Du auch sonst keine Problem dabei identifizierst, mache ich den Rest. Viele Grüße!

Hallo Kolja21, sind Dir zwischenzeitlich Probleme mit diesem Import aufgefallen? Falls nicht, dann würde ich zeitnah den großen Rest durchlaufen lassen. Viele Grüße!

Alles im grünen Bereich. Danke für deine Mühe!

So also:

• Der initiale Import ist nun abgeschlossen, dabei sind 47731 Aussagen entstanden. Die Abfrage steht drei Kommentare weiter oben, sie gilt weiterhin unverändert.
• Jetzt habe ich aber noch gut 1900 Fälle zurückgehalten: da geht es um zu importierende GND-Identifikatoren, die bereits in einem anderen Datenobjekt verwendet werden. Dem Augenschein sind dabei ziemlich viele Datenobjekt-Dubletten zu finden. Wie wollen wir dabei vorgehen? Ein Beispiel wäre: Thorsten Uthmeier (Q92976760), via ORCID 0000-0003-1265-061X wäre der GND-Identifikator 1013813901 zu importieren, aber der sitzt bereits in Thorsten Uthmeier (Q2429275).

Viele Grüße!

Kannst du die 1900 Fälle danach sortieren, wer die Datenobjekte erstellt hat? Die Importe von User:LargeDatasetBot, wie im Fall von Thorsten Uthmeier, könnte man mit said to be the same as (P460) verknüpfen, da es zu viele sind, um sie von Hand zu überprüfen. Im Grunde ist das die einfachste Lösung: Die Information geht nicht verloren, ohne dass man eine weitere Wartungsliste am Hals hat.

Bisher weiß ich nicht, wer ein Datenobjekt angelegt hat – aber es dürfte nicht zu kompliziert sein, das zu ermitteln.

Du bist eher an den Datenobjekten interessiert, die bisher keine GND haben, richtig?

"Du bist eher an den Datenobjekten interessiert, die bisher keine GND haben, richtig?" Ja, aber ich verstehe die Frage nicht ganz. Die Fälle betreffen doch nur Paare von Datenobjekten, bei denen eines bereits eine GND hat. Die meisten diese Paare kann man zusammenführen, aber per Bot ist das zu heikel. Daher wären wir mit said to be the same as (P460) auf der sicheren Seite.

Hier wurde ein Geburtsdatum aus der arabischen Wikipedia übernommen. Dass es grundfalsch ist, sollte klar sein, denn wie sollte jemand 1989 geboren sein, der Wirkungsdaten von 1940 und 1950 eingetragen hat. Auch 1889 kann nicht richtig sein, dann hätte er im zarten Alter von 68 Jahren noch Fußball gespielt.

Problem ist, dass der Artikel der arabischen Wikipedia vom User JarBot geschrieben wurde und zwar nur von dem. JarBot ist ein Bot, siehe Benutzerseite. *rumnörgel*

Ich glaub Du wolltest hier nörgeln: User talk:Lockal ;-)

Nee, ich sehe Wikidata immer mehr als Müllhalde, sorry für die harten Worte.

Nächstes Beispiel: Rudolf Hencl (Q2172918) Sterbedatum aus der italienischen Wikipedia übernommen. Dort wurde von einer IP in der Infobox aus dem Rudolf Hencl ein Lepold Hencl siehe it:Special:diff/124844234 Es gibt einen Leopold Henzl bei der angegebenen Seite eu-football.info https://eu-football.info/_player.php?id=8187

Nunja, Du machst es Dir etwas einfach wenn Du basierend auf Einzelfällen, die Du vor die Augen bekommst, hier generalisierst. Ich sehe nicht, dass sich in jüngerer Zeit etwas zum Schlechten verändert hätte.

Der Arbeitsmodus hier setzt eben stark auf Automatisierung. Vorteil ist, dass damit der anfallende Aufwand überhaupt erst zu leisten ist, und dass erratisches manuelles Editieren entfällt; Nachteil aber eben auch dass dabei Fehler entstehen. Insgesamt ist die Fehlerrate ziemlich niedrig, global gesehen.

Auch ist die Offenheit (i.e. IPs können Editieren) ein Kernmerkmal dieses Projektes, genau wie bei den Wikipedias. Daraus resultiert überhaupt erst langfristige Lebensfähigkeit, aber kurzfristig haben wir halt damit Ärger durch Vandalismus und schwierige Edits.

Deshalb arbeiten wir hier iterativ, mit starker Automatisierung wo möglich. Fehler ausbessern tun wir aber überwiegend manuell, und da sieht man halt auch den ganzen Mist (was geklappt hat, kriegt dagegen kaum jemand mit). Trotzdem ist es wichtig, den Verantwortlichen für den Fehler darauf aufmerksam zu machen, damit das im Zweifel nicht wieder passiert. Die meisten Benutzer haben da doch ein offenes Ohr.