| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

MARC elements

Page history last edited by Karen Coyle 11 years, 11 months ago

Sections:

Analysis: Fixed Fields: 007, 008

Number and Code Fields (0XX)

Variable Fields (1XX-8XX) 

Indicators

Content and Carrier

Resulting Data (in various formats)

 

(Note: if you want to comment on these pages, I need to add your email address to the list of approved participants. Send me an email - kcoyle at kcoyle.net - and I'll add you. I REALLY want comments because you know things about the use of fields that I may not.)

 

Any future metadata format for library bibliographic information must be able to address the legacy data that is stored in MARC format.  A first step in addressing that data is to analyze MARC into a set of data elements, independent of the ISO 2709 record structure. As much as possible, the elements must be atomistic and clearly defined. This is in contrast to the MARC record structure, which bundles data elements into complex fields, and which has areas that are more in the nature of marked-up text than data elements in the usual sense.

 

The set of atomistic elements will not provide the same overall structure as the MARC record; that should be achieved by an actual application. Throughout the process of developing a MARC21 element description, it will be important to keep in mind the difference between the declaration of properties and vocabularies and the actual creation of instance data. Properties and vocabularies should be tested to make sure that they do function for instance data, but they do not have to replicate an actual MARC21 record in structure.

 

What MARC Is

It may seem odd to be looking for data elements in a data format. They should be obvious, right? Not in the case of MARC. The MARC record was not created as a set of data elements but as a format for the storage and display of the text of library catalog records. At the time that it was developed there were few anticipated functions beyond the presentation of text to a person. Because there was little thought about processing the data as data the record format was not structured to fit into database structures. A common question on library lists has been: "How do you fit the MARC record into a relational database system?" The answer is that you don't, because it isn't a data structure, but primarily consists of marked-up text. This becomes visible when you look at the repetition of data in a single record. For example, the date of publication can be carried in a publication statement:

   New York, Random House, 1923

as well as in a uniform title in the same record:

   Odyssey. English. 1923

In addition the date is carried in the 008 fixed field positions for date of publication, and in some cases may be repeated in an 041 field, which is a field used in records with multiple dates.

 

If the record carried data rather than display text there would be no need to carry the same information multiple times in the record, since one could repeat data from a single element multiple times in a display.

 

Not every element of information in the MARC record can be transformed into a data point that meets database or application processing needs. Even those that can be defined as computable data elements may not exactly match the intention of the catalog rules that determine the content of the catalog records. In fact, this exercise of extracting the data elements of MARC also challenges the nature of library catalog creation. In some cases I have found that describing the MARC data elements brings me close to the new vision of catalog data that is inherent in RDA. This is a line of thought that I will take up later when the bulk of my analysis is done.

 

The Field Types in the MARC Record

 

There are three general field types in the MARC record:

  1. Fixed fields (00X)
  2. Number and code fields (0XX)
  3. Variable bibliographic fields (100-899)

 

The fixed fields meet the definition of "data elements" in most cases: they are coded values with defined value lists. (There are a few structured values, e.g. for dates.) Each field is of fixed length, and the data elements are assigned to fixed positions within the fields. This should be the easiest area to translate into a set of discrete data elements.

 

The number and code fields are variable length fields with variable length subfields. They contain data that is not considered to be very human-friendly such as identifiers, mathematical data (mainly geographic), and classification numbers. These fields are mostly textual in nature, however, and some key data elements, like ISBNs, are in subfields that also can contain free-text notes:

 

  020 __ |a 046503912X (hardback)

 

Variable bibliographic fields make up the majority of the MARC format. These are for the most part the fields that display to users and that are searchable: authors, titles, information about publishing details, notes, and subjects. All of these are textual in nature. Most contain both the full punctuation that would normally be included in text as well as punctuation required by the International Standard Bibliographic Description (ISBD). For example, in the following, the use of " = " is the ISBD indication that the second set of text is a translation of the first into another language:

 

245 14 |a Der Ring des Nibelungen. |p Das Rheingold = |b The ring of the Nibelung. The Rhinegold /

 

Many of the variable fields that represent agents (persons, corporate bodies, events) and subjects have a corresponding record in an authority file. The authority file is a form of controlled list and to some extent the agents and subjects could be represented by the identifier for the entry in the appropriate authoritative list.

 

Complicating the analysis of variable fields is an internal structure of links between fields, and qualifiers that can significantly change the meaning of fields.

Comments (1)

Tina Marie Maes said

at 7:03 am on Aug 8, 2011

Thank you for this description of MARC. I wish my professors in SLIS had defined it like this, especially as we discussed FRBR.

You don't have permission to comment on this page.