User talk:Frettie

talk

Previous discussion was archived at User talk:Frettie/Archive 1 on 2016-01-27.

https://www.wikidata.org/w/index.php?title=Q124844608&action=history - no ISNI, but https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=js20241219095 shows an ISNI - do you know why it wasn't added?

The ISNI exists since 2020 in WD https://www.wikidata.org/w/index.php?title=Q95338544&action=history

https://aleph.nkp.cz/F/?func=direct&doc_number=001219095&local_base=AUT

There is not ISNI in MARC, it's external showed ISNI from WD. NKLink – you can find blogpost about at https://blog.wikimedia.cz/2020/10/12/nklink-novy-nastroj-propojujici-wikidata-se-svetem-narodnich-autorit/

Same here, by @Vojtěch Dostál: https://www.wikidata.org/w/index.php?title=Q112481508&action=history - ISNI in WD since 2021 https://www.wikidata.org/w/index.php?title=Q93448456&action=history

Yeah do you realize that the ISNI IDs that you see in NKC are actually sometimes dynamically loaded from Wikidata, and are not stored there? :-)

Counter example: Q112523124 VIAF NKC merged with Q130790030 VIAF ISNI GND DDB - https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=utb20181000953 does not show "ISNI". But I looked at the record before merging, so maybe "dynamically"-not finding any ISNI was cached.

Hi, i checked the source code – there is a redis cache for 24 hours. You have to wait probably. --Frettie (diskuse) 19:09, 3 November 2024 (UTC)

https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=utb20181000953 - ISNI now visible.

do you know the follwoing about NK CR data set:

1. quantity of humans
2. quantity of humans having ISNI
3. quantity of humans which also exist in WD

Hi,

1. it's not so easy, but humans and terms are 1 213 304 – in prepared file
2. 61487 (probably)
3. @Vojtěch Dostál ? Do you have right answer of 1. and 3.?

Last time I checked, about a month ago, there were 907 847 human entries (you can get more precise stats by checking the https://aleph.nkp.cz/data/aut_ja.xml.gz file)

About 64883 of them had ISNI.

687183 were in Wikidata.

@Frettie, Vojtěch Dostál: - Děkuji mnohokrát. So:

1. 907847 humans
2. 64883 humans having ISNI - this is from aut_ja.xml.gz?
3. 687183 humans in WD

So ~ 10% have an ISNI. Are all of these that have an ISNI in WD?

From WD:

1. P213 and P691 - https://w.wiki/BmiA - 443461
2. human P213 and P691 - https://w.wiki/BmiF - 424485
3. P691 and human - https://w.wiki/Bmig - 682801

So, a lot of ISNI missing in NK CR DB.

Do you plan to import more NK CR humans into WD, if yes, what would be the criteria, e.g. having ISNI, having other characteristics?

There is a difference between 687183 and 682801, maybe because multiple records in NK CR are in one record in WD.

Not all people with ISNI in NKC are currently in Wikidata. About 4500 missing from WD. But - I recently synced all NKC entries that had an ISNI value which already exists somewhere in Wikidata.

I do plan to import more NKC entries. In past, we imported all people which either had a birth of date or were to be used as authors in imported books from a parallel NKC bibliographical database. You can suggest other criteria. Every import job takes some time to prepare so I do them in larger bulks. It also always brings a risk of creating new duplicates with preexisting items in Wikidata, which I don't like nothing is 100 %.

@Vojtěch Dostál: Děkuji mnohokrát. Would be nice to have those having an ISNI, then probably more cross-references can be found. Maybe you can download all WD Q5 ISNI that do not have NKC ID in WD (or use OPTIONAL NKC) and check which of these ISNI are in NKC DB - so more NKC IDs can maybe be matched to existing objects - but maybe this is already done. The other part is to add ISNI humans from NKC to WD. ISNI for a NK CR DB human that is not in WD would be nice to have. Two tasks:

1. add NKC ID to WD ISNI humans - maybe already done
2. create new ISNI humans in WD based on NKC ISNI humans.

Yeah, 1 has recently been done. Always new cases appearing, of course, but I can't do this every week.

I'll consider uploading all people in NKC which have either ISNI or ORCID ID in NKC and are not in Wikidata yet.

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

Do you control your automated edits via constraint violation checks, or do just dump data and let others fix?

Thanks, i'll merge this. But this is two records in external db ... maybe its better to make two records. Do you agree?

Sorry, I made a mistake. No shared ID on the items. So, maybe not the same. Independent of that, my above text wasn't justified.

father and son, I will adjust

Q127163915 - why?

Maybe, because i did not find the correct Allan House, i am sorry. There are 100 millions items.

But they have the same ISNI, this has nothing to do with "100 millions items" - there was only one other having that ISNI.

Q124623773 - why?

Hello Frettie! It looks like you are commonly setting the "sex or gender" property based on the grammatical gender used for a person at the Czech National Authority Database. While this usually works fine, it causes errors for non-binary people, as the Czech language only uses 2 grammatical genders for people. I'm not sure if there is any good solution for this other than not setting "sex or gender". It may be better to wait and let someone set it based on a better reference.

Hi @Nosferattus – do you have some examples of non-binary people of Czech National Authority Database? I'll check it and i want to make it better! Thanks! --~~~~

Here are a few examples:

• https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=mub20211105782 (spisovatelky)
• https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=xx0304540 (spisovatelky)
• https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=mub2015867526 (spisovatel and spisovatelé)

The first example is Kate Bornstein who has identified as non-binary for a decade or so and is very well-known for being non-binary. For the other two, it's possible their gender identity wasn't known or was different when the entries were created.

Hi, hm, there are problems in authority DB of National Library and / or czech language (spisovatelky/spisovatelka as women/woman, spisovatelé/spisovatel as men/man). So when i looked at Kate Bornstein – There is merged itemhttps://www.wikidata.org/w/index.php?title=Q105970034&oldid=1382886499 – and there is only date and NK ČR ID. If you look at MARC record detail (https://aleph.nkp.cz/F/B99JQS1NUPLPMRIQTBFC75NCKUK21JF9X77CDCB9481GN1SPYV-42677?func=full-set-set&set_number=057357&set_entry=000001&format=001) – there is field 375a – žena (woman). So if there is not filled or there is not "žena" or "muž", there is not filled.

We can discuss methodology with NKČR – but there is actually not gender set to non-binary people – you can check this – https://autority.nkp.cz/jmenne-autority/metodicke-materialy/metodika-jmena-cvicne-2#pole375

But i can check it when i creating items manually and some time by descriptions unset gender or set it corrected. Thanks!

Thanks for looking into it! It's good to know that NKČR isn't explicitly setting gender in these cases. The edit that brought this issue to my attention was actually where you created the item for A. K. Mulford. In that edit, P21 is set to female with the reference given as https://aleph.nkp.cz/F/?func=find-c&local_base=aut&ccl_term=ica=xx0304540. Do you think that was just based on the grammatical gender of spisovatelky? No criticism intended, just hoping to figure out how to avoid these errors in the future :)

Hi, no, its based by men / women in 375a MARC field. So in our tables (Wikidata:WikiProject Czech Republic/New authorities) are descriptions, where some details are appended – sometime there are info about pseudonymes etc, maybe there will be some info about gender. After this, ill correct it after create.

Hi @Nosferattus – what do you think about this new created item – Q130339912 – its created from NK ČR authorities and there is not filled gender (in NK ČR DB). Is it correct?

Yes, that looks correct. Thanks for explaining to me about 375a. I will look for that in the future and send NKČR requests for corrections when needed. Cheers!

Solved as of now; to be repeated periodically in the future using the query now stored in Wikidata:WikiProject Redundancy

Hi! We have nearly 500 items (I have already fixed about 20 manually) which have the same identificativo NKC (P691) repeated twice, one time with soggetto indicato come (P1810) and the other time usually without it; https://w.wiki/AuLf. Could your bot fix massively these cases periodically? Thanks in advance! FYI @Vojtěch Dostál:

Hi! I think these six should be sorted out manually: https://w.wiki/AuWg

I will use Wikibase-Cli to remove the others remaining. I can't automate this job (run it periodically) - unfortunately, I don't have the skills.

Solved manually these 6; thanks in advance for the others!

All should be done now, thanks for reporting the problem.

Hi! I see a few cases in which occupazione (P106)papa (Q19546) has been added by FrettieBot with source NKC; however, this is redundant in comparison with carica ricoperta (P39)papa (Q19546), which also has the qualifiers for start end etc. I have removed the P106 statements; could you assure they won't be added again? Thanks as always!

Hi @Epìdosis – i think, that it is ok already – for popes and some other "in function" cases there is existing solution.

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.