Frettie

https://www.wikidata.org/w/index.php?title=Q125295386&action=history - when you created that item, the contained ISNI was already at https://www.wikidata.org/w/index.php?title=Q18912045&oldid=2046163419

At least you should merge such cases afterwards.

Hi, i am sorry, if i found the same people, i merging that. Thanks. I created thousands items, i know it. --~~~~

Same here https://www.wikidata.org/w/index.php?title=Q124645313&action=history - it is good to have the connection to NKČR

Maybe before import refresh Property_talk:P213/Duplicates/humans and after import refresh again - then it is more clear how many new duplicates have been created.

Very good NKČR has ISNI and you import it, so we have more chance to find duplicates. Best regards

Shouldn't the "File:Uhry-znak chronicon.jpg" in Adelaide av Ungern (Q2457515) be in bild av heraldiskt vapen (P94) not in bild (P18)? I added it to bild av heraldiskt vapen (P94) but it should be removed from bild (P18). Maundwiki (disk) 11:54, 15 June 2024 (UTC)

Hi, i agree. --~~~~

Hi! Why js20010125049 has been added to Oleh Olehovyč Kandyba (Q25442482) on 25 May although it does not contain that Wikidata ID (because it was removed from it on 20 May)? Thanks!

Hi, it's strange. Maybe because ISNI in NK ČR record? But even that's unlikely.

As of the 25 May surely js20010125049 did not contain a reference to Wikidata item Oleh Olehovyč Kandyba (Q25442482); maybe the bot retrieved it before 25 May (in this specific case, before 20 May when the Wikidata item was removed)?

Yes, but there is ISNI field in js20010125049 – and we can add " js20010125049" to WD by ISNI field in WD item.

This is strange: js20010125049 contains ISNI 0000000109914931, whilst the Wikidata item before last bot addition contained ISNI 0000000074945489, so the two ISNIs did not match. Anyway, removing now NKC and ISNI from the item should be safe, right?

Hm, it is strange ...

I think so, it may be correct way.

Hi! For early-modern printers often women are registered as "widow of X"; however, vedova di Johann Nikolaus Gerlach (Q124640128) was imported just as "Johann Nikolaus Gerlach", omitting the fundamental indication "vdova"; this may lead to wrong merges and other types of confusion. The indication "vdova" should never be omitted; and, if possible, already existing items should be checked and their labels edited adding missing "vdova". Thanks as always!

Hi, i tried to write correct czech label "vdova po XY", its similar "widow of XY", i try to check when insert similar records. Thanks!

Thanks, this is surely better; if possible, take a look also on previously imported items ;-)

Hello, your recent batch with the tool Quickstatements (1710581543492) added some values to the property skådespelare (P161) from the ČSFD database. However, this database doesn't differentiate between skådespelare (P161) and röstskådespelare (P725) which duplicated the values on items such as Odysseus a hvězdy (Q931721). Now, I've reverted your edits on this item, but do check your edits to see if this hasn't created more work for others and be cautious in the future.

Thanks

Thanks, that is very special case of movie.

Hello, Can you please use Q11569986 rather than Q329439 when you find "rytiny" on Czech authorities? First one refers to printmakers artists ; second one to craftsmen. Example with Alix (see history of Q3573440: the information is duplicated, as the source is already used for Q11569986 occupation). It is a lot of work to correct these assertions. Thank you!

I think, that is correct setup, Q3573440 (Alix) has in NKČR "rytci" (engraver – Q329439). @Vojtěch Dostál – what do you think?

Hello, no, as I said, Q329439 refers to craftmen who worked metal to do some decoration on metal or medals. And Q11569986 refers to artists (printmakers) who work metal plates to produce art prints. 99% of Q329439 uses after the Czech authority notice are wrong...

Oh, i see! Thanks! I moved "tiskař" from Q329439 to Q11569986.

Did you move all usages? I can do that

I didn't.

I will do it when I have some time.

Thank you very much, both of you :)

@Daehan There's 14 statements where the claim is supported by another reference. What should be done about these? Also moved?

https://w.wiki/9SWs

Hello @Vojtěch Dostál, I checked them, and they are all printmakers, yes.

An additional request, maybe. When you get a source (P854) from https://cs.isabart.org, shouldn't P248 be Q107456632 instead of Q10855166 ? (Example here: Q6149252)

Just to be clear, regarding the 14 statements, there should not be Q329439 as an occupation: they all are Q11569986 and the sources used for the first should actually be added to the second. Thanks!

OK, I will fix all statements.

As for Abart, I can't help unfortunately. Tools available to me cannot edit references so easily. But I agree.

OK, thank you for everything, @Vojtěch Dostál !

Please avoid conflating disjoint classes in an item, ad you did in Gerhard Breitfellner : 15.07.1935–08.09.2019 (Q91699599) where you conflated a human with a scientific article.

Ok, thanks a lot.

Hi Frettie,

The bot added a redundant 'place of birth', along with a reference, to the entry 'George Gilder' (Q3760499). There already was a place of birth established for the entry 'George Gilder' (which was 'New York City' in the US). The bot added a place of birth of "United States of America', which is correct (in a way), but both redundant and broader than the narrower place of 'New York City'. I suppose that there are several ways to fix this problem. But the simplest would seem to be to not add a 'place of birth' value if one already exists on an entry. For your information, the bot used as a reference for the added value the 'Czech National Authority Database'. I suppose that the place value of 'United States of America' was in that database. But regardless, I still think that the best solution is for the bot to not add a 'place of birth' if a value for that property already exists on the item. Best regards,

--~~~~

Hi, i set USA as Deprecated, which is not best solution, but its correct solution, if there is better (NYC) information.--~~~~

Hi 👋, I must admit that the idea of ​​your bot may at first glance be a very good idea.

But from the moment we delete what the bot has put, it should stop putting it back! He constantly puts places of birth or death when there is already another more precise one! Just recently, he keeps adding a place of death to the Q270271 page. This causes a duplicate which is then displayed in the biography2 infobox on the French Wikipedia.

I think there should be a feature where the bot does not come back to modify the same information that it had already done before if it has been deleted.

Hi, thanks for the message, the logic of the bot and Wikidata is that you need to set non valid data as Deprecated, not delete it directly. The bot is not clairvoyant to be able to guess that a deletion has occurred in few days back. Process should be followed - the infobox should reflect this and only take "valid" (non-deprecated) claims. --~~~~

If there was a case where a certain item of information is in dispute, then sure, add the other possibilities. This is completely understandable and warranted. This is what multiple value instances of a property is for in the first place. But in cases where the information item is well established (like the place-of-birth for the famous George Franklin Gilder - Q3760499) adding additional junk entries does not clarify anything for the readers. It only distracts. I see that this also happened for Q270271 (as was pointed out above by User:Storberg). Are many other WikiData personal entries are being modified in this manner?

There may be few items that are edited similarly. Correct way to solve this is set this (Paris) data as deprecated. There was a very long discussion about this on Project chat, where the bot was unblocked again after a month long block, with the being the correct procedure as deprecated claims are set. I understand your view, but when it auto-editing from authoritative sources, there is practically no other options.