Bug 41414

Summary: ISBNs linked to items, not records
Product: Koha Reporter: Christopher Brannon <cbrannon>
Component: CatalogingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: alexander.wagner, anneli.osterman, m.de.rooy
Version: Main   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Christopher Brannon 2025-12-09 18:43:42 UTC
Is there a reason that ISBNs are not directly linked to specific items?  It seems like it would help us manage ISBNs if we knew which libraries needed which ISBNs.
Comment 1 Alexander Wagner 2025-12-12 08:38:32 UTC
The ISBN defines a title not the item. All items of a given title have the same ISBN by definition of the ISBN.

If I get your point right you want to know that all branches have a given title in their holdings. I think this should be possible with some kind of report, but I am not sure that it works in stock koha. (Depends on fields exposed.) If not it might be one of the use cases for https://github.com/HKS3/koha-normalize-marc2db which serializes all Marc fields into Koha so they are directly accessible via SQL.
Comment 2 Christopher Brannon 2025-12-12 16:13:43 UTC
I disagree with your perception of the ISBN.  The ISBN isn't just a title.  It represents a specific edition and format of that title.  Not all items in the record are exactly alike, which is why there are multiple ISBNs in a record.  This is the point of this ticket.  It seems like we should have some way of tying ISBNs to items so that if all items that are tied to a specific ISBN are deleted from the record, that ISBN could also be removed.  Right now, we just dump every known ISBN in that record.  Some of them could be related to audio or large print, which might not be part of the same record.

We ended up splitting our large print records from our other copies a while back, but have no easy way of cleaning up the ISBNs between records because the ISBN information is not connected to the item in any way.  We would have to manually verify every single ISBN.  And then, you could only do so with the items in hand.

ISBN management would be easier if there was a link to the item.
Comment 3 Alexander Wagner 2025-12-15 09:56:27 UTC
> The ISBN isn't just a title.

Well, it was a bit unclear. From a data perspective the ISBN lives on the title level. Otherwise you'll have to repeat the same value for each item in a record that is associated with said title.

> It represents a specific edition and format of that title.

Agree. (Ignoring some funny corner cases we have.)

Still, _of the title_ is the crucial part here, IMHO. The ISBN is not a property of the item(tm), but of all items of the same specific edition, format etc. Hence it should live on a level above the item. In this regard the ISBN is IMHO like the authors, title, edition statement, extent... And IMHO that's why it's modelled that way by the cataloguing rules.

> Not all items in the record are exactly alike

I think this is where we may differ. Usually, items of the same edition live on one record here. If we get identical copies they are added. I believe even unchanged reprints fall now in this category. If there is a `2nd revised edition` however, it get's a new record.

In general I think your approach would require a bunch of other fields to live on the item as well. E.g. (100/700, 245,) 250, 300, thinking of works like https://pubdb.desy.de/record/383719 where the author changed at some specific point in time and later even the title changed as a reference to the original author. Still it's the same book that just got expanded in certain editions.

Stuff like this most likely does not happen on a novel, though. But well, thinking of Tolkiens "Lord of the Rings" originally published in 3 books or as one large bound volume... Or it's translations even to the same language by various translators. (I admit that I'd strongly prefer either the English edition or a specific translation myself, in this case, so it would be nice if I could get that one.)

> We ended up splitting our large print records from our other copies a while back

As soon as it's a new edition or something _different_ we do add a new record. (Being from a small special library: one would also cite it differently. Or to your example: the page numbers are surely different in the large prints than in the regulars.)

To me it sounds a bit like you are heading for a light version of FRBR. 

That is, I think I understand now what you want to do. I am still unsure if your approach is the most suitable.
Comment 4 Anneli Österman 2025-12-15 12:10:25 UTC
In Finland every ISBN gets it's own record. Maybe there are different kind of cataloging rules around the world?

Or you could use the MARC holdings? https://www.loc.gov/marc/holdings/echdhome.html

The National Library of Finland have made a bug about to add support for MARC holdings records: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20447
Comment 5 Christopher Brannon 2025-12-15 17:19:10 UTC
Ideally, yes, it would be great to have only one ISBN to a record.  But unfortunately everyone catalogs differently.

I'm wondering if there could be some way to create a table to link an item number to a specific ISBN, and then reflect that in the record/holdings somehow.

It would be great if:
* The ISBN fields (20a) could show how many items in that table use that ISBN.  If we see a zero count, we could remove the entry from the table
* The holdings editor allowed us to select an ISBN from the 20a and that would update the this table.  Then the table wouldn't have to be updated manually.

I don't know if this information could be stored in the item record, as it would make showing counts by the 20a field difficult/slow.  I think having a separate table would be the way to go.  Just spitballing ideas here.
Comment 6 Owen Leonard 2025-12-16 16:05:44 UTC
This sounds like it's a request for Bug 15500