ISBNs in MARC records

Hi everyone,

ISBNs will be a key data element across a number of apps:

• Acquisitions: for searching and order output
• Inventory: for searching
• Data Import: for matching
• MARCcat: for searching and matching

AtCult already has some useful code for ISBN handling, e.g. being able to recognize 10/13 equivalents, plus stripping punctuation and qualifiers so that we have clean ISBNs for searching/matching. We’ll be gathering our knowledge about ISBN handling so that the developers can hopefully share best practices and code across the various apps.

A question came up from the Folijet folks (who are working on Data Import), and we need MM SIG input:

Would it be OK if Folijet adds/ensures that there is always a 978 (13-digit) version in the stored MARC record if it is not already present? If there is only a 10-digit version in the record, is there any harm if FOLIO automatically adds an 020 for the 13-digit equivalent, as long as it has the same $a/$z and qualifiers/additional subfields as its 10-digit equivalent?

Thank you for your input.

Ann-Marie (PO for Data Import)

Hi @Ann-Marie, I have to think about this idea. In the meantime I want to let you know that we store the ISBN with hyphens in 020 $9 in addition to the ISBN without hyphens in 020 $a. This refers to the field definition from the German National Library, available online: https://d-nb.info/1162293993/34. Subfield $9 is not part of the official LoC definition.

Hi @fhemme That’s good to know. It sounds like if you have 020 $9, you will always have an 020 $a without the hyphens. Is that correct? If so, would you ever need to match on the 020 $9, or only the 020 $a? Thank you!

Yes, this is a correct assumption. 020 $a is mandatory if applicable. In Inventory I would only want to match on ISBN, no matter if it is inserted with or without hyphens. This could be done by code logic I guess - no need to store both strings.

Edit: According to RDA D-A-CH guideline 2.15.1.4 the individual groups should also be recognizable. But this looks like a seperate question to discuss at a later point.

I don’t see any issues – in fact, I think this would be quite valuable.

• If an incoming record only has a 10 digit ISBN and a record in FOLIO has been converted to a 13 digit, will a match still be generated?

• I’ve been thinking about ISBNs in MARCcat, thinking about their heading index that groups like strings together, as I understand it. This “headings” layer doesn’t concern me particularly, except when I think about ISBNs and match points. Do we know if the Data Import process will match against MARCCat’s headings index? I’m not even sure if this is a good question…It’s one I’m still working through.

I think that as long as the check-digit functionality of the derived 13-digit ISBN works, then adding it wouldn’t be problemmatic. I am presuming that it would be put into a subfield that somehow indicates it was not recorded from the piece.

[A-M]: Yes, I think that needs to be a later question. By “individual groups,” do you mean the 10 and its related 13, or do you mean the sections within an individual ISBN (where you would normally expect to find the hyphens)?

[A-M]: If I had my way, we would just get rid of all ISBN-10s, and all systems everywhere in the world would magically know how to change them into 13s for searching and matching purposes.

[A-M]: That’s an interesting question, and not one we’ve thought much about yet. Any bib record in MARCcat will be represented in the Source Record Storage and in Inventory. We may not need to worry much about matching via a particular MARCcat field or index, but instead match on the Inventory Instance ISBN or the Source Record ISBN. Once FOLIO has identified whether the incoming record matches an existing FOLIO Source Record or not, then whatever bibliographic actions happen (creating a new record, updating an existing record) will happen first to the Source Record, and then flow to the related Inventory Instance and MARCcat Bib.

While doing that, could they validate the checkdigit at the same time?

[A-M]: Yes, we would definitely apply the correct check digit.

[A-M]: As for subfields, there’s not really a concept of transcribed versus derived in the 020 field.

[A-M]: 020 $a is used for any valid ISBN for the piece, whether it’s transcribed from the piece itself or from other sources (like a catalog, or derived from the 10/13 version). If an ISBN is in $a, it should be formatted properly and pass validation for calculating the check digit. If it doesn’t, even if it’s an exact transcription from the piece, it doesn’t go in $a.

[A-M]: 020 $z is used for any invalid ISBN, whether it’s transcribed from the piece or not. In practice, that tends to mean:

• ISBNs that are too short or long (when transcribed from the piece)
• ISBNs that don’t calculate properly (even if they match the piece)
• ISBNs for related versions (eBook ISBNs on a print record, or vice versa); these are likely valid ISBNs as far as formatting and check-digit, but not for the piece that is represented by this particular cataloging record
• ISBNs that may be printed on the piece but that are identified as belonging to a different piece (mainly when publishers recycle ISBNs for reprints or subsequent editions or long-OP works; these are the hardest to identify, since it’s challenging to definitively declare which piece a reused ISBN belongs to, and since order transactions may be expecting to use that (reused) ISBN)

[A-M]: Yes, definitely for the newly-built one. That’s part of building a 13 from a 10. Cut off the 10th digit, add 978 to the beginning, and recalculate the check digit. I’m not sure about validating the check digit for the existing 10-digit one, though I expect that the reformatting would fail if the original 10-digit ISBN was not valid numerically to start with.

• When we are dealing with a MARC record, what is the difference between MARCcat ISBN and the Source Record ISBN? I’m thinking these are two different storage sources, but the information stored in each will be the same, correct?

• My understanding is that all MARC fields and subfields will be available in the Source Record Storage. So, don’t we need to be concerned with exactly that, or am I misinterpreting what you are saying?

Thanks Ann-Marie!

A-M: Yes, Correct. MARCcat is basically the UI that surfaces the source storage MARC records for editing by FOLIO users. The MARC data in Source Record Storage and MACRcat should be the same, with perhaps the exception of some non-MARC data that is added to the MARCcat record (e.g. tags). So there should be no difference between ISBNs in Source Record Storage and MARCcat.

A-M: Correct. You should be able to rely on the data in the MARC source record to establish any particular MARC matchpoints.

That said, you may end up matching and accessing MARC records through non-MARC data elements, e.g. using an Item record barcode number to find an item record and then FOLIO works its way up to the associated Instance, and over to the related MARC Bib. Or similar idea if PO Line number is used to identify and act on a MARC record (like overlaying preliminary bib data with final cataloging data).