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

  • Files spread between Dropbox, Google Drive, Gmail, Slack, and more? Dokkio, a new product from the PBworks team, integrates and organizes them for you. Try it for free today.

View
 

fixed_fields

Page history last edited by Karen Coyle 7 years, 10 months ago

back to MARC Elements

Fixed Field Analysis


The fixed fields are the proof that the developers and maintainers of the MARC format recognized that there is a need for DATA that the textual fields and subfields do not fulfill. Unfortunately, this data portion of the record seems to be considered of secondary importance in comparison to the textual fields. These data elements are not visible except on the cataloging input screen; they are not displayed to users and therefore appear to be less important to the cataloging culture that is based on displays. There is a strong "chicken and egg" dilemma relating to the fixed fields: they are not seen as being important because there isn't a visible system use of them, but because record creators often neglect to input the values in these fields they cannot be used reliably for automated functions. The fact that with a few exceptions the fixed fields are valid for only certain resource formats (text, maps, music, etc.) also makes it difficult to find uses for them in catalogs of mixed content. It may not be obvious to a user that an element like Target Audience will retrieve books, music, computer files and visual materials, but not maps, serials or sound recordings.

 

As elements, the fixed fields are relatively simple, although they also pose some problems for analysis. Most of the fixed field elements take controlled lists ("value vocabularies" in semantic web terminology), and the list implicitly has the same name as the data element. Many of the lists are specific to a particular physical resource type which is coded in the record or in the field.

 

Go directly to resulting data.

 

Identification of MARC Origin of Data Elements

 

To identify the MARC data element, we can create an identifier made up of the tag, the material designation, and the position or position range. This identification gives us a link back to the MARC field for mapping:

 

reduction ratio = 007microform05

projection = 008map22-23

 

The 006 terms are all repetitions of an 008 term. In that case, both identifiers could be associated with the same data element (rather than creating a duplicate data element for the 006). The positions of the elements in the two fields will be different. (Note that if round-trip mapping between MARC21 and RDA is desired, applications will need to store the MARC21 element of origin in the resulting data.)

 

Identification of the vocabulary terms is similar, but adds the term code to the string:

 

   reduction ratio: low reduction = 007microform05a
   projection: sinosoidal = 008map22-23bg

 

Property Names

 

Some MARC fixed elements have names that stand alone:

  • braille music format
  • azimuth

 

Others need something added for them to make sense:

  • "data type" in Remote sensing, probably needs to be named "Remote sensing data type"
  • "tape width" in Sound recording, probably needs to be named "Sound recording tape width"

 

There are terms that are used for more than one material type and with different values:

  • "dimensions" - used with video, sound recording, microform, etc.
  • "color" - used with motion picture, microform, globe, map

 

Each of these needs to have the material type in the name:

  • dimensions of video recording, or dimensions (video recording)
  • color of map, or color (map)

 

There are a few data elements, mostly in the 008, that are repeated exactly for different material types:

  • Government document
  • Audience

 

These could be a single data element, with links to multiple material-specific MARC 008 elements.

 

We do not want to include the MARC tag in the property names, partly because of the overlap between 008 and 006, but also because the names need to make sense to people who do not think in terms of MARC tags.

 

URIs

 

The URIs could all follow the pattern:

 

http://marc21.info/element/  -- for "properties" (this could also be "/property/". The use of "element" follows the pattern that is used in the registry of RDA.

http://marc21.info/vocab/ -- for value vocabularies

For the fixed fields the name of the property and the name of the vocabulary list are the same,

 

There are three options:

  • Opaque names -- simply number the elements and vocabulary terms, "1001" "1002" etc. 
  • Human-friendly name -- "azimuth" "dimensions(map)"
  • A MARC21 identifier, e.g. following the pattern: tag+indicator, or tag+subfield

 

Discussion:

 

Using the human-friendly data element names in the URIs is risky because it may take  a while to develop a set of names that people agree on.

 

Using opaque names makes it harder for humans to visualize the term meanings when URIs are used. Also, some utility programs that analyze RDF assume that the last part of the last part of the URI string is the name of the property, and use those in graphs.

 

Using the MARC21 "code" will make sense only to persons well-versed in MARC (e.g. librarians). Also, using the code in the URI does not make it easily searchable or easily linked to MARC.

 

 

Overlaps and Conflicts

 

This is for the future, but at some point we may want to reconcile some of the overlapping term lists.

 

There is real overlap and partial overlap between vocabularies. For real overlap, more than one material uses the same values for Government publication. This vocabulary can be defined once, but identified with more than one 008 material.

 

Partial overlap is when similar vocabularies, like Color, have a different selection of values. For example:

 

color = 007map03

  •  One color
  •  Multicolored

color = 007microform09

  • Black-and-while
  • Multicolored
  • Mixed

 

These seem to be a selection from a larger universe of color, and this select may be better handled in an application profile than in the definition of the vocabulary terms themselves, if that is possible.

 

007 Data Elements

 

The first byte of the 007 gives a material type. The list of 007/00 values provides a list of material types. Within those material types there are subtypes, so the full 007 material type vocabulary will be a list of types and sub-types. e.g.

 

Globe

-- Celestial globe

-- Planetary or lunar globe

-- Terrestrial globe

-- Earth moon globe

-- Unspecified

-- Other

 

(Aside: Obviously it would be nice to do without "Unspecified" and "Other." "Unspecified" is probably unnecessary once you move away from fixed fields. Removing "Other" requires that you have a way to add values to the list at the time of cataloging, however.)

 

The 007 primary material types are:

 

- electronic resource

- globe

- map

- microform

- motion picture

- non-projected graphic

- projected graphic

- sound recording

- tactile

- text

- video

 

The remaining bytes in the 007 are properties of the resource type that is represented by byte 007/00. (I do not know of a case where the value of a fixed field byte changes based on the value of 007/01, the specific material type. Need to confirm that is the case.)

 

006/008 Data Elements

 

Every 006 element is also an 008 element, but with a different byte position, since the 006 is only a partial repeat of the 008. There may be no need to create two sets of vocabularies; instead, a single vocabulary description with both the 008 and 006 identifier could suffice. When MARC records are transformed to another format, the originating field+position could be included in the data.

 

The 008 has different values for different formats. In this case, the format information is found in the record Leader, not in the 008 itself.  Position 00 of the 006 contains a code for the resource format.

 

Comments (0)

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