MARC Misconceptions: Incorrect ISSN or the 022$y

I’ve been thinking about this series for a while: MARC Misconceptions or, really, the mismatch between data and desire. Specifically, I’m going to explore very specific cases where I’ve run up against the difference between what’s in our MARC and the kinds of questions we want to ask it. These may caused by failings of MARC as a data standard, the content standards and practices we’ve developed over time, or our own assumptions. At first, I was going to make this into one massive post, but I’m more likely to actually get it done if I limit it to one at a time. I have three planned and may get to as many as five in the near future with more to come if I think of them.

Today’s topic is the “Incorrect ISSN” subfield: MARC 022, subfield y. I’ll be focusing on its use in bib records, but MARC Authority uses the same encoding and definition.

Technical Definition of the 022$y

The 022$y is a repeatable subfield.

The LC docs define it as:

Incorrect ISSN that has been associated with the continuing resource.

For usage, they note:

Each incorrect ISSN is contained in a separate subfield $y.

And they clarify that it is not the same as a canceled ISSN:

A canceled ISSN is contained in subfield $z.

LC doesn’t provide any other context about what an incorrect association might mean. OCLC’s docs define it as:

An ISSN printed in a serial but assigned by ISDS to another serial.

This is a practical, if very limiting, definition and one that might’ve served us well over time.

So the 022$y is a place to record incorrectly-associated ISSNs, such as in cases when they’re mis-printed on a journal issue. What makes it a problem?

Practical Uses of the 022$y

Practically, the 022$y tends to be used for a purpose which can only be loosely-interpreted as “Incorrect”: recording the ISSN of a different form of the continuing resource.¹ I’d estimate this accounts for well over 90% of the instances of 022$y in anyone’s catalog, maybe as high as 99%.

Are these incorrect? Well, they’re not the correct ISSN for this form of the resource. But these also aren’t recording misprints or errors of association, they’re recording different ISSNs.

It’s been going on for a quite a while, perhaps since the early days of e-journals.

Perhaps if I scoured… ok, you know what, I’m back, I did just scour AUTOCAT’s archives for references to the Incorrect ISSN/ 022 $y. That sent me to PCC Provider Neutral E-Resource MARC Records Guidance, from which I downloaded “Provider-Neutral Record Guidelines for Online Serials AACR2 version (Word, 52 KB) [superseded]” in which I found what I was looking for on page 3:

Give the ISSN of the electronic in $a; give the ISSN of the print in $y

I chose AACR2 because it’s the oldest available. I’m not going to dig all the way into CONSER manual revisions, but I think that gives an idea of the age of this practice.

Some AUTOCAT posters observe that the practical effect is a kind of grouping function – you search for an ISSN and, if your catalog indexes the $y as well as the $a, you get both forms of the resource. That’s quite useful!

But what about that pesky 1-10% that are actual incorrect ISSNs, improperly printed or otherwise associated with a resource? The field is now serving two functional purposes – helping those who’ve encountered the misprint and helping those who would be served by resource grouping.

Implications of Practical Uses of the 022$y

The bifurcated function served by the modern 022$y can lead one to misconceptions about how it should be used in one’s infrastructure or code.

Search Results

One reason the 022$y exists is for search! For example, if you search the Journal of Asia-Pacific Business, ISSN: 1059-9231, you’ll get links to both print and e-records, or to a FRBRized version of the record. You’ll also get the Journal of Bisexuality where it’s an actual incorrect ISSN. Try it in WorldCat!

In a catalog or discovery system, where a human is looking at the results, this may lead to nothing more than a confused: “Why is the Journal of Bisexuality in my results?”

If you were working from the misprinted version, then you’re asking the opposite question!

However, in a more automated context, it becomes complicated.

Automated Attempts at Grouping

One way I learn about these misconceptions, of course, is running headlong into them myself. Not always, sometimes I’m responding to someone else’s suggestion or analyzing their implementation. But nope, I ran straight into the wall on this one.

Let me explain:

I was attempting to do a big analysis project for a coworker² who provided me with a big batch of ISSNs, some of which were for print resources and some of which were for e-resources. For the project to be successful, I really needed both ISSNs for as many of the resources as possible.

So I figured I’d hit up WorldCat’s brief bib API to get those additional ISSNs. And this is where my own assumptions served me wrong. I’d looked at some results and noted that sometimes they had multiple ISSNs in the “issns” field. I’d also seen a lot of good results where it’d bring back something like 4 records for the print and 2 for the electronic and if I just grabbed and deduped all the ISSNs, I could build a nice little data pool. I think I’d also assumed some FRBRization.

But no, it was exactly like the human-facing search results.

Some records, like oclc # 1058002230 or 1229238302 have two ISSN fields, each with a different medium’s ISSN in the 022a³. These make me raise an eyebrow but both show up in the “issns” field and I can grab them and add them to my data. Others, like #1097266627 Journal of Bisexuality are included, and the “issns” field is, of course, not data I want.

Now, at least as of writing in July 2024, there’s an “incorrectIssns” field in the brief bib API response and one could automate things by making sure the ISSN one was searching wasn’t in that field and only then pull in whatever’s in the “issns” field. At the time, I just revised my approach a little and wrote the instances where it’d still cause an issue into the Limitations.

Will the 023 solve this?

I find CONSER’s choice a baffling one. When I ran across the problem with my data last fall, I found myself yelling “JUST ADD A NEW SUBFIELD FOR ‘ISSN FOR OTHER VERSION OF THE RESOURCE’! This is our standard! We wrote it! We can refine it!” There is no reason why 022$y couldn’t have remained for misprints and been clarified as such in the docs and another field couldn’t have been added for handling this second use case. Our systems could easily index both for search, if we want, but it would’ve also let us code in a lot of great stuff around grouping!

There is some light on the horizon, sort of, with the introduction of the 023, a “Cluster ISSN”. LC MARC defines this as:

A mechanism first defined in ISO 3297:2020 to provide for the identification of specific groups of ISSN (International Standard Serial Number), such as the various medium editions of a continuing resource, or serials related by preceding and succeeding title relationships.

Finally, a solution to the existing cluster—?

Maybe. The 023 can handle ISSN-L and ISSN-H⁴, which means that either of these must be created and the records must be updated. That’s a lot of work. It should be automatable if one exercises great care (matching only on the 022a). But our data is already muddied. It’s muddled. Hundreds of hours have been spent by catalogers making this data that’s essentially unusable for any use case where one is not visually reviewing one’s search results. It didn’t have to be this way and it’s a real shame.

Written while listening to Dvorak’s Symphony no. 9 : From the new world, Royal Philharmonic Orchestra conducted by Artur Rodzinski and recorded 1954 October at the Walthamstow Assembly Hall in London. On repeat.