Property talk:P213

Documentation

ISNI
International Standard Name Identifier for an identity. Starting with 0000.

Represents

International Standard Name Identifier (Q423048)

Applicable "stated in" value

International Standard Name Identifier (Q423048)

Has quality

VIAF component (Q26921380)

Data type

External identifier

Template parameter

en:Template:Authority control: "ISNI" - Template:Authority control (Q3907614)

Domain

person or organization (Q106559804), university campus (Q209465), facility (Q13226383), fictional human (Q15632617), fictional character (Q95074), position (Q4164871), mythical character (Q4271324), protected area (Q473972), human settlement (Q486972), human whose existence is disputed (Q21070568), pseudonym (Q61002), animal (Q729) or ship (Q11446)

Allowed values

[0]{7}[0-9]{8}[0-9X]

Usage notes

Only when displayed preceded by the letters ISNI and a space; the digits are displayed as 4 blocks of 4 digits

Example

Switzerland (Q39) → 0000000122974701
Nero (Q1413) → 0000000121416409
Charles Martel (Q3301) → 000000006629310X
Pink Floyd (Q2306) → 0000000109397559
Intel (Q248) → 0000000103545207
Narula Institute of Technology (Q6966447) → 0000000403855362

Formatter URL

https://isni.org/isni/$1

Robot and gadget jobs

DeltaBot does the following jobs:

Tracking: usage

Category:Pages with ISNI identifiers (Q13280236)

Complex constraint[edit]

no instance of
(Help)
Violations query: SELECT ?item ?itemLabel ?isni {?item wdt:P213 ?isni. MINUS {?item wdt:P31 []} } ORDER BY ASC(?isni)
List of this constraint violations: Database reports/Complex constraint violations/P213#no instance of

Complex constraint - instance of human[edit]

instance of a subclass of human
this shouldn't exist on any human in WD, but was found on human items having ISNI (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?type ?typeLabel {?item wdt:P213 ?isni; wdt:P31/wdt:P279+ wd:Q5 ; wdt:P31 ?type.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni)

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of a subclass of human

instance of human and having P1476 (title)
this shouldn't exist on any human in WD, but was found on human items having ISNI (Help)
Violations query: SELECT ?item ?isni ?title {?item wdt:P213 ?isni; wdt:P31 wd:Q5; wdt:P1476 ?title. } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and having P1476 (title)

instance of human and instance of role
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P2868 subject has role (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?type ?typeLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P31/wdt:P279* wd:Q214339 ; wdt:P31 ?type.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni)

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and instance of role

instance of human and part of X and member of X
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe remove P463 part of, respect qualifiers (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf; wdt:P463 ?partOf.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X and member of X

instance of human and part of X, X instance of educational organization
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q5341295.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of educational organization

instance of human and part of X, X instance of armed organization
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q17149090.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of armed organization

instance of human and part of X, X instance of association
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q15911314.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of association

instance of human and part of X, X instance of social organization
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q11799101.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of social organization

instance of human and part of X, X instance of non-profit organization
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q163740.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of non-profit organization

instance of human and part of X, X instance of music organization
this shouldn't exist on any human in WD, but was found on human items having ISNI; maybe move to P463 member of (Help)
Violations query:

SELECT ?item ?itemLabel ?isni ?partOf ?partOfLabel {?item wdt:P213 ?isni; wdt:P31 wd:Q5 ; wdt:P361 ?partOf. ?partOf wdt:P31/wdt:P279* wd:Q32178211.   SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }. } ORDER BY ASC(?isni) LIMIT 10000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of human and part of X, X instance of music organization

Complex constraint - other[edit]

instance of organization and having ISSN, ISSN-L and P1476 (title)
organization should not have ISSN, ISSN-L, title (Help)
Violations query:

SELECT ?item ?isni (GROUP_CONCAT(?title; SEPARATOR="; ") AS ?titles) {?item wdt:P213 ?isni; wdt:P236 [] ; wdt:P7363 []; wdt:P1476 ?title. } GROUP BY ?item ?isni LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of organization and having ISSN, ISSN-L and P1476 (title)

instance of organization and having P1476 (title)
organization should not have title P1476 (Help)
Violations query:

SELECT ?item ?isni (GROUP_CONCAT(?title; SEPARATOR="; ") AS ?titles) {?item wdt:P213 ?isni; wdt:P31/wdt:P279* wd:Q43229; wdt:P1476 ?title. } GROUP BY ?item ?isni LIMIT 100

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of organization and having P1476 (title)

instance of role and subclass of role
this shouldn't exist anywhere in WD, but was seen on an item having ISNI (Help)
Violations query: SELECT ?item ?isni {?item wdt:P213 ?isni; wdt:P31/wdt:P279* wd:Q214339; wdt:P279* wd:Q214339 } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P213#instance of role and subclass of role

instance of X and direct subclass of X
this shouldn't exist anywhere in WD, but was seen on an item having ISNI (Help)
Violations query: SELECT ?item ?isni ?x {?item wdt:P213 ?isni; wdt:P31/wdt:P279+ ?x; wdt:P279 ?x } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P213#instance of X and direct subclass of X

instance of role
since humans can assume roles, this should not exist for humans, but for the others (according to ISNI-IA there are is only type:Person and type:Organization) it should be controlled too (Help)
Violations query:

SELECT ?item ?isni ?instanceOf {?item wdt:P213 ?isni; wdt:P31/wdt:P279* wd:Q214339; wdt:P31 ?instanceOf} ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of role

instance of written work
an ISNI-item should not be an instance of written work, but this has been found in WD (Help)
Violations query:

SELECT ?item ?isni ?instanceOf {?item wdt:P213 ?isni; wdt:P31/wdt:P279* wd:Q47461344; wdt:P31 ?instanceOf} ORDER BY ASC(?isni) LIMIT 1000

List of this constraint violations: Database reports/Complex constraint violations/P213#instance of written work

Proposal of changing format deleting spaces[edit]

Hi all! In the sections above, and also in other pages, many discussions (mainly: 2013-2014, 2016, 2017, 2018, 2020-1, 2020-2, 2020-3) have taken place about the format of this property.

In this official document International Federation of Library Associations and Institutions (Q1334284) declares:

"ISNI consists of 15 digits followed by a check character. The check character may be either a decimal digit or the character “X” and shall be calculated using the preceding 15 decimal digits in accordance with the ISO/IEC 7064, MOD11-2 algorithm."
"The 16 digits of the number are entered in a compact form, without blank spaces or punctuation, and not preceded by the letters ISNI."
"When an ISNI is displayed in a human-readable format it shall be preceded by the letters ISNI, separated from the identifier by a space, and the 16 digits shall be displayed as four blocks of four digits, with each block separated from the next by a space."
"The number is actionable, resolvable as follows: http://www.isni.org/XXXXXXXXXXXXXXXX."

Thus, I will define:

storage format: 16 digits without spaces
display format: 16 digits divided by spaces in four blocks of four digits

Currently Wikidata stores ISNI (P213) values in the display format (= with spaces). The current proposal is to store ISNI (P213) values in the storage format (= without spaces), for the following reasons:

ISNI says clearly that IDs should be stored in the storage format
the storage format is more compact, so requires less storage space
spaces make more difficult matching our IDs with spaces stored by other databases without spaces (as advised by ISNI)
spaces make more difficult for other databases storing our IDs with spaces, as they have to remove spaces firstly (as advised by ISNI)

The current proposal also states that values should continue being visualized in the display format (= with spaces), which is easily possible creating a gadget and enabling it by default in user preferences; this implies that single users can voluntarily disable the gadget and visualize values in the storage format (= without spaces).

In the sections above, four users have already supported the proposal of storing values in storage format (Bargioni, Carlobia, Sotho Tal Ker and I), while one has opposed (Jura1). Please write here your opinion, for or against the proposal. This discussion has been advertised in Project chat. Good night, --Epìdosis 00:07, 26 June 2020 (UTC)[reply]

Comment the above proposal keeps being brought up by a globally banned users/related IPs. Please avoid quoting and voicing their point of view.--- Jura 00:32, 26 June 2020 (UTC)[reply]
Where have I quoted him here? I've just quoted an official document coming from IFLA. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
Comment Wikidata opted for the display format a few years ago and @Ivan_A._Krestinin: bot ensure that the format was consistently maintained. That format is visible to all users here and at other Wikimedia projets, such as the default functions for Wikipedia. --- Jura 00:32, 26 June 2020 (UTC)[reply]
The storage format can be consistently maintained too by a bot; as I said, there is no plan of changing the display format, but only the storage format. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
Comment a change of format of a well maintained identifier is disruptive for all datausers. --- Jura 00:32, 26 June 2020 (UTC)[reply]
No proof that external datausers wouldn't prefer using data in storage format, so that they can decide if they want or not to add spaces when they store IDs; imposing spaces in our storage format makes work harder for all datausers who want to store IDs without spaces. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
Comment whatever the format currently preferred by someone called "as advised by ISNI", we don't really know what will be their next POV and the solution Wikidata adopted is consistent with what was previously opted for. --- Jura 00:32, 26 June 2020 (UTC)[reply]
@Jura1: ISNI never changed its point of view regarding storage format and display format, they have always been consistent; on the other side, Wikidata hasn't been consistent with IFLA recommendations using display format both as storage format and display format. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
weak Oppose. Ideally the numbers would be stored in storage format and displayed in display format. But the fact that they've been stored here for so long in display format counts for something: there have been multiple, considered decisions to keep them that way, and it would be significantly expensive to change them all. This time around, the proposal to change them was motivated by changes at the ISNI site, changes which it sounds like are still in flux. I would favor changing our storage policy only when (a) there's a good way to display them in display format by default, (b) we're sure the URL format accepted at the ISNI site is stable, and (c) we're sure there are available cycles to change millions of entries, cycles that couldn't better be used for a more important task. (Finally, the "good way to display then in display format" should be based on a formatter property that's stored, somehow, explicitly in the database; it shouldn't be out in one UI.) —Scs (talk) 03:05, 26 June 2020 (UTC)[reply]
@Scs: I've read past discussions and my impression is that "multiple, considered decisions" where just based on the two argumentantions: changing so many IDs was a big work; it was crucial maintaining the display format as display format. In my proposal, differently from the proposal in the paragraphs above, I've made no reference to recent changes in ISNI website, because ISNI guarantees that the URL "http://www.isni.org/XXXXXXXXXXXXXXXX" is stable and this is factually true, also in these days it always worked (differently from the URL "http://www.isni.org/XXXX+XXXX+XXXX+XXXX", which is still broken). So, coming to your points: a) as I said, format can easily be changed through a gadget enabled by default - I agree about a formatting property being potentially better, but that would require an intervention by WMDE (@Lea Lacroix (WMDE):), which can take some time; b) the URL format accepted by ISNI, http://www.isni.org/$1, has always been stable, but only inserting values without spaces, not inserting values with spaces; c) the work (about 1.2 M edits) can be done with slow rhythms, in order not to interfere with other editors. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
Comment - the only thing that really matters to me: if you click on the generated link, will it bring you to the right ISNI-profile? If yes, I don't care for a (lack of) dashes/dots/spaces/etc. Edoderoo (talk) 06:10, 26 June 2020 (UTC)[reply]
@Edoderoo: The only URL which ISNI explicitly guarantees as stable is "http://www.isni.org/XXXXXXXXXXXXXXXX", which means that the values should not include spaces; all other URLs can potentially become broken in the future. --Epìdosis 08:38, 26 June 2020 (UTC)[reply]
Support IMO, the most important reason to store ISNI without spaces is "spaces make more difficult matching our IDs with spaces stored by other databases without spaces (as advised by ISNI)", as Epìdosis wrote. @Edoderoo: WD data are mostly used by other machines, in apps or ingested in other databases. I think it's better to avoid constrain/force programmers to remove ISNI spaces introduced by WD, and to not propagate WD (wrong?) previous choice. Thus, I also think that a copy/paste (cataloguing) operation has to exclude spaces, while a friendly display is a matter of interfaces. -- Bargioni 🗣 08:37, 26 June 2020 (UTC)[reply]
- You want to force users to add spaces, in order to prevent forcing script programmers to remove them. Removing spaces in a script is supa-dupa-easy, forcing all users is impossible. The more formatting you add to your data, the trickier it will get to compare that data. We have the same for phone numbers, the constraints force you to add a US-generic format, that does not work in other countries. Edoderoo (talk) 08:49, 26 June 2020 (UTC)[reply]
  - BTW: on june 9th I added an ISNI-number, a day later DeltaBot came by to add the spaces for me. Easy does it, I think. Edoderoo (talk) 12:47, 26 June 2020 (UTC)[reply]
Support with Comment I generally support this. Does anybody know any big third party data users who would be affected by this change? If so, why not reach out to them what they think. This change is not urgent. --Sotho Tal Ker (talk) 17:05, 27 June 2020 (UTC)[reply]
- Wikipedia? --- Jura 17:13, 27 June 2020 (UTC)[reply]
Support Moebeus (talk) 21:11, 27 June 2020 (UTC)[reply]
I am against changing ISNI from 4-character groupings - until ISNI changes from 4-character groupings. This doesn't mean that if I enter 16 characters without spaces that I should get an error, WD should auto-format 16 characters into the 4-character groupings. Quakewoody (talk) 19:23, 8 July 2020 (UTC)[reply]
Support If the display format can be easily changed, the storage format without spaces should make it easier for data consumers. Hanif Al Husaini (talk) 02:12, 8 March 2022 (UTC)[reply]
Support The distinction between display format and storage format is clear. An ISNI identifier does not contain spaces (i.e. spaces are not part of the identifier), they shouldn't be stored. Salpynx (talk) 23:50, 7 August 2022 (UTC)[reply]
Support The distinction between display format and storage format is clear. An ISNI identifier does not contain spaces (i.e. spaces are not part of the identifier), they shouldn't be stored. Inserting the string of the display format into a place that is expected to contain the string of the storage format causes problems in tools chains. E.g. Listeria creates links like [https://isni.oclc.org/xslt/DB=1.2/CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A0000 0000 8261 5295 0000 0000 8261 5295] resulting in "0000 8261 5295 0000 0000 8261 5295" Humanisator (talk) 16:36, 6 February 2023 (UTC)[reply]
I quote... myself :-) : "a friendly display is a matter of interfaces". Bargioni 🗣 20:55, 6 February 2023 (UTC)[reply]
Listeria created a broken display (groups 2-4 of ISNI followed by groups 1-4, instead of just the ISNI once in whatever format) and a broken link and Epidosis deactivated the link [1], probably he saw no simple way to get the link fixed. Issue of broken links when identifier contains spaces reported 2021-04-12 in github [2]. Humanisator (talk) 00:32, 8 February 2023 (UTC)[reply]

Summary 2023[edit]

Notified participants of WikiProject Authority control in more than 2,5 years, my proposal seems to have 7 supports (including me), 1 weak against and 1 against, besides various comments. I would personally judge it a good support, but since the change would affect a relevant number of reusers (in Wikimedia projects and outside) I would like to get more opinions about this. --Epìdosis 20:34, 6 February 2023 (UTC)[reply]

Support making this change. - PKM (talk) 03:57, 8 February 2023 (UTC)[reply]

Support --1-Byte (talk)

Support VIAF uses no spaces in ISNI, eg see https://viaf.org/viaf/64013650 then "Record Views" at the bottom. ORCID uses dashes not spaces, eg https://orcid.org/0000-0002-0966-2559.

Comment But @Epìdosis: How will you do the update "with slow rhythms": it means you'll have a mix of ISNI with and without spaces: won't this confuse consumers a lot? --Vladimir Alexiev (talk) 19:23, 13 February 2023 (UTC)[reply]

I think a bot programmer could probably find an acceptable solution; counting 1 edit per second, it would take a little more than 2 weeks. IMHO the problems caused by the spaces we stored could be more relevant, in the long term, than the discomforts we could cause for a few weeks; surely I recognise that there will be some discomfort. --Epìdosis 20:38, 13 February 2023 (UTC)[reply]

@Epìdosis Please notify Frettie before someone starts the bot. We will then pause automatic ISNI additions before it is completed. Who else imports ISNI IDs regularly? I guess the Bargioni's MoreIdentifiers script will need an update too. We may also discontinue some Mix'n'Match catalogues before the jobs starts. Vojtěch Dostál (talk) 21:18, 15 February 2023 (UTC)[reply]

Maybe we should announce this on the Wikidata weekly update as a planned "breaking change". Vojtěch Dostál (talk) 21:22, 15 February 2023 (UTC)[reply]

Or as "important fix of long-standing bug"? 77.191.48.51 14:05, 30 March 2023 (UTC)[reply]

Yes, we will pause the bot or stop ISNI part. --Frettie (talk) 22:10, 15 February 2023 (UTC)[reply]

@Vojtěch Dostál, Frettie: Of course I agree, the idea of reporting it in the weekly updates is very good. I think the bot could continue to work until the substitution effectively starts, it may take days or weeks. Fixes to MnM, moreIdentifiers, constraints, Autofix, authority control templates in Wikipedias etc. are already planned, of course :) --Epìdosis 07:35, 16 February 2023 (UTC)[reply]

What is the schedule? A lot of ISNIs are missing, I am just checking the area of tango music and find several ISNIs that have not yet been stored in Wikidata. Maybe 100 000s are missing. And I copy the value from the source isni.org/isni - without spaces - then Deltabot comes and inserts spaces. So, that is uneccessary botwork and when thousands of missing ISNIs are added the conversation will be more work. Would be nice this could be started next week, so Wikidata is ready by 2023-04-01, start of 2023Q2. 77.191.57.186 11:06, 18 March 2023 (UTC)[reply]

@Vojtěch Dostál, Frettie: it seems no one has answered Wikidata:Bot requests#Request to delete spaces from ISNI IDs (2023-02-15) yet. Should we wait for a bot being ready for adding the post in status updates or should we post there now? Anyway, here a first list of things to check for the format change: update format of P213; stop User:DeltaBot; update User:Bargioni/moreIdentifiers and User:Magnus Manske/authority control.js and User:Tpt/viaf.js; reprogram Frettiebot; ask Magnus to fix all P213 IDs present in the auxiliary data of Mix'n'match; after the bot finishes, set a new autofix (or reprogram DeltaBot for the inverse task). --Epìdosis 20:29, 18 March 2023 (UTC)[reply]

What is the benefit of an extra bot instead of reversing the autofix? Since DeltaBot was working on that property in the past, maybe will work on it afterwards, it could be beneficial to have the initial removal be carried out by DeltaBot too. Autofix reversal wouldn't even require a bot programmer. If it is decided that DeltaBot can do the initial removal too, then

Frettiebot can be stopped without problem?
the three js files can be changed very easily?
the Mix'n'match might be a bottleneck - @Magnus Manske: can you prepare for that change and tell how much time you would need? Maybe it is not critical to have the change ready when the initial P213 conversion is done
post in status updates - what is the process, any dead lines, e.g. if not daily?

89.12.47.125 11:47, 20 March 2023 (UTC)[reply]

Frettiebot can be stopped without problem. --Frettie (talk) 16:32, 24 March 2023 (UTC)[reply]

Support Use storage format for storage. An ISNI identifier does not contain spaces. Users that want to see the data in display format when displayed can look for tools that do so, but that will should have no effect on the storage. The core of Wikidata is the database (storage of information), not the UI (display of information). 5678fghj (talk) 00:27, 4 July 2023 (UTC)[reply]
Support If all precautions as requested above are accounted for, there is no reason why this shouldn't be done. Jonathan Groß (talk) 16:17, 5 November 2023 (UTC)[reply]
Support let's go, how could we help now to see it done? Cheers, VIGNERON (talk) 17:17, 5 November 2023 (UTC)[reply]
Support This would affect some matching I do, but it's trivial enough to change the interaction so yes let's do this. ArthurPSmith (talk) 22:13, 7 November 2023 (UTC)[reply]
Support ―Eihel (talk) 16:24, 9 November 2023 (UTC)[reply]
Support Too late for the discussion, but I strongly agree with this fix. Cheers, — Envlh (talk) 14:03, 30 December 2023 (UTC)[reply]

To-do list[edit]

Since there is no objection, I try to outline the procedure we can follow to change the format of P213:

change ISNI (P213) format and constraints
change {{Autofix}} here
change User:DeltaBot/fixClaims/jobs
adapt User:Bargioni/moreIdentifiers system regex.js
adapt User:Magnus Manske/authority control.js
adapt User:Tpt/viaf.js
check the correctness of links to ISNI in the Wikipedias displaying it from Wikidata

As of now I don't have other points in mind. The points regarding the 3 gadgets can be performed most easily by an interface admin (or by the users who wrote the gadgets); the same interface admin could also perform the first 3 changes, so that everything starts at the same time. For the last one, I can check it. One last question: since, as said multiple times in the above discussion, we are changing the storage format removing the spaces (as advised by IFLA) but we would like to maintain the spaces in the display format, do we have some method ready to display with spaces the IDs that we will store removing the spaces? Thanks, --Epìdosis 17:09, 11 November 2023 (UTC)[reply]

@Epìdosis Format, constraints and Autofix changed. Frettiebot warned. How do we fix User:DeltaBot/fixClaims/jobs? @MisterSynergy Thanks Vojtěch Dostál (talk) 16:57, 17 December 2023 (UTC)[reply]

For DeltaBot I think this edit is sufficient. --Epìdosis 17:18, 17 December 2023 (UTC)[reply]

No idea what is going on here, but all DeltaBot fixClaims jobs are defined on User:DeltaBot/fixClaims/jobs, and the current source code for the bot is at GitHub. Search for P213 on the jobs page and adjust whatever is necessary. —MisterSynergy (talk) 18:16, 17 December 2023 (UTC)[reply]

@Vojtěch Dostál: DeltaBot and KrBot are not reformatting the present values; I have deprecated momentarily the constraint to avoid having 1.5+ M violations. I think we probably need an apposite bot for the reformatting. --Epìdosis 15:36, 18 December 2023 (UTC)[reply]

Yeah, maybe their queries are timing out. Maybe @MisterSynergy will help us understand the situation with Autofix bot better? Vojtěch Dostál (talk) 19:52, 18 December 2023 (UTC)[reply]

I am quite confused. DeltaBot seems to be running fine with regards to this job, except maybe for a few dozen cases. Aren't most P213 claims already in the correct new format with spaces? —MisterSynergy (talk) 21:37, 18 December 2023 (UTC)[reply]

I try to clarify. In fact the new format is the format without spaces, whilst the old format is the one with spaces; most P213 values are in the old format with spaces. Autofix and DeltaBot should eliminate the spaces to convert the IDs to the new format. --Epìdosis 23:46, 18 December 2023 (UTC)[reply]

I see. If we talk about 1.5M claims, I don't think this should be done with DeltaBot. It would likely clog its job queue which is already a delicate procedure to keep in good running condition. A dedicated job for this seems reasonable, and it is not an overly complicated one. I would deactivate the fixclaims jobs in the meantime, in order not to interfere with the transition. We can reactivate it with the new format at a later point in time. Okay? —MisterSynergy (talk) 23:53, 18 December 2023 (UTC)[reply]

@MisterSynergy: OK, I very much agree with your reasoning. --Epìdosis 09:05, 19 December 2023 (UTC)[reply]

@Epìdosis @MisterSynergy Yeah, it's an easy job, but it will take ages to run. I am trying to gain access to some server where I can run Wikibase Cli. If someone is able to do it sooner, I have a CSV with the statement IDs and current values. Vojtěch Dostál (talk) 17:46, 19 December 2023 (UTC)[reply]

Probably the anti-abuse filter "Inappropriate ISNI (P213) change" should also be voided to allow the entering of ISNI without spaces manually. --Jahl de Vautban (talk) 21:28, 19 December 2023 (UTC)[reply]

Roughly 11-12 days at 90 edits per minute. This would be possible from Toolforge using pywikibot with a short custom script. I just do not have time to go through the approval process and monitor it for ~2 weeks properly. —MisterSynergy (talk) 22:13, 19 December 2023 (UTC)[reply]

@Jahl de Vautban: thanks for noticing, I have deactivated Special:AbuseFilter/110 ("Inappropriate ISNI (P213) change"); in the future, when the mass-change will be completed, it could be useful reactivating it with the opposite value. @Vojtěch Dostál: thanks for taking care of it, unfortunately I have no technical capabilities to anticipate you. --Epìdosis 00:17, 20 December 2023 (UTC)[reply]

@MisterSynergy I am not planning to go through an approval process as this has been already approved by the community. Otherwise I agree. Vojtěch Dostál (talk) 16:31, 20 December 2023 (UTC)[reply]

@Epìdosis @MisterSynergy Before I was able to start a bot, KrBot seems to be already on it. See Special:Contributions/KrBot. Also FYI @Frettie Vojtěch Dostál (talk) 08:17, 29 December 2023 (UTC)[reply]

@Epìdosis KrBot is a tad too slow, so I started my own bot and I will try to help him. Vojtěch Dostál (talk) 10:22, 2 January 2024 (UTC)[reply]

Conversion observations 2024[edit]

The page as of today says there are 1,671,359 main statements. The report page as of now says there are 972835 "Format" violations. With ca. 65.5 edits/entities per min as of today in the job https://editgroups.toolforge.org/b/wikibase-cli/1d9061a46973c/ , 65.5*60*24=94320 are done per day. So, in 10 days, 2024-01-16 it should be over.

The quantity of unique violations was 2222 (2023-12-19 [3]) and currently is 1260 (2024-01-06 [4]). For the next 10 days this may still be unreliable. But since resources are restricted probably no action is recommended. In case the conversion stops or slows down significantly, one should maybe make sure that the 2222 values listed 2023-12-19 are all converted. Ac2wd (talk) 20:05, 6 January 2024 (UTC)[reply]

Since KrBot also converts [example: https://www.wikidata.org/w/index.php?title=Special:Contributions/KrBot&target=KrBot&offset=20240106203820], the conversion could end in less than 10 days. Ac2wd (talk) 20:48, 6 January 2024 (UTC)[reply]

User:KrBot maybe doesn't work on ISNI starting with 00000005 (first significant digit is 5). See https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Constraint_violations/P213&oldid=2046959687#%22Format%22_violations - I converted the first seven 5ers manually. @User:Ivan A. Krestinin, FYI. Ac2wd (talk) 20:48, 6 January 2024 (UTC)[reply]

0000 0005 should be fine soon, changed the autofix: https://www.wikidata.org/w/index.php?title=Property_talk:P213&diff=prev&oldid=2052281314 Ac2wd (talk) 21:11, 12 January 2024 (UTC)[reply]

1.6 mio pages are touched and cached with the non-standard URL. Ac2wd (talk) 19:13, 10 January 2024 (UTC)[reply]

@Ac2wd @Epìdosis I think it's mostly done now, correct me if I am wrong. I see only sixteen cases of ISNI with spaces, KrBot should be able to fix it. Vojtěch Dostál (talk) 18:05, 14 January 2024 (UTC)[reply]

Yes, looks good, I saw it in the early morning. KrBot also did the 0000 0005 values, as expected. Waiting for https://isni.org/isni/$1 to be used in item pages and at connected pages, e.g. in the Infobox at commons:Category:Charles Martel. I thought it might be due to caching and tried to force rewrite [5] but it didn't help. In the example section at Property_talk:P213#Documentation and at the Constraint violations report the only official-ISNI URL as stored in the formatter is used. Ac2wd (talk) 23:41, 14 January 2024 (UTC)[reply]

Consistent problem with entering value[edit]

I have had this problem occurring recently with entering ISNI values. It seems to reverse the number. Case in point: Q110980377. I enter the value 0000 0000 6357 8206‏ for ISNI. It displays that way when I am entering it or saving it, yet it displays 8206 6357 0000 0000 & throws a ‏format constraint issue The value for ISNI (0000 0000 6357 8206‏) should match the regex ([0]{4} [0-9]{4} [0-9]{4} [0-9]{3}[0-9X]|). When I click on the link, it takes me to https://isni.oclc.org/xslt/DB=1.2/CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A0000%200000%206357%208206%E2%80%8F just fine.

A seemingly related symptom is that w:en:Template:Authority control displays The ISNI id 0000 0000 6357 8206‏ is not valid. Category:Articles with faulty ISNI identifiers. Peaceray (talk) 23:01, 21 February 2022 (UTC)[reply]

See the enwiki example at w:en:Draft:Benjamin Pang Jeng Lo. Permanent link: https://en.wikipedia.org/w/index.php?title=Draft:Benjamin_Pang_Jeng_Lo&oldid=1073281501 & expand the Authority Control template. Peaceray (talk) 23:03, 21 February 2022 (UTC)[reply]

The identifier included a trailing right-to-left mark which caused all of this. —MisterSynergy (talk) 23:29, 21 February 2022 (UTC)[reply]

I would love to know how that right-to-left mark is getting in there. I don't seem to have any problem posting any other text anywhere else, only in this one particular field — and it is consistent! It is hard for me to believe that I am entering the right-to-left mark with my copy & paste, typically coming from the VIAF record, then inputting the spaces manually while in the field entry. I am using Firefox 97.0.1 on Windows 10 Home Version 10.0.19044 Build 19044 on an x64-based PC if that is of any help. Peaceray (talk) 23:45, 21 February 2022 (UTC)[reply]

If you copy the identifier from https://viaf.org/processed/ISNI%7C0000000063578206, e.g. one of the "035" fields … then you do indeed get a trailing rtl mark from there. Don't ask for reasons—I don't know either. I have seen and experienced this myself before as well. There is really nothing wrong with your setup, and neither with Wikidata or Wikipedia. —MisterSynergy (talk) 00:02, 22 February 2022 (UTC)[reply]

Ah! Okay good to know. I will paste it in an intermediary text editor before copying it into the ISNI value field. Peaceray (talk) 01:57, 22 February 2022 (UTC)[reply]

Hi, @Peaceray!

I would like to know if the explanation worked for me as I seem to be facing the same issues ("format constraints") with the ISNI ID. Atibrarian (talk) 23:08, 26 January 2024 (UTC)[reply]

Yes, pasting it into Notepad or Notepad++ then recopying it seems to work. Peaceray (talk) 23:43, 26 January 2024 (UTC)[reply]

Issues of the Wikidata P213 specification as of 2024-01[edit]

Wikidata settings don't allow me to fix issues regarding the specification

description field: spaces or 20 digit
1. "es" : "identificador internacional normalizado de nombres para una identidad. formato: 4 bloques de 4 dígitos separados por un espacio, el primer bloque es 0000" added 2024 [6]
2. "ast" : "International Standard Name Identifier pa una identidá. Formatu: 4 bloques de 4 cifres separaos por un espaciu, el primer bloque ye 0000."
3. "en-GB" : "International Standard Name Identifier for an identity. Format: 4 blocks of 4 digits separated by a space, first block is 0000"
4. "fi" : "ISNI-standardin (engl. International Standard Name Identifier) mukainen tunniste kohteelle (käytä 20-merkkistä tunnistetta ilman väliviivaa)"
5. "it" : "identificatore ISNI (4 blocchi di 4 cifre separati dallo spazio)"
6. "fa" : "شناسهٔ 16 رقمی برای افراد و سازمان ها که 4 رقم 4 رقم از هم فاصله می دهیم مثل 1422 4586 3573 0476 کد بین‌المللی شناسهٔ بین‌المللی ایزو 27729"
7. "ksh" : "engernazjonahl Schtandatt-Nahme-Kännzahl (Met Zweschereum, alsu esu wi 0000 0001 0886 1508.)"
8. "la" : "siglum International Standard Name Identifier (exempli gratia 0000 0001 0667 8013)"
9. "ms" : "pengenal pasti untuk identiti di Nama Piawai Antarabangsa. Format: 4 blok bagi 4 digit yang dipisahkan dengan ruang, blok pertama adalah 0000"
10. "nb" : "internasjonal standard navneidentifikator (Føres inn med mellomrom. Eksempel: 0000 0001 0886 1508)"
11. "pl" : "International Standard Name Identifier. Format: 4 serie po 4 cyfry oddzielone spacją, pierwsza seria to 0000"
12. "scn" : "International Standard Name Identifier a 16 cifri. Es.: 0000 0001 0886 1508. (Quann'è mmustratu si prifissa chî littri ISNI, spartuti dî cifri di nu spazziu, e li 16 cifri su' mmustrati a 4 blocchi di 4 cifri, spartuti cu nu spaziu.)"
13. "sq" : "Standardi Ndërkombëtar për Identifikimin e Emrit për një identitet. Formati: 4 blloqe me nga 4 shifra të ndara me një hapësirë, blloku i parë është 0000."
14. "sr" : "идентификатор за Међународне идентификаторе стандардизованих имена (формат: 4 блока од по 4 цифре одвојене размаком, први блок је 0000)"
15. "tr" : "bir kimlik için Uluslararası Standart İsim Tanımlayıcı. Biçim: Bir boşlukla ayrılmış 4 basamaklı 4 blok, ilk blok 0000"
16. "uk" : "International Standard Name Identifier — шістнадцятизначний Міжнародний ідентифікатор стандартних найменувань (за ISO 27729); формат: 4 блоки по 4 цифри розділені пробілом"
17. 6x cn : (not quoting here)
Property:P1630 formatter URL : "https://wikidata-externalid-url.toolforge.org/?p=213&url_prefix=http://isni.org/&id=$1" https://www.wikidata.org/w/index.php?title=Property:P213&oldid=2046945027#P1630
Property:P1855 Wikidata property example : 6 examples, each containing three spaces https://www.wikidata.org/w/index.php?title=Property:P213&oldid=2046945027#P1855
Property:P8966 URL match pattern : 8 times URL match replacement value "\1 \2 \3 \4" https://www.wikidata.org/w/index.php?title=Property:P213&oldid=2046945027#P8966
Property:P1793 format as a regular expression : "[0]{4}[0-9]{4}[0-9]{4}[0-9]{3}[0-9X]" - overly complicated, suggest "[0]{7}[0-9]{8}[0-9X]" https://www.wikidata.org/w/index.php?title=Property:P213&oldid=2046945027#P1793
Property:P2302 property constraint https://www.wikidata.org/w/index.php?title=Property:P213&oldid=2046945027#P2302
1. format constraint : format as a regular expression "([0]{4}[0-9]{4}[0-9]{4}[0-9]{3}[0-9X]|)" - overly complicated, suggest "([0]{7}[0-9]{8}[0-9X])"
2. format constraint - deprecated - causing several kinds of issues, see below

Caused or possibly caused by deprecated "format as a regular expression":

Topic:Xws6eqithns3eo9m
unknown number of users and bots performing batch and other operations inserting spaced ISNI or changing non-spaced to spaced
1. "Created a new Item: #quickstatements; #temporary_batch_1704565363667" https://www.wikidata.org/w/index.php?title=Q124157235&oldid=2047097271 (User:Bargioni)
2. https://www.wikidata.org/w/index.php?title=Q124158709&diff=prev&oldid=2047191703 (User:Animalparty)

Proposed fix: undo the deprecation [7] so that all tools and users are warned not to insert any value violating the ISNI specification or not having 7 leading zeros.

Ac2wd (talk) 19:28, 6 January 2024 (UTC)[reply]

Except for undoing the deprecation, each problem should be fixed. Additionally the example Norway (NATO member) was switched to Switzerland (politically more neutral, but still widely known). Ac2wd (talk) 19:08, 10 January 2024 (UTC)[reply]

Changed: format constraint to normal rank again, each constraint mandatory, the examples: Intel down to other organisation, the example with ending in X up to 3rd position and switching from Q57188 Ernst Cassirer 000000012146438X to Q3301 Charles Martel 000000006629310X (lower QID, lower ISNI) [8]. There are still two humans, the other being Q1413 Nero 0000000121416409, maybe to demonstrate that humans can also have an ISNI ending in [0-9].

Apart from "conflicts-with constraint - instance of - ..." there is no constraint on what the items can be instances of and that they have to be instance of something. Suggested fix: make instance of mandatory and restrict allowed target values to person, organisation. The daily report should show statistics and violations, and one can then refine. Ac2wd (talk) 20:01, 12 January 2024 (UTC)[reply]

Added subject type constraint instance of person or organization (Q106559804). First "Wikidata:Database reports/Constraint violations/P213"-results [9]:

5589 violations, 588 records skipped in display
most used type: human (Q5) : 1484110
ten most used non-conforming types:
1. campus (Q209465) 1435
2. facility (Q13226383) 1348
3. theatre (Q24354) 141
4. building (Q41176) 110
5. church building (Q16970) 94
6. university campus (Q30785519) 86
7. human settlement (Q486972) 60
8. fictional human (Q15632617) 55
9. architectural structure (Q811979) 54
10. unincorporated community in the United States (Q17343829) 53

Added the first two most often occurings non-conforming types temporarily as allowed, so that each other violation is listed ("Too many results. 588 records skipped.") and allow easier focus on those that can be maybe be fixed manually.

The type statistics itself are not complete: "Too many results. 4270 items skipped". Four non-conforming types occur 12 times each. Ac2wd (talk) 21:22, 13 January 2024 (UTC)[reply]

ISNI formatter URL[edit]

2024-01-10 two values have been removed, since they never were official ISNI-URLs [10]. One even caused thousands of broken links in DB reports, see the ISNI-"xslt"-links 2024-01-10 [11].
2024-01-13 23:39 the formatter for the official ISNI-URL-syntax was added [12] in preparation for the switch.
2024-01-14
1. 05:12 the switch was made [13], since the conversion was nearing the end, and caching problems were expected.
2. 06:03 The new URL was active for the examples at Property talk:P213 web archive 2024-01-14 06:03:45, but not on the items itself, and not on the examples at Property:P213.
3. 06:16 the bot by User:Vojtěch Dostál slowed down
4. 06:22 it looked as if the bot had ended in editgroup 221e03c358cf4.
5. 12:56 KrBot2 used the officials URLs when updating Wikidata:Database reports/Constraint violations/P213
6. 16:52 User:Haseeb55, not seen on this talk before started editing the property:
  1. 16:52 undid the removal of the never-have-been-offical-ISNI-URL containing xslt without edit summary
  2. 16:52 undid the removal of the never-have-been-offical-ISNI-URL pointing to a toolforge.org-URL, which can cause privacy issues, edit summary: "no need to remove this statements"
  3. 16:56 inserted the formatter URL https://isni.oclc.org/cbs/DB=1.2//CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A$1 with "Preferred rank", but without any reference
  4. 17:01 changed the formatter URL introduced 5 min ago to https://isni.oclc.org/cbs/DB=1.2/CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A$1
7. 22:35 User:Ac2wd who was engaged in the talk before and watched the conversion from the very beginning, cf. Topic:Xws6eqithns3eo9m Topic:Xx1c3v17w0zw3oun changed the "Preferred rank" to "Normal rank" and for the only ISNI-official-syntax changed the rank from Normal to Preferred, which was made necessary by the insertions of three never-have-been-offical-ISNI-URLs

I object to the claim "no need to remove this statements" - it wasn't done for fun, there was a real need as shown above.

I recommend to remove any URLs that belong to the group of never-have-been-offical-ISNI-URLs. The property is meant to store ISNIs and the property page should only store verifiable facts. Ac2wd (talk) 23:24, 14 January 2024 (UTC)[reply]

@Ac2wd, First of all, it is not an editing criterion that someone who has never talk on a subject before cannot make edits on the subject. Secondly, you should know when a statement is kept and when it is considered for removal. And I think "https://isni.org/isni/$1" should not be the preferred value as it is a redirect. — Haseeb (talk) 03:21, 15 January 2024 (UTC)[reply]

re "First of all": Yes, but using the talk page before reverting can reduce the chance of introducing mistakes, especially when reverting a user that demonstrated knowledge related to that property and the ID system it represents and was active on the talk page
re "Secondly": What is your proof for that and what do you think about the corresponding status of my knowledge? Please provide evidence / references for your claim.
re "And": Why? Why should Wikidata not do what many reliable sources do? Why would being a redirect a criterion? Please provide evidence / references for your claim.

Ac2wd (talk) 06:37, 15 January 2024 (UTC)[reply]

False ISNI claims by Frettie, Frettiebot[edit]

2023-01-24 on a painting page, 2023-01-29 reverted by User:Epìdosis, 2023-01-30 re-inserted by Frettiebot, 2024-01-15 reverted by User:Ac2wd https://www.wikidata.org/w/index.php?title=Q57393883&action=history
2023-05-05 on a disambiguation page, 2024-01-13 reverted by User:Haseeb55 https://www.wikidata.org/w/index.php?title=Q1034176&action=history

User:Frettie, what is the source of these claims, how many more false claims exist (were inserted by the same method, were re-inserted after removal)? Ac2wd (talk) 17:37, 15 January 2024 (UTC)[reply]

The source is in the reference, no? See https://aleph.nkp.cz/F/?func=direct&doc_number=001174348&local_base=AUT . Please don't remove deprecated sourced claims! Vojtěch Dostál (talk) 18:21, 15 January 2024 (UTC)[reply]

you seem to refer to the issue "1", because The page https://aleph.nkp.cz/F/?func=direct&doc_number=001174348&local_base=AUT does say "Meister von Heiligenkreuz, činný 1395-1420" and it says Standardní čísla Q57393883 [wikidata]. It seems that aleph.nkp.cz is not a reliable source. Two users removed. It is not a minor mistake, the item is since inception about an instance of a class not represented by ISNI items at all [14]
no answer to issue "2"?

Ac2wd (talk) 18:36, 15 January 2024 (UTC)[reply]

The Czech national library is a reliable source, but just like every source it may contain errors. Being able to track those down and report them ensures that both the original database and Wikidata will profit from it. Once those claims are not supported by the Czech national library we'll be able to remove them. In the meantime, we ought to keep them. Though on this case they might be a slight confusion as there is on the authority file another link to Wikidata, which point to the correct Qid.
That seems to originate in a wrong edit by Frettie in a presumably large batch when adding the identifiers for the Czech library, which was then used to import other data. It happens. --Jahl de Vautban (talk) 19:12, 15 January 2024 (UTC)[reply]

What is your source for that claim? A pre-school child could determine that a painting never is an instance of "person or organisation". Re "In the meantime, we ought to keep them. " - Why? It is obviously crap.
A presumably large batch, with a presumably large amount of outright false claims, from the same unreliable source as in "1."?

Ac2wd (talk) 19:17, 15 January 2024 (UTC)[reply]

By concern isn't children, but bots, which I do not expect to be intelligent as that's not what they are for. By keeping the data and marking it as deprecated, it doesn't cause any harm to end users and it will prevent the same data to be reimported until the original source is fixed. I have worked on numerous items with NKČR, I don't think that a single, if curious, error is sufficient to label the entire database as unreliable.
Nothing to add on 2. --Jahl de Vautban (talk) 20:27, 15 January 2024 (UTC)[reply]