User talk:Reinheitsgebot: Difference between revisions

From Wikidata
Jump to navigation Jump to search
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
Matthias.Wolf (talk | contribs)
1,695 edits
Line 697: Line 697:


https://www.wikidata.org/w/index.php?title=Q55988514&oldid=722054660 [[User:MrProperLawAndOrder|MrProperLawAndOrder]] ([[User talk:MrProperLawAndOrder|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 03:52, 12 June 2020 (UTC)
https://www.wikidata.org/w/index.php?title=Q55988514&oldid=722054660 [[User:MrProperLawAndOrder|MrProperLawAndOrder]] ([[User talk:MrProperLawAndOrder|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 03:52, 12 June 2020 (UTC)

== GND 4053219-7 not a human ==

https://www.wikidata.org/w/index.php?title=Q72940909&diff=next&oldid=1041621620 [[User:MrProperLawAndOrder|MrProperLawAndOrder]] ([[User talk:MrProperLawAndOrder|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 22:05, 16 June 2020 (UTC)

Revision as of 22:05, 16 June 2020

This is a bot run by Magnus Manske.

Sourcing

@Magnus Manske: Please stop mass-adding unreliable sources to statements that already have better ones. Nikkimaria (talk) 14:35, 9 January 2018 (UTC)[reply]

Please be more specific, and please talk to me on my talk page. --Magnus Manske (talk) 15:20, 9 January 2018 (UTC)[reply]
@Magnus Manske: I'm referring to the contributions of this bot, which should be stopped. Nikkimaria (talk) 15:42, 9 January 2018 (UTC)[reply]
Apologies, I must have been unclear. When I say on my talk page, I mean on my talk page. And when I say "more specific", I don't mean "state the obvious". This bot does several things. --Magnus Manske (talk) 15:46, 9 January 2018 (UTC)[reply]
This bot's last several hundred contributions have all been edits like this one. Nikkimaria (talk) 15:57, 9 January 2018 (UTC)[reply]
OK, I'll be friendly, even though you ignored my request. I see the edit. May I take it that your issue with it is the use of Find-a-grave as a source? Find a Grave (Q63056) does not have a talk page, and Property talk:P535 does not say anything about it not to be used as a reference. For the example you gave, the entry does have the birth date that that it was used as a reference for. It even has a picture of the grave (albeit only with the birth and death years, not days). So, what exactly is the issue? --Magnus Manske (talk) 16:09, 9 January 2018 (UTC)[reply]
The statement is already reliably sourced; there is no value in adding an unreliable source. Nikkimaria (talk) 16:15, 9 January 2018 (UTC)[reply]
Please don't lie, or at least, be less blatant about it. The statement you linked to has, as its other source, "imported from English Wikipedia". That does not qualify as an actual source, it is merely a tracker to see when it was copied from. It had no source; now it has one. And you still have not established that Find-a-grave should not be used as a reference. --Magnus Manske (talk) 16:23, 9 January 2018 (UTC)[reply]
You are correct that I was mistaken about that particular diff - most but not all of the bot's additions are in cases where there are already sources. So I will use the bot's edits as a tracker for statements requiring reliable referencing, and I would ask that you consider limiting the bot's edits to cases where there are not already multiple reliable references provided. Nikkimaria (talk) 17:03, 9 January 2018 (UTC)[reply]
...which apparently won't work because the bot will just repeat its edits, so please also limit the bot to only doing one pass per item. Nikkimaria (talk) 19:12, 9 January 2018 (UTC)[reply]

Nikkimaria, to bring this to a close:

  • you have failed to show that Findagrave is a "low quality source" that should not be used
  • you have also failed to show that at the RfC
  • you have even failed to show a single example for your claim where an additional Findagrave reference makes things worse somehow

I know what you want, you keep repeating it ad nauseam. But stomping your foot and saying "But I wanna!" is not constructive. --Magnus Manske (talk) 14:27, 10 January 2018 (UTC)[reply]

@Magnus Manske: Will you at least ensure that your bot does not repeat edits? Given that we will need to agree to disagree on the other points, this would allow for a productive route forward. Nikkimaria (talk) 16:17, 10 January 2018 (UTC)[reply]
For other contributors to be able to review, it's preferable that you report bot errors here rather than delete any statemements.
--- Jura 17:09, 10 January 2018 (UTC)[reply]
Don't expect so, no. However, I recognize that my feelings about the issues at play here led to me not expressing myself as well as I might have done, and I will apologize to Magnus for that and for any offense I have caused him as a result of that. I felt a quick intervention was needed, and as a result was more brusque in my approach than warranted. I will reiterate that I believe he is acting in good faith, although I disagree with the approach taken by the bot. Nikkimaria (talk) 03:56, 11 January 2018 (UTC)[reply]
Then let's agree to disagree. I have no special attachment to Findagrave, but I fail to see the harm, and I do see the benefit. Could you point me to an instance where the same edit was repeated? That should not have happened, and an example will help to diagnose a potential issue. --Magnus Manske (talk) 09:30, 11 January 2018 (UTC)[reply]
[1]. Nikkimaria (talk) 13:35, 11 January 2018 (UTC)[reply]
I believe I found the issue. It should be fixed for future edits (as in, the bot will remember doing the edit), but it doesn't remember some previous ones, and it's hard to find them (as in, adding a specific source to a specific statement, where the source has been removed now) in the Wikidata item history. So, it might add it again in some instances, but no more than once. --Magnus Manske (talk) 13:53, 11 January 2018 (UTC)[reply]
Thanks, appreciate that. Nikkimaria (talk) 15:00, 11 January 2018 (UTC)[reply]

Clearly false edit

Hi Magnus. This edit [2] was clearly wrong. At this point, English Wikipedia did not list the guy as dead, and he only died a week ago. Could you please have a look and see what happened. If this is a major problem, may be many edits around the time must be reverted.--Ymblanter (talk) 08:29, 16 January 2018 (UTC)[reply]

I do not recall what, exactly, the bot did four years ago. It was most likely some one-off code. --Magnus Manske (talk) 08:37, 16 January 2018 (UTC)[reply]
Persondata had DATE OF DEATH = 27 august 2011.
--- Jura 08:39, 16 January 2018 (UTC)[reply]
I see, than this must be on the Wikipedia side.--Ymblanter (talk) 09:05, 16 January 2018 (UTC)[reply]

Duplicates

Hi Magnus, I'm writing you regarding a Wikidata entry for Samuel Blatchley Webb created by your hard working bot way back in March 2015, i.e., Q19423927. Actually, the person described there is Samuel Blatchley Webb's son, James Watson Webb who has his Wikidata entry at Q3161477. Also, the correct Wikidata entry for Samuel Blatchley Webb is Q48257893. Additionally, please note that The Appletons' Cyclopædia of American Biography does not have a separate entry for James Watson Webb, only for his father: [3]. However, James described quite vividly there: [4], which probably confused your bot. Best regards to both, --Taterian (talk) 07:23, 15 February 2018 (UTC) P.S. ✓ Done --Taterian (talk) 07:21, 20 February 2018 (UTC)[reply]

Revert

Hi, FYI I have reverted your bot: [5]. — Ayack (talk) 12:43, 19 February 2018 (UTC)[reply]

Corporate authors from OCLC_Authors are not human!

Hi - you created this entry and several others like it from the Mix n Match OCLC_Authors list, but these are corporate "authors", not humans. KRbot seems to be able to tell that the VIAF entry is corporate and not human, so you might want to check that before doing more like this (if these are still happening). ArthurPSmith (talk) 21:18, 26 February 2018 (UTC)[reply]

Year parsing

Deleted this.
--- Jura 13:36, 5 March 2018 (UTC)[reply]

Repeated bad edits

Magnus, look at the history of

Reinheitsgebot adds statements like Commons category (P373)}} XXXXX HIER FEHLT ALLES!-->, volunteers remove them, and bots add them over and over again. How do we break the cycle? --Jarekt (talk) 16:03, 21 March 2018 (UTC)[reply]

@Jarekt: Probably by blocking the bot? Nothing else seems to help. —Tacsipacsi (talk) 19:16, 25 March 2018 (UTC)[reply]
I have turned off that function of the bot. @Jarekt:: See here. --Magnus Manske (talk) 09:11, 26 March 2018 (UTC)[reply]
Thank you Magnus, and no blame. I know how much time I spend in Wikiverse on the few things I am involved in and you seem involved in much more tool development and maintenance. But there should be some mechanism for you to be able to pass some of the tasks to others. Maybe WMF should get you an intern assistant, whose job would be to monitor communication channels and run daily chores. --Jarekt (talk) 12:04, 26 March 2018 (UTC)[reply]
Thanks! If you would link to the wiki page from where the bot works (it’s obvious from the erroneous data that the source is some wikitext), we could probably fix it – or just remove the bad entries –, and backing everything with sources is an important goal on Wikidata (although Commons links don’t require sources most of the time). Anyways, thanks for your many tools! —Tacsipacsi (talk) 22:31, 26 March 2018 (UTC)[reply]

THANK YOU <3

Thank you very very much for your action via LfDS object ID (P1708). That is much structured fun for many people :) . Regards, Conny (talk) 15:12, 30 April 2018 (UTC).[reply]

My pleasure! Don't forget to check for images! :-) --Magnus Manske (talk) 20:55, 30 April 2018 (UTC)[reply]

Peter Marcus vs. Philipp Otto Runge

Hallo Magnus, hier scheint was schiefgelaufen zu sein: Peter Marcus (Q52150818) mit den Normdaten von Philipp Otto Runge (Q52150818). Kannst du mal drüberschauen? Gruß --Kolja21 (talk) 00:34, 14 May 2018 (UTC)[reply]

Habe mal aufgeräumt, aber da scheint es ein Problem in VIAF zu geben :-( --Magnus Manske (talk) 07:30, 14 May 2018 (UTC)[reply]
Danke für die schnelle Rückmeldung. VIAF vermischt häufig Personen, aber in dem betreffenden Datensatz scheint alles in Ordnung zu sein. "Runge, Philipp Otto, 1777-1810" enhält alle drei Suchbegriffe: PETER, MARCUS und 1889.
Person als Relation: Betthausen, Peter‏ ‎‡d 1941-...
Person als Relation: Behmer, Marcus‏ ‎‡d 1879-1958
Person als Relation: Marcks, Gerhard‏ ‎‡d 1889-1981
Fröhliches Schaffen --Kolja21 (talk) 23:02, 14 May 2018 (UTC)[reply]
Argh, danke. Habe das VIAF-Suche-Automatching mal rausgenommen... --Magnus Manske (talk) 08:51, 15 May 2018 (UTC)[reply]

Dublette

Der neue Eintrag Jean Baptiste Boisduval (Q52148297) scheint eine Dublette von Jean Baptiste Boisduval (Q722712) zu sein. --Kolja21 (talk) 00:38, 14 May 2018 (UTC)[reply]

Danke, merged. Der Bot-Run hat neue Einträge basierend auf Namen und Geburts-/Todesjahr (mit mehreren Mix'n'match-Quellen) angelegt. Wegen unterschiedlichen Geburtsjahren hat er den existierenden Eintrag nicht gefunden. Das ist durchaus so geplant; ein paar gut referenzierte Dubletten können meist gut gefunden werden (z.B. VIAF-Duplikation), und ich finde, Datum-"Streitigkeiten" sollten durchaus dokumentiert werden. Die meisten neuen Einträge sollten aber "unique" sein. --Magnus Manske (talk) 07:24, 14 May 2018 (UTC)[reply]
Das klingt einleuchtend. Herauszufinden, ob Edward Fisher (Q5342908), "Irish mezzotint engraver" und Edward Fisher (Q53045850), "artist born on 1722 at ? and deceased on 1785 in ?" wirklich die gleiche Person sind, ist aber trotz identischer Normdaten gar nicht so leicht. Apropo Normdaten: Alleine bei der GND liegen mittlerweile über 3.000 "Single value" violations vor. Ich habe keine Ahnung, wie die Wartung langfristig bewältigt werden soll. Gruß --Kolja21 (talk) 23:52, 14 May 2018 (UTC)[reply]
Ich hab' mal was gebaut, das die GND-Redirects entfernt. Kann ich täglich laufen lassen. --Magnus Manske (talk) 08:40, 15 May 2018 (UTC)[reply]
Super: Mit einem Botlauf 437 Fälle erledigt. Danke! --Kolja21 (talk) 12:44, 15 May 2018 (UTC)[reply]
Very bad if redirects are deleted! That will break incoming links via the property value. 2.247.26.14 16:35, 16 June 2018 (UTC)[reply]

Ty Unwin

Im VIAF-Eintrag 288051 kann ich das Geburtsdatum nicht finden. Woher kommen die Daten? --Färber (talk) 12:03, 25 May 2018 (UTC)[reply]

Aus den RDF-Daten. Keine Ahnung, warum die nicht im normalen interface auftauchen. --Magnus Manske (talk) 12:32, 25 May 2018 (UTC)[reply]

Nadia Magnenat Thalmann

Hallo. Geht um dies. Es gibt auch andere Quellen mit einem anderen Jahrgang: Auteurs (form. 1982) Née 1942. Canadienne. Was tun? Danke --KurtR (talk) 15:33, 25 May 2018 (UTC)[reply]

False edits

Hi. This bot makes recent repeated false edits like this one, this or also this one. The source doesn't indicate any of these informations, which are aberrants (an anonymous master can't have a birth and death date, only a period of activity). I revert some of them but I don't know if there's other ones. Thanks. Mel22 (talk) 18:50, 25 May 2018 (UTC)[reply]

same here and here (reverted) Eru (talk) 20:23, 25 May 2018 (UTC)[reply]
I just checked the marc21 on viaf, there is a date with 1950, but it's say "flourished", what ever it's mean
<mx:datafield tag="997" ind1=" " ind2=" "> <mx:subfield code="a">1950</mx:subfield> <mx:subfield code="b">0</mx:subfield> <mx:subfield code="c">flourished</mx:subfield> </mx:datafield> Eru (talk) 21:12, 25 May 2018 (UTC)[reply]

What are you doing? —Tom.Reding (talk) 01:49, 26 May 2018 (UTC)[reply]

Bonjour, j'ajoute ma plainte aux plaintes précédentes. C'est une catastrophe : les ajouts sont tous identiques (année de naissance 1950), complètement fantaisistes et sourcés par une source imaginaire du VIAF !!! --Pierrette13 (talk) 06:13, 26 May 2018 (UTC)[reply]

Bonjour. Ah, je vois que je ne suis pas le seul à être interloqué par ces naissances en 1950. Par exemple sur Cécile Prieur (que j'ai annulé) et Stephen Schultz, sourcés de manière tout aussi imaginaire sur le VIAF. Je suis surpris que depuis mai il n'y ait pas eu d'annulation en bloc de ces modifs. Cordialement, Xavier 90.40.187.195 15:59, 19 December 2018 (UTC)[reply]

Your bot incorrectly read birth and death dates from VIAF. Please check to see what VIAF records actually say, and modify your bot's script accordingly. It must be able to recognize dates that are approximate (circa) and import them accordingly, and should also identify which records on VIAF were used when VIAF import records vary. --EncycloPetey (talk) 14:05, 26 May 2018 (UTC)[reply]

Your bot also added birth and death dates to Dhanañjaya (Q51137951), but this time VIAF did not have those dates. Your bot invented its own dates. --EncycloPetey (talk) 14:10, 26 May 2018 (UTC)[reply]

@Magnus Manske:, if you don't automatically get notifications whenever this page is updated. Mahir256 (talk) 20:54, 26 May 2018 (UTC)[reply]
@Mahir256, Magnus Manske, EncycloPetey, User:Pierrette13: in fact, I see this date very clearly in xml format of the viaf record https://viaf.org/viaf/263357483/viaf.xml for example, except, it's not a year date, it's a century date : probably a wrong reading of the date encoding (like when 20th century is displayed 2000-01-01 on wd).
That VIAF XML record says <ns1:dateType>flourished</ns1:dateType> so should not be used as a lifespan (but could possibly be used for the floruit (P1317) property). --Canley (talk) 23:53, 27 May 2018 (UTC)[reply]
please Magnus, could you re-check the encoding of dates on viaf. Many century dates replaced by a date in x50... which is quite wrong :/ --Hsarrazin (talk) 18:21, 27 May 2018 (UTC)[reply]

Invaluable dates

Please can you stop adding birth/death dates from M'n'M catalogue 1056 - it seems they are not always correct. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:42, 27 May 2018 (UTC)[reply]

Nr. 1264 as well https://www.wikidata.org/w/index.php?title=Q325097&type=revision&diff=688317704&oldid=688306557 --Masegand (talk) 13:07, 1 June 2018 (UTC)[reply]

Wrong year of birth and year of death

Hi,

I would like to inform you that, almost all of your edits from Cheng Zhiyun (Q45643012) 17:13, 16 December 2017‎ to Liu Tingchen (Q45666339) 18:35, 17 December 2017 are wrong. The years of birth and years of death do not match the China Biographical Database.--QBear (talk) 08:48, 12 June 2018 (UTC)[reply]

2018-01-08 P31 human

Don't know the source and if it is fixed. Not human: https://www.wikidata.org/w/index.php?title=Q47115982&type=revision&diff=617757960&oldid=617757919 2.247.48.113 15:37, 26 June 2018 (UTC)[reply]

Nehemiah

https://www.wikidata.org/w/index.php?title=Q1025598&type=revision&diff=684872428&oldid=677176314

Reporting some erroneous edits. Cheers, Bovlb (talk) 17:49, 27 June 2018 (UTC)[reply]

Import von Platzhaltern

Hi Magnus, danke für den Import aus kaiserhof.geschichte.lmu.de. Nur eine Bitte: Kannst du den Bot so einstellen, dass er die Tns (= Platzhalter) nicht als Dubletten importiert? Beispiel: Johann Rudolf Sprinzenstein (Q55238177) mit gültiger GND (Tp = Person) 139320393 und dem Platzhalter (Tn = Name = BKL in Wikipedia): 102979030. Gruß --Kolja21 (talk) 02:03, 10 July 2018 (UTC)[reply]

Ich werde mein Bestes tun, aber leider sieht man das der ID ja nicht an... --Magnus Manske (talk) 08:18, 10 July 2018 (UTC)[reply]
Danke für die Rückmeldung. Es gibt leider in der Tat keinen getrennten Nummernblock für Platzhalter, aber die Wartungslisten in deWP (User:Wurgl kennt sich mit den technischen Details aus) kriegen das hin. Gruß --Kolja21 (talk) 01:54, 11 July 2018 (UTC)[reply]
Moin!
Möglichkeiten der Prüfung auf nicht individualisierten Datensatz (Tn):
  • Du gehst auf die Webseite https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=nid%3D<hier Tn einfügen> und suchst nach der Zeichenfolge <strong>Name</strong> Bei gefunden --> ist ein Tn, wenn nicht gefunden --> ist ein individualisierter Datensatz (Person oder Körperschaft oder Sachbegriff oder Geographikum oder Veranstaltung). Ob eine GND-Id (egal welcher Subtyp) überhaupt gültig ist, kannst du mit einem HEAD-Request auf http://d-nb.info/gnd/<hier Tn einfügen>/about/html feststellen. Bei Status 404 ungültig/nicht existent, sonst via Status 302 eine Umleitung auf eine URL wie oben.
  • Du lädst dir von https://data.dnb.de/opendata/ die Datei Tngesamt1806gnd.<Endung> und suchst die Id. Wie der Name schon sagt, sind in der Datei nur diese nicht-individualisierten Ids drinnen. Allerdings gibt das ein kleines Problem: Eine Tn kann individualisiert werden und zu einer Tp werden (ich hatte gestern zwei solche Fälle) und diese Dump-Files werden 3 mal im Jahr (Februar, Juni und Oktober) neu erzeugt. Bei ganz frisch angelegten oder bei solchen die gerade erst dieses "Upgrade" von Tn nach Tp erfuhren, läuft die Prüfung falsch.
Ach ja, der User-Agent bei einem HTTP-Zugriff sollte etwas darstellen, das von der Webseite als Browser identifiziert werden kann. Wenn du als User-Agent sowas wie "Super-Duper-Bot (siehe https://www.wikidata.org/wiki/User:Reinheitsgebot)" hast, dann mag dich die Webseite nicht gar so sehr und murmelt oft was in der Art "Session ist abgelaufen". Ich hab rotzfrech den User-Agent meines Browsers reingemacht und gut war es.
Hoffe das hilft. --Wurgl (talk) 05:27, 11 July 2018 (UTC)[reply]

Duplicates from pseudonyms

At Wikidata:Database_reports/identical_birth_and_death_dates/1, items like Q55685004 duplicating Q1000323 show up. Maybe there is a way to match them with the real name before upload.
--- Jura 07:58, 28 July 2018 (UTC)[reply]

They are checked against external IDs (VIAF and GND, for Heinrich Wilhelm Lawätz (Q55685004)), and against Wikidata search, before creation. That is, if any item comes up in the name search, or already has one of the external IDs, it is not created. Not sure what else I can do. Also, not sure what a "real name" is, in this context. --Magnus Manske (talk) 08:11, 1 August 2018 (UTC)[reply]
Die Frage in diesem Fall ist: Soll das Objekt für das Pseudonym erhalten bleiben? ("real name" = Heinrich Wilhelm Lawätz (Q1000323) = GND 123529751.) Auch die GND hat in diesem Fall ja bewusst zwei Datensätze. BTW: Nur aus Neugierde: Wie wählst du aus den über 4 Millionen Tps die Personen aus, für die du Objekte anlegst? --Kolja21 (talk) 11:19, 1 August 2018 (UTC)[reply]
  • Viaf mentions the other name (sourced from GND, I think). If items for pseudonyms are created, they shouldn't have "P31=Q5", but "P31=pseudonym (Q61002)".
    Given that the items are quite complete, I think merging them is fairly straightforward. So the occasional duplicate isn't much of an issue. I would be more worried if the duplicates were nearly empty and almost identical to existing ones.
    --- Jura 11:25, 1 August 2018 (UTC)[reply]

Deutsche Biographie descriptions

Any reason why clearly German descriptions for the Deutsche Biographie entries your bot is creating are ending up as English descriptions here? Mahir256 (talk) 20:37, 31 July 2018 (UTC)[reply]

Wrong setting, changed now. --Magnus Manske (talk) 08:07, 1 August 2018 (UTC)[reply]

Sigismund Päminger

Hallo Magnus, bei Sigismund Päminger (Q55875077) nimmt dein Bot an, dass der "Komponist protestant. Motetten (1495-1567)" mit dem "Beitr. im VD-16" identisch ist. Ich würde die beiden eher getrennt lassen, da der VD-16 Päminger unter anderem Leichenpredigten verfasst hat, also nicht zwangsläufig mit dem Komponist identisch ist. --Kolja21 (talk) 21:42, 3 August 2018 (UTC)[reply]

Q1010102

Der revert meines Eintrags in Q1010102 ist fachlich nicht richtig.

Bunyaviridae wurden 2016 nach Peribunyaviridae umbenannt.

Phenuiviridae sind eine neue Virusfamilie seit 2016.

--Murma174 (talk) 11:02, 5 August 2018 (UTC)[reply]

P.S. Auch der Eintrag von enwiki in Q1010102 ist nicht richtig. --Murma174 (talk) 17:10, 7 August 2018 (UTC)[reply]

@Magnus Manske: Ping. Tommy Kronkvist (talk), 17:35, 7 August 2018 (UTC).[reply]

2030er

Guten Tag Reinheitsgebot, Du hast zu de:2030er hier einen neuen Datensatz angelegt, obwohl es dazu bereits einen gegeben hat, der mit 60 Spraxhversionen verknüpft ist. Ich habe jetzt einen Löschantrag gestellt. Es wäre also leicht möglich gewesen, die Existenz festzustellen. Bitte prüfe in Zukunft, ob es nicht bereits entsprechende Einträge gibt. —Lantus 06:48, 26 August 2018 (UTC)[reply]

Adding reference(s) from Wikipedia

Hello Magnus Manske Bot, adding reference from Wikipedia in any language is not valid. Wikipedia whatever the language cannot be used as a source/reference. Please prefer VIAF et al. Thanks. Cheers! DDupard (talk) 17:42, 19 September 2018 (UTC)[reply]

References to Wikipedia have been used here as a way to keep track of the source of information, in the hopes that this can be replaced by humans with a proper reference at some point. Do you have a specific example? --Magnus Manske (talk) 21:26, 19 September 2018 (UTC)[reply]

#quickstatements; invoked by Mix'n'match:References https://tools.wmflabs.org/mix-n-match/?#/catalog/17

https://www.wikidata.org/w/index.php?title=Q1909462&type=revision&diff=751744191&oldid=737846896 Something just went wrong with about 24 musicians declared dead / P569=P570 from beic.it https://tools.wmflabs.org/mix-n-match/?#/catalog/17 --Masegand (talk) 14:39, 24 September 2018 (UTC) it is still continuing https://www.wikidata.org/w/index.php?title=Q2272644&diff=prev&oldid=751775457.--Masegand (talk) 15:49, 24 September 2018 (UTC)[reply]

Bot's mistakes

[6], [7] and many like that. Elfhelm (talk) 15:29, 24 September 2018 (UTC)[reply]

Judi Dench (Q28054)

Hi,

Are you sure ? I think there's a problem, the person is alive and the source does not correspond.

There are many others, I didn't check them all.

Best regards --Do not follow (talk) 20:48, 25 September 2018 (UTC)[reply]

Some more errors

  • Bernard Haitink Q158370 [8]
  • Cleo Laine Q291309 [9]

Both had their year of births added as a death date, and both still breathing AFAIK. These just happen to be some people I watch, I have not checked but I suspect likely to be others. Periglio (talk) 15:18, 26 September 2018 (UTC)[reply]

Filmportal-Darsteller

Habe eben Frieder Rometsch (Q55683036) gesehen, könntest du das auch mit allen Personen in [10] machen, die nur "Darsteller"/"Darstellerin" (+ ggf. Lebensdaten) und keine Suchergebnisse haben? Queryzo (talk) 20:38, 21 October 2018 (UTC)[reply]

BTW: Filmportal.de hat vor einigen Jahren alle biographischen Datensätze in die GND eingespielt. Trotzdem finden sich immer wieder Fälle, in denen keine GND vergeben wurde. Es wäre interessant zu wissen, welche Personen das sind, dann können wir von Hand nachbessern. --Kolja21 (talk) 16:20, 22 October 2018 (UTC)[reply]

Jean-Louis Besson (Q3166634)

Hi,

Jean-Louis Besson (Q3166634) is a French association football player. Margaret Jean Adair Besson isn't the same person, she is Jamaican anthropologist.

Best regards. --34 super héros (talk) 18:21, 3 November 2018 (UTC)[reply]

Klaus Groth

Hallo Reinheitsgebot, du hattest bei Klaus Groth Q76494 Geokoordinaten und Adresse hinzugefügt, das ist ungewöhnlich und wohl auch eigentlich nicht gewollt. Sollte das vielleicht für das Klaus-Groth-Museum Q1744763 gelten ? -- Gerd Fahrenhorst (talk) 19:06, 9 November 2018 (UTC)[reply]

Incorrect interpretation of dates in Q1165538 leading to persons still alive getting P570 by Reinheitsgebot invoked by Mix'n'match

For a number of items related to still living people, Reinheitsgebot has added a date of death (P570). It seems various dates in the source Nationalencyklopedin (Q1165538) have been incorrectly used as date of death (P570). I have undone these 19 edits. --Larske (talk) 22:53, 11 November 2018 (UTC)[reply]

Chemistry

This is the second time I had to revert edits made by this bot:

  • acetyl (Q481808): 1, 2; #quickstatements; #temporary_batch_1541195733806; invoked by mixnmatch:aux2wd, #quickstatements; #temporary_batch_1542070512957; invoked by mixnmatch:aux2wd.
  • pyrroline (Q899707): 1, 2; #quickstatements; #temporary_batch_1541576355836; invoked by mixnmatch:aux2wd, #quickstatements; #temporary_batch_1542063308929; invoked by mixnmatch:aux2wd

Neither the person responsible for these edits nor source of the data is provided, so I can't even check what could cause this problem. Wostr (talk) 01:22, 13 November 2018 (UTC)[reply]

Wrong automatization of dates

Hi, I see that several persons have already indicated the problem. The bo does not take correctly the information of the databases it consulted, for instance for Cosette Harcourt (Q23926334), the source indicates 1968-1976 and the bot put January 1st 1968 as the date of death (in fact the correct date is 1976). Could you please correct this (or if there are several dates in a source, make the bot not take any of them) ? Thank you, --Cgolds (talk) 08:46, 18 November 2018 (UTC)[reply]

How do you guess birth and death dates from VIAF?

Hello,

I see here+here that you add birth and death dates according to VIAF, who doesn't know those dates.

How do you proceed?

Regards, --Daehan (talk) 09:04, 28 December 2018 (UTC)[reply]

bad P570 statements

https://www.wikidata.org/w/index.php?title=Q15449518&diff=prev&oldid=830475638 and https://www.wikidata.org/w/index.php?title=Q12963&diff=prev&oldid=830455798 --Masegand (talk) 18:09, 9 January 2019 (UTC)[reply]

Putting errors back in

Over the past few days I have painstakingly removed errors. I see your bot now has put them back in:

04:19, 10 January 2019 diff hist +353‎ Anisostachya elytraria (Q17679645) ‎ ‎Created claim: PlantList-ID (P1070): tro-104126, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847

04:19, 10 January 2019 diff hist +353‎ Justicia valerii (Q17680347) ‎ ‎Created claim: PlantList-ID (P1070): tro-102781, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847

04:19, 10 January 2019 diff hist +354‎ Lepidagathis alvarezia (Q17680510) ‎ ‎Created claim: PlantList-ID (P1070): tro-50287058, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847

04:19, 10 January 2019 diff hist +353‎ Chasmatophyllum musculinum (Q17248247) ‎ ‎Created claim: PlantList-ID (P1070): kew-2715967, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847

04:19, 10 January 2019 diff hist +353‎ Drosanthemum anomalum (Q17244917) ‎ ‎Created claim: PlantList-ID (P1070): kew-2778129, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Caralluma bhupinderiana (Q18083982) ‎ ‎Created claim: PlantList-ID (P1070): kew-2699067, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Dischidia elmeri (Q18080994) ‎ ‎Created claim: PlantList-ID (P1070): kew-2772504, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Melodinus philippinensis (Q18083139) ‎ ‎Created claim: PlantList-ID (P1070): kew-124254, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Secamone oleifolia (Q18078255) ‎ ‎Created claim: PlantList-ID (P1070): tro-2602338, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Polyscias bellendenkerensis (Q27828718) ‎ ‎Created claim: PlantList-ID (P1070): kew-162450, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +355‎ Lithospermum tubuliflorum (Q17416623) ‎ ‎Created claim: PlantList-ID (P1070): tro-50319763, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Cardamine chenopodiifolia (Q17242858) ‎ ‎Created claim: PlantList-ID (P1070): kew-2699586, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +351‎ Aechmea vanhoutteana (Q4687417) ‎ ‎Created claim: PlantList-ID (P1070): kew-218298, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Spergularia fasciculata (Q17241355) ‎ ‎Created claim: PlantList-ID (P1070): tro-6301643, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Calophyllum touranense (Q17565266) ‎ ‎Created claim: PlantList-ID (P1070): kew-2693527, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Ageratina calaminthifolia (Q15573812) ‎ ‎Created claim: PlantList-ID (P1070): gcc-147859, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Erica harveyana (Q17234855) ‎ ‎Created claim: PlantList-ID (P1070): kew-2793451, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Erica bruniades (Q17234951) ‎ ‎Created claim: PlantList-ID (P1070): kew-2792806, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +350‎ Croton sarcocarpus (Q25673731) ‎ ‎Created claim: PlantList-ID (P1070): kew-51099, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Jatropha stephani (Q49519258) ‎ ‎Created claim: PlantList-ID (P1070): kew-104932, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Gentianella nummulariifolia (Q18078308) ‎ ‎Created claim: PlantList-ID (P1070): kew-2822195, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Smithiantha cinnabarina (Q17709077) ‎ ‎Created claim: PlantList-ID (P1070): tro-14001042, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Cryptocarya bellendenkerana (Q18077442) ‎ ‎Created claim: PlantList-ID (P1070): kew-2745858, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Bunchosia matudae (Q49524918) ‎ ‎Created claim: PlantList-ID (P1070): kew-2686010, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Cristaria molinae (Q17579749) ‎ ‎Created claim: PlantList-ID (P1070): kew-2742853, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Firmiana minahassae (Q17573784) ‎ ‎Created claim: PlantList-ID (P1070): kew-2812997, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Turraea madagascarensis (Q18078224) ‎ ‎Created claim: PlantList-ID (P1070): tro-50217215, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Melaleuca phratra (Q20721780) ‎ ‎Created claim: PlantList-ID (P1070): kew-463477, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Syzygium velarum (Q27828808) ‎ ‎Created claim: PlantList-ID (P1070): kew-200470, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +353‎ Epilobium nummulariifolium (Q21257436) ‎ ‎Created claim: PlantList-ID (P1070): kew-2790782, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Amitostigma tominagae (Q15237077) ‎ ‎Created claim: PlantList-ID (P1070): tro-50024950, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +350‎ Corybas muscicola (Q54922157) ‎ ‎Created claim: PlantList-ID (P1070): kew-47752, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +350‎ Cymbidium munronianum (Q39336955) ‎ ‎Created claim: PlantList-ID (P1070): kew-53299, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +350‎ Habenaria ferdinandi (Q56234888) ‎ ‎Created claim: PlantList-ID (P1070): kew-94623, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Pennilabium proboscideum (Q11059402) ‎ ‎Created claim: PlantList-ID (P1070): kew-149776, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +352‎ Prasophyllum viretrum (Q42329972) ‎ ‎Created claim: PlantList-ID (P1070): kew-348050, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Paropsia vareciformis (Q17558939) ‎ ‎Created claim: PlantList-ID (P1070): tro-24201625, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:19, 10 January 2019 diff hist +354‎ Piper verruculifolium (Q18037930) ‎ ‎Created claim: PlantList-ID (P1070): tro-25001925, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Piper schlechtendalianum (Q18038103) ‎ ‎Created claim: PlantList-ID (P1070): tro-25000906, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Piper mikaniifolium (Q18036805) ‎ ‎Created claim: PlantList-ID (P1070): tro-25001710, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +353‎ Piper canovillosum (Q18035716) ‎ ‎Created claim: PlantList-ID (P1070): kew-2873179, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Russelia syringifolia (Q49519418) ‎ ‎Created claim: PlantList-ID (P1070): tro-29200880, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +352‎ Elymus cacuminis (Q24853084) ‎ ‎Created claim: PlantList-ID (P1070): kew-410965, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Alchemilla sibbaldiifolia (Q15289093) ‎ ‎Created claim: PlantList-ID (P1070): tro-27800469, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Zanthoxylum rhodoxylon (Q18084059) ‎ ‎Created claim: PlantList-ID (P1070): tro-50100043, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Salix balansae (Q17561917) ‎ ‎Created claim: PlantList-ID (P1070): tro-50146588, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Serjania rutifolia (Q18080588) ‎ ‎Created claim: PlantList-ID (P1070): tro-28601475, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

04:18, 10 January 2019 diff hist +354‎ Pseudocyclosorus angustipinnus (Q15239168) ‎ ‎Created claim: PlantList-ID (P1070): tro-50166326, #quickstatements; mixnmatch:microsync for catalog 1005 #temporary_batch_1547093922847 current

The purpose of Wikidata is not to track every error anybody ever made on the www and import them into Wikidata to perpetuate them. - Brya (talk) 05:15, 10 January 2019 (UTC)[reply]

Apologies for causing you additional work. Looking at your first example, Anisostachya elytraria (Q17679645), it appears you "added" Plant List ID (Royal Botanic Gardens, Kew) (P1070) yourself by merging, then removed it again. Since no "P1070" shows up in the item's history, it is, for all practical purposes, impossible to automatically detect that such a property was ever edited/deleted.
Your remarks imply that I and my bot should, somehow, magically, have known what is correct and what is not, and that we have offended you, Wikidata, and the world by not acting on that fictitious knowledge. No worries, once I finish my Skynet AI project, no more errors will be tolerated. Until then, shit happens. --Magnus Manske (talk) 10:08, 10 January 2019 (UTC)[reply]
Hi, Magnus Manske, thank you for responding. Yes, I did merge the erroneous item, and then deleted the erroneous content, as the fastest way to create a redirect. And creating a redirect is faster than putting in a request for deletion.
        As to "I and my bot should, somehow, magically, have known what is correct and what is not", in view of the very many errors in The Plant List ("P1070"), it seems safe to assume that if by this time "P1070" is not there, there is a reason for its absence. - Brya (talk) 05:16, 11 January 2019 (UTC)[reply]
The bot does not work for Plant List ID (Royal Botanic Gardens, Kew) (P1070), it runs on all of Mix'n'match, which is >50M entries in >2K catalogs, of which The Plant List is only a small part. It appears there are still >12K Plant List items not matched to Wikidata. Assuming they are all wrong is quite a leap (disclaimer: I don't care about Plant List, specifically, one way or another). --Magnus Manske (talk) 10:10, 11 January 2019 (UTC)[reply]
12K sounds like a lot, but in view of the size and nature of The Plant List it would not be a stretch to say there can easily be two or three times that number of errors in that database. The Plant List is an aggregator of other databases, so basic quality is never better than that of the component databases. At least one of these is quite good, but at least one other is out of date by some twenty years. So the basic quality is less than top of the line. The big problem is that one of the component databases (in itself pretty good) was miscopied, creating massive error.
        Those 12K may not be all wrong, but it seems safe to bet that >95% is indeed wrong. Otherwise they would already have an item here. - Brya (talk) 11:51, 11 January 2019 (UTC)[reply]

Duplicate references with a false date of consultation

Hello. From time to time and since several months you duplicate the source of HDS, with a false date of consultation (always the same, 9 October 2017). Like in [11]. Greetings, Sapphorain (talk) 20:28, 14 January 2019 (UTC)[reply]

... you did it again, in (Q30731373). Sapphorain (talk) 10:35, 5 February 2019 (UTC)[reply]
... and again, in (Q3173987). Can you please stop that?. Sapphorain (talk) 10:39, 5 February 2019 (UTC)[reply]
...and again in (Q3154793), (Q42803664), (Q3579819)... Sapphorain (talk) 11:51, 5 February 2019 (UTC)[reply]
...and again (Édouard Diodati (Q3579819)‎, Jean Pierre Girard-dit-Vieux, (Q3173987)‎Antoine Maurice (Q30731373)‎). Can you please stop that nonsense? Sapphorain (talk) 05:14, 5 March 2019 (UTC)[reply]
...and again ( Jean Frédéric Théodore Maurice (Q42803664)‎). Please DO stop vandalizing. Sapphorain (talk) 09:45, 5 March 2019 (UTC)[reply]
... and again 3 more. Hello? Is there somebody behind this stupid bot? Is this somebody stupid also, or just a vandal? Sapphorain (talk) 16:09, 28 March 2019 (UTC)[reply]
And again... Please do stop vandalizing. Sapphorain (talk) 22:38, 19 April 2019 (UTC)[reply]
...And again... Moreover, the date of consultation is false (2017), and thus misleading (the old edition available in 2017 does not exist anymore). Please stop vandalizing. Sapphorain (talk) 08:12, 1 November 2019 (UTC)[reply]

Strange edit

Hi,

Was this edit Special:Diff/151448396 done on purpose? It seems like the bot removal was a mistake. If I'm correct, it created a bug and we should now merge The Hall (Q17537656) and The Hall (Q17582911). What do you think?

Cheers, VIGNERON (talk) 20:40, 16 January 2019 (UTC)[reply]

Weird dates of death

It looks like your bot is claiming that some people died in 2050. You probably want to keep your time traveling under wraps and not claim that 31 years in advance... Sumurai8 (talk) 23:03, 18 January 2019 (UTC)[reply]

Should be fixed now.--Magnus Manske (talk) 10:51, 5 February 2019 (UTC)[reply]

1900 birth dates from VIAF

Your bot has given a lot of living academics 1900 birth dates with a VIAF ref (e.g. Rosamund Bartlett (Q7367298), Kim Barrett (Q29653444), Jerome Groopman (Q6182708)). --ASchedulingError (talk) 19:58, 10 February 2019 (UTC)[reply]

bad P570 statements

seems to use the entry of a different person https://www.wikidata.org/w/index.php?title=Q4098419&type=revision&diff=857308682&oldid=839632159 --Masegand (talk) 13:26, 13 February 2019 (UTC) This one https://www.wikidata.org/w/index.php?title=Q159913&action=history twice--Masegand (talk) 15:41, 14 February 2019 (UTC) Here it is also wrong twice: https://tools.wmflabs.org/mix-n-match/?#/search/klaus%20kinkel?include=875 --Masegand (talk) 21:35, 14 February 2019 (UTC)[reply]

Invalid P4491 statements

Hello, over the past months, your bot has added the sources' URLs instead of IDs as Isidore identifiers (property P4491) to several objects. Examples: Special:Diff/819817353, Special:Diff/863631057, Special:Diff/878996613. Regards, Axolotl Nr.733 (talk) 08:45, 10 March 2019 (UTC)[reply]

Dates of birth and death for "Giovanni Gabrielli" (Q18823013)

Your bot added added a date of birth of 1550 and date of death of 1551 to Q18823013, Gabrielli's Wikidata page, based on his VIAF page and/or the linked Library of Congress page, but I see no evidence for those dates on either of those pages, so I deleted them from Wikidata. In any case, his dates of birth and death are not known, that I know of. I don't know why your bot did this, but I believe it was done in error. --Robert.Allen (talk) 04:48, 15 March 2019 (UTC)[reply]

bad edit

Something wrong with this bot edit. The person would have lived 200 years. Also I could not find those dates at the page used as a reference. --Jarekt (talk) 13:39, 18 March 2019 (UTC)[reply]

Library of Parliament of Canada person ID (P6616)

There are a lot of duplicate items created where the names do not exactly correspond to existing pages. Most (if not all) Canadian MPs already have a Wikipedia page and thus a Wikidata item. Ebe123 (talk | contributions) 13:32, 2 April 2019 (UTC)[reply]

Bad P214 statements

A recent batch introduced junk values for VIAF ID (P214) in several objects:

I'd love to fix myself, but I don't have a source. — Yerpo Eh? 08:50, 19 April 2019 (UTC)[reply]

P813: Abgerufen an

Hello Magnus Manske,

Thanks for all your work on Wikidata.

I just saw your bot doing this edit on the Wikidata-article on 'Elisabeth von Österreich'. I'm curious about the given date for retrieved (P813), which is put to 'October 9, 2017'. Did your bot keep this information for one and a half year for itself? Or is the information retrieved more recently, but is the date hard coded?

Thanks in advance, RonnieV (talk) 22:05, 3 May 2019 (UTC)[reply]

Same problem [12] on May 23, 2019. Does your bot work with a fixed date for 'retrieved'? I hope you can have a look at it. Thanks, RonnieV (talk) 09:23, 13 June 2019 (UTC)[reply]

Conflating different people

I have reverted [13] and [14] because they appear to conflate two different people. I don't know how this bot works, but I don't think you should be either: a) adding a second ORCID to an item that already has one; or b) adding an ORCID that is already present on a different item. Cheers, Bovlb (talk) 22:34, 1 July 2019 (UTC)[reply]

Also [15] [16] [17] Bovlb (talk) 22:48, 1 July 2019 (UTC)[reply]
@Magnus Manske: Here is another example. Are we assuming they're the same person because they both have the last name "Smith"? Bovlb (talk) 16:42, 4 July 2019 (UTC)[reply]

Redundant references

Please explain the merit of this edit which adds yet another reference to the death date of Galileo, even though there are already many references to reliable sources for this fact. Jc3s5h (talk) 16:55, 3 July 2019 (UTC)[reply]

Guggenheim fellows ID as reference for date of death

Hello, the bot is currently adding the Guggenheim fellows ID as references for dates of death (example), which is fine. However, it's incorrect to say that the info is stated in the Solomon R. Guggenheim Museum, because Guggenheim fellowships are awarded by the John Simon Guggenheim Memorial Foundation, a different organization. --Axolotl Nr.733 (talk) 20:32, 3 July 2019 (UTC)[reply]

Manual worker

The bot added a statement to Q55720463 that Jane Elizabeth Robbins was a manual worker, but I cannot find it in the given source. It was probably mistaken by the phrase "settlement house worker". I have corrected it but decided to let you know in case the bot made more mistakes like this one. --Jan Kameníček (talk) 17:49, 11 August 2019 (UTC)[reply]

Normdatei der Spanischen Nationalbibliothek

Die BNE importiert wie Wikidata ihre Daten ohne Überprüfung aus allen möglichen Quellen; bei der GND gerne auch Platzhalter, Dubletten und Namensvetter. Die "Normdaten" sind daher mit Vorsicht zu gebrauchen. Die Beschreibung bei Augusto Córtina Aravena (Q55947699) lautet sinngemäß: "Entdecken Sie Cortina, Augusto, im offenen und verlinkten Datenportal der spanischen Nationalbibliothek", d.h. raten Sie mit, um wen es sich handeln könnte. Vermutlich handelt es sich um Augusto Córtina Aravena (Q56318455). Aber bei häufiger vorkommenden Namen sinkt die Trefferquote schnell unter 50 Prozent. Daher sollte man aus der BNE imho nur jene Datensätze importieren, die das Geburtsjahr oder den Beruf der Person enthalten. Gruß --Kolja21 (talk) 15:18, 31 August 2019 (UTC)[reply]

Death date for someone still living?

Hi,

Your bot added a death date for this writer in 2014, without any source. We (OTRS) received today an email about the writer still beeing alive. Indeed, she published a book in 2016! A wrong information of this nature can cause harm to people. Please be more careful and cite source!

Jules78120 (talk) 18:29, 7 October 2019 (UTC)[reply]

Ok, your bot imported a false information from en-wp ([18]). Please do not make your bot import information without source when related to living persons: instead of having a vandalism only on English Wikipedia, we had it too on French Wikipedia… Jules78120 (talk) 18:39, 7 October 2019 (UTC)[reply]

Fraglicher Edit bei Michael Chapman (Q70022813)

@Magnus Manske: Dieser Edit ist aus meiner Sicht wenig schlüssig: Erstens hat der VIAF als solcher keinen Quellenwert, sondern nur die verlinkten Normdaten. Zweitens ergibt auch das „named as: Michael Chapman“ keinen Sinn, weil der VIAF keine feste Ansetzform bereitstellt. --Emu (talk) 07:36, 8 October 2019 (UTC)[reply]

Very unlikely aliases being added (at least in June)

I've run across several cases like this, here's the edit I just undid. Why would you be adding such aliases to researchers? It looks like something is confusing one person with another who has the same first name but very different last name??? ArthurPSmith (talk) 15:35, 8 October 2019 (UTC)[reply]

Just hit another here, also from June. ArthurPSmith (talk) 15:41, 8 October 2019 (UTC)[reply]
Here's another. That same item also had a more recent (September) edit from Quickstatementsbot that seemed to follow the same pattern of adding an entirely bogus "alias" value: here. It looks like whatever was doing this has migrated from Reinheitsgebot to Quickstatementsbot ??? The edit summaries are extremely undescriptive also "Updated item". ArthurPSmith (talk) 19:21, 8 October 2019 (UTC)[reply]
David-Alexandre Trégouët (Q47502434) is probably the item for the alias added to David M. Evans (Q30348322). Maybe they authored a paper together (I couldn't find that) or it was the next row in some list. --- Jura 19:50, 8 October 2019 (UTC)[reply]
Looking at [19], the above seem rather exceptional .. --- Jura 20:05, 8 October 2019 (UTC)[reply]
I keep running across these - here's another: Nicholas Eriksson and Nicholas Wood surely different people. ArthurPSmith (talk) 21:00, 8 October 2019 (UTC)[reply]
And another: He Gao added as alias to Ruifang Li-Gao ??? ArthurPSmith (talk) 21:43, 8 October 2019 (UTC)[reply]

bad death date

https://www.wikidata.org/w/index.php?title=Q47002805&type=revision&diff=1028737281&oldid=1028693998 but https://viaf.org/viaf/76349591/ does not have 1999 as death date.--Masegand (talk) 15:26, 9 October 2019 (UTC)[reply]

https://www.wikidata.org/w/index.php?title=Q881154&type=revision&diff=1043448692&oldid=1042629181 but https://www.blackpast.org/african-american-history/people-african-american-history/wilder-lawrence-douglas-1931/ does not have 1994 as death date.--Masegand (talk) 18:35, 2 November 2019 (UTC)[reply]

suggest meta user page for user:Reinheitsgebot

Hi. With this bot editing at wikidata, yet the user links showing on each wiki as a red link, can I ask for you to consider creating a user page for your bot at metawiki. It will enable users to better understand the edits being made. Thanks.  — billinghurst sDrewth 21:32, 31 October 2019 (UTC)[reply]

If you need assistance getting it done at meta, then please welcome to ping me.  — billinghurst sDrewth 21:33, 31 October 2019 (UTC)[reply]

Duplicate reference to NooSFere

Hi,

Reinheitsgebot is now adding references to NooSFere (Q55790874), but it's a redirection to NooSFere (Q3343389) and they already exist, as here . — eru [Talk] [french wiki] 09:43, 2 November 2019 (UTC)[reply]

Another instance of this error. Jc3s5h (talk) 17:53, 2 November 2019 (UTC)[reply]

@Magnus Manske, Matěj Suchánek: it's worse, MatSuBot fixes a redirect, and Reinheitsgebot recreates it, see this diff. ~~
Hi @Magnus Manske:, still appending [20]. — eru [Talk] [french wiki] 06:50, 15 March 2020 (UTC)[reply]

Unreasonable P813 inserted

@Magnus Manske: See this edit where a reference to the date of death (P570) of Robert Mugabe (Q10707) is inserted. The retrieved (P813) of 9 October 2017 is unreasonable as the date of death (P570) is 6 September 2019, almost two years later!

Please don't insert such fake retrieved (P813). Correct or remove the already insterted. --Larske (talk) 12:55, 6 November 2019 (UTC)[reply]

False information reverted

I have reverted the false information about the calendar use for a birth date at Caroline Matilda of Great Britain (Q57668). Jc3s5h (talk) 21:03, 11 November 2019 (UTC)[reply]

Unnötige Wiederholungen

Ihr Bot scheint mehrmals dieselbe Information zu ergänzen, wie zum Beispiel in den folgenden Einträgen: [21], [22], [23], [24], [25]. Maitake (talk) 16:37, 13 November 2019 (UTC)[reply]

Request approval of Reinheitsgebot be revoked

See Wikidata talk:Bots#Request approval of Reinheitsgebot be revoked Jc3s5h (talk) 16:22, 19 December 2019 (UTC)[reply]

Alfred Mayer Q13424327

Hallo, die Aussagen "Geburtsdatum", "Sterbedatem" und "Deutsche Biographie ID" gehören zu einem anderen "Alfred Mayer". Die hier behandelte Person hat laut IPNI-Eintrag 1995 fünf Strandflieder-Arten aus Sardinien und Kreta beschrieben. Ich kenne ihn persönlich, er ist 1958 geboren und meines Wissens quicklebendig. Viele Grüße --RLJ (talk) 16:48, 13 February 2020 (UTC)[reply]

Vielen Dank, sollte jetzt behoben sein! --Magnus Manske (talk) 09:07, 14 February 2020 (UTC)[reply]

Please stop adding wrong death dates

Three times within two days this bot has added "1651" as the year of Duchess Catherine of Cambridge's death, even though she wasn't born until 1982 and luckily seems to be alive and well. There are numerous other examples. Please make it stop. --SorenRK (talk) 17:18, 14 February 2020 (UTC)[reply]

Hi, first when a bot adds something like this, you can just mark it as deprecated.
In this case the problem does not come from Reinheitsgebot, the first add was made 2 days ago by Thierry Caro but it just confirmed a bad automatch.
The mix'n'match for Deutsche Biographie (GND) ID (P7902) is 1619, and I found Catharina here, then I just deleted the bad match, now the bot won't add it anymore.
Similarly here and here. — eru [Talk] [french wiki] 17:48, 14 February 2020 (UTC)[reply]
@eru: when a bot adds something like this, you can just mark it as deprecated This advice is new to me. Is it documented anywhere more public? What should we put as reason for deprecated rank (P2241)? Cheers, Bovlb (talk) 14:48, 19 March 2020 (UTC)[reply]
@eru: This is terrible advice. Deprecation should be use to indicate that a normally-credible source has published an erroneous value. It should not be used to indicate crap from out-of-control wikimedia tools or bots. Jc3s5h (talk) 16:15, 19 March 2020 (UTC)[reply]
@Jc3s5h: I'm assuming that the motivation for this advice is that some/many bots have the feature that they will not add a claim that already exists, and thus deprecating a claim rather than deleting it is a way to prevent a bot from re-adding an erroneous claim. Obviously it is suboptimal, as not only do we retain the erroneous claim, but it is also slower for a human to do when dealing with a bot that makes many errors. Bovlb (talk) 17:16, 19 March 2020 (UTC)[reply]
Hi, in this cas it was a bad match, so no, we shouldn't mark them deprecated, but remove them from wikidata and mix'n'match.
Deprecated must be use when a bot (or a human) makes a good match, but the source is wrong.
But if you don't know how to use mix'n'match and a bot adds it again, mark them deprecated can prevent this and can be use if you add reason for deprecated rank (P2241) => applies to other person (Q35773207) for example.
It's not offical, just what I usually do. — eru [Talk] [french wiki] 17:45, 19 March 2020 (UTC)[reply]

VIAF date with flourished or lived

Hi Magnus Manske,

Imports from viaf with a flourished or lived dateType should not be add as a year date like here, but with a precision of a century. — eru [Talk] [french wiki] 17:42, 19 February 2020 (UTC)[reply]

God on Discogs and Songkick

Why this happened? --Obsuser (talk) 21:57, 13 March 2020 (UTC)[reply]

@Obsuser: We seem to be getting some crazy false results from the "mixnmatch" tool. I have reverted some more errors on the same item. See the topic "Blocked" below for more discussion. Bovlb (talk) 17:24, 19 March 2020 (UTC)[reply]

URL-encoded Artnet artist IDs

Hi! Such edits cause mass constraint violations, as only decoded IDs are permitted by the format constraint (which seems quite reasonable, given that external identifier links are URL-encoded anyway by the software, so the current link is http://www.artnet.com/artists/ilona-barab%25c3%25a1s/past-auction-results—the “á” is double encoded, notice the %25s). Please decode these IDs with your bot. (Fortunately the links work even in this double-encoded form, so I can leave these two items in their current state for you as test cases.) Thanks in advance, —Tacsipacsi (talk) 22:49, 13 March 2020 (UTC)[reply]

Doppeleinträge bei Findagrave

Hallo Magnus! Ich gehe mal davon aus, dass Du die Diskussionsseite Deines Bots liest und ich mein Anliegen hier loswerden kann. Es geht darum, dass Dein Bot offenbar in Datenelementen Findagrave-IDs ergänzt, aber offenbar ohne Prüfung, ob dort schon solche enthalten sind. Ein aktuelles Beispiel ist dieser Edit. Dies führt aber dann in den Artikeln, hier also bei de:Jonathan Cilley, zu dem sehr unschönen Ergebnis, dass dort nun zu lesen ist: "23303799 Jonathan Cilley in der Datenbank von Find a Grave (englisch)". Verlinkt ist dort der erste Findagrave-Eintrag aus dem Datenelement, aber der zweite wird offenbar als Teil des Namens ausgelesen. Das kann sicher nicht der Weisheit letzter Schluss sein. Vielleicht lässt sich das ja ändern. Liebe Grüße! --Secretary McCord (talk) 15:46, 16 March 2020 (UTC)[reply]

Hi, das ist aber eher ein Problem der de-Vorlage? Beide Find-a-Grave-IDs scheinen korrekt zu sein, und sollten deshalb auch auf Wikidata sein, auch wenn die Property ein "single value constraint" hat, glaube ich. --Magnus Manske (talk) 09:09, 17 March 2020 (UTC)[reply]
Hallo Magnus! Dazu kann ich Dir, wie Du verstehen magst, natürlich auch nichts sagen, da ja die de-Vorlage nun nicht von mir stammt. Ich wende mich an Dich halt in der Hoffnung, dass Du weißt, wie ein solches Problem zu beheben ist. Letztlich finde ich halt schon ärgerlich, wenn dieser Darstellungsfehler in den WP-Artikeln steht, weil es einen Doppeleintrag in Wikidata gibt - und es wäre echt super, wenn es irgendwie zur allgemeinen Zufriedenheit repariert werden könnte. Ich bin auch froh, dass ich es hier bei Dir auf Deutsch darlegen kann, weil mein Schulenglisch zwar für den Hausgebrauch reicht, aber vermutlich nicht für komplexere Angelegenheiten. In den Tiefen des hiesigen Systems kenne ich mich natürlich auch nicht so aus. Liebe Grüße! --Secretary McCord (talk) 09:49, 20 March 2020 (UTC)[reply]

Blocked

I have blocked the bot as it seems to be making incorrect and somewhat disruptive errors at a high rate. See this thread for details. Unblocking is at the botop's discretion, once they have had a chance to investigate and can assure us that the problem is fixed. Bovlb (talk) 01:26, 19 March 2020 (UTC)[reply]

Unblocked per botop Bovlb (talk) 14:57, 21 March 2020 (UTC)[reply]

old ETIS ID-s

why do you add back old ETIS ID-s [26] ? --WikedKentaur (talk) 08:29, 29 March 2020 (UTC)[reply]

It's automatic from a mix'n'match catalog, but it was deactivated yesterday : Topic:Uw1xiumimpg2gwfb
You can delete it now. — eru [Talk] [french wiki] 08:59, 29 March 2020 (UTC)[reply]

Where can I request that all changes by Reinheitsgebot to add Property:P2953 would get reverted? --WikedKentaur (talk) 08:18, 9 April 2020 (UTC)[reply]

Has there been any development with this? Old ID-s are still a problem. Kruusamägi (talk) 22:03, 22 April 2020 (UTC)[reply]

Hi, Magnus Manske. Your bot created a lot of wrong claims for Q27046 and it has just created a new one. Q27046 or Carabidae is a family, there is no need to link it with every genus or specie within this family. Track13 (talk) 20:21, 29 March 2020 (UTC)[reply]

The link to then bad match is in the comment, it must to be dissociated here for exemple : https://tools.wmflabs.org/mix-n-match/#/entry/11656413 — eru [Talk] [french wiki] 20:36, 29 March 2020 (UTC)[reply]
Ok, thank you for the explanation, I've removed associations. Track13 (talk) 08:59, 30 March 2020 (UTC)[reply]

WORK not HUMAN

In this edit, your bot added an ID from the University of Barcelona to a data item. The ID was identified as that for a creative work, but the item it was matched to is a human. This is the same mistake that was happening before. --EncycloPetey (talk) 14:19, 30 March 2020 (UTC)[reply]

Same data item, same problem: [27] --EncycloPetey (talk) 00:56, 2 April 2020 (UTC)[reply]

Several errors in French churches

Hello, your BoT generates errors when adding wrong links to the property P3963 (eg error1 or error2 or error3. Pls check it, --FHd (talk) 19:39, 8 April 2020 (UTC)[reply]

Hi, you can cancel it by clicking on the link in the comment, such as https://tools.wmflabs.org/mix-n-match/#/entry/24064435
I canceled the 3, the first was automatic, but the others were matched by Ayack and AyackBot. — eru [Talk] [french wiki] 21:02, 8 April 2020 (UTC)[reply]

Work/edition duplicates

Please see Property_talk:P648#Work/edition_duplicates, I think it was this bot --Bultro (talk) 10:16, 16 April 2020 (UTC)[reply]

Please fix human label that you added

https://www.wikidata.org/w/index.php?title=Q85794907&oldid=1119794048 MrProperLawAndOrder (talk) 00:07, 9 May 2020 (UTC)[reply]

another one https://www.wikidata.org/w/index.php?title=Q85857466&oldid=1120345395 MrProperLawAndOrder (talk) 00:11, 9 May 2020 (UTC)[reply]
January 2019:
you seem to be inserting these errors since at least 2018

Wrong IDs

  1. Markus Ebner (Q119378)
    1. pnd133528537 was removed https://www.wikidata.org/w/index.php?title=Q119378&diff=1121111897&oldid=1114578553
    2. your bot adds it again as 133528537 https://www.wikidata.org/w/index.php?title=Q119378&diff=1134298424&oldid=1126950518
    3. your bot adds wrong CERL https://www.wikidata.org/w/index.php?title=Q119378&diff=1126950518&oldid=1121112021
  2. Johann Theodor Roscher (Q126802)
    1. wrong CERL https://www.wikidata.org/w/index.php?title=Q126802&diff=1117930585&oldid=1113907116

MrProperLawAndOrder (talk) 02:47, 10 May 2020 (UTC)[reply]

@MrProperLawAndOrder: I cleaned up the matches for Markus Ebner (Q119378) here and here.
It was already unmatched for Johann Theodor Roscher (Q126802) here. — eru [Talk] [french wiki] 07:51, 10 May 2020 (UTC)[reply]
eru, this is a systematic problem. Why are the wrong IDs there in the first place? The Deutsche Biographie ID is tied to GND ID, but the items had no GND ID. 690 at https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P7902#Item_P227 and currently 632 https://w.wiki/QUj - maybe all wrong. MrProperLawAndOrder (talk) 00:44, 11 May 2020 (UTC)[reply]
  1. Theodor Koch (Q101652) 1905-1975!!!
    1. user:Thierry Caro batch-adds pnd136084222 - this is for a person 1786-1863
    2. your bot adds CERL for a person 1786-1863!!! with comment "#quickstatements; invoked by Mix'n'match:add_person_dates" ... but what is the basis?

MrProperLawAndOrder (talk) 01:05, 11 May 2020 (UTC)[reply]

Hi, both are matched by "Auxiliary data matcher" here and here, starting the at 2020-02-13 08:51:01, after the #temporary_batch_1581486542647 , so because it was already match for Deutsche Biographie, and because of the common GND id for CERL.
Thierry Caro, what was this batch ? (could be just a apply for waiting match on mix'n'match 1619) — eru [Talk] [french wiki] 06:47, 11 May 2020 (UTC)[reply]
It came from Mix'n'match. Thierry Caro (talk) 06:49, 11 May 2020 (UTC)[reply]
Thanks, so I can't say why the auxiliary data matched, since there is no gnd id on the item.
Let's notify Magnus Manske. — eru [Talk] [french wiki] 16:36, 11 May 2020 (UTC)[reply]

Still wrong CERL values [28] MrProperLawAndOrder (talk) 19:25, 25 May 2020 (UTC) @Eru, Epìdosis: can catalog 1619 be disabled? On top of complete nonsense, the GND IDs can change leading to duplicates etc. DtBio can be linked via tracking GND IDs and SPARQL detecting differences. MrProperLawAndOrder (talk) 19:30, 25 May 2020 (UTC)[reply]

I've asked for deactivation ten days ago. --Epìdosis 19:35, 25 May 2020 (UTC)[reply]

False match then false ID then year of death from the false match

Not only mismatches and wrong IDs, but then also adding year of death from mismatch. Can an admin intervene?

[37] - are you going to fix? MrProperLawAndOrder (talk) 20:57, 25 May 2020 (UTC)[reply]

maybe he switched from Deutsche Fortschrittspartei to Jugendfunktionär der Kommunistischen Internationale or the other way around. But no evidence presented. MrProperLawAndOrder (talk) 21:07, 25 May 2020 (UTC)[reply]

Imperfect references

Hi! I've noticed the addition of these references: they are correct, but they should have stated in (P248)Internetowy Polski Słownik Biograficzny (Q96022943), not stated in (P248)property (Q1400881). Could you launch a massive substitution? Thanks, --Epìdosis 09:21, 3 June 2020 (UTC)[reply]

...

Cousin Emmy (Q55720156) wurde von dir erstellt. Muss das einzeln geführt oder kann das eventuell mit Cousin Emmy (Q5178819) gemerged werden? Gruß -- MovieFex (talk) 20:28, 5 June 2020 (UTC)[reply]

Pilze Deutschland ID

Hallo Magnus, seit dem letzten Lauf im September 2019 scheinen die Einträge auf pilze-deutschland.de neu organisiert worden zu sein. Kannst Du bitte den Import noch einmal starten, damit die Einträge hier korrigiert werden? Im Moment enden alle Links, die ich geprüft habe, auf einer Fehlerseite. (#quickstatements; mixnmatch:microsync for catalog 2767 (5d73363101767874917373)) Vielen Dank, Matthias.Wolf (talk) 17:15, 10 June 2020 (UTC)[reply]

Erledigt, cleanup läuft. --Magnus Manske (talk) 09:57, 16 June 2020 (UTC)[reply]
Cool - danke! Matthias.Wolf (talk) 19:44, 16 June 2020 (UTC)[reply]

Number as label for human

https://www.wikidata.org/w/index.php?title=Q55988514&oldid=722054660 MrProperLawAndOrder (talk) 03:52, 12 June 2020 (UTC)[reply]

GND 4053219-7 not a human

https://www.wikidata.org/w/index.php?title=Q72940909&diff=next&oldid=1041621620 MrProperLawAndOrder (talk) 22:05, 16 June 2020 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=User_talk:Reinheitsgebot&oldid=1209225445"