Property talk:P213

Documentation

ISNI
International Standard Name Identifier for an identity. Format: 4 blocks of 4 digits separated by a space, first block is 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

persons, places, organizations... (note: this should be moved to the property statements)

Allowed values

[0]{4} [0-9]{4} [0-9]{4} [0-9]{3}[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

Norway (Q20) → 0000 0001 2197 5163
Nero (Q1413) → 0000 0001 2141 6409
Intel (Q248) → 0000 0001 0354 5207
Pink Floyd (Q2306) → 0000 0001 0939 7559
Ernst Cassirer (Q57188) → 0000 0001 2146 438X
Narula Institute of Technology (Q6966447) → 0000 0004 0385 5362

Formatter URL

https://isni.oclc.org/xslt/DB=1.2/CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A$1
https://wikidata-externalid-url.toolforge.org/?p=213&url_prefix=http://isni.org/&id=$1

Robot and gadget jobs

DeltaBot does the following jobs:

Tracking: usage

Category:Pages with ISNI identifiers (Q13280236)

Autofix[edit]

Pattern ^(0000)(000[0-4])(\d\d\d\d)(\d\d\d[\dX])$ will be automatically replaced to \1 \2 \3 \4.
Testing: TODO list

ExternalUse[edit]

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Navigation[edit]

ISNI format[edit]

Query[edit]

I don't know much about identifiers, but according to en:ISNI, ISNIs are 16 characters, not 20. Could somebody more knowledgeable on the matter than I please explain the discrepancy? — PinkAmpers&^{(Je vous invite à me parler)} 23:49, 6 March 2013 (UTC)

Yes, I am fixing this to their preferred format, that is

16 digits dumb identifier. When displayed it is preceded by the letters ISNI, separated from the identifier by a space, and the 16 digits are displayed as four blocks of four digits, with each block separated from the next by a space. EXAMPLE ISNI 1422 4586 3573 0476

Maximilianklein (talk) 18:39, 25 March 2013 (UTC)

So what should we add: "0000 0001 2095 5689" (like Vincent van Gogh) or "0000000120955689" (like the example in Wikidata:List of properties)? For human readers the spaces are helpful. Are they machine-readable? If yes we should use them. --Kolja21 (talk) 00:36, 4 April 2013 (UTC)

The thing is that the outbound links will eventually look like http://isni-url.oclc.nl/isni/000000011593412X , which is without spaces. So the question is, whether using template logic the spaces can be removed? If so, we should use the human readable form for display. If it's impossible to build the template like isni-url.oclc.nl/isni/{{#removespaces|$1}} then it's more important we have clickable links. Maximilianklein (talk) 16:31, 4 April 2013 (UTC)

It's difficult to remove spaces with parser functions but not with Lua and I think that authority templates will soon be move to Lua (at the same time as the migration to Wikidata). So, I believe that we can use spaces as we have remove the "/" for LCCN ids. Tpt (talk) 14:13, 5 April 2013 (UTC)

parameter value normalization[edit]

This is not a broken links issue. Magnus Manske's authority control.js tool detects the ISNI / ISNI (ISO 27729) parameter in WMF project pages with Authority control templates. In most cases the values for the ISNI parameter at enwikipeia, commons etc. is a string containg three spaces for better readability.
At this moment the tool does not state that the value "000035411562" is an instance of the value "35411562".
note: scanning the viaf.org source code page for lines using "new Node" helps identifying the national identifiers
see: viaf:24590642 for Q153905 Paul Celan

new new Node("ISNI|0000000122837889", "ISNI", "ISNI");

http://viaf.org/processed/ISNI%7C0000000122837889 relates to this

VIAFbot made this changes

[1] VIAFbot (talk | contribs) (‎Created claim: Property:P213, 0000 0003 6865 2462)

property / ISNI (ISO 27729)

+ 0000 0003 6865 2462

[2] VIAFbot (talk | contribs) (‎Created claim: Property:P213, 0000 0001 2283 7889)

property / ISNI (ISO 27729)

+ 0000 0001 2283 7889

notes:

In urls as http://isni-url.oclc.nl/isni/0000000368652462 no spaces are used
at viaf:24590642 in the header one can see ISNI: 0000 0001 1022 7004 where multiple spaces are used

pro and contra about using spaces in the internal representation:
"copy and paste" of s single numerical string is much easier then reformating it manually. The perameter string may wrap around or eaven worse might wrap according to BiDirectional script rendering.
One should use one internal representation only. Onece agreed the problem might be fixed with regex. Bothe MediaWiki talk:Gadget-AuthorityControl.js and the WMF AC templates should support both value formats. Thanks for any help!
see also MediaWiki talk:Gadget-AuthorityControl.js
additional note: At Q153905 Paul Celan one can find additional issues

viaf:27062193 is a deprecated VIAF id showing This VIAF Cluster has been deleted. It is no longer part of VIAF.
the tool shows at thle lines tool en.wikipedia and ja.wikipedia contains the "wrong" VIAF id
1. probably also more the WMF projects
  theoratically one needs to verify at least the projects supporting Template:Authority control (Q3907614)
  The list / table is ( 'als', 'ar', 'arz', 'as', 'bar', 'be' 'bn', 'bs', 'ca', cs', 'cv', 'da', 'de', 'en', 'eo', 'ee', 'fa', 'fr', 'hu', 'id', 'ilo', 'it', 'ja', 'km', 'ko', 'mk', 'nds', 'ne', 'nn', ', 'no', 'or', 'pl', ', 'pt', 'ro', 'ru', 'sl', 'st', 'th', 'uk', 'ur', 'vi', 'yi', 'zh', 'commons' )

לערי ריינהארט (talk) 08:22, 10 October 2013 (UTC)

This is still an open issue. לערי ריינהארט (talk) 12:26, 30 October 2013 (UTC)

Spaces are wrong[edit]

Spaces are wrong. There are no spaces in the ISNI. It is a 16 character ID:

http://www.iso.org/iso/catalogue_detail?csnumber=44292

No other ID maintained by TC 46/SC 9

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=48836&published=on

like ISBN, ISCI, ISSN, ISRC, ISMN, ISWC has spaces, nor does this one have.

John B. Sullivan (talk) 12:19, 7 December 2014 (UTC)

Some thinks:

Often identifiers has internal presentation and standard display presentation. For example globally unique identifier (Q254972) is 128-bit number. But it is presented not as 123456789023456789456789 but as {21EC2020-3AEA-4069-A2DD-08002B30309D}.
Wikidata used display presentation, not internal. For example the most numeric identifiers are presented using string datatype, not numeric.
Standard display presentation for ISNI is 0000 0000 0000 000X as I see. For example see [3], [4].
0000 0000 0000 000X is more readable than 000000000000000X.

So, I think 0000 0000 0000 000X format is more preferred than 000000000000000X. Anyway changing format in 250000+ items is global operation. It need to be discussed before implementing. Please do not touch Constraint template too until the discussion complete because the template is used by bots and inaccurate changes breaks normal work. — Ivan A. Krestinin (talk) 14:03, 7 December 2014 (UTC)

This conversation was advertised at the village pump. I restored the description pending this conversation. Multichill (talk) 14:39, 7 December 2014 (UTC)

Dear John, please be polite and don't change things before consensus has been reached. Accusing me and Ivan of vandalism is not polite. I tend to agree with Ivan. Could you please respond to this? I have to warn you, if you revert us again you'll get blocked for edit warring. Multichill (talk) 15:48, 7 December 2014 (UTC)

John kept on replacing the regex reverting Jura1, Ivan and me. I asked him nicely to please not do that. He did it again so I blocked him for a day. Multichill (talk) 16:13, 7 December 2014 (UTC)

See also en:Template talk:Authority control#Valus in Wikidata are false and adjacent sections. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 16 December 2014 (UTC)

Storing in a display format breaks usability in tools like Reasonator[edit]

There has been discussion before about storing the data in the display format or in the actual format. Storing in a display format breaks usability in other tools. Showing it in a format is just a matter of having some code at our end if that is what you want.

The current wrong practice defeats the purpose of linking to ISNI and needs to be remedied. Thanks, GerardM (talk) 06:10, 8 January 2016 (UTC)

Current format was introduces two years ago. All tools and bots use this format now. The format is more readable. I do not think that we need to start migration process in this stage. Reasonator is looked as the only tool that does not support this format. I think better way is fixing Reasonator code. — Ivan A. Krestinin (talk) 08:10, 8 January 2016 (UTC)

There are several other identifiers that currently don't link correctly with Reasonator. Is there anything special about this one?
--- Jura 09:41, 8 January 2016 (UTC)

This is the only one using spaces. It heavily breaks usability. GerardM, thanks for bringing this up. 85.179.24.163 04:47, 19 November 2016 (UTC)

Value constraints[edit]

"Item type principal (GND) (P107) = personne (Q215627)" violations[edit]

There is a problem with this constraint, since ISNI (and VIAF) also comprise "Organizations" (moral persons) and even "Locations" like Switzerland or Paris - could it be possible to check if one of the 3 is used, instead of a long list of Organization here that won't ever be removed from the list if the constraint stays as it is… (same thing on Property:P214 (VIAF) and probably all AC used in VIAF. --Hsarrazin (talk) 03:19, 28 May 2013 (UTC)

Yes, the constraint should also comprise organisation. For "Locations", this is more complicated: the ISNI for Paris is in fact the identifier of the Paris as organisation (the Marie de Paris) and not Paris as place. But, as the distinction is not done in Wikidata. So, waiting for a good solution, I think that we should remove the "Item type principal (GND) (P107) = personne (Q215627)" contraint. Tpt (talk) 05:47, 28 May 2013 (UTC)

If you remove simply Q215627, it will list those without the main type property. OTH, if 95% are persons, it might still be worth checking for that. -- Docu at 06:44, 28 May 2013 (UTC)

instead of removing the constraint, would it be possible to "extend" it to "organizations", so that all the "treated" values, on top of the list of "violations", can be removed… it is very disappointing to try and treat a list of errors, and all the first 20 or 50 values you try, should simply not be on the list… ;) --Hsarrazin (talk) 09:15, 31 May 2013 (UTC)

removed the constraint. add it again if you find a solution for organizations. --Akkakk 17:17, 19 June 2013 (UTC)

Multiple values[edit]

People with multiple identities (e.g. those using pseudonyms) generally have several records in ISNI database. Since this is not just an exception, I assume, the unique value constraint check should not be applied here.--Shlomo (talk) 08:37, 1 October 2013 (UTC)

Do you mean {{Constraint:Single value}}? — Ivan A. Krestinin (talk) 18:43, 1 October 2013 (UTC)

Yes, I did... My mistake, sorry for troubling and thanks for correcting me.--Shlomo (talk) 19:30, 1 October 2013 (UTC)

Restricting regex to ASCII[edit]

OLD \d\d\d\d \d\d\d\d \d\d\d\d \d\d\d[\dX]
NEW [0-9]{4} [0-9]{4} [0-9]{4} [0-9]{3}[0-9X]

Further reading https://www.regular-expressions.info/shorthand.html 85.179.115.121 21:23, 27 April 2018 (UTC)

Why not (\d{4} ){3}\d{3}[\dX]? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 1 June 2018 (UTC)

In most regex implementations, [0-9] is more specific than \d since the latter also matches digits in non-latin scripts (example: \d matches ۸ = 8 in Persian (Q9168)). I guess ISNI allows only latin-script digits. The rest is probably personal flavor: the longer version is easier to understand, while the compact one looks more sophisticated. It does not really matter which one is used here. —MisterSynergy (talk) 12:13, 1 June 2018 (UTC)

Item requires statement constraint[edit]

I've gone ahead and removed item-requires-statement constraint (Q21503247):VIAF ID (P214) because, having examined a sample of 90 ISNIs, I found that 15% of them didn't in fact have a corresponding VIAF ID. 15% is a lot of exceptions. — Levana Taylor (talk) 15:52, 13 October 2020 (UTC)

Link to ISNI Registration Authority[edit]

URL[edit]

(noted by user:Reptilien.19831209BE1 at WD:Bistro) Most ISNI database entries appear to be available at 2 URLs: either isni.org/xx [5] or isni.org/isni/xx [6]. Currently the link is set to format the first one, but in some cases, only the second one appears to work ([7] / [8]). So, can I change MediaWiki:Gadget-AuthorityControl.js to format 2 ? -Zolo (talk) 16:30, 11 July 2014 (UTC)

ISNI-test[edit]

I notice that there are some items with "ISNI-test" on viaf.org, e.g., Vibeke Klint (Q19590089) [9]. I added the ISNI in this case, but the link Reasonator constructs for the ISNI http://www.isni.org/000000011499485X does not resolve: "Page not found". What does this mean? Should ISNI of viaf.org be avoided? — Finn Årup Nielsen (fnielsen) (talk) 20:13, 14 March 2015 (UTC)

Update: When searching with http://www.isni.org/search I can find 0000 0001 1499 485X. — Finn Årup Nielsen (fnielsen) (talk) 20:15, 14 March 2015 (UTC)

http://isni.org/000000011499485X resolves fine for me. Eldizzino (talk) 15:12, 31 May 2015 (UTC)

Problem[edit]

The link to Isni item leading to error. Look like the link format was changed.Geagea (talk) 02:27, 9 December 2016 (UTC)

It still works for me. Can you provide a link which doesn't work? --Pasleim (talk) 09:53, 9 December 2016 (UTC)

Exaples:

Q12411778 --> ISNI leads to this
Q20 --> ISNI leads to this

Geagea (talk) 23:15, 9 December 2016 (UTC)

I'm getting an error as well - "Your data limit has been reached". Manually searching on the ISNI site returns valid results, though. Looks like it's rejecting the direct links for some reason. Andrew Gray (talk) 16:19, 11 December 2016 (UTC)

Both work ok now --Vladimir Alexiev (talk) 16:15, 25 June 2020 (UTC)

Property example[edit]

Property Example[edit]

Why does the current Property Example here point to the country Norway? The ISNI used there is "0000 0001 2298 9524" with a reference of Imported from VIAF. However, the corresponding link http://isni.org/0000000122989524 goes to a page containing Creation class: "Musical sound recording" and Creation role: "author, musician", which seems to indicate that this value is not a country. -- Perhaps the item for USA would be a better example. On the face of it, it seems to have a P213 pointing to an ISNI page which might be correct: http://isni.org/0000000123315230. On the other hand, I can't see any particular semantic information on that page to verify that this is indeed the correct item/entity. (There is no "Creation class" on that page, for one.) I tried to use the search form on the ISNI page to search for potential conflicts, but the search form does not work, at least not for me. How should these property values be verified? Fred Johansen (talk) 14:53, 15 July 2015 (UTC)

Property example including X[edit]

Changed one human example to one where the ISNI includes an X. Example taken from English Wikipedia. https://www.wikidata.org/w/index.php?title=Property:P213&diff=728502505&oldid=724397681 77.180.221.5 10:44, 18 August 2018 (UTC)

Data type[edit]

Shouldn't the data type be External identifier not String? Pinging user:Tpt as creator. -- Netoholic (talk) 07:08, 14 April 2016 (UTC)

Yes definitely. It is an ID on the same level as ISBN-13 (P212) or ISO 639-1 code (P218). Tpt (talk) 08:19, 14 April 2016 (UTC)

Hello, I agree. How can we change that ? --Daehan (talk) 08:17, 13 June 2016 (UTC)

Double-check procedure (and previous decisions) at Wikidata:Identifier migration. -- LaddΩ chat ;) 11:23, 13 June 2016 (UTC)

Follow-up at: Wikidata:Identifier_migration/0#ISNI. -- LaddΩ chat ;) 11:35, 13 June 2016 (UTC)

Adding values to items[edit]

Importing ISNI ids from GRID[edit]

I am going to import ISNI identifiers from the GRID dataset: all items that have a GRID ID (P2427) and no ISNI (P213) will receive a ISNI (P213) if there is a unique ISNI for that GRID id in the latest dump. − Pintoch (talk) 19:49, 1 February 2017 (UTC)

Still that links do not work, same problem as above. --MovieFex (talk) 23:36, 2 February 2017 (UTC)

The fact that the resolver blocks direct links is not a reason to remove the statements using that property. Can you please stop reverting my edits? Thank you! − Pintoch (talk) 23:43, 2 February 2017 (UTC)

ORCID[edit]

Great news: ISNI now provides ORCID corresponding ID for researchers. Enjoy! Nomen ad hoc (talk) 16:08, 14 January 2018 (UTC).

YouTube and ISNI[edit]

YouTube has become an ISNI registry, and will begin creating ISNI IDs for the musicians whose videos it features [10]. They anticipate the number of ISNI IDs "going up by perhaps 3-5 million over the next couple of years" as a result [11]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 1 June 2018 (UTC)

Which is one of the reasons why I think ISNI should no longer be considered an important identifier. If all it takes is a MusicBrainz or YouTube account to get an ISNI, we'll never be able to delete anyone. Quakewoody (talk) 19:18, 8 July 2020 (UTC)

formatter URL[edit]

Hi,

I do not know for before, but today the url http://isni.org/$1 (see http://isni.org/0000+0001+2259+0564) works well, so we can modify the formater Url to remove wmflabs, agree ? — eru ^{[Talk] [french wiki]} 19:44, 16 March 2019 (UTC)

URL broken 2020-06-07 - proposal to switch to LD URL[edit]

Notified participants of WikiProject Authority control

ISNI recently changed their website: Wikidata talk:WikiProject Authority control#ISNI new website. The entities were displayed at isni.oclc.org/ ... Now that changed, see:

https://www.wikidata.org/wiki/Q94855634#P213
click the value, pointing to http://www.isni.org/0000+0000+7820+432X
ending at http://www.isni.org/isn/0000+0000+7820+432X (isn!), message:

This page isn’t working
www.isni.org redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS

The final URL currently is at https://isni.org/isn/000000007820432X/ (isn!)
The URL displayed on the page is http://isni.org/isni/000000007820432X
The value in bold on the page is 000000007820432X

The following four URLs work fine:

http://isni.org/isni/000000007820432X (LD URL, advertised)
https://isni.org/isni/000000007820432X (httpS version of LD URL)
http://isni.org/000000007820432X
https://isni.org/000000007820432X

Could WD just use the advertised LD URL instead of the current linking to + + +, with the slight variation of using HTTPs for security and privacy reasons? MrProperLawAndOrder (talk) 12:16, 7 June 2020 (UTC)

@MrProperLawAndOrder: Given that the ISNI values we use contain spaces between groups of four digits, there are two options:

change regex and remove spaces from all our values (nearly 2.5 M edits, which requires a lot of work and time)
change formatter URL, probably using https://wikidata-externalid-url.toolforge.org/ (requires only one edit)

I would strongly support option 2. --Epìdosis 12:29, 7 June 2020 (UTC)

Oppose option 2 - yet another hack. More privacy and security issues, since users are routed via another service. Breaks LD interoperability. It also is waste of computing power, isn't energy efficient. MrProperLawAndOrder (talk) 12:52, 7 June 2020 (UTC)
Can you tell us about the privacy and security issues that you see here? The energy efficiency to write a comment here is certainly higher than a simple redirect via the toolforge server, that is likely true. --Sotho Tal Ker (talk) 16:17, 7 June 2020 (UTC)
Somewhat counterintuitively, phab:T112081 (pages are not re-rendered when the formatter URL changes) means that #2 doesn't actually gain us much - to make the changes propagate to pages we'd need 2.5m null edits anyway :-). However, option 1 involves removing the spaces. I personally have no objection to this (we remove the ISBN dashes, after all) but I believe this is something that's been pretty contentious before (see earlier on this talkpage) so I would be careful doing this without clear consensus - otherwise there will probably be a lot of shouting later on. Andrew Gray (talk) 13:03, 7 June 2020 (UTC)
Andrew Gray, thank you for pointing out that it doesn't re-render and for the report on ISBN. One should research other ISO IDs that come in different formats: IBAN, ISWC, ISRC, maybe more. There is now a section MediaWiki:Wikibase-SortedProperties#ISO IDs. MrProperLawAndOrder (talk) 13:13, 7 June 2020 (UTC)

That is nothing new. Pages get only rerendered if there have been edits on them. The same behavior happens for any edits on a property like changing the label. --Sotho Tal Ker (talk) 00:41, 8 June 2020 (UTC)
Support option 1 - fix it once and be done forever. It seems to be an issue since 2013, and the spaces inserted with massive bot edits by Maximilianklein / VIAFbot (bot not editing for long time, user almost absent) and Ivan A. Krestinin / KrBot (bot currently blocked for other external-id edits). MrProperLawAndOrder (talk) 13:10, 7 June 2020 (UTC)

The spaces are a longstanding and well-discussed community consensus. There's no reason to imply this is something which particular users have forced through bot edits, or that their current activity level has anything to do with whether the edits were good or not. If you think making the change is good, fine, but don't randomly attack other people to justify it. Please see Wikidata:No personal attacks. "Do not make personal attacks anywhere in Wikidata. Comment on content, not on the contributor." Andrew Gray (talk) 13:27, 7 June 2020 (UTC)

@Andrew Gray:, longstanding, yes, and I claimed, mostly made by bots. Can you show a diff for your claim "well-discussed community consensus"? Accusing me of randomly attacking when the evidence for what I claim is right on this page, could constituted a violation of "No personal attacks" itself. Waiting for your evidence. MrProperLawAndOrder (talk) 13:38, 7 June 2020 (UTC)

There are discussions on this page about whether spaces are appropriate, and as the matter has rested as "we include spaces" for years, that is a pretty good sign of community consensus. But you can also read this 2016 discussion, this 2017 discussion, this 2018 discussion, and no doubt many more. Let me be clear - I'm not saying "oh, we can't do this"; I'm saying that there has been a lot of discussion on this in the past, and you might not be aware of it, so we should tread carefully before overturning what seems to be a stable and well-discussed consensus.

Labelling users as "user almost absent" or "bot currently blocked" is what I was referring to, and it is clearly not appropriate commentary because it is fundamentally irrelevant to whether the current URL format is desirable. Andrew Gray (talk) 13:59, 7 June 2020 (UTC)

I referred to

2013-03-25 "Yes, I am fixing this ... Maximilianklein 18:39, 25 March 2013 (UTC)"
2013-05-06 VIAFbot operated by Maximilianklein [12]
2014-12-07 "So, I think 0000 0000 0000 000X format is more preferred than 000000000000000X ... Ivan A. Krestinin (talk) 14:03, 7 December 2014"
Krbot doing replacements

Thanks for bringing up the various discussions, yet more evidence of the problems surrounding the current spaced implementation. BTW: In 2014 Ivan wrote "changing format in 250000+ items is global operation", today user:Epìdosis wrote "nearly 2.5 M edits, which requires a lot of work and time".

Re "bot currently blocked" - it is a sign, that the situation was created by a bot, operated no only once without proper consensus, but by what the operator thought was right. MrProperLawAndOrder (talk) 14:24, 7 June 2020 (UTC)

The bot being blocked has nothing to do with adding spaces to ISNI values. The current situation was not "created by a bot", there have been many discussions about this, as shown above. Instead of converting the values manually by editor monkeys, a bot task was implemented according to the agreed standards. While there have been a few complaints and remarks regarding spaced values, no one ever made a serious attempt to get this changed. --Sotho Tal Ker (talk) 00:41, 8 June 2020 (UTC)

@Sotho Tal Ker: 1) "The bot being blocked has nothing to do with adding spaces to ISNI values." - the blocked bot did add the spaces. 2) The point isn't that discussions took place, but that consensus was reached prior to bots starting their operations. I see no such consensus reached before the two mentioned bots started their operations. MrProperLawAndOrder (talk) 14:14, 8 June 2020 (UTC)

The bot was not blocked because of adding the spaces. If you fail to understand that, then I cannot help you and any further discussion is useless. No one made any objections when that task was implemented and executed. This is called implicit consent. --Sotho Tal Ker (talk) 19:31, 8 June 2020 (UTC)

Re "user almost absent", actually I wrote "(bot not editing for long time, user almost absent)", implying that the bot and the user are not contributing to the current spaced value insertion anymore.

MrProperLawAndOrder (talk) 14:24, 7 June 2020 (UTC)

Comment Since the usability of the ISNI website is limited, WD itself could become a service for others to find out more about a given ISNI. Currently the spaces inhibit using the standard resolver, try https://wikidata-todo.toolforge.org/resolver.php?prop=213&value=000000007820432X MrProperLawAndOrder (talk) 13:45, 7 June 2020 (UTC)
I prefer option 1, but can live with option 2. --Sotho Tal Ker (talk) 00:41, 8 June 2020 (UTC)
IMHO, we have to be patient: there is a redirect error, and they have to publish something more, like the APIs.

I wrote them the following email:

Hi, as promised, your new website is up and running. With compliments!
The Wikidata community has started a discussion about changing the url formatter of P213 (ISNI) property, since it is now broken. However, I noticed that possibily there are issues in redirects and URI, due to the use of "isn" (not "isni") string.
My proposal: please publish URI and RWO for a given ID, and check the chain of redirects, that in some cases seems to enter an infinite loop. E.g.:

http://www.isni.org/isn/0000+0000+7820+432X
This page isn’t working
www.isni.org redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS

Thx. Best regards. Stefano

-- Bargioni 🗣 14:09, 8 June 2020 (UTC)

Here is their immediate reply:

Hi Stefano,

Thanks so much for these observations and for your interest in ISNI. We are actually still busy in trouble-shooting redirects in the new configuration, so I'd ask your patience whilst we work our way through them. I'm going to refer your email to two of my more-technical colleagues and we'll get back to you as soon as we can.

all best wishes
Tim

-- Bargioni 🗣 14:30, 8 June 2020 (UTC)

For years they created problems for ISNI users. Instead of publishing and using one URL (https://isni.org/000000012146438X) they used several others. oclc.nl, oclc.org, http, www, /isni/ - Now they came up with one more URL using /isn/ and a slash at the end https://isni.org/isn/000000012146438X/ - . And the current system uses a frame, if one searches within the frame, the URL shown in the browser doesn't match the content. MrProperLawAndOrder (talk) 15:20, 8 June 2020 (UTC)

@Bargioni, Sotho Tal Ker, Epìdosis, Andrew Gray: if WD would store the values as is done by VIAF, GND, BNF and probably any other decent system,

WD would not rely on them caring about obscure links containing + + + and users emailing them, it's not the first time ISNI IA managed to break links
WD data would be closer to standard LOD data
WD would require less storage space : How much is it per 1 million ISNI? Live data, dumps, third parties using the dumps. Sure it is only a fraction of all data, but it adds no value, and the fraction is higher for people only using a part of the data, e.g. those item that have an ISNI and the items they link to
WD data could be matched with other databases on a field ISNI stored as 16 digit
WD search would be more reliable : the 16-digit string is less likely to appear on unrelated items than the four subgroups of 4-digits each; and probably it would be faster since the input would be treated as one "word" and not four
WD search index would require less storage space
WD could be a resolver for the 16-digit values using standard tools for linking by property value
WD SPARQL using VALUES would be shorter to write
WD property would have a shorter regex

Yes, the transition is work, but afterwards, WD would be more robust, more standard conform, more climate-friendly. MrProperLawAndOrder (talk) 14:52, 8 June 2020 (UTC)

@MrProperLawAndOrder, Epìdosis: As noted above, this was a perennial problem here - and was one of the original issues that motivated the creation of the wikidata-externalid-url service as the isni.org website never used to support the spaced format. However, ISNI itself states that the official display format includes the spaces, so to the extent UI's pull ISNI's from Wikidata (the Wikipedia authority control templates) then it makes sense for us to keep in the spaces; also it's easier for users to cut-and-paste the ID's from the various sources that display things as ISNI itself states it should be. On the other hand ISNI also recommends using the format without spaces for storing in databases. So either way is fine with me I guess, but there does seem to be a long-running community consensus to keep the spaces in here. But it looks like right now we mainly need to just wait for them to fix their website. If you go to wikidata-externalid-url.toolforge.org one of the examples is an ISNI case, which works, so feel free to adjust the formatter URL here to use that again if wanted. ArthurPSmith (talk) 15:23, 8 June 2020 (UTC)
@ArthurPSmith: "ISNI itself states that the official display format includes the spaces," - What do you mean with "ISNI"? The standard defining ISNI is ISO 27729:2012 found at https://www.iso.org/standard/44292.html . I the term "display format" part of the standard? What else does it say about such a display format? Only including spaces but not following other requirements of the format would mean creating another format that is not ISO compliant. When is it to be used? For IBAN one can find https://www.ecb.europa.eu/paym/integration/retail/sepa/iban/shared/pdf/iban_registry.pdf : IBAN electronic format and IBAN print format - the WD database clearly is electronic. MrProperLawAndOrder (talk) 15:57, 8 June 2020 (UTC)
@MrProperLawAndOrder: I can't find it on their rearranged website, but they used to have some (?) of the text of the associated ISO standard available. It does appear to be online here at least for now. The relevant paragraph states: "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." ArthurPSmith (talk) 16:39, 8 June 2020 (UTC)
@ArthurPSmith: if this is coming from ISNI IA they have no clue what they talk about. How would the environment storing a value know if the value is displayed to a human? How would it work, if a value is stored in a database, WD is a database, and a human decides to have the value from the database displayed, shall the database fake what is actually in the database? MrProperLawAndOrder (talk) 16:45, 8 June 2020 (UTC)
@MrProperLawAndOrder: I agree it's confusing; however, my understanding was that this paragraph is taken directly from the ISO standard - ISO 27729:2012, though ISO doesn't generally provide them online for free which makes it harder to cite and confirm. ArthurPSmith (talk) 16:56, 8 June 2020 (UTC)

Breaking update: URL no more broken[edit]

Notified participants of WikiProject Authority control Hi all! I've just updated the formatter URL to https://isni.org/isn/$1 and the redirect works; also our old formatter URL http://www.isni.org/$1 works well. As a consequence, the adoption of either option 1 or option 2 is no more enforced by the need to have a working URL. However, the discussion may remain open in the following terms: considering that both solutions work well, do we prefer to maintain current IDs with spaces or to delete the spaces? --Epìdosis 15:35, 8 June 2020 (UTC)

I changed it to https://isni.org/isni/$1 closer to the LD URL. MrProperLawAndOrder (talk) 15:46, 8 June 2020 (UTC)

@Epìdosis: I could only tell what I would prefer. The current values are not ISO compliant and, I would prefer that WD does not store misinformation. MrProperLawAndOrder (talk) 16:01, 8 June 2020 (UTC)

What misinformation do you mean? Just because the values are not stored in your preferred format does not make it any "misinformation". And can you show us the source which states that all information in Wikidata has to be stored in an ISO compliant format? --Sotho Tal Ker (talk) 19:38, 8 June 2020 (UTC)

Re "What misinformation do you mean?" - the misinformation stored in WD's P213 property page and that stored using this property

Re "And can you show us the source which states that all information in Wikidata has to be stored in an ISO compliant format?" - I don't know who is "us", I don't know of such a source, and I don't even see a presentation of the relevance for such a source - if it would exist at all- for the discussion about P213 taking place in this section. MrProperLawAndOrder (talk) 20:54, 8 June 2020 (UTC)

Support I suggest to store ISNI in P213 using the original code, without spaces, since storage is not display. I never add display reasons in my data stores. It is very simple to display an ISNI divided in 4 blocks of chars. It is absurd to enter them, say, in a WD SPARQL query having to add white spaces. Most important, they cannot be immediately reused elsewhere. In library catalogs ISNI is stored as is. -- Bargioni 🗣 21:40, 8 June 2020 (UTC)
Finally Support the form without spaces, I've been convinced by @MrProperLawAndOrder: (especially point 1 and 3) and @Bargioni:: basically, we can store values more compactly without spaces and, if wanted, spaces could easily be visualized through some gadget. I think it is the best solution to the two suggestions by ISNI itself reported by @ArthurPSmith: above: "ISNI also recommends using the format without spaces for storing in databases" (so we store them without spaces) and ""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." (so we can find some way to display this visualization in a second time, after having stored the IDs in the most compact way, without useless spaces). --Epìdosis 21:47, 8 June 2020 (UTC)
Support for most of the reasons listed by @MrProperLawAndOrder: --Carlobia (talk) 06:26, 12 June 2020 (UTC)

URL broken 2020-06-11 - proposal to switch to LD URL[edit]

Notified participants of WikiProject Authority control

each results in ISNI error page

Page Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

redirect to

Proposal: Remove spaces, resulting in + + +, from P213. MrProperLawAndOrder (talk) 23:06, 11 June 2020 (UTC)

As above, @Bargioni: and I Support the removal of spaces. --Epìdosis 23:09, 11 June 2020 (UTC)

Implementing ISNI 16-digit no space - Discussion[edit]

User:Epìdosis, Jura1 just restored the section he started and removed his comment from here [13], taking away some context of your reply. MrProperLawAndOrder (talk) 18:40, 12 June 2020 (UTC)

@Jura1, MisterSynergy: I agree with you: such a big change, involving over one million items, needs to be discussed at least for one week before being implemented. The discussion can take place in this section. --Epìdosis 09:56, 12 June 2020 (UTC)

User:Epìdosis it is an urgent fix. Your opposition means people actually working on ISNI links have their work disrupted. Editors not clicking on the links, maybe don't care. 1.2 million links broken, fix is very easy and was already started. MrProperLawAndOrder (talk) 20:56, 13 June 2020 (UTC)

I also would urge a bit more caution here, though it's probably the right thing to do. How about posting a notice on Project Chat? Also weekends tend to be quiet so maybe Monday would be better to ask for any further input on this proposal? ArthurPSmith (talk) 17:05, 12 June 2020 (UTC)

@ArthurPSmith: "I also would urge a bit more caution here" - what more caution? Where is the indication for "more caution" being helpful? There is a consensus, and the implementation was very carefully started. Removal of spaces is nothing complicated, autofix, a bot etc. - these details have their subsections here. Much more transparent than the 2013 enactments of some format - and based on a much more technical, fact-based discussion. MrProperLawAndOrder (talk) 23:07, 13 June 2020 (UTC)

@MisterSynergy, ArthurPSmith, Epìdosis: the insinuation by Jura1 that it may have been done "lightly" and that I am not a trusted user is a personal attack against my work in Wikidata by said user.

1.2 million links broken, what is the purpose of these 1.2 million broken links? Does Wikidata not have an obligation to minimize disruption, to deliver URLs that resolve, to its readers and the other parties that re-use the data. "Also weekends tend to be quiet so maybe Monday would be better to ask for any further input on this proposal" - Friday is not weekend and how many more Mondays are needed, as the proposal was made on 2020-06-07, a Sunday? How long do you plan to delay? Where are the reasons against delivering a resolvable URL? And if weekend is low-activity (quiet), it is the ideal time to have a bot run without using the always scarce hardware resources. MrProperLawAndOrder (talk) 17:27, 12 June 2020 (UTC)

@MrProperLawAndOrder: URL no more broken using https://isni.oclc.org/xslt/DB=1.2//CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A$1, which I've introduced right now. Of course I still support the removal of spaces, but I also think we can wait at least one week, also considering that the links are broken no more. --Epìdosis 17:37, 12 June 2020 (UTC)

@Epìdosis: not true for those rendered here, has been mentioned during the last five days on this talk page, Thousands even use www.isni.org https://www.wikidata.org/w/index.php?title=Special:LinkSearch&limit=500&offset=0&target=http%3A%2F%2Fwww.isni.org%2F MrProperLawAndOrder (talk) 17:45, 12 June 2020 (UTC)

@Epìdosis: your fix indeed doesn't seem to have fixed things - even with a purge on a page I'm still seeing the old broken links. Is the Wikidata UI ignoring the preferred vs. normal ranks of the two statements? You might have to deprecate the isni.org link for now. Note that the wikidata-externalid-url formatter does still work as it rewrites to the no-spaces format for ISNI, so feel free to switch to that. ArthurPSmith (talk) 19:33, 12 June 2020 (UTC)

@ArthurPSmith: the reason is given in the comment preceding yours. I reverted. MrProperLawAndOrder (talk) 19:48, 12 June 2020 (UTC)

At this point, it is not clear to me whether the Wikidata identifiers that worked for seven years are broken, or ISNI's software update was not done properly.
Anyways, since ~1.3 million claims would need to be edited, we need to consider our limited edit resources. 1.3 million edits correspond to roughly 1.5 days of edit resources for entire Wikidata; in other words: once this would be done, *everything* else in this project would be delayed by 1.5 days minimum. Also mind that there are no timeframes these days with "low" activity, as the servers are pretty much always running at their limits since months.
The task would also require a bot flag, which needs a couple of days of discussion before being granted. —MisterSynergy (talk) 17:42, 12 June 2020 (UTC)

@MisterSynergy: ISNI has recently renewed its website and the redirects from the URL we use (containing spaces) to the URL they use as preferred (not containing spaces) are evanescent in these days; I think that hopefully the problem should be solved in the next few weeks. However, obviously the question of which form of ID is more convenient for us to store remains actual, if not dramatically urgent. --Epìdosis 17:48, 12 June 2020 (UTC)

@Epìdosis, MisterSynergy: the site change was one operation and the + + + URLs worked again little time after Bargioni did email ISNI IA/editeur. But as pointed out, it wasn't the first time they disrupt resolution of their URLs and I said - not broken until they break it again. Exactly that happened ~3 days later, support for + + + was removed. https://isni.org/isni/0000+0001+2146+438X broken. They also changed redirect chains, their LD URLs is http://isni.org/isni/000000012146438X it was ending at https://isni.org/isn/000000012146438X/ at the beginning of the week, now it redirects to isni.oclc.org.... There is one URL promoted in the data sheet, field "ISNI:" and that is http://isni.org/isni/000000012146438X . For security and privacy I suggested to alter it using httpS - but otherwise change nothing. These kinds of URLs are used in VIAF, GND, BnF. MrProperLawAndOrder (talk) 18:30, 12 June 2020 (UTC)

@MisterSynergy: "The task would also require a bot flag, which needs a couple of days of discussion before being granted." - DeltaBot is set to insert spaces, see below section for Bot. One could turn DeltaBot to remove them by editing a page which DeltaBot seems to base its edits on. MrProperLawAndOrder (talk) 18:34, 12 June 2020 (UTC)

The bot code itself is not much of a problem, as this is a fairly simple task. —MisterSynergy (talk) 20:32, 12 June 2020 (UTC)

@MisterSynergy: "At this point, it is not clear to me whether the Wikidata identifiers that worked for seven years are broken, or ISNI's software update was not done properly." - The WD URLs are broken, WD used an undocumented hack, it stopped working. Not a single P213 using space ever linked to isni.org according to linked data principles. It seems the software cannot remove the spaces via formatter. MrProperLawAndOrder (talk) 18:45, 12 June 2020 (UTC)

Can this please be presented in a comprehensive way, including references for the main points so that a casual user is able to follow the process? Given that ISNI is a relatively large player in the identifiers game, I reckon there should be some public documentation for the redesign.
More in general, I do see chances that we might move to the non-spaced version of the identifiers. Yet, this should not be done in a hurry; it needs a thorough vote that includes a comprehensive motivation why we should do this heavy operation and a relatively detailed action plan, it also needs a couple of announcements, and finally the implementation. I would be willing to provide input for most of these steps, but I am not going to be the main proponent for this operation. —MisterSynergy (talk) 20:32, 12 June 2020 (UTC)

@MisterSynergy: "action plan" : places needing adjustment are mentioned below, actions have been implemented and requested. There was a vote, for removing the spaces, more votes and more substance than seen above in 2013 when one user decided to use a bot to mass-insert the spaced-ISNIs. It was twice in one week that one user detected that a change at isni.org broke the links and reported it here. Others didn't. That user presented thoughts about the general direction, Epidosis proposed to remove the spaces, voting took place, no one objected. When the URLs were broken the second time, the implementation started. But an abuse filter and an editing restricted bot-managing page required action by users with more editing rights. Then a previously uninvolved user started reverting the fixes, clearly against consensus, included leaving an attack against the fix-implementer right on the page. 1.2 million broken since several hours. Four admins involved. But the already installed fixes reverted and the needed other changes not done. And no-one objecting in Property talk:P213#URL broken 2020-06-07 - proposal to switch to LD URL, the place for discussing whether to do it, as the section Property talk:P213#Implementing ISNI 16-digit no space is for the implementation. People stop the well planned implementation, and revert the as, far as normal editing rights are involved, correctly enacted parts of the implementation, claiming no consensus. But there is zero vote against removing the spaces. Is removing the spaces a consensus that shall exist for some more time? Is there no consensus because talking didn't take place for long enough time? It is a special situation: alone on wikidata.org 1.2 million links broken. Any delay means disruption to editorial processes - people cannot verify if an ISNI is correctly placed by clicking a link, and disruption anywhere else where the data is used with the WD formatter. MrProperLawAndOrder (talk) 22:38, 12 June 2020 (UTC)

Strongly agree that we should slow down and take some time to discuss this. The faster we rush it through, the more chance we make a mistake, or that we miss a really pressing reason to do it some other way and have to change over. I don't want us to have to do 1.5m edits twice just because we're hasty... Andrew Gray (talk) 22:24, 12 June 2020 (UTC)
@Andrew Gray: you are free to present substantiated reasons against the proposal by Epidosis to remove the spaces in the section Property talk:P213#URL broken 2020-06-07 - proposal to switch to LD URL. Citing you "However, option 1 involves removing the spaces. I personally have no objection to this (we remove the ISBN dashes, after all) but I believe this is something that's been pretty contentious before (see earlier on this talkpage) so I would be careful doing this without clear consensus - otherwise there will probably be a lot of shouting later on. Andrew Gray (talk) 13:03, 7 June 2020 (UTC)". Six days, no one objected. MrProperLawAndOrder (talk) 22:43, 12 June 2020 (UTC)

I said there would be shouting, and lo and behold, there was shouting. I don't care what you decide to do about spaces or no spaces, I just wanted to make it clear it was a sensitive issue and shouldn't be rammed through without proper discussion. I am not going to engage in this further because it's very tiring and frustrating, so please do not tag me again in this discussion. Andrew Gray (talk) 12:01, 13 June 2020 (UTC)

Implementing ISNI 16-digit no space - Bot[edit]

User:DeltaBot mentioned in the #Documentation section.

Informed: Topic:Vo3z27bjobf4uxr9 MrProperLawAndOrder (talk) 00:54, 12 June 2020 (UTC)
Despite the invitation on User:DeltaBot "For programmers" ... "add new jobs to User:DeltaBot/fixClaims/jobs" and me being a programmer, the editing of the page was restricted and I couldn't add a job, nor change the one that inserts spaces. MrProperLawAndOrder (talk) 01:02, 12 June 2020 (UTC)
@Matěj Suchánek: can you adjust the page? MrProperLawAndOrder (talk) 02:53, 12 June 2020 (UTC)
Are you done at WD:DEV#Conversion to external-id (June 8)? --Matěj Suchánek (talk) 08:14, 12 June 2020 (UTC)
@Matěj Suchánek: that is not an answer to my question. Please show the connection or ask things related to Conversion to external-id (June 8) there. MrProperLawAndOrder (talk) 17:31, 12 June 2020 (UTC)
The connection is you. Sorry but I lack trust in you. I won't do this without prior community's acceptance. --Matěj Suchánek (talk) 09:21, 18 June 2020 (UTC)

Implementing ISNI 16-digit no space - Abuse filter[edit]

Tried to remove the spaces in Q57188#P213, but could not save:

Could not save due to an error. The save has failed. Your action has triggered the Abuse Filter This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Inappropriate ISNI (P213) change

@Epìdosis, ArthurPSmith: can you help? MrProperLawAndOrder (talk) 00:21, 12 June 2020 (UTC)

@MrProperLawAndOrder: I don't know anything about the abuse filter, but could you please WAIT until we really have a consensus on this? Another week as suggested above won't hurt. ArthurPSmith (talk) 17:07, 12 June 2020 (UTC)
@ArthurPSmith: the data above shows consensus, no oppostion. There are 1.2 million external links broken, not counting the places where the Wikidata data is re-used, and such information might be hard to obtain. Not fixing bugs is not in the general spirit of WMF-wikis. Two users MisterSynergy and Jura1 reverted/disrupted my fixes. They didn't say what the benefit is. MrProperLawAndOrder (talk) 17:36, 12 June 2020 (UTC)
@MrProperLawAndOrder: People reverting your changes indicates you have not achieved consensus here. Think about it, and just be a little more patient. If Wikidata users hadn't been so impatient to switch to ISNI's own resolution service which has now been broken by ISNI, we wouldn't have any broken links. ArthurPSmith (talk) 17:43, 12 June 2020 (UTC)
@ArthurPSmith: reversions are no indications for that. A consensus is reached via talk, the proposal to switch has been made, people agreed, no one voted against. URL was broken again, so the proposal was implemented to reduce harm. Then two users jump in and revert, one the autofix the other the settings on the properties. MrProperLawAndOrder (talk) 17:56, 12 June 2020 (UTC)
People don't need to use Oppose to indicate something has not yet been resolved. You yourself never responded to my notes about the ISNI standard requiring the spaces in "human-readable" display - if we make the proposed change, then everywhere ISNI's are displayed to humans in Wikimedia services will violate that ISNI standard. How do you propose to resolve that? You haven't addressed it at all. ArthurPSmith (talk) 18:01, 12 June 2020 (UTC)

Format change[edit]

I undid the autofix added above to chnage the format of this property. I don't think such a change should be done lightly. This needs to be reviewed by trusted users before. --- Jura 05:20, 12 June 2020 (UTC)

Reverting formatter changes?[edit]

I attempted to replace the formatter URL with something that would actually work under the current situation (since it has been claimed that our 1.2 million "broken links" are a big problem) and was reverted. Another attempt along the same lines was also reverted. There does seem to be a problem with the formatter URL value not taking effect immediately, but we could at least have working URL's in principle here if we wanted to without doing millions of edits to items. ArthurPSmith (talk) 18:02, 15 June 2020 (UTC)

It looks like the current formatter URL is working at least for now (see the property examples on this page). ArthurPSmith (talk) 12:55, 22 June 2020 (UTC)

@ArthurPSmith: I confirm, the current formatter URL works well, mainly because it is based on the old website, which seems stable. --Epìdosis 16:30, 22 June 2020 (UTC)

What does ISNI IA say?[edit]

Hi folks, lots of heated discussion here about those spaces. Let's not make a rash decision based on some breakage at the ISNI site.
If someone has a working connection to ISNI IA, could you please ask them what is the preferred way to store their id's? Do they store them internally without spaces?
Whatever decision we take will have to also be done for ORCID and Crossref Funder id's --Vladimir Alexiev (talk) 16:33, 25 June 2020 (UTC)
- @Vladimir Alexiev: ORCID explicitly includes a '-' between the groups of 4 digits - though it also confusingly claims to be "compatible with" ISNI - see this page - in particular: When stored, the ORCID iD should be expressed as a full https URI: https://orcid.org/xxxx-xxxx-xxxx-xxxx, complete with the protocol (https://), and with hyphens in the identifier (xxxx-xxxx-xxxx-xxxx). As for Crossref Funder id's, I believe those are DOI's, so not related to ISNI at all? ArthurPSmith (talk) 19:42, 25 June 2020 (UTC)

I think the problem is solved as the user was blocked for ban evading. --- Jura 16:50, 25 June 2020 (UTC)

So, let's try to resume the discussion; I don't think "the problem is solved as the user was blocked for ban evading". So, the points are the following:

the formatter URL used until the 8th of June, http://www.isni.org/$1, is now broken using values with spaces (e.g. https://isni.org/isni/0000+0001+1063+2069), not broken using values without spaces (e.g. https://isni.org/isni/0000000110632069)
the formatter URL used at the moment, https://isni.oclc.org/xslt/DB=1.2//CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A$1, works both with values with spaces (e.g. https://isni.oclc.org/xslt/DB=1.2//CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A0000+0001+1063+2069) and with values without spaces (e.g. https://isni.oclc.org/xslt/DB=1.2//CMD?ACT=SRCH&IKT=8006&TRM=ISN%3A0000000110632069)
however, because of phab:T112081 (pages are not re-rendered when the formatter URL changes) most items still use the old formatter URL, so their links are broken
there have been previous discussions about spaces or non-spaces: this 2016 discussion, this 2017 discussion, this 2018 discussion, finally the discussion in the last weeks (and maybe others)
Regarding suggestions by ISNI itself, @ArthurPSmith: said above: "ISNI itself states that the official display format includes the spaces, so to the extent UI's pull ISNI's from Wikidata (the Wikipedia authority control templates) then it makes sense for us to keep in the spaces; also it's easier for users to cut-and-paste the ID's from the various sources that display things as ISNI itself states it should be. On the other hand ISNI also recommends using the format without spaces for storing in databases."
1. In this file by IFLA I read "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".
2. It is thus clear that ISNI suggests storing ISNI IDs without spaces and displaying them with spaces
Given the passage above, three users (@Bargioni, Carlobia: and I) supported removing spaces from our IDs; also @Sotho Tal Ker: expressed his support before the quotation of this passage; re-reading the discussions, I've not found any explicit opinions against the removal of spaces, although many users (@ArthurPSmith, Andrew Gray, MisterSynergy:) correctly underlined the necessity of a longer and more serene discussion, which I hope will now take place

So, let's evaluate pros and cons of removing spaces from our values of ISNI (P213). --Epìdosis 17:36, 25 June 2020 (UTC)

I do not see many cons regarding a change. A few could be that the current form is established in Wikidata, changing the values is a lot of effort from Wikidate side, some third parties might need to adjust their parsers if we change the format, we "violate" the expected display format etc. Regarding the display format, I see that the above excerpt contains the ambigious shall. Nearly every jurisdiction has held that the word "shall" is confusing because it can also mean "may, will or must". It is deemed the preferred display format, but it does not mean we have to show it like that. --Sotho Tal Ker (talk) 18:46, 25 June 2020 (UTC)

@Epìdosis: Just a note on the history - as can be seen from the changes in the formatter URL on this property, and also further up on this page, the wikidata-externalid-url formatter was used until March 2019, so the isni.org URL was only used between March 2019 and June 2020. If items older than March 2019 are using the isni.org formatter that indicates there was some process run to re-update all of those with the new formatter, so I assume that could be done again to fix the current problems (perhaps WMDE does a refresh like this regularly for all properties?) ArthurPSmith (talk) 19:47, 25 June 2020 (UTC)

@Epìdosis, ArthurPSmith: For what it's worth, out of 1221732 items with P213, 1221448 (99.98%!) have been edited since 1 March 2019 (count). So almost all the items will have been "naturally" purged since the last big update - there will be very few that have been completely untouched. I don't think there is any periodic auto-purging to update formatter URLs on items, though it's not a bad idea. Andrew Gray (talk) 21:22, 25 June 2020 (UTC)

Keep the existing format. Changing around formats is just disruptive. The decision on creation may be have been debatable, but for stability's sake, let's keep the existing format. Please adjust the formatter url instead. --- Jura 19:54, 25 June 2020 (UTC)
@Jura1: The formatter URL has already been adjusted, as I said. But how about "The 16 digits of the number are entered in a compact form, without blank spaces or punctuation, and not preceded by the letters ISNI"? I don't think we should keep a format which is explicitly deemed as wrong by ISNI only "for stability's sake". --Epìdosis 22:29, 25 June 2020 (UTC)
- The pros and cons of the two formats were discussed a couple of years back. Wikidata opted for what the standard calls the "display format". It's not wrong, it's just different from what some may prefer. --- Jura 22:42, 25 June 2020 (UTC)
@Jura1: The "display format" is OK as a display format, but is wrong as a storage format, as clearly said by ISNI. I've now read all the discussions I have previously cited (this 2016 discussion, this 2017 discussion, this 2018 discussion) in order to find the discussion about pros and cons of the two formats and here is what I've found:
2016: GerardM claims ISNI (P213) are "[m]alformed" because "they contain spaces" and says "They should do when shown, not when stored. When You click on a source, the website should open correctly". Pasleim replies "the bot preserving a standard format. There are 270,000 statements containing spaces." GerardM replies "It is irrelevant that 270.000 statements are wrong? There should be no spaces at all" and adds "Showing the "correct" format is just a formatting trick. Easily done if you want to do that." Succu says that we should not "change an old and well documented format" because it would be "breaking the usage by other data consumers".
My summary: the only argumentation for retaining spaces is that they are widespread in Wikidata and widely used by other data consumers; however, it has not been demonstrated that other data consumers wouldn't find it easier to use ISNI IDs not containing spaces (!); the fact that they are widespread obviously doesn't guarantee that this standard is correct

2017: an IP complains about "Wikidata-specific format" of ISNI IDs; Jarekt says "I also find "4 groups of 4 digits separated by spaces" format for ISNI quite annoying and it was a pain to add those spaces each time I copy it from a source that does not use spaces." ArthurPSmith replies "It's not a Wikidata-specific thing, it's the standard display format". Also d1g says "We need to follow standards of course, so spaces in ISNI shouldn't be meaningful."
My summary: the only argumentation for retaining spaces is that they are present in the standard display format, which is of course true, but it is a display format, not a storage format, as pointed out before.

2018: an IP complains again about "Wikidata-specific way of storing ISNI"; ArthurPSmith replies "It's not Wikidata-specific, it's the standard ISNI display format, but obviously there are (at least) 2 different ways of representing ISNI as a string and you have to pick just one of them. This one at least makes clear it's a string and not a number (where leading zeroes might be truncated, giving yet a third representation)". The IP replies citing "The characters “ISNI” and the space characters shall not be considered to form part of the ISNI". ArthurPSmith replies "Well Wikidata are certainly not the only ones confused about this then. The GRID institution database, for instance, in its JSON data file or external_ids.csv file, pretty uniformly has ISNI in the space-separated format.".
My summary: ArthurPSmith says that using the display format makes clear that ISNI IDs are strings and not numbers, which is of course true, but again is a feature related to display, not to storage

So, I've then read also the first discussion about this issue, which is the first paragraph of this talk page, #ISNI format: it appears clear that "display format" has been chosen as both display and storage format on Wikidata as it was the best display format. While it is obvious that the display format advised by ISNI (= with spaces) is the best display format, mainly for readability reasons, I've found no argumentation for the display format being also the best storage format, while I've found many reasons for the storage format advised by VIAF (= without spaces) being the best storage format:
ISNI says clearly "The 16 digits of the number are entered in a compact form, without blank spaces or punctuation, and not preceded by the letters ISNI"

removing spaces saves 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)

These four reasons, mainly the first (which can be summarized: storage is not display!), haven't yet been addressed by supporters of the use of display format as storage format. Good night, --Epìdosis 23:36, 25 June 2020 (UTC)

Is it the same banned user/IP you are quoting? Can we stop this?

Unfortunatly Wikidata can display just one format. Clearly the point has been reviewed before and Wikidata opted for the format with spaces. --- Jura 23:43, 25 June 2020 (UTC)

@Jura1: Display format can easily be changed through a gadget, which can be enabled by default in user preferences, with the possibility for user to disable it if they want to. I've now formalized my proposal of format change below. Good night, --Epìdosis 00:09, 26 June 2020 (UTC)

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)

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)
Where have I quoted him here? I've just quoted an official document coming from IFLA. --Epìdosis 08:38, 26 June 2020 (UTC)
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)
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)
Comment a change of format of a well maintained identifier is disruptive for all datausers. --- Jura 00:32, 26 June 2020 (UTC)
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)
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)
@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)
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)
@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)
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)
@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)
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)
- 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)
  - 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)
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)
- Wikipedia? --- Jura 17:13, 27 June 2020 (UTC)
Support Moebeus (talk) 21:11, 27 June 2020 (UTC)
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)

An entity with ISNI should also have a statement VIAF ID. How to resolve this[edit]

--Skancc (talk) 21:00, 6 October 2020 (UTC)

@Skancc: It is not a mandatory constraint, so it indicates something that usually, not necessarily happens. If a VIAF ID (P214) potentially exists for the item, it should be added. If it does not exist, just ignore the constraint. --Epìdosis 21:10, 6 October 2020 (UTC)

Thank you --Skancc (talk) 21:12, 6 October 2020 (UTC)