remove ISBNs status of canonical edition URIs ids

[maxlath]

preferring inv URIs over isbn URIs would have several advantages:

• simplify entities code: by turning ISBN URIs into aliases among other ids, that would let URIs to be either inv or wd, making many things simpler (merge, revert merge, entities and items redirections, etc)
• that would also open the possibility to have several editions with the same ISBN, in cases where the publisher didn't care to observe the 1 edition = 1 ISBN relation rule

Requirements:

• refactor all code depending on get_inv_entity_canonical_uri
• update all items entity attributes to use the inv URI: can be used with a migration checking on an isbn uri to inv uri map, generated from the entities byClaim view

[maxlath]

examples of several editions for one ISBN:

• 978-2-9534848-1-6 (spotted by @belett, which confirmed with the books at hand that it isn't a mistake on Wikipedia >< )
• 978-2-259-45980-8: for this one, the problem is that each data source as a different opinion on what it is
  • Mariage à l'indienne: 1, 2, 10
  • Nuit grave: 3, 4
  • Arithmétique appliquée et impertinente 5
  • Les dépossédés 6
  • L'exilé 7, 10
  • Spirales 8
  • Antéchrista 9, 10
  • La Grotte de Cristal 10, 11

[belett]

In fact, there is (at least) two different situations that broke the 1 edition = 1 ISBN :

• an edition with two corrects ISBN, very rare but it can happen (especially for the 'beaux livres"), "Histoire de Rennes" for instance is printed by two editors each giving an ISBN : 978-2-84398-378-8 for Apogée and ISBN 978-2-7535-1260-3 for the Presses universitaires de Rennes
• an edition with an wrong ISBN printed in it and then a correct ISBN in the database (also rare but common for small publishers), here this is the case mentioned, ISBN 978-2-9534848-1-6 is wrongly printed in the back but ISBN 978-2-9534848-3-0 is the correct one.

The first case is weird but the second case is the most trickiest because when someone has the book in them hands, there is no way to know that the ISBN is wrong.

[jum-s]

2 editors and 2 isbns on one edition, what a funny world we live in.. The "wrong" isbn case happens because of database attempts defined before printing. This a priori definition do not fit the physical world. Can we then say the printed isbn actually is the correct one ? Systems that use code bar scanners would. Human work sourcing and/or editors database sourcing.

[maxlath]

maybe we need to introduce Wikidata-like references in Inventaire data model to say that the cover says something and the database something else ;)

[belett]

Can we then say the printed isbn actually is the correct one ?

In theory, we could. In some cases that could work but most of the time, this would be weird and dangerous.

Here some examples:

• The printed ISBN can be shared between different editions or even different works. 978-2-9534848-1-6 - cited supra - is used by 2 differents books Ur voutailh war an traezh and Naoned Senegal (this kind of case is quite common with "small" publisher).
• The printed ISBN could be invalid. For example De Quimperlé aux Montagnes Noires is printed with "978-2-911210-59-X" where it should be "978-2-911210-59-4" (the check digit was wrongly calculated, they used the ISBN-10 calculation formula for an ISBN-13 :/ ). Not sure how much of the problem this would be, 978-2-911210-59-X is unique to one edition.
• bonus: there is also the case where the printed ISBN doesn't match the barcode... (I don't have an example in mind but I remember that I stumble upon some)

Finally, it depends on what database we talk about, it could be "defined before printing" but also "corrected after printing". For an official database like the BnF catalog - which is in charge of giving and administrating ISBN in France - it almost always the second case.

[maxlath]

@belett:

it's not uncommon for one edition to have multiple ISBN per format [source]

not sure how we should deal with this kind of case

[belett]

On the wikidata side, multiple ISBN per edition should always have qualifiers. Maybe you can use these qualifiers?

[maxlath]

another issue created by ISBN uris, consider the following scenario:

• an item is created with the uri of an edition entity without ISBN
• this edition entity is then associated an ISBN
• the item uri needs to be updated to follow the change of canonical uri, but that's not the case today

This change of item entity uri already happens in the case of an entity merge, but not on entity claims update. Removing the status of canonical uri to ISBN would solve this issue: no more need to update URIs on claims updates

[maxlath]

doing some ISBN cleanup in the database as we got some madness in there:

• due to the update of our ISBN lib groups data, some ISBN hyphenation changed. example:

  require('isbn2').ISBN.parse('9788832821819').codes.isbn13h
  // => '978-88-328-2181-9'
  require('isbn3').parse('9788832821819').isbn13h
  // => '978-88-3282-181-9'

• some ISBN errors due to confusion between 978 and 979 prefixes. example: 978-1-0906-4847-1 instead of 979-10-90648-47-0 I suspect that this kind of error might be the result of organization that assume that all ISBN-13 have a corresponding ISBN-10 (example below from fnac.com), which when reconverted to ISBN-13 get the 978 prefix

this bad conversions 979 ISBN-13 -> ISBN-10 -> 978 ISBN-13 are good candidates to explain all the reports we got for ISBNs that were already used by a different book, especially between the 978-1-0 and the 979-10 groups. Here after, an examples of entities that I had to manually split in the database, because both had where based on 9781090648471 (but with different hyphenation, due to the lib change, yeay):

• https://inventaire.io/entity/isbn:9781090648174
• https://inventaire.io/entity/isbn:9791090648173

[maxlath]

a new illustration of the problem (source)