User talk:Magnus Manske

Previous discussion was archived at User talk:Magnus Manske/Archive 9 on 2024-01-01.

Hi - I've just been spending many hours dealing with another few hundred duplicate-authors actions; this tool is *really* not ready for prime time. Latest example: https://www.wikidata.org/w/index.php?title=Q4757048&diff=2133123022&oldid=2118661421 - how can you merge "Andrew G. White" and "Alex White"? There have been far too many similar merges like this that I've had to revert - and I'm concerned that somebody's going to go in again and re-merge them if the tool is recommending this. Also I'm finding many cases of incorrect merges where the issue is likely that the wrong person was assigned to a paper by the other author in Wikidata, so your tool thinks they're the same person because of that. I had a case yesterday where a political scientist with the same name as a biochemist was set as the author of some biochemistry papers, and your tool then was used to merge them. What actually would have been useful in a case like that was to point out that those biochem papers had been likely assigned to the wrong person as author. Can you adjust your tool to do that? In any case until some significant fixes are in place this needs to be turned off ASAP.

By the way part of the problem (including the political scientist one) is that ORCID sometimes has these bad author assignments - some of the data in ORCID comes from services like Scopus that can be mistaken on things like this.

Another common issue I'm seeing is two different authors with the same family name and same first initial co-authoring a paper. This often happens with husband-wife teams; also other family relationships can result in paper co-authoring, and even just being from the same region of the world area two individuals may be likely to share a surname. Your duplicate authors game will always try to merge these cases, because of course being co-authors on a paper means they are both co-authors with the other authors on that paper. Instead I think it should catch cases like this as a sign that they *are not* the same person. Having both wikidata id's as co-authors on the same work should be an indicator that they are distinct, not the same. I know there are exceptions where real duplicates exist, but at the least it should be handled differently from other cases where they are never co-authors.

Mix'n'match [1.0] inserts ISNI in spaced format, example: 2024-02-02 https://www.wikidata.org/w/index.php?title=Q124408545&oldid=2067027790

2024-02-14 behaviour persisting https://www.wikidata.org/w/index.php?title=Q124527901&oldid=2076914287

@Anvilaquarius: 2024-02-14 you created

1. https://www.wikidata.org/w/index.php?title=Q124536572&action=history
2. https://www.wikidata.org/w/index.php?title=Q124537285&action=history

Can you confirm that the spaced format of the ISNI, which causes constraint violations, came from mix-n-match?

Yes, it came from Mix-n-match. I try to correct them, but maybe I forget it sometimes. --Anvilaquarius (talk) 10:27, 20 February 2024 (UTC)

Thank you. @Magnus Manske: It would be helpful if you could fix the problem at the source, by removing the spaces in any P213 stored there.

I have cleaned up non-standard ISNIs in Mix'n'match, but I don't have a good mechanism to prevent them from being added for new entries

By new entries, do you mean new entries in Mix'n'match, created after the clean-up?

yes.

Left a note at Talk:Q28054658#ISNI format and linked that from Help:P213.

@Magnus Manske: https://www.wikidata.org/w/index.php?title=User:DeltaBot/fixClaims/maintenance/P213format&oldid=2085273963 14 items, each spaced ISNI from mix-n-match and inserted by Reinheitsgebot with the comment "Created a new Item: #quickstatements; details; invoked by mixnmatch:CreateNewItemsFromCatalogWithNoSearchResults from catalog 6218"; "details" links to https://editgroups.toolforge.org/b/CB/65d8e8ee10f12969781889/

2024-02-24 new item from mix-n-match containing spaced ISNI and non-spaced ISNI https://www.wikidata.org/w/index.php?title=Q124653772&oldid=2086098294

2024-03-01 new item from mix-n-match containing spaced ISNI and non-spaced ISNI https://www.wikidata.org/w/index.php?title=Q124708468&oldid=2090941453#P213 @Epìdosis, Bargioni: this is from a catalog from Italy, can you see what is actually store there? It seems to have been imported before "User:Magnus Manske: "I have cleaned up non-standard ISNIs in Mix'n'match".

ISNI is stored without spaces in identificativo SBN di un autore (P396). But as of now it seems that the catalogue of MnM has both the forms with and without spaces in the auxiliary data; the first should be removed.

@Magnus Manske: can you have a look why 2024-02-24 and 2024-03-01 new items created contained "spaced ISNI and non-spaced ISNI"?

Hi Magnus, in https://mix-n-match.toolforge.org/#/catalog/5076 the auxiliary data still contain identificativo ISNI (P213) both with and without spaces; the form with spaces should be removed to avoid format-constraint violations. Thanks in advance!

Hi, your bot imports nonsensical data about swimmers. Could you make it stop doing that (and ideally revert the wrong additions)?

Hello, I have imported mixnmatch:6299 and mixnmatch:6300 for Archnet site ID (P7323) and Archnet authority IDs (which don't have a property yet) using the import form. Both ended up having 0 IDs though the example entries in the preview looked fine. Do you have an idea what might have gone wrong? Thanks a lot in advance for any help or recommendations!

I manually ran an update, should be all there now.

Vielen tausend Dank!

Listeria bot is currently not working after working very well for a week. Thanks.

Listeria Bot is currently not updating since yesterday morning. Thanks.

Listeria Bot is currently not working, Thanks.

The bot is not working again. Thanks.

Sorry, that's me above.

The bot is currently not working. Thanks.

The bot is currently not working. Thanks.

LIsteria bot is not working again, since two days ago. Thanks,

Listeria bot is currently not working. Thanks.

https://www.wikidata.org/w/index.php?title=Q24951300&diff=1913323411&oldid=1542240767

Hallo Magnus, das Tools importiert weiterhin veraltete und fehlerhafte GNDs, selbst wenn diese bereits im Datenobjekt vermerkt sind. Beispiel: dein Editv vom 3. April. Ein nicht individualisierter Datensatz, der mit missbilligter Rang gekennzeichnet ist.

Ich glaube, ich habe das jetzt repariert. Kann es leider nicht an Deinem Beispiel ausprobieren, da hat wohl GND oder VIAF aufgeräumt?

Danke für die schnelle Rückmeldung. Die nicht individualisierten Datensätze (Tn) sind seit Juli 2020 nicht mehr Bestandteil der GND und wurden bei VIAF gelöscht. Laut Versionsgeschichte des VIAF-Clusters 296429616 wurde der Tn dort bereits 2017 gestrichen und damals vermutlich zu einem anderen Cluster verschoben. Mein Eindruck ist, dass sich das Tool an dem Datenobjekt orientiert, wo der Tn als GND mit missbilligter Rang eingetragen war. Aus der ungültigen GND wurde die neue (identische) GND abgeleitet. Das gleiche passiert mit ehemaligen GNDs, die als Weiterleitungen im PICA-Feld 007N vermerkt sind. Ein Beispiel zu Testzwecken: PICA-Feld 007N in GND 118541579 für Günter Grass: https://d-nb.info/gnd/1020430370. Quelle: OGND.

Hi Magnus - see Wikidata:Project chat#Problems with naive user merges with Distributed game: duplicate authors - this is becoming a serious problem, something needs to be fixed here.

thanks

Thanks!

Hi! Could you please implement paging or limit=500 on https://mix-n-match.toolforge.org/#/jobs ? The queue is now full of errors ( perhaps they should also be moved below TODO), and it was also stuck for a week until today. I added several autoscrape jobs during the week, and now it's impossible to find these catalogues.

Pagination added.

Hello,

I report Listeria bot is not working when trying to update this page:https://en.wikipedia.org/wiki/Wikipedia%3ADatabase_reports%2FRecent_deaths, despite not returning any error message.

I know, working on it

It briefly worked on the 15th, now not working again.

Thanks.

Hello,

The bot has not been working for almost three days.

Thanks again.

Working on it, might take a few days.

It has been working fine for two days, now it is not working again. Thanks.

The bot is not working today. Thanks.

Since 29 February, all entity labels in this list have disappeared and no longer appear after updates: https://www.wikidata.org/wiki/Wikidata:WikiProject_Movies/lists/Instance_of_film_genre

The bot is not working again. Thanks.

The bot is not working again. Thanks.