#bib format

[marchistory]

If it’s a shiny disc that plays a video...: 007 coding for DVDs

I got an email from a colleague at my library last week that a DVD was not showing up in the catalog correctly.  Looking into it, it turned out that the record was actually coded in the 007 field as a laserdisc (007/04 = g, instead of v).  I’d seen this particular error before, and decided to dig a little deeper.  It turns out that until 2001, the same code was actually used for both!

A little refresher on 007, in case anyone needs it: 007 is one of the “variable control fields”, where each character contains a particular value depending on its “relative character position.” The meaning of the characters differs based on the code in 007/00, the first position, which defines the type of material being described (text, sound recording, map, etc.)  For video recordings (007/00 = v), the fifth character, 007/04, is defined as Videorecording format.  This is where you code for whether the item being cataloged is a DVD, VHS, U-matic tape, or one of several other defined formats (several of which I’ve never heard of).

Because it is a coded field, possible types of Videorecording format have to be specifically enumerated. So when a new format becomes popular, a new code has to be defined for it.  The DVD format was developed in 1995, and presumably it didn’t take long after that for libraries to start acquiring and cataloging them. But there was no 007/04 code specifically for DVDs. However, code “g” was used for “Laser optical (Reflective) videodisc” (007/04 = g), which was used for videodiscs read by lasers.

“Laser optical (Reflective) videodisc” was generally used in MARC for LaserDiscs, an early analog optical disc format. LaserDiscs began being produced in 1978, and although they never became as popular as VHS tapes, had some level of popularity during the 80s and early 90s. Ironically, most sources indicate that its ultimate downfall was the rise of DVDs, although it was already decreasing in use by the late 90s. Globally, LaserDiscs completely ceased being produced in 2009.

DVDs and LaserDiscs are not at all the same thing (except for the fact that they are shiny discs that hold videos), so it never made sense to treat them the same way in MARC records.  As the proposal for a new DVD code put it, “Because laserdiscs and DVDs are not compatible with each other, they should be coded differently in 007/04 to enhance both information retrieval and help in the accurate management of videodiscs.” And so, in 2001, code “g” was redefined specifically as Laserdisc, and a new code, “v”, was added for DVD.

Part of the discussion in 2001 included whether dimensions should be specified for videodiscs, like LaserDiscs and DVDs.  LaserDiscs, in particular, come in different sizes, which a user would presumably need to know.  There was discussion about redefining code “g” as specifically 12-inch LaserDiscs, or possibly of adding new codes to 007/07 (“Dimensions”) to record the diameter of videodiscs. According to a report in the OLAC newsletter [PDF], “It was decided to remove the dimensions from the definitions of codes "v" and "g" and the proposal was approved. If further work is needed on the coding of dimensions of discs, it will have to be another proposal.” It doesn’t seem that any more work on dimensions was ever done.  The current MARC specification says to use z for “Other” in 007/07 for all videodiscs “since standard code values for videodiscs do not yet exist.” ¯\_(ツ)_/¯

Everything about this picture of a student using a laserdisc is very 80s, and I’m into it.  Source: Susquehanna University via POWER Library.

[marchistory]

258: If you liked it, then you should have put a stamp on it.

Field 258 - Philatelic Issue Data is possibly my favorite obscure MARC field.  It’s an entire field for recording information about stamps!  It has always felt delightfully specific and obscure - who actually makes MARC records for stamps?  Well, it turns out the answer is Canadian archivists.

According to the MARC format specification, 258 is defined as: “Issuing jurisdiction and denomination information about philatelic material, such as postage stamps, postal stationery (postal cards, etc., made available by a postal administration bearing a stamped impression (indicium) of denomination), revenue stamps (tax stamps), postage due stamps, and registered mail stamps. These are usually valid within a defined area and carry a value signifying prepayment or payment due for services or taxes.” It has two subfields defined: $a, Issuing jurisdiction (the governmental body that issued the material), and $b, Denomination (the monetary value of the item).

Not surprisingly, quirky little 258 is not a heavily used field. According to OCLC Research’s analysis of WorldCat data, it is used in only 19 records, which have a total of 400 holdings attached to them. (The holdings number jumped hugely from 18 in 2015 to 255 in 2016, and has been increasing ever since, which is probably an interesting story in its own right.)

Digging around in the proposals to the Network Development and MARC Standards Office at the Library of Congress, I found the initial proposal for field 258 from 2003. The proposal was submitted by the National Archives of Canada, because Issue Data is considered an important part of archival description for philatelic records under the Rules for Archival Description (RAD), Canada’s archival description standard. And indeed, the structure and content of MARC field 258 is basically the same as RAD rule 12.3, since that it was it was based on.

Obviously, I wanted to read the RAD instructions for philatelic data [pdf], and thankfully the Canadian Council on Archives makes RAD freely available online. Hooray! I didn’t know that RAD (very unlike DACS) has chapters with distinct instructions for different material types. RAD is based on ISBD(G), and intended to be “compatible with” AACR2, so the chapter structure makes sense. And it explains why there are specific instructions for how to describes stamps and other postal materials.

It also turns out that RAD rules can be applied at any level of description - fonds, series, or individual item. I wonder if levels of description help explain the low number of occurrences in WorldCat. Philatelic issue data would seem to be more likely to be applied at series, folder, or item level description, and those are also the levels that are less likely to be shared in a shared bib environment like OCLC.

But this is also a big problem with our friend 258, right? The things that it seems like it would be useful for - hierarchical description, description of unique items - are not MARC’s strengths.  Even the National Archives of Canada seems to have figured that out. The 2004 proposal for field 258 mentions that it would be valuable for Archives Canada, a MARC-based cross-institution search for Canadian repositories. Archives Canada, though, is now an instance of Access to Memory, which does not use MARC. The National Archives of Canada does provide access to philatelic materials through its catalog, including at item and file/folder levels - for example, here and here. I can’t tell for sure, but it doesn’t seem likely that that system is based on MARC, either.

The 258 field serves a need for these specialized materials, but it’s obviously very limited in application and came out of a very specific use-case that the people who proposed it seem to have moved away from. I know that some institutions do use it (I’ve seen it in records in the Folger Shakespeare Library’s catalog, for example), but it’s pretty rare. Poor lil’ 258 doesn’t seem to be likely to get used much more any time soon.

I guess the 258 field for this cool Romanian postage stamp from the Science History Institute would be: 258 __ $a Romania : $b 1 leu

[marchistory]

The creators are out of control!: Uncontrolled names in 720

One of the most important facts for understanding the history of MARC is that the standard was developed specifically in reference to library cataloging rules. MARC fields, and indeed the whole structure of the format, have been designed to accommodate bibliographic cataloging practices under AACR, AACR2, and later RDA. But of course, it isn’t as simple as that; there have also been sporadic attempts at using MARC for other purposes, which have also left their mark on the standard.

Take field 720, “Added Entry - Uncontrolled Name.” 720 is defined as “Added entry in which the name is not controlled in an authority file or list. It is also used for names that have not been formulated according to cataloging rules.” It was added to USMARC in 1996, specifically to cover situations where records were not created according to library cataloging standards. 720 doesn’t care if the name is a personal name, a corporate body, or a meeting; it doesn’t have any fancy subfields for recording different parts of the name; and importantly, it doesn’t imply the very library-ish concepts of main entry or added entry.

MARC, after all, doesn’t have an “author” or “creator” field. As the discussion paper that led to the creation of 720 notes, “It often surprises non-librarians to discover there is no MARC field defined specifically for author.” The choice of 1XX or 7XX field depends on the type of agent and that agent’s relationship to the thing being cataloged. Which is all well and good for library catalogers, but isn’t very useful in other contexts. The proposal for 720 listed several possibly needs for a more generic author field, including order records in an ILS and generating citations. But the most pressing reason for such a field was the “increasingly common use of USMARC bibliographic records as a vehicle for metadata created by various communities according to various other standards.” And the cool new metadata standard on the block in 1996 was none other than The Dublin Core.

In its very early iterations, the Dublin Core had elements named “Author” and “Other Agent” (which we now know as Creator and Contributor). A pair of MARC Discussion Papers from June 1995 discussing how to map Dublin Core elements to MARC (DP86 and DP88) laid out the differences between how Dublin Core and MARC deal with names. Particularly, Dublin Core doesn’t differentiate between personal and corporate names, and the creator/contributor dichotomy doesn’t map easily into the MARC main entry/added entry framework. A few options were considered for how to resolve those differences and allow for mapping from DC to MARC:

Throw caution to the wind and choose an existing 1XX or 7XX field to put all creator & contributor names

Define new indicator values for the 7XX fields to specify that the names’ exact relationship to the work is unknown

Define a new “generic author” field.

Ultimately, the third option was chosen. Defining a new field kept the integrity of information in existing 1XX & 7XX fields (since those could be relied on to be formatted according to AACR2) and did not require differentiating corporate and personal names. The proposal for 720 compares it to fields 653 for uncontrolled subject terms and 740 for uncontrolled title added entries. It was defined with only two subfields: $a Name and $e Relator term. To this day, 720 has only gained three new subfields, $4 Relationship (in line with other 1XX and 7XX fields) and the typical $6 and $8 control subfields. It remains just a field for names - nothing else.

The dream of the 90s to have well-formed Dublin Core records for a variety of online resources never quite came to pass. But field 720 has still consistently shown its usefulness in multiple scenarios. It’s an interesting case of trying to de-tether MARC somewhat from the strictures of library cataloging rules - something that certainly still feels relevant for current discussions about library data formats and structures.

[marchistory]

301/307: Keeping the "Hours, Etc." in line

As the family of MARC standards started to expand in the 1980s, with the introduction of the Holdings format in 1984, one of the principles of MARC development was that field numbers in the different formats should overlap only if the content in those fields was roughly the same. In other words, if two formats use the same three-digit tag, then the content in those fields should be similar. So, for example, the 100 field in the Bibliographic, Authority, and Community Information format always has personal names used as a primary access point. It’s a principle that has worked well over the years, but there have occasionally been times when things get… tangled, and need to be sorted out.

In 1994, a new field was defined in the Bibliographic standard for “Hours, Etc.” The field was to be used to record when the item being described was available to be accessed, and was mostly used for electronic resources.

(Sidenote: The idea that some electronic resources used to only be accessible during certain days and times is wild to me. That is not a version of the Internet that I have ever known. That world also lives on in field 856 $v, which similarly allows for recording days and times that a resource can be accessed.)

The Community Information format has a field for similar information, also called “Hours, Etc.” and then defined as field 301. In the CI format, the field contains: “Information as to the days and/or times pertaining to the operations of the community information entity (such as when the office of a program or organization is open, when a club is to meet, when an event is to take place, when a person is available for hire), as well as to special information, e.g., the size of the staff, whether or not a translator is available.”

(For folks who aren’t familiar with the Community Information format, it was created in the early 1990s for cataloging non-library resources like people, organizations, and community events. Almost no one uses it, but it is still around. I am absurdly fond of it.)

So when the hours field was being defined for the Bibliographic standard, the initial plan was to make it also use the 301 tag, to match the similar field in Community Information. But there was a problem! 301 had previously been used in the Bibliographic format for something different. Up until 1983, field 301 was Physical Description for Films. Apparently, in pre-AACR2 cataloging, the physical description of films was different enough from other materials, that there was a field just for that in the visual materials format.

Well, another principle of MARC development is that once a field is made obsolete, that tag cannot be reused for anything else. That way, older records that still contain obsolete fields don’t have their information misunderstood by newer systems. So “Hours, Etc.” in the Bibliographic format was given tag 307. But now the Bibliographic and Community Information formats had similar information in fields with different tags!

So in 1995, a proposal was made to change the Community Information field from 301 to 307, to “keep the Community Information format in sync with the Bibliographic format from which many of its field tags have been borrowed” and correct the “oversight” of using a tag which had already been used for an obsolete field. It was a relatively minor change, especially since the Community Information format was at the time still provisional. But it shows the work that has to be done to keep the various MARC formats in sync as both the formats themselves and the nature of library description change over time.

In the end, the proposal passed, both formats now record hours in field 307, and peace was restored to the MARC family.

[marchistory]

How many digits in a year? Y2K and field 263

Remember Y2K? When all computer systems around the world were going to come crashing down because they couldn’t handle 21st-century dates? It obviously turned out to not be an enormous disaster, as some people feared (I definitely knew some people in my small town who stockpiled canned food), but it was a problem that required a lot of work in the years before 2000.

Libraries, like every other industry that relied heavily on computer systems, had to deal with the Year 2000 problem. In case you don’t remember, the Year 2000 problem occurred because most computer systems were designed to store dates using only two digits for the year, which would make the year 2000 indistinguishable from 1900. That would have wreaked havoc with any system that used dates to function. From a quick perusal of library industry articles about getting ready for Y2K, acquisitions and circulation (as well as general systems work) were the biggest concerns. But cataloging wasn’t immune to to the Y2K bug, either.

The only actual change to any of the MARC standards that I can trace directly back to the Year 2000 problem was an adjustment of field 263, used for projected date of publication for CIP (or similar) records. 263 is a very simple field - it’s only subfields are $a, used for project publication date, and $6 and $8, in their standard role as control subfields. Originally, $a was four digits long: yymm (2 digits each for the month and year of publication). Initially, it was felt that 263 could be left using only 2 digits for the year, because it would only have reflected dates from the late 20th century, so there wouldn’t be any confusion about overlapping years. But the Library of Congress and a bookseller who used MARC records realized in 1998 that it would be problematic. It turned out that not being able to easily determine the century would cause problems for automatic processing of pre-publication records. So, in early 1999, 263 $a was redefined to be six digits: yyyymm (4 digits for the year, and 2 for the month).

The MARC proposal that changed 263 for Year 2000 compliance mentions an “initial analysis of the year 2000 problem and the MARC formats.” However, I haven’t been able to get a copy of that analysis - it wasn’t presented as a MARC discussion paper or report, and I can’t find it anywhere else online. No other MARC proposals explicitly address the Year 2000, and no other coded date fields seem to have been affected. Fields 005, 008, 033, and 046 don’t show any evidence of being changed in the lead up to Y2K. In fact, 008/00-05, which stores the date the MARC record was created, continues to use just 2 digits for the year (presumably because it is embedded in a field where character position matters, so changing it would have required totally reworking the entire 008 string). The only other Y2K-related change I have found is a change to the structure of LCCNs, which adopted a new structure using 4-digit years in 2001, but that didn’t require any changes to MARC itself.

I’m probably missing some changes that were made for Y2K (in particular, I didn’t look too closely at the non-bibliographic standards), but overall, the MARC standards seem to have emerged into the new millennium mostly unscathed.

(Vintage gif source. Aaah, the 90s - the original era of gifs.)

[marchistory]

Call me by multiple surnames: X00 first indicator 2

X00 fields, used for individual personal names in both bibliographic and authority records, used to have separate first indicators defined for single and multiple forenames.  Today, the indicators are: 0) Forename, 1) Surname, and 3) Family name.  But until 1996, they were: 0) Forename, 1) Single surname, 2) Multiple surname, and 3) Family name.  

(Did you know that you can see what fields, subfields, and indicators used to be valid on the bottom of most pages of the MARC specification? Because you totally can!)

The rationale for encoding single surnames and multiple surnames differently was that certain filing rules handle names with multiple surnames differently. The different indicators went all the back to the MARC II standard from 1968 (at least according to a 1996 report), making me feel like the importance of filing rules is a holdover from a time when MARC was as much about creating catalog cards and printed library catalogs as anything else.

However, the separate indicators became a problem when the British Library and the Library of Congress started exchanging name authority records in 1994, as part of NACO. At the time, the British Library was using UKMARC, and LC was using USMARC. Both had first indicator values defined for single and multiple surnames, but the two communities used them in different ways. USMARC had a fairly confusing set of rules about when to consider something a multiple surname, depending on the type of element included in a multi-part surname and how many parts made up the whole name, while UKMARC… only cared about whether the surname had more than one part.  Obviously, that led to some discrepancies.  For example, UKMARC treated the name “Walter de la Mar” as having multiple surnames (first indicator 2), while USMARC treated it as a single surname (first indicator 1), because the elements that make the surname more than one part are a preposition and an article.

When the issue became apparent, the USMARC Advisory Group started looking into it, and discovered that very few systems actually used the first indicator for making a sorting distinction between the two types of surnames. So, rather than either side changing their encoding practices for multiple surnames, the distinction was eliminated altogether. USMARC got rid of it in 1996 - first indicator value 2 was rendered obsolete, and value 1 was redefined as just “Surname.” Although I can’t confirm for sure, UKMARC seems to have made the same change (see, for example, the last published version of UKMARC’s definition of field 100). So even though the British Library (and by extension, much of the UK library community) didn’t move from UKMARC to MARC 21 until 2004, differences between the two formats were being reconciled well before that - in this case, due to shared authority projects.

In a twist, the Library of Congress didn’t actually implement the change until 2000. When they did, the decision was to encode new bib and authority records correctly, but only to change old records when those records were touched for some other reason. Presumably by now, all the records with first indicator 2 have been changed - I assume that LC and OCLC have done some mass updating of that by now. But it doesn’t seem impossible that the old surname encoding is still hanging around in various local systems.

[marchistory]

090: Location, location, location!

Field 090 is a MARC field that many catalogers use regularly, for locally assigned LC-type call numbers.  Although it is recognized by OCLC, it’s not formally part of the MARC 21 standard.  The official MARC bibliographic standard simply specifies that all 09X fields are “reserved for local call number use and local definition.”

But 090 used to actually be an officially designated field. It was designated as “Local Call Number” when it was made obsolete in 1982.  But it wasn’t always used for that! Up until 1977, 090 and 091 were designated for “Shelf Location” and “Microfilm Shelf Location,” respectively.  Both were designated as part of the archives and manuscript control (AMC) format.

Before format integration in the mid-1980s (which I’ve mentioned before), different MARC formats existed for different material types. The fact that 090 and 091 were only valid under the AMC format suggests that their use was for something particular to that type of material. I haven’t been able to get my hands on a copy (yet!) of the Archives and Manuscript standard from before 1985, so I’m not exactly sure how 090 and 091 were supposed to be used.  It’s interesting that a separate field was designated for microfilm shelf location - probably under the assumption that institutions could hold both the original and a microfilmed copy, and would describe them both on the same record? I don’t know a lot about the history of microfilming as a preservation practice, much less cataloging microfilms, but having both on the same record would seem to make sense.

The earliest version that I’ve been able to get access to of the Archives and Manuscript Control format is from 1985. At that point, fields 090 and 091 are gone, but the location could be recorded in the 851 field, with $e being used for “Location of units.” It’s not an exact match for “Shelf Location,” but I wonder if 851 was intended to replace 090 and 091. If so, it’s interesting that the distinction between locations for originals and microfilm copies was discarded.

(851 itself would become obsolete in 1993, mostly replaced by 852.  Possibly to align better with the MARC Holdings format? But that’s a question for another day…)

I still have a lot of questions about 090. Why was it only designated for the archives and manuscripts format, and not any other materials? Why was it made obsolete for AMC in 1977?  When and how did it then become “Local Call Number,” before disappearing again in 1982? That’s a period that it’s hard to track down sources for exactly what happened, but I’m tantalized by what I was able to piece together about 090 and 091.

“Woman in the stacks,” ca. 1965, National Archives and Records Administration. https://catalog.archives.gov/id/29011058