How to track different books with one ISBN

[Himura2la]

We have a pretty strange item in out library

https://books.hackem.cc/admin/books/249

Our librarian tells that the entire collection has one ISBN for some reason, but there's four books!

Even on Amazon.

I guess it's some kind of deep underground publishing, but we anyway need to track them, preferably as separate books.

Is this somehow possible?

[fabiodalez-dev]

Yes, this works today — the ISBN constraint does not block it.

The ISBN and EAN columns are unique, but a unique index ignores NULLs, and Pinakes stores a missing ISBN as NULL rather than as an empty string. So any number of records without an ISBN coexist, and the identifier simply goes on one of them.

For your four volumes I would do this:

• catalogue them as four separate books, one record per volume;
• put the ISBN on one of them — the set, or volume 1;
• leave the ISBN empty on the other three;
• tie them together with Series (the collection title) and Series number (1 to 4).

Each volume then has its own copies, loans, shelf mark and availability, which is what your librarian actually needs to track. I created exactly this shape on a test install before answering: the four records save normally and stay linked by the series fields.

If someone does try to reuse the same ISBN on a second record, nothing breaks and nothing is silently merged: Pinakes answers with a conflict, says that a book with that identifier already exists, and points at the record that holds it — title and shelf mark included — so the cataloguer can go and check it.

It is also worth saying that your collection is not an oddity of underground publishing. A multi-volume work sold as a single product legitimately carries one ISBN: the identifier belongs to the set, and each volume is described as a part of it. Amazon shows one ISBN for the same reason. Library cataloguing handles it the same way, which is why the one-record-per-identifier rule in Pinakes lines up with practice rather than fighting it.

The one place where the single identifier is felt is the search: on its own, the ISBN only leads to the volume that carries it. That is solvable with what is already there, and I describe how in the next comment.

[fabiodalez-dev]

One addition, and it removes the limitation I mentioned at the end — you can make the shared ISBN findable today, without waiting for any new field.

The catalogue search does not read the ISBN column directly: it reads a denormalised full-text index that folds title, subtitle, authors, publisher, ISBN10/ISBN13/EAN, keywords and the description, and it is rebuilt whenever a book is saved. So if you put the shared ISBN in the Keywords field of the volumes that cannot hold it in the ISBN field, searching that number returns all of them.

I checked it on a test install rather than assuming: with three volumes of the same set — one carrying the ISBN in its own field, the others carrying it as a keyword — a catalogue search for the number returned the volumes that had it either way.

One trap worth knowing, which the same check exposed: write it without hyphens. 9780306406157 and 978-0-306-40615-7 are different tokens for the index, so a search for the plain digits does not match a hyphenated keyword, and the other way round. If your librarian is used to typing the hyphenated form, put both in the keywords field, separated by a space.

Strictly speaking the Keywords field is meant for subjects rather than identifiers, so treat this as what it is: a practical use of an existing field. It costs nothing, it is visible to whoever edits the record, and it keeps the unique ISBN free to do its own job — deciding whether a CSV import row updates an existing book, and resolving metadata lookups to a single record.

[Himura2la]

The workaround you suggested it not much better than the current situation when all four books share a single record: both does not reflect the reality...
If your architecture allows for making ISBN non-unique in this particular "shared ISBN" special situation, that would be much better.

Considering the fact that (according to your own words) this is not a rare case, I believe a mature library system should support this case.

[fabiodalez-dev]

Fair point, and I am not going to defend the workaround as a model of reality: it makes the four volumes findable, it does not make them four properly identified records. You are right that a mature system should describe the set as it actually is.

Let me be straight about what stands in the way, because it is not reluctance, it is architecture.

The uniqueness of ISBN/EAN in Pinakes is not only a database index. It is the assumption that "one identifier resolves to one book", and a large part of the application was built on top of that corollary:

• metadata scraping — every provider fills a record by looking it up with its ISBN, and expects a single target;
• CSV and LibraryThing imports — a row with an ISBN is matched against the catalogue to decide update or insert; with several possible matches, the importer would have to ask, or would silently write into the wrong volume;
• barcode lookup, the public API and the mobile bridge — all resolve an identifier to one record;
• interoperability exports (OAI-PMH, BIBFRAME, FRBR-LRM, OpenURL) where the identifier is what a remote system uses to recognise the manifestation;
• the duplicate guard itself, which today can tell a cataloguer "this ISBN already exists, here it is".

In numbers: about sixty PHP files touch those columns, and a dozen bundled plugins depend on that assumption. Relaxing the index takes a minute; teaching every one of those flows what to do when an identifier matches four records is the actual work. And the failure mode of getting it wrong is the bad kind — not an error message, but an import quietly updating the wrong volume, or a scraper overwriting a record with another volume metadata.

So: I am not saying no. A proper answer for shared identifiers is worth having, and I would rather design it once than bolt it on. It is a structural change, it needs a plan for each of the flows above, and it needs to be done without breaking libraries that are running today. I will take the time to study it properly when I have it, and this issue is the right place to track it — I am leaving it open.

In the meantime the honest summary is: four records with series and volume numbers describe your set correctly in every respect except the identifier, which only one of them can carry. That is a real limitation, not a solution, and I am not going to call it one.

[Himura2la]

I see, the design decisions made at the core are indeed make the straightforward support of such unusual cases unnecessary hard...

May you consider denormalizing the ISBN field and allowing to append a "number in series" value to it so that the value passes validation, and the ISBN remains searchable/matchable in all cases?

Just an option, TBH also looking kinda hacky. As you said, this isdue needs a separate research.

Denormalization is always a bad thing eventually..