User talk:Bargioni/moreIdentifiers

From Wikidata
Jump to navigation Jump to search

Bug BNE[edit]

@Epìdosis, Bargioni: "0" https://www.wikidata.org/w/index.php?title=Q318347&diff=prev&oldid=1196501498 MrProperLawAndOrder (talk) 00:57, 2 June 2020 (UTC)[reply]

@Bargioni, Epìdosis, Kolja21: ouch, that is ugly. Maybe BNE passed it to them and later fixed it. Maybe more BNE have that bug. Anyway, no regex active in VIAF. I will mention it on Wikidata:VIAF/cluster/containing invalid source ID. MrProperLawAndOrder (talk) 09:46, 2 June 2020 (UTC)[reply]

no missing identifiers from this cluster[edit]

Q8962158#identifiers - ISNI and BNE are missing. And a lot of false IDs are there, needing lessIdentifiers.js MrProperLawAndOrder (talk) 01:57, 4 June 2020 (UTC)[reply]

@MrProperLawAndOrder: The gadget is programmed for not adding an identifier if one or more values of it (also different) are already present; if false IDs are present, they need to be removed first. --Epìdosis 06:54, 4 June 2020 (UTC)[reply]
It could maybe show conflicting data. MrProperLawAndOrder (talk) 07:44, 4 June 2020 (UTC)[reply]

Q2409128#identifiers : 

VIAF cluster 166694015
NUKAT: vtls005733705 Popov, Dušan. ⚡
SUDOC: 22846210X Popov, Dušan. ⚡

VIAF cluster 111265087
DNB: 118595776 Popov, Duško 1914-1981 ⚡
J9U: 987007355040505171 Popov, Duško ⚡
LIH: LNB:CnJE;=BW Popov, Dušan (1912-1981) ⚡
NSK: 000182975 Popov, Duško ⚡
PLWABN: 9810606367905606 Popov, Dušan (1912-1981) ⚡
RERO: vtls000132230 Popov, Duško ⚡
SUDOC: 180639595 Popov, Dušan (1912-1981) ⚡

After SUDOC from 2nd VIAF has been added, the other SUDOC disappeared. MrProperLawAndOrder (talk) 16:57, 13 June 2020 (UTC)[reply]

@MrProperLawAndOrder: The gadget is programmed for not adding an identifier if one or more values of it (also different) are already present; if you add the first SUDOC and refresh the page, the gadget sees that one SUDOC is already present in the page and doesn't show the second SUDOC. --Epìdosis 17:04, 13 June 2020 (UTC)[reply]
And this behavior is a misleading. MrProperLawAndOrder (talk) 17:12, 13 June 2020 (UTC)[reply]
I don't think so, it is clearly stated in the instruction page: "Remember that moreIdentifiers only shows properties not already present in the item". So if a property is already present, it won't be shown. --Epìdosis 17:15, 13 June 2020 (UTC)[reply]

Bug LIH[edit]

https://www.wikidata.org/w/index.php?title=Q96074977&diff=1199572682&oldid=1199572678 , coming from https://viaf.org/viaf/4500150470094004330009/justlinks.json ... link does not resolve. MrProperLawAndOrder (talk) 14:36, 5 June 2020 (UTC)[reply]

not a MI bug, in VIAF the link goes to
but justlinks has
  • "LIH":["LNB:2bf;=Ba"],
MrProperLawAndOrder (talk) 14:47, 5 June 2020 (UTC)[reply]
Very interesting, you have rightly opened a discussion in the talk of National Library of Lithuania ID (P7699); we can choose there which form of the ID is more convenient for us to keep, personally I would prefer the form in justlinks.json as it is the one used by their website. --Epìdosis 19:26, 5 June 2020 (UTC)[reply]
✓ OK Just a little update here: the discussion has finished and we decided to keep the values of justlinks; all the values have already been corrected in the items. --Epìdosis 17:42, 13 June 2020 (UTC)[reply]

DNB → GND[edit]

Hi Bargioni, can you change DNB into "GND"? The GND is not only a project of the German National Library (DNB). Also it would be helpful if the script would provide a link to the authority files. --Kolja21 (talk) 03:33, 13 June 2020 (UTC)[reply]

@Kolja21: Hi! The criterium is that we use the code use by VIAF, and VIAF uses "DNB" for GND. We can reflect about providing a link to the authority file, probably it's not too difficult. --Epìdosis 09:32, 13 June 2020 (UTC)[reply]
I know the VIAF code. VIAF even changes GND's with dashes. [1] But to avoid confusion with DNB edition ID (P1292) imho an other label would be helpful. What about "DNB/GND"? --Kolja21 (talk) 13:05, 13 June 2020 (UTC)[reply]
The visualized code is based on the qualifier of Property:P227#P1552, which is "DNB"; changing "DNB" in something different, the gadget wouldn't be able to read anymore the code from VIAF. So I think it's impossible to change. --Epìdosis 14:01, 13 June 2020 (UTC)[reply]
@Kolja21: ✓ Done links to the entries just added by @Bargioni:. --Epìdosis 17:41, 13 June 2020 (UTC)[reply]
@Kolja21: The name of the VIAF source is DNB. Exactly because the GND is not only a project of DNB, we have to identify the source of the... identifier :-) At the same time, hovering the DNB label, or any other source code in MI, a tooltip appears with the label of GND ID (P227) in your language. In English, "GND ID". -- Bargioni 🗣 19:29, 13 June 2020 (UTC)[reply]

Some suggestions[edit]

  1. Have a quicklink to the script in the sidebar on the left via mw.util.addPortletLink. Avoids needless scrolling.
    The starting point of Identifiers section can be reached clicking J having KeyShortcuts activated in Preferences --Epìdosis 19:45, 13 June 2020 (UTC)[reply]
  2. Fix RERO and NUKAT, both are currently broken in the script. :)
    ✓ Done RERO; see underneath for discussion about NUKAT --Epìdosis 21:10, 13 June 2020 (UTC)[reply]
  3. LIH/LNB is still shown twice, somehow. Might want to fix that.
     Not done same for BNC/BNCHL, it is an error in VIAF JSONs; see underneath --Epìdosis 19:45, 13 June 2020 (UTC)[reply]
    I saw there is some commented code in moreIdentifiers_system_regex.js which should have dealt with this. But I guess VIAF fixing their justlinks output for LIH/LNB and BNC/BNCHL should be the optimal choice. --Sotho Tal Ker (talk) 00:29, 14 June 2020 (UTC)[reply]
  4. An advanced mode would be nice. Things I consider possible: Check current values against links provided by VIAF. Existing values could be marked green (and collapsed by default), different values could be marked yellow. Add some external links for a few values that can be manually added when VIAF participants replaced identifiers (NLP, NLI, LAC) or additional values can be gotten (CCAB, NLA Trove). I still keep and maintain my fork of the authority_control.js originally by Magnus_Manske [2]. The main difference is that this script does not rely on already present VIAF entries for an item, but checks name and birth/death against VIAF directly, which works OK in most cases. --Sotho Tal Ker (talk) 15:10, 13 June 2020 (UTC)[reply]
  5. Oh, one I forgot: Since the names are already shown next to the entries, one could likely add those claims with the additional "named as" qualifier. --Sotho Tal Ker (talk) 15:17, 13 June 2020 (UTC)[reply]
     Not done see the reasons underneath --Epìdosis 19:45, 13 June 2020 (UTC)[reply]
Sotho Tal Ker, thank you!
@1 Scrolling is issue for me too.
@2 confirmed.
@3 LIH is Lithuania (Lietuvos nacionalinė Martyno Mažvydo biblioteka https://www.lnb.lt) and LNB is Latvia (Latvijas Nacionālā bibliotēka https://www.lnb.lv), each locally LNB. VIAF messed it up with their codes, they could have used country codes in front of local codes, or using ISIL.
@4 replace or remove could be helpful. Could conflict with the name "moreIdentifiers".
MrProperLawAndOrder (talk) 17:07, 13 June 2020 (UTC)[reply]
What I mean with the third point is behavior like this [3] when both LIH and LNB are missing. It is basically just a display issue, since you cannot add "unfit" IDs. --Sotho Tal Ker (talk) 17:25, 13 June 2020 (UTC)[reply]
Sotho Tal Ker, thanks, so in line 3 of the screenshot the LIH value (Lithuania) is shown under the LNB partner ID (Latvija). Checking the source https://viaf.org/viaf/14770699/justlinks.json:
"LIH":["LNB:V*7853;=BJ"],
"LNB":["LNC10-000043754","LNB:V*7853;=BJ"],
Yet another bug in VIAF. Maybe they got confused by the "LNB" string inside LIH source code. MrProperLawAndOrder (talk) 17:36, 13 June 2020 (UTC)[reply]
@MrProperLawAndOrder, Sotho Tal Ker: Of course it is a confusion in VIAF: it happens both with LIH/LNB (due to the "LNB" present in LIH) and with BNC/BNCHL (due to the "BNC" present in BNCHL). I want to thank Sotho Tal Ker for his suggestions, we will briefly consider point 5 which is probably the easiest and is a very clever idea; regarding point 1, if you have activated the gadget KeyShortcuts in the Preferences you can just get at the starting point of Identifiers section clicking J; we will try in the next days to have a look at other points and of course we will post updates here. --Epìdosis 17:47, 13 June 2020 (UTC)[reply]
Regarding NUKAT, this does not seem to be an easy fix, as we currently store the "wrong" value. Let me use Wilhelm Grimm as example again. VIAF stores the value from MARC field 010 [4] as main value when browsing an entry via the web. This "n93090046" is what we store in VIAF aswell. But you can search the NUKAT catalogue directly with the value stored in MARC field 035 by removing the "vtls" [5]. justlinks.json has it correctly. I guess this means we need to change another identifier... --Sotho Tal Ker (talk) 17:54, 13 June 2020 (UTC)[reply]
@Sotho Tal Ker: Very interesting guess about NUKAT, I perfectly agree with you! Of course, after the proposal and creation of the new property, I and Bargioni can guarantee the addition of all the values. Regarding point 5: probably is better not to add the qualifier "named as" for the following reason: often VIAF attaches to the name used by the national library the birth-death date, which some national libraries effectively consider part of the title of the entry (e.g. BNF, LCNAF), while others not (e.g. GND). Being it difficult to understand in general when the title of the entry is altered by VIAF, it is probably better not to add the qualifier. --Epìdosis 17:59, 13 June 2020 (UTC)[reply]
Not a big deal regarding the "named as". :) For NUKAT is the question, what do we want: 2 properties or the old one updated, breaking third party usage. Regarding RERO IDs, this is an easy fix, just replace vtls with 02-A for anything that is not a book or magazine (which is not covered by this script anyway) in moreIdentifiers_system_regex.js: 'RERO': { 'regexp':/^vtls/, 'repl': '02-A' } --Sotho Tal Ker (talk) 18:08, 13 June 2020 (UTC)[reply]
@Sotho Tal Ker: Great, the RERO fix will be enabled very soon. Regarding NUKAT: probably better to create a new one (see NSZL (VIAF) ID (P951) and NSZL name authority ID (P3133); a similar discussion is ongoing about Slovak National Library (VIAF) ID (P7700), waiting for a clear response from SKMASNL). --Epìdosis 19:37, 13 June 2020 (UTC)[reply]
@Sotho Tal Ker: RERO just fixed, now works. --Epìdosis 21:10, 13 June 2020 (UTC)[reply]

Errors[edit]

This script is one of the reasons for systematic errors, see e.g. Q96107618. There is a reason why I created the item and the reason is simply because the VIAF cluster merges serveral different persons. It is absolutely disturbing to see that the mistakes are being semi-automatically re-introduced. Maybe this script should be disabled? Mautpreller (talk) 18:30, 13 June 2020 (UTC)[reply]

More specifically: The script ignore the ranks. @MrProperLawAndOrder: FYI. --Kolja21 (talk) 19:25, 13 June 2020 (UTC)[reply]
@Mautpreller: No ID is automatically inserted by this script: the user using it chooses which IDs are correct and inserts them through the script, so the error is by the user, not by the script. But yes, it is correct that at the moment the script ignores the presence of deprecated rank, we will remedy it soon. --Epìdosis 19:30, 13 June 2020 (UTC)[reply]
@Epìdosis: Mautpreller had inserted the VIAF ID and marked it is deprecated and the cluster as conflated. MrProperLawAndOrder (talk) 19:34, 13 June 2020 (UTC)[reply]
It should be fixed, not disabled. MrProperLawAndOrder (talk) 19:32, 13 June 2020 (UTC)[reply]
It's exactly what I said: the script should ignore VIAF ID (P214) values having deprecated rank. --Epìdosis 19:35, 13 June 2020 (UTC)[reply]
It should not be used again before this is fixed. Mautpreller (talk) 19:36, 13 June 2020 (UTC)[reply]
User:Epìdosis, when an item has 20 sources in a given moment and one is wrong, then some user may claim deprecated and conflated. If that source is removed later on, the deprecated rank may stay, even if the conflation doesn't exist anymore. MrProperLawAndOrder (talk) 20:20, 13 June 2020 (UTC)[reply]
@MrProperLawAndOrder: I agree, it is a true problem related to the deprecation of conflated clusters. --Epìdosis 20:23, 13 June 2020 (UTC)[reply]
Yes but it is a real problem. I invested considerable effort to separate the identities that are conflated in the VIAF cluster, and now the wrong links came back again by way of this script. This cannnot be okay. Why, then, should I do anything to correct data? This seems like a Sisyphus work. I think the clusters should be reviewed regularly to check if the problem still exists. But it is most important to avoid wrong data, in my opinion. Mautpreller (talk) 20:43, 13 June 2020 (UTC)[reply]
"But it is most important to avoid wrong data, in my opinion." - the best way to achieve this is to not have any data at all. MrProperLawAndOrder (talk) 21:12, 13 June 2020 (UTC)[reply]
Simple thing: This version has undeniably "more data" than that one. But all additional data demonstrably refer to the wrong person. So in this case the version with less data is better than the version with more data. Maybe one should also consider that there had been absolutely no data concerning this person on Wikidata before I created and filled this item.Mautpreller (talk) 11:00, 14 June 2020 (UTC)[reply]
@Mautpreller: I fixed the bug in MI about deprecated VIAFs. They are no longer present in the box. I tested it with Q96107618 only, anyway. -- Bargioni 🗣 20:51, 13 June 2020 (UTC)[reply]
@Mautpreller: Fixed correctly. -- Bargioni 🗣 10:21, 14 June 2020 (UTC)[reply]
THX. I think this is better because mistakes are avoided. This is, in my view, much more important than to add as many identifiers as possible. The benefit of identifier multiplication is small, the damage of inserting wrong data is big. Mautpreller (talk) 21:06, 13 June 2020 (UTC)[reply]
Great for vandals, claim conflation and the ID is hidden from some tools but not others. MrProperLawAndOrder (talk) 21:12, 13 June 2020 (UTC)[reply]
But the VIAF I talked about is conflated. I am not a vandal but simply a user who is interested in correct information. I invested some work to correct wrong authority links. I should think that is in the interest of the project. And I should think that it is against the interest of the project to revert this work, to undo it.Mautpreller (talk) 21:21, 13 June 2020 (UTC)[reply]
Mautpreller, not sure what you mean by "the VIAF I talked about" - a cluster at a given point in time? Or a cluster over the whole lifetime, identified by a VIAF ID? For the latter it could be that it isn't conflated anymore. MrProperLawAndOrder (talk) 22:12, 13 June 2020 (UTC)[reply]
Yes, I meant the VIAF as it is now. If the cluster is separated or re-grouped end of the month, maybe the conflation will be removed. I'll check beginning of July and remove the deprecation if the problem is solved. But I think that the clusters should be generally checked in regular intervals.Mautpreller (talk) 09:07, 14 June 2020 (UTC)[reply]
As explained above this removes sources from the menu even if they are correct. MrProperLawAndOrder (talk) 21:07, 13 June 2020 (UTC)[reply]
Yes but this is exactly the question: Is it most important to have good data or is it most important to have many data? My opinion is that quality is much more important than quantity. See also my idea on Wikidata talk:VIAF to store the exact nature of the conflation in the items, also with exact date.Mautpreller (talk) 21:10, 13 June 2020 (UTC)[reply]
@Mautpreller: Or neither. In some situations some may prefer a data set having a billion correct claims and one incorrect claim over a data set containing one correct claim and no incorrect claim. MrProperLawAndOrder (talk) 22:09, 13 June 2020 (UTC)[reply]
Maybe. But I don't think you see the full problem. If it only were for an incorrect claim among many correct ones, I could agree with you. But not if this incorrect claim is being propagated and multiplied on and on by using a script indiscriminately. This is what wreaks havoc in the system. Mautpreller (talk) 09:07, 14 June 2020 (UTC)[reply]
Mautpreller, in Wikidata please don't share your thoughts about characteristics of users if they could put that user in a bad light and you have no proof for these characteristics being true. MrProperLawAndOrder (talk) 04:59, 15 June 2020 (UTC)[reply]
@Mautpreller: Just a little update: there was a problem in the fix, so we suspended it momentaneously and tomorrow we will have a look to finally solve it. Anyway, the instructions say clearly "moreIdentifiers helps you to add properties whose quality depends on you, of course. Please verify what you save: VIAF links may contain errors, or modifications applied by moreIdentifiers can be wrong". So, the user should always verify if a cluster, deprecated or not, contains any errors and it always his responsibility not to add incorrect IDs. See you soon for updates. Good night, --Epìdosis 21:17, 13 June 2020 (UTC)[reply]
@Mautpreller: Finally ✓ Done, now deprecated P214 are correctly not shown in MoreIdentifiers. Bye, --Epìdosis 09:33, 14 June 2020 (UTC)[reply]
Thanks a lot.Mautpreller (talk) 11:03, 14 June 2020 (UTC)[reply]
@Epìdosis, Bargioni, Kolja21, Mautpreller: this reduces the usefulness of the script and may result in even more errors being inserted: some could be tempted to think less, if a a VIAF isn't deprecated, but that it isn't deprecated doesn't mean every source in the cluster refers to the human in the item. And many good values aren't inserted, because the data is hidden from the user. More and more hacks in this tool that hide information and take away control from the user. MrProperLawAndOrder (talk) 04:36, 15 June 2020 (UTC)[reply]
@Epìdosis, MrProperLawAndOrder, Kolja21, Mautpreller: From now, deprecated clusters are not hidden. A red warning is shown, and any ID can be added to the item. -- Bargioni 🗣 10:49, 15 June 2020 (UTC)[reply]
@Epìdosis, Bargioni, Kolja21, Mautpreller: thank you! Thanks to all of you for working and discussing this issue. MrProperLawAndOrder (talk) 22:27, 15 June 2020 (UTC)[reply]

Bug ISNI[edit]

The tool shows "0000 0000 1488 9307", clicking the label, to verify if the ISNI is related to the human, one arrives at https://isni.org/isni/0000%200000%201488%209307 and is redirected to https://isni.org/isni/0000%200000%201488%209307/ - Page Not Found. This bug seems to exist since inception of the tool. The ISNI to use for linking should be the no-space ISNI. The spaces are an issue in WD at least since 2013. Epìdosis suggested to not fix it at the root now even after consensus has been reached, but to wait a week. Delay looks like more work for users of P213. MrProperLawAndOrder (talk) 22:50, 13 June 2020 (UTC)[reply]

Strategic planning - viafIdentifiers[edit]

Proposal to rename:

  1. Add More Identifiers from VIAF / Manage VIAF identifiers (cluster and source)
  2. moreIdentifiers / viafIdentifiers

That would allow to add functions:

  • remove source ID
  • change rank and qualifiers of cluster ID
  • change rank and qualifiers of source ID

MrProperLawAndOrder (talk) 04:20, 16 June 2020 (UTC)[reply]

Additional properties that can be inferred from VIAF values[edit]

As seen with NUKAT and NSZL & SKMASNL, some values are stored differently in VIAF than in the original authority records. Sometimes values in VIAF get replaced with a different one (NL of Poland, Canada and Isreal did this). And sometimes additional authority records can be linked. I just put a list of what is stored in VIAF and which other properties could be inferred from that. If and how you implement that link is up to you:

  1. Libraries Australia ID (P409) View with SQID -> NLA Trove people ID (P1315) View with SQID: Trove is the second catalog of the NLA. It can be searched with the value stored in VIAF and produces usually an unique match to a Trove ID for persons and organizations.
  2. Canadiana Name Authority ID (P8179) View with SQID -> Canadiana Authorities ID (former scheme) (P1670) View with SQID: The older entries have been withdrawn from VIAF and got replaced by the new NCF ID. This has happened in conjunction with the switch by Canadiana to NACO/their own database. The old entries can still be gotten from field 016 from the MARC-21 record. Basically obsolete, as the old links are dead, but should still be added for completeness.
  3. PLWABN ID (P7293) View with SQID -> NLP ID (old) (P1695) View with SQID: The NLP also withdrew the old entries from VIAF and replaced them. Most PLWABN values contain the old NLP value in field 035 of the VIAF MARC-21 record.
  4. National Library of Israel J9U ID (P8189) View with SQID -> National Library of Israel ID (old) (P949) View with SQID: The NLI also withdrew their entries and replaced them with new longer values. The old value is still stored in field 035 of the VIAF MARC-21 record.
  5. National Library of Chile ID (P7369) View with SQID -> CCAB ID (P1890) View with SQID: CCAB was initially proposed as VIAF component, but it actually is not. Thus the newer BNCHL property was created. Values from the CCAB catalog are usually accessable via field 035 from the VIAF MARC-21 record. Stored values need to be truncated to the last 9 digits.
  6. NSZL (VIAF) ID (P951) View with SQID -> NSZL name authority ID (P3133) View with SQID: VIAF stores a different value than the actual catalog. Nektar catalog number is stored in field 035 of the VIAF MARC-21 record.
  7. NUKAT ID (P1207) View with SQID -> not created yet: VIAF stores a different value than the actual catalog. NUKAT internal number is also stored in field 035 of the VIAF MARC-21 record, just remove the vtls.
  8. Slovak National Library (VIAF) ID (P7700) View with SQID -> not decided yet how to proceed: The two catalogs are not linked via the MARC-21 records, but I expect a 1-to-1 match. The corresponding Koha catalogue has to be searched by name.

--Sotho Tal Ker (talk) 00:03, 24 June 2020 (UTC)[reply]

Bug with LIH/LNB: Valid ID cannot be added[edit]

Example on Q144535. The valid LNB identifier cannot be added because the box is disabled. Likely due to the wrong LIH value above it, which was disabled. --Sotho Tal Ker (talk) 13:19, 28 June 2020 (UTC)[reply]

Yes, I remember having seen it sometimes: it happens only when the correct value follows the wrong value, and happens also with BNC/BNCHL. We will investigate :) --Epìdosis 13:21, 28 June 2020 (UTC)[reply]
I left it open as an example. Why not uncomment the stuff in User:Bargioni/moreIdentifiers_system_regex.js that deals with these wrong values by filtering them out. With a quick look I do not see much of a problem there. :) --Sotho Tal Ker (talk) 18:11, 28 June 2020 (UTC)[reply]
✓ Solved. --Epìdosis 10:03, 1 July 2020 (UTC)[reply]

GND entries need to be manually checked before adding[edit]

GND entries need to be manually checked before adding, if they are of type "Person" or of type "Name". The latter are usually placeholder entries for names and should not be used in Wikidata, therefore also not added. See the German Wikipedia for more information regarding the differences (of course in german): de:Hilfe:GND#Wichtige_Unterschiede_bei_GND-Datensätzen. While VIAF does differentiate them via the usual display and in the main json (i.e. [6], the justlinks.json used by moreIdentifiers does not. --Sotho Tal Ker (talk) 18:26, 30 June 2020 (UTC)[reply]

In July 2020 these undifferentiated records were removed from GND. Are they still found in VIAF? Pyfisch (talk) 13:22, 17 November 2020 (UTC)[reply]
@Pyfisch: I recall having found some recently, probably they are still in; hopefully they will be removed soon, very good news. --Epìdosis 18:04, 17 November 2020 (UTC)[reply]

P3280 has changed format[edit]

BAnQ authority ID (P3280) View with SQID has changed format. Before it were 10 digits, starting with zeros. Now they seem to have switched to the same NCF format that the Library and Archives Canada (LAC) uses. Previous values have been pulled from VIAF and new values have been uploaded, see for example history of [7]. Just leaving this as a note here, as this script. I will open a discussion on the property aswell. --Sotho Tal Ker (talk) 22:31, 8 July 2020 (UTC)[reply]

Rare error message while loading page[edit]

Sometimes when loading a page , I get the following error:

Uncaught (in promise) ReferenceError: moreIdentifiers_props is not defined

at moreIdentifiers_addinterface (index.php?title=User:Bargioni/moreIdentifiers.js&action=raw&ctype=text/javascript:276)

at index.php?title=User:Bargioni/moreIdentifiers.js&action=raw&ctype=text/javascript:605

--Sotho Tal Ker (talk) 21:15, 18 July 2020 (UTC)[reply]

Warn about duplicated identifiers[edit]

Sometimes multiple people are conflated, or there are multiple items for one person on Wikidata. This results in errors like Special:Diff/1271140626, where a GND-ID was wrongly added to the item because it was incorrectly contained in the VIAF cluster. I propose that the script checks using the Linked Data Fragments Server, whether a given identifier is already present on another item. If the identifier is already present a warning should be displayed next to the line and the script should refuse to add this identifier to the item. Example: Query for GND=120436051. --Pyfisch (talk) 10:23, 16 November 2020 (UTC)[reply]

@Pyfisch: I agree, but I think the easiest way to do this check is just reloading the item and see if there are unique-value constraint violations. Embedding the unique-value constraint check into the gadget would be far more difficult. --Epìdosis 20:48, 9 January 2022 (UTC)[reply]

CYT[edit]

recently created CYT/CCS (P10307) ( CYT component of VIAF) didn't show in the checkbox. I have labeled the former NCL ID (P1048) as a fake CYT component of VIAF.

Take Bing Xin (Q374757) as an example, this item has a ```CYT AC000211345``` property, but the check box didn't show the CYT part.

Could you please have a look? @Bargioni Kethyga (talk) 07:59, 1 February 2022 (UTC)[reply]

@Kethyga: moreIdentifiers requires that in the property the (e.g. P10307) the format as a regular expression (P1793) for the format is present not only in the constraint, but also as main value; now added, it works well. Thanks for reporting, --Epìdosis 09:17, 1 February 2022 (UTC)[reply]
Got it. Thanks. Kethyga (talk) 09:29, 1 February 2022 (UTC)[reply]

cryptic error message[edit]

@Bargioni: Hi, a lot of times the script doesn’t work for me, error code Uncaught (in promise) ReferenceError: moreIdentifiers_props is not defined at moreIdentifiers_addinterface (Google Chrome on Mac). I used to fixe those problems by deactivating CORS with a Chrome extension but that doesn’t seem to work lately. Do you have any idea what I might try to do? Thanks! --Emu (talk) 08:40, 5 May 2022 (UTC)[reply]

@Emu: If I'm not wrong, your https://www.wikidata.org/wiki/User:Emu/common.js doesn't include
  importScript( 'User:Bargioni/moreIdentifiers_defaultconf.js' );

Please add this line before moreIdentifiers.js'. -- Bargioni 🗣 09:50, 5 May 2022 (UTC)[reply]

@Bargioni Thank you! It seems to work! --Emu (talk) 11:22, 5 May 2022 (UTC)[reply]

Enabling WikidataComplete gadget breaks moreIdentifiers[edit]

As the title days, if the Wikidata:WikidataComplete gets enabled via common.js, moreIdentifiers does not show up above the identifiers section. I guess it has something to do with how WikidataComplete adds its own section to the page. Maybe someone could have a look at it from the moreIdentifiers side, if this can rectified in this script. Possibly User:Bargioni/personal_sort_identifiers.js is affected aswell. --Sotho Tal Ker (talk) 13:02, 10 July 2022 (UTC)[reply]

You are right :-| I hope to find the cause, and a solution too.  Bargioni 🗣 14:16, 10 July 2022 (UTC)[reply]
Please try to delay loading WikidataComplete using instead
setTimeout(function(){
importScript('User:Data-Complete-Gadget/WikidataComplete.js');
}, 2000);
in your common.js. This is a workaround, anyway. But let me know. Thx.  Bargioni 🗣 14:39, 19 August 2022 (UTC)[reply]

Doppi import[edit]

Ciao Bargioni, oggi usando moreidentifiers ho notato che il gadget importa gli identificativi per due volte, e ho anche notato che la view del gadget viene visualizzata a doppio. Ne sei al corrente? Mastrocom (talk) 13:53, 19 August 2022 (UTC)[reply]

Non direi: guarda per esempio la cronologia di Ramon Bidagor (Q65594009) e R. Duane Thompson (Q104771714), in cui ho usato moreIdentifiers.
Se hai qualche esempio, passamelo, per favore.
Se mai, tieni presente che devi togliere le spunte a quelli già fatti, se ne fai altri senza ricaricare prima la pagina.  Bargioni 🗣 14:23, 19 August 2022 (UTC)[reply]
Mi pare strano, non sto riscontrando alcun problema di duplicazione. --Epìdosis 19:04, 19 August 2022 (UTC)[reply]
In pratica la finestrella del gadget mi compare due volte, e ogni identificativo sotto al cluster VIAF viene visualizzato due volte, tant'è che devo spuntare solo le prime occorrenze per evitare ripetizioni invece che spuntare tutto il cluster come faccio di solito Mastrocom (talk) 12:47, 20 August 2022 (UTC)[reply]
Un esempio a caso, in questo item Maria Cristina Assumma (Q105688943) ho spuntato il cluster e mi ha importato il GND due volte, poi ho dovuto togliere io la ripetizione come si vede dalla crono. Per evitare la ripetizione, avrei dovuto selezionare solo uno dei due GND che mi compaiono (questo mi succede da ieri) Mastrocom (talk) 12:56, 20 August 2022 (UTC)[reply]
@Mastrocom: penso sia dovuto al fatto che nel tuo common.js MI compare due volte; prova a togliere le righe 9 e 21, potrebbe sistemarsi. --Epìdosis 18:16, 20 August 2022 (UTC)[reply]
@Epìdosis: grazie, problema risolto. Non riesco a capire come mai il problema si sia presentato solo ieri, visto che non toccavo il mio common.js da una vita. Ad ogni modo grazie ancora --Mastrocom (talk) 19:05, 20 August 2022 (UTC)[reply]
I also had duplicate additions. Asterix2023 (talk) 23:32, 25 October 2023 (UTC)[reply]
@Asterix2023: More details are needed to investigate the issue. Thanks, --Epìdosis 06:26, 26 October 2023 (UTC)[reply]

FAST Import[edit]

It seems as FAST import is broken. See e.g. Q571922, Q7072, Q61928 or many other towns. To enable it for Geographic records, I added moreIdentifiers_props.accepted_P31.includes=function(){return true} before the moreIdentifiers import. I once had a fix for this here, it may give an idea how to handle it. Kind regards, --Frlgin (talk) 19:00, 31 January 2023 (UTC)[reply]

Bug ISNI missing but no missing identifiers from this cluster[edit]

John Stonehouse (Q1639223) in the moreidentifiers section it shows: 

VIAF cluster 1444942
no missing identifiers from this cluster
VIAF cluster 11001538
no missing identifiers from this cluster

But https://web.archive.org/web/20231025232317/https://viaf.org/viaf/1444942/ contains https://isni.org/isni/0000000034600697 which is not in the item. The LC value of that cluster is in the item. Asterix2023 (talk) 23:28, 25 October 2023 (UTC)[reply]

@Asterix2023: This is intentional, I added a phrase to the manual to make it clearer: "if the item contains more VIAF clusters, and each VIAF cluster contains an ID by VIAF member X, and the item also contains one ID of VIAF member X, moreIdentifiers will not give the option to add IDs of VIAF member X from VIAF". --Epìdosis 06:33, 26 October 2023 (UTC)[reply]

Bug ISNI missing despite statement no missing identifiers from this cluster 2023-11-18[edit]

Ignaz Lindl (Q101217) in the moreidentifiers section it shows: 

VIAF cluster 32763187
no missing identifiers from this cluster
VIAF cluster 7325162669466455500004
no missing identifiers from this cluster

But https://web.archive.org/web/20231118143519/https://viaf.org/viaf/7325162669466455500004/ contains https://isni.org/isni/0000000500233362‏ which is not in the item. The LC value of the ISNI cluster, the only id, is in the item. ISNI description refers to Wikipedia: "German Wikipedia, March 29, 2019 (Ignaz Lindl; b. October 3, 1774 in Ried bei Mering, Germany; d. October 31, 1845 in Barmen; Catholic priest; evangelist in Russia and Bessarabia (modern Ukraine); founded, with his followers, Sarata, a settlement of Bessarabian Germans, in 1822)"

Asterix2023 (talk) 14:39, 18 November 2023 (UTC)[reply]

22-digit VIAF numbers[edit]

Hello, it seems to me, there is a problem with "long" 22-digit VIAF numbers. It worked but since recent time the identifiers do not load. Sincerely –Gumruch (talk) 13:54, 21 February 2024 (UTC)[reply]

Hi @Gumruch:, could you provide one or two examples so that we can investigate the issue? And thanks for reporting! Epìdosis 23:38, 22 February 2024 (UTC)[reply]
@Epìdosis:Hi, I noticed it recently twice: Ella Yevtushenko (Q23659387) and Anna Zak (Q29554348). The blue box appears, the VIAF cluster with number appears inside it, but seems to be freezed in the middle and no identifier loads nor an error message appears. Anyway great tool, many thanks. –Gumruch (talk) 14:48, 23 February 2024 (UTC)[reply]

not charging[edit]

is it me or the tool isn't charging since a day or 2 ? Simon Villeneuve (talk) 18:27, 7 March 2024 (UTC)[reply]

@Simon Villeneuve: other users have reported me that, in this day, both this and other gadgets have more difficulties in loading; I haven't had significant issues, but it may be a temporary problem of loading regarding all the gadgets. Epìdosis 08:57, 8 March 2024 (UTC)[reply]
All my others tools are working. Simon Villeneuve (talk) 12:34, 9 March 2024 (UTC)[reply]
Ok, I've found the problem. It seems to be related to this tool. Now that I have suppressed it, I can see again my moreidentifiers. Simon Villeneuve (talk) 01:07, 17 March 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=User_talk:Bargioni/moreIdentifiers&oldid=2103650978"