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.
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.
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
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.
Fun with fixed field formats: Biographical information in 008
One of the moments that first got me thinking about creating this blog happened when I was cataloging a serial a year or so ago. I don’t work with serials very often - and if I’m being honest, I’m happy to keep it that way. But this day, as I was creating an original serial record in Connexion, and I was faced with an unfamiliar set of fixed fields:
I have a hard enough time remembering all of the fixed field values for monographs, which are mostly what I catalog, so I definitely had to look up some of the fixed field values for serials. I ended up reading through the possible values for “Nature of Contents” in OCLC Bib Formats & Standards, and noticed something kind of odd. One of the possible values is “h” for Biography. It’s allowable for continuing resources, but NOT for books. Presumably, that is because books have their own fixed field just for recording if something is a biography or not. But why would that be? Why would books and continuing resources handle biographical information differently in fixed fields?
At this point, it’s probably worth stepping back and talking about what the “fixed fields” are. For people who do the majority of their original cataloging in Connexion (I am one of them), we’re used to thinking of the fixed field as separate chunks of data, which change based on the type of resource we are cataloging, because that’s how OCLC presents them to us. But as defined in the MARC standard, what OCLC presents as separate elements are actually defined by their position within the Leader and 008 fields. Those fields (and the other 00X fields) are called “control fields,” or sometimes “coded fields,” because the information in them is defined based on relative character position, instead of subfields and indicators. For example, the three-character language code is characters 35-37 within the 008 string.
This is where it gets fun: the values of characters in the 008 field vary depending on the resource type. There are always 40 characters, but the meaning of characters 18-34 changes per resource type (technically, they are the 19th through 35th characters, because the numbering starts with position 00). For example, 008/34 can carry these meanings, depending on the material:
Nature of contents is 008/24-27 for books, and 008/25-27 for continuing resources. (For continuing resources, position 24 is the similar Nature of Entire Work.) Most of the possible values are the same for both material types, but some, like h for Biography, are not.
Okay, so different material types have different 008 definitions, which explains the biography difference between books and serials. But… why? Why would the positionality be different for these two types of materials?
Well, it’s probably because books and serials used to have two separate MARC formats. When MARC II was published in 1969, it only covered books. Other MARC formats were released over the next several years for other materials types: serials and maps in 1970, film in 1971, music and manuscripts in 1973.[1] Each of those formats contained fields needed specifically for that material type. Serials and books (along with other material types) have different characteristics, so it made sense that the 008 field defined different values for each position.
The model of different formats for different materials worked well enough for a while, but by the early 1980s, there was a desire to bring the different formats into one comprehensive bibliographic format. The project of “format integration” formally launched in 1983, and was mostly accomplished by 1988, although some lingering work lasted for years after that. According to a report about the subject from the Library of Congress, “Format integration is the validation of data elements for all forms of material, thus removing the restrictions on data elements that currently make them valid only for specific forms of material. The result is a single bibliographic format that contains data elements that can be used to describe many forms of material.”
The variable control fields like 008 were a particular source of concern with format integration. The ultimate solution was that the values of the specific positions would continue to differ based on material type, and would be defined by the type of material coded in the Leader/06-07. Additionally, the 006 field was defined in parallel to 008, so that additional characteristics could be recorded (because 008 could not be repeatable). This solution enabled the different types of information recorded in the 008 to remain, even though the new, unified bibliographic format could be used for all types of materials.
The 008 field itself was not changed very much during the process of format integration. Particularly, the positions that are defined differently per material type (characters 18-34) don’t seem to have been altered. I can’t confirm this, but my suspicion is that once it was decided that 008 would remain different per material type, it was easier to just leave it alone, rather than trying to redefine the characters and create a lot of work to convert existing records.
So that’s it: the different definitions of 008 apparently go all the way back to the earliest days of MARC, when each material type had its own separately defined format. Which seems fitting, in a way. The entire structure of the variable control fields, with each character position bearing a unique definition, makes the most sense when thought of in terms of the data storage and computing restrictions of the 1960s and early 1970s. Of course, none of this explains why we should code for the presence of biographical material at all, but that’s a topic for another blog...
[1 ]These dates come from Michele Seikel & Thomas Steele, “How MARC Has Changed: The History of the Format and Its Forthcoming Relationship to RDA” Technical Services Quarterly (2011) [paywall].
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.)
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.
It turns out there is a field specifically for imprint statements for films, with dedicated subfields for producing company and releasing company. And it goes waaaay back, to AACR1, pre-1976.
Before 1976, AACR apparently instructed catalogers to create an imprint statement for films that is totally different than for books. And that went into MARC 261. In addition to subfields for producing and releasing company, it also has one for “contractual producer,” a category I’m not sure I understand (since I haven’t yet gotten my hands on a pre-1976 copy of AACR). The order of the subfields is different than 260, as well - for example, the place of production, release, etc. is 261 $f, as opposed to 260 $a. Additionally, the subfields for date and place are repeatable, if there are multiple producing companies, releasing companies, and contractual producers recorded (which is a total nightmare for thinking about translating that data). Here’s the actual field definition:
261 IMPRINT STATEMENT FOR FILMS (PRE-AACR 1 REVISED) (NR)
Indicators - Both undefined, contain blanks.
Subfield Codes
$a Producing company (R)
$b Releasing company (primary distributor) (R)
$d Date of production, release, etc. (R)
$e Contractual producer (R)
$f Place of production, release, etc. (R)
$6 Linkage (NR)
$8 Field link and sequence number
Then, when ISBD released a full specification for moving images in 1975, AACR was revised to match it. Thus, the 1976 AACR revision made imprint statements for films the same as for other materials and put them into the 260. The contractual producer was recognized as equivalent to a manufacturer, and went into 260 $f. The production company and releasing company were considered publishers, and went into 260 $b.
So why is 261 still around, if the cataloging rules haven’t called for it since 1976? Well, CAN/MARC, the Canadian version of MARC, got rid of 261 in 1988, but USMARC hung onto it. Which was fine, until the two countries started bringing their MARC formats together in the 1990s, into what would become MARC 21 (published in 1999). During this process of aligning the two standards, discrepancies between USMARC and CAN/MARC had to be reconciled. (See “Superseded Documentation” in the intro to the bib format.)
Therefore, the Library of Congress proposed in 1998 to make 261 obsolete, along with a few other fields that were valid in USMARC but not CAN/MARC. (This was actually after the two standards were officially announced to be in harmony in July 1997, but, well, oops?) MARBI voted not to make the field obsolete, though. There were concerns that it might be necessary for retrospective conversion of pre-1975 records, since it would be too difficult to transform the imprint statements in those records into the format of 260. Instead, 261 (and the other fields that were included in the same proposal) became “local” fields in MARC21 - so they aren’t officially obsolete, but they are only valid in some contexts. A similar compromise had been made earlier for 9XX fields used in Canada - they weren’t considered valid fields in MARC21, but they were officially documented as part of the standard - so the same was done for 261.
Currently, 261 is listed in the content designator history for the 2XX block as “USMARC only,” and fully described in Appendix H: “Local/Obsolete Data Elements.” I’m not clear what the real difference is between making it “USMARC only” versus “obsolete,” since either way effectively no one is going to use it. Instead, it just lurks in the appendix, like a ghost haunting the hallways of our data standard. 👻
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
MARC is pretty weird, right? Our venerated library data standard is a clunky, mixed-up hodgepodge. After all, what would you expect of a standard that’s been around in some form for almost 50 years? Whether you love it or you hate it, it’s hard to avoid the conclusion that MARC can be very odd.
This blog is my attempt to explore some of the history of the MARC formats - to understand how we ended up with the data standard that we have today. Over the past few years, I’ve worked with MARC records fairly extensively (and occasionally, intensively), both as a cataloger and as a manager of my library’s discovery system. I constantly feel like I’m still exploring all of the nooks and crannies in the MARC standards. Every once in a while, I’ll come across some field or subfield or indicator that makes we wonder how it got there. I want to explore how the standard evolved, what factors went in to its development and maintenance, how it relates to changes in cataloging practice over time. If I’m feeling fancy, I could say that, following Star & Bowker in Sorting Things Out (1999), I want to understand the history of the hidden infrastructures through which library work gets done across communities of practice. But mostly, I just want to solve some mysteries about MARC, find out what made it the way that it is, and learn some new things along the way.
Right now, I envision this blog as a series of posts, exploring different MARC fields - each post a little self-contained story about how some piece of MARC came to be what it is. I think of it like a treasure hunt - following clues across various historical library documentation until I find the treasure of learning something new about MARC and/or library history. Most of the posts will probably focus on the bibliographic standard, although the others may make appearances too (look out for my favorite, Community Information!). I already know that there will be some things that appear multiple times across posts, but my goal isn’t to write a definitive history of MARC or make with any overarching arguments about that history.
Similarly, I’m not planning on doing any serious in-depth research on most of these topics. Fortunately, the Library of Congress and the MARC Advisory Committee keep a fairly in-depth online collection of proposals, discussion papers, and other sources, dating back to 1995. Plus I’ve been able to find old cataloging documentation in HathiTrust and elsewhere online. But there will be things that I can’t explore as fully as I’d like, because the sources aren’t there or aren’t accessible to me. There will also be mistakes - either because I missed a source, or didn’t understand something correctly, or just plain made a mistake. If I’ve gotten something wrong, please don’t hesitate to let me know, and I’ll try my best to correct it!
So now - let’s dig in! Plenty of MARC treasures out there to find...
-Elliot
Shout-out to @kaytacari for inspiring the title of this post!
