Bibliographic Framework Initiative (Library of Congress)

The Library of Congress > BIBFRAME > BIBFRAME 2.0 to MARC 21 Conversion Specifications

The following specifications were developed to support a pilot in the use of BIBFRAME 2.0 at the Library of Congress. They specify the conversion of BIBFRAME Work and Instance descriptions to MARC Bibliographic records.

MARC Bibliographic Conversion Specifications

Usage Notes

The Specifications are written in a domain specific language in XML for specifying rules to generate MARCXML from RDF/XML that we have labeled “RDF2MARC” conversion language.  They are presented as MS Excel files that are organized by MARC tag ranges. The Specifications are based on the MARC to BIBFRAME conversion specifications maintained by the Library of Congress, and track that conversion very closely.

Some MARC elements are rarely used in Library of Congress records, or cannot be generated reliably from BIBFRAME. If this is the case, the Specifications usually say "nac" (no attempt to code) in the conversion column.

The Specifications use the vocabularies and authorities that are in ID.LOC.GOV – Linked Data Service at as they are resident in the Library’s BIBFRAME descriptions.

Note that these Specifications will be changed as needed as we develop the system for the BIBFRAME 2.0 Pilot.  Revisions to specifications will be indicated in the file name and the URI on the document will indicate a revision (e.g., v1.0, v1.1, v1.2, …).  Changes in a new version will be color coded.

MARC Conventions used in the Conversions

In the BIBFRAME to MARC conversion it was occasionally necessary to make choices in the conversion.  Also the Library of Congress makes extensive use of URIs in BIBFRAME data and wished to avoid the loss of these URIs in the MARC version of a description.    The following conventions were followed.

  • The 008 and 007/00 and /01 are converted but they are also duplicated in other places in the format where a URI for the value could be recorded.
  • For data where MARC may have multiple locations for data, only one was usually chosen.
  • For data where MARC allows options, choices had to be made.  For example, Model B was selected for records containing non-Latin data rather than the Model A.   Thus the 880 field is not used in the records.  This is like MARC Authority records that use Model B.  Non-Latin data will appear in regular fields and there will be less transliteration of non-Latin data.  MARC documentation Appendix D explains the A and B options referenced in the BIBFRAME documentation. 
  • For LCSH subject headings the URI for the whole string precedes the string and the URI for a component follows the component it applies to.
  • Punctuation at subfield boundaries will not be inserted if it is not carried in the corresponding BIBFRAME element.
  • URIs are carried in the MARC $0 subfields.