From MARC To Bibframe

Cataloging & Classification Quarterly
ISSN: 0163-9374 (Print) 1544-4554 (Online) Journal homepage: http://www.tandfonline.com/loi/wccq20
From MARC to BIBFRAME 2.0: Crosswalks
Amanda Xu, Kirk Hess & Laura Akerman
To cite this article: Amanda Xu, Kirk Hess & Laura Akerman (2017): From MARC to BIBFRAME
2.0: Crosswalks, Cataloging & Classification Quarterly, DOI: 10.1080/01639374.2017.1388326
To link to this article: http://dx.doi.org/10.1080/01639374.2017.1388326
Published online: 13 Nov 2017.
Submit your article to this journal
View related articles
View Crossmark data
Full Terms & Conditions of access and use can be found at

http://www.tandfonline.com/action/journalInformation?journalCode=wccq20
Download by: [DUT Library] Date: 14 November 2017, At: 18:23

CATALOGING & CLASSIFICATION QUARTERLY
https://doi.org/10.1080/01639374.2017.1388326
From MARC to BIBFRAME 2.0: Crosswalks

a
Amanda Xu , Kirk Hessb, and Laura Akermanc
a
Cataloging and Metadata Department, University of Iowa Libraries, Iowa City, IA, USA; bLibrary of
Congress, Washington, DC, USA; cWoodruff Library, Discovery Systems and Metadata Librarian from
Emory University, Atlanta, GA, USA
ABSTRACT ARTICLE HISTORY

One of the big challenges facing academic libraries today is to Received June 2017
increase the relevance of the libraries to their user communities. Revised September 2017
If the libraries can increase the visibility of their resources on the Accepted October 2017
Downloaded by [DUT Library] at 18:23 14 November 2017
open web, it will increase the chances of the libraries to reach to KEYWORDS
their user communities via the user’s first search experience. Metadata crosswalks; MARC
BIBFRAME and library Linked Data will enable libraries to publish standards; BIBFRAME 2.0;
their resources in a way that the Web understands, consume conversion specifications;
Linked Data to enrich their resources relevant to the libraries’ converter
user communities, and visualize networks across collections.
However, one of the important steps for transitioning to
BIBFRAME and library Linked Data involves crosswalks, mapping
MARC fields and subfields across data models and performing
necessary data reformatting to be in compliance with the
specifications of the new model, which is currently BIBFRAME
2.0. This article looks into how the Library of Congress has
mapped library bibliographic data from the MARC format to the
BIBFRAME 2.0 model and vocabulary published and updated
since April 2016, available from http://www.loc.gov/bibframe/
docs/index.html based on the recently released conversion spec-
ifications and converter, developed by the Library of Congress
with input from many community members. The BIBFRAME 2.0
standard and conversion tools will enable libraries to transform
bibliographic data from MARC into BIBFRAME 2.0, which introdu-
ces a Linked Data model as the improved method of biblio-
graphic control for the future, and make bibliographic
information more useful within and beyond library communities.
Introduction
In May 2011, the Library of Congress officially launched its Bibliographic Frame-
work Initiative. The goal is to “re-envision and, in the long run, implement a new
bibliographic environment for libraries that makes ‘the network’ central and makes
interconnectedness commonplace”.1 The newly proposed model is called BIB-
FRAME, short for Bibliographic Framework. The new model is “more than a mere
CONTACT Amanda Xu axu789@gmail.com Cataloging and Metadata Department 5020-12 Lib University of
Iowa Libraries 100 Main Library (LIB) Iowa City, IA 52242-1420 USA.
Color versions of one or more of the figures in the article can be found online at www.tandfonline.com/wccq.
Published with license by Taylor & Francis © Amanda Xu, Kirk Hess, and Laura Akerman
2 A. XU ET AL.
replacement for the library community’s current model/format, MARC. It is the

foundation for the future of bibliographic description that happens on, in, and as
part of the Web and the networked world we live in”.2 From 2012–2017, the BIB-
FRAME development went through several iterative phases from releasing the ini-
tial data model to the public in 2012, testing vocabulary and transformation tools
for early experimenters in 2013, implementing testbed in 2014 and pilot 1 project
in 2015 based on BIBFRAME 1.0, to releasing BIBFRAME 2.0 Model and Vocabu-
lary in 2016 and planning pilot 2 project in June 2017 based on BIBFRAME 2.0.
The authors, initially starting with the idea of a crosswalk recommendation project,
decided to examine the mapping tables, converter and updated BIBFRAME 2.0 Vocab-
ulary released by the Library of Congress as of March 13, 20173, and to investigate any
mapping issues discovered through weekly project team meetings, experiment, and
email correspondence for the duration of the project (March–August 2017). Our goal
was to determine how well the conversion produced validate BIBFRAME RDF that
renders MARC bibliographic information in a coherent and usable way.

Within this timeframe, we did not attempt a comprehensive review of all map-
pings. Our aim has been to examine a sample of mappings and conversions, look
for patterns, issues, and problem areas. Our initial goal was to assess the mapping
as a mapping, not to critique the BIBFRAME ontology. In the process of examin-
ing the output, however, we made some observations about BIBFRAME as well.
We were mindful that the framework is going to accommodate many bibliographic
formats and models and the only prerequisite for it to be utilized is the application sup-
port for Linked Data technologies and the Resource Description Framework (RDF).
We were also aware of multiple resource description models using the Linked Data
model, e.g., FRBR-LRM, RDA, BIBFRAME, Dublin Core, Schema.org, etc. Osma
Suominen from the National Library of Finland tested BIBFRAME 2.0. He switched
from BIBFRAME 1.0 to 2.0 with favorable impression.4 His presentation at Semantic
Web in Libraries,5 available from http://swib.org/swib16/slides/suominen_silos.pdf,
makes clear that he is using BIBFRAME 1.0 as the intermediate data model between
MARC and schema.org. Therefore, we have an example of the use of BIBFRAME as an
intermediate data model from which only a few elements will be mapped, while also
being aware of the hundreds of units of information contained in MARC.
In the course of our review, we encountered issues and questions, both with the
mapping and conversion process, and with BIBFRAME 2.0 ontology released on
April 21, 2016. Some MARC elements not mapped in the BIBFRAME 1.0 conver-
sion have been added to the 2.0 mapping, but many are not. BIBFRAME 2.0 elimi-
nated authority class and annotation class in BIBFRAME 1.0. It introduced items
and events, and remodeled titles, identifiers, notes, and roles. One question we
have – will it be necessary to retain all of the detail coming from MARC21? These
and other questions will be addressed in our findings.
For this article, we realized there are many issues that will require further explora-
tion. We decided to present those that we focused attention on in our review to make
others aware of them. We recently became aware of the work of The Library of the
CATALOGING & CLASSIFICATION QUARTERLY 3
Hungarian National Museum in making BIBFRAME 2.0 and MARC descriptions cross
linked. Given the BIBFRAME URI of an instance, one can get the MARC description
by appending .opac to the URI, and given the permalink of an OPAC record, one can
invoke other formats by appending the extensions, e.g., .rdf-ttl, rdf-nt, rdf-json, rdf-
jsonld, and .rdf-rdf. Clicking the BIBFRAME icon in the OPAC also leads to the BIB-
FRAME description.6 We have not addressed this kind of conversion in this article.
Literature review
Roy Tennant famously proclaimed that MARC must die.7 He found this necessary in
order for libraries to be “flexible”, “responsive” to users’ needs and to “serve their users
in exciting new ways. Or not … If libraries cling to outdated standards, they will find it
increasingly difficult to serve their clients as they expect and deserve.” As Kroeger
(2013) put it, “there remains a widespread perception that continued adherence to
MARC is causing libraries to fall behind the technological curve and to miss out on col-
laborative opportunities with other metadata communities.”8
“The BIBFRAME model is the library community’s formal entry point for
becoming part of a much larger Web of Data”.9 It is defined in RDF, and uses sev-
eral foundational ontologies for RDF developed by W3C: OWL (Web Ontology
Language), RDF, RDFS (RDF Schema) and SKOS (Simple Knowledge Organiza-
tion Systems). “It is designed to integrate with, and engage in, the wider informa-
tion community while also serving the very specific needs of its maintenance
community – libraries and similar memory organizations.”10
In addition, the Library of Congress provides supporting services and tools for
aiding migration from MARC to Linked Data environment. LC Linked Data
Service (a.k.a. ID Service) provides URIs for entities and controlled vocabularies,
and together with Getty vocabularies, OCLC and VIAF, serves as a Linked Data
gateway for authorities and vocabularies for the library community and beyond.
The Library of Congress also shares BIBFRAME 2.0 components and tools11 with
the library community, not only to enable the Library to convert the whole Library
of Congress bibliographic file to BIBFRAME (Model and Vocabulary), but also to
facilitate “libraries with in-house XSLT expertise who are interested in converting
to frameworks other than or in combination with BIBFRAME.”12
Although the specs and converter enable the BIBFRAME pipeline to take exist-
ing MARC21 and translate it to the BIBFRAME Model, we also need a program
for quality control, and mechanisms to allow individual libraries to add or request
BIBFRAME extensions. There is nothing currently available for BIBFRAME com-
parable to what’s in place for MARC development through MARC proposals,
available from http://www.loc.gov/marc/mac/list-p.html#2017. Simon Spero
(2017) announced on the BIBFRAME email discussion list,13 his own Open BIB-
FRAME Project, which was hosted in GitHub, and included a summary of progress
in the Readme. Is this a model for how the community should deal with the need
for modifications at this stage? Or should there be a more open and robust “official
4 A. XU ET AL.
way” to propose changes, extensions, or even alternative models to BIBFRAME

Ontology? A development as complex as this needs an experimentation period
before official maintenance is locked down, or else innovation may be stifled.
What’s more, there are other resource types like motion pictures, where there
are actual recordings and books to be modeled using BIBFRAME Model and
Vocabulary. Linked Data for Production (LD4P)14 groups have had to develop
their own ontology as they work to model things beyond the coverage of MARC21
standards. Europeans also looked BIBFRAME as the thing that could unify all
other data models like MARC does.15 “Just as MARC had tried to accommodate
different cataloging norms and various media, the new initiative needs to be as
open to different norms and models and media as possible.”16
Being able to make inferences is one of the goals for BIBFRAME and BIB-
FRAME extensions. But we need data in a Linked Data model first before we can
truly explore the kinds of logical inferences we can make based on the semantics of
our RDF graphs. People can ask hundreds, perhaps thousands, of questions that
couldn’t be asked before, once library data is in the Linked Data model.
Finally, implications for next generation discovery are still evolving. However,
Smith, Stahmer, Li, and Gonzalez (2017) stated that one primary purpose of
Linked Data was to “allow machines to traverse the vast web of networked infor-
mation with the same facility as human readers. Given a starting record or text,
the computer … should be able to identify webs of connectivity and traverse par-
ticular paths based on semantic decision making.”17 Specific to library discovery is
supporting a SPARQL endpoint that enables an external machine to query the
library triplestore. VIAF APIs were logging over 5 million queries a week in
2013.18 And one of the most obvious benefits is to be able to make library resources
visible to the Web so that users can access the resources through search engines
and connect them with a graph of information beyond the library. Xu (2017) called
for developing a library information spotlight and embedding it into library users’
preferred social, local, mobile, semantic, and visual experiences.19 Specifically,
“when users begin their information hunt with a search engine or social network,
whose objective is to help users locate information, then the cultural heritage
organizations need to help those search engines and networks direct users to
answers, especially those held by libraries.”20 It is the possibility to make library
resources appear in users’ first search experience that makes it sensible to trans-
form the resources into BIBFRAME and library linked data and engage users
through enhanced discovery, which is to return a few relevant and qualitative hits
that assist users’ task completion and solve their problems in hand. In short,
Linked Data implementation for discovery is still at its infancy, but has the greatest
potential to impact user research and discovery processes.
One of the important steps for transitioning to BIBFRAME and library Linked
Data involves crosswalks, mapping MARC fields and subfields across data models
and performing necessary data reformatting to be in compliance with the
specifications of the new model, which is currently BIBFRAME 2.0 and which is
the main focus of the article.
Semantic mapping methodology

As early as 1998, St. Pierre and LaPlant gave the definition that “a crosswalk is a set of
transformations applied to the content of elements in a source metadata standard that
result in the storage of appropriately modified content in the analogous elements of a
target metadata standard. A complete or fully specified crosswalk consists of both a
semantic mapping and a metadata conversion specification. The metadata conversion
specification contains the transformations required to convert the metadata record con-
tent compliant to a source metadata standard into a record whose contents are compli-
ant with a target metadata standard.”21 The Library of Congress developed its MARC
21 to BIBFRAME 2.0 Conversion Specifications and Converter following the same best
practice recommended by St. Pierre and LaPlant.
Element to element mapping

BIBFRAME 2.0 organizes the information, providing the description of a resource
into three core levels of abstraction: Work, Instance, and Item. The BIBFRAME
vocabulary uses a Linked Data model and leverages the RDF modeling practice of
uniquely identifying Web resources, all of their entities and relationships through
RDF classes and properties. The RDF classes and properties can be found as an
ordered list through BIBFRAME 2.0 Vocabulary List View.22 BIBFRAME 2.0
Vocabulary also presents all properties in Category View,23 and its entire vocabu-
lary as RDF View through bibframe.rdf.
In addition to the basic vocabulary, BIBFRAME 2.0, which has had minor
updates in response to community corrections and comments since it was first
posted in April 2016, introduces the LC Extension24 vocabulary to include ele-
ments that LC found needed for its extensive pilot preparations.
What’s more, many controlled vocabularies and lists used for bibliographic
description are transformed into RDF and their links can be referenced by URIs
accessible for human and machine processing via LC Linked Data Service or LC
ID Service at id.loc.gov and other vocabulary gateways. The ontology closely
related to LC ID Service is MADSRDF (Metadata Authority Description Schema
in RDF). It provides a data model that is suitable for the types of authority code
and term lists used in bibliographic data.25 It is the combination of BIBFRAME
basic vocabulary, LC extension, and MADSRDF that not only gives the semantic
definition of each metadata element and organization of them, but also drives the
modeling and conversion from MARC21 to BIBFRAME 2.0.
One of the possible processes to map MARC data elements in a MARC21 record
to the BIBFRAME2.0 Model and Vocabulary is to batch MARC URI insertion and
transform the resource description into RDF statements,26 also known as triples of
subject, predicate and object, following BIBFRAME 2.0 RDF Conventions27and
6 A. XU ET AL.
Guidelines.28 The batch MARC URI insertion process can be done by a vendor or
by in-house MARC experts. For instance, data in MARC can be matched with
linked data services such as id.loc.gov and URIs inserted before conversion to BIB-
FRAME. The BIBFRAME converters can then process those URIs into correct
properties on BIBFRAME RDF. This process is necessary for legacy MARC data
conversion. For those entities or field elements that do not find a match of URIs
from LC ID Service, the LC converter in XSLT will create minted URIs constructed
from the stem of the baseURI parameter (default http://example.org), record ID of
MARC record (by default the value of the 001 field) and a hash URI.29 The hash
URI is constructed from the element class, e.g., #Topic, the field number, e.g., 650,
and position of the field in the MARC record, e.g., http://example.org/
ocn782927281#Topic650-42.
The Library of Congress has done the mappings through MARC 21 to BIB-
FRAME 2.0 Conversion Specifications which are grouped by MARC fields in 20
MS Excel spreadsheets and accompanied by processing instructions in Word as

indicated in Figure 1.30
The MARC21 to BIBFRAME 2.0 Conversion Specifications are written by the
Library’s Network Development and MARC Standards Office from the perspective of
MARC so that each element in MARC would at least be considered, even if not con-
verted. “If there is little or no use of an element in the Library of Congress records, the
Specifications indicate ‘nac’ (no attempt to convert) in the conversion column”.31
“Libraries outside Library of Congress may want to have different choices for which ele-
ments in MARC record are to be converted and augment the Specifications to address
‘nac’ elements”.32 Elements in MARC records which are deemed not relevant outside
the MARC environment are marked “ignore.” A shorthand is used for the Specifica-
tions. The shorthand uses W for Work, I for Instance, and Item for item. To illustrate
how it is done, we choose an example of the Conversion Specification for MARC fields
001–005, 007—Control, Physical Description fixed fields—R1 in Figure 2.33 The first
column indicates the source of MARC fields and subfields. The Conversion 1 column
indicates the mappings into the target–BIBFRAME Model using BIBFRAME Vocabu-
lary and cases where the vocabularies in id.loc.gov are used. The Conversion 2 column
indicates additional mapping instructions for target RDF statement conversion based
on BIBFRAME 2.0.
The example of the Conversion Specification for MARC Field 648–662 – Sub-
jects – R1 in Figure 334 illustrates more complex mappings. Again, the first column
indicates the source of MARC field 650 and its subfields. The second column indi-
cates the mapping to the target–BIBFRAME Model using MADSRDF vocabulary
for conversion of the topical subject headings.
Still another example of the Conversion Specifications—Fields 1XX, 6XX, 7XX, 8XX,
X00, X10, X11—Names – R0 (Excel 12 KB, 03/07/2017) in Figure 435 illustrates the
conversion of X00, X10 and X11 for names, and the use of local elements from LC
Extension with bflc as namespaces in the conversion of names and titles. The first col-
umn indicates the source of MARC fields and subfields. The second column indicates
Figure 1. LC MARC21 to BIBFRAME 2.0 conversion specifications.
the mapping to the target–BIBFRAME Model, using conversion instructions from Pro-
cess 0-names/titles and Process 1-names with selected illustration in Figure 5,36 e.g.,
making a name match key using bflc:nameXXMatchKey, making a name marc key
using bflc:nameXXMarcKey, making a name rdfs:label for literals taken from each sub-
field of X00, X10, and X11, figuring out name role based on $e (X00, X10) or $4, and
making a name primary contributor using class bflc:PrimaryContribution, etc. These
local elements “will be eliminated from RDF when merge and match is complete”37
unless there is a need to keep some of them that “come into BIBFRAME environment
from MARC.”38
Fields X30, 240, (6, 7, 8/X00, X10, X11), etc. are for uniform titles. They are
mapped into bf:Work so that subjects can be associated with the titles. But fields
200–24X, except 240 are mapped into bf:Instance. The different manifestations of
a bf:Work are separately described as bf:Instance. Each instance is an instance of
8 A. XU ET AL.
Figure 2. LC conversion specifications “Fields 001–005, 007 –Control, Physical Description – R1”
(Excel, 36 KB, 06/07/2017).
Figure 3. LC Conversion Specifications “Fields 648–662 – Subjects – R1” (Excel, 14KB, 06/09/2017).
Figure 4. LC Conversion Specifications “Fields 1XX, 6XX, 7XX, 8XX, X00, X10, X11 – Names – R0”
(Excel, 12 KB, 03/07/2017).
Figure 5. LC conversion specifications “Process Notes – R2 – 0.3.1 RDF for Names” (Word, 28 KB, 07/
27/2017).
10 A. XU ET AL.
Figure 6. LC conversion specifications “Fields 240, X30, etc. – Uniform titles – R1” (Excel, 12KB, 06/
09/2017).
one and only one bf:Work with some exceptions.39 The property bf:title and class
bf:Title are used in both bf:Work and bf:Instance.
Figure 640 indicates the mapping of MARC fields X30, 240, etc.to uniform titles
in bf:Work class using processing instructions from Process 0.3 (see Figure 7) for
converting RDF titles and Process 2 for making a title match key bflc:titleXX-
MatchKey, title marc key bflc:titleXXMarcKey, title rdfs:label for literals taken
from subfield codes in MARC X00, X10, X11, X30, and 240; and title sort string
bflc:titleSortKey. The first column indicates the source of MARC fields and sub-
fields. The Conversion 1 column indicates the mapping to the target–BIBFRAME
Model for bf:Work class and its associated properties such as bf:title, bf:mainTitle,
bf:language, bf:genreForm, bf:partNumber, etc. The Conversion 2 column
Figure 7. LC conversion specifications “Process Notes R2 – 0.3.2 RDF for Titles” (Word, 28KB, 07/27/
2017).
Figure 8. LC conversion specifications “Fields 200–24X, except 240 – Titles –R1” (Excel, 12KB, 06/08/
2017).
identifies changes for BIBFRAME 2.0 conversion and additional clarifications are
provided in the Notes column.
The construct of Title class is from title subfield as indicated in Figure 741 con-
version specifications – process notes – R2 – 0.3.2 RDF for titles.
Figure 842 indicates the mapping of MARC 245 – Title Statement. The first col-
umn indicates the source of MARC field 245 and its subfields. Conversion 1 col-
umn indicates the mapping to the target – BIBFRAME model for instance title.
Conversion 2 column indicates that the same MARC 245 field will also be mapped
to BIBFRAME Work if the MARC record does not have a 130 or 240 field. That is
the reason why we will find “Snoopy on wheels” as rdfs:label for the title property
extracted from 245 $a, $f, $g, $k, $n, $p, and $s (if the subfields are available), and
bf:mainTitle extracted from 245 $a appearing in both bf:Work and bf:Instance in
MARC to BIBFRAME Comparison Viewer available from <http://id.loc.gov/
tools/bibframe/compare-id/full-ttl>.
The relationship is derived from patterns in MARC fields, e.g., if 1XX, then it is
name/title relationship; if 6XX, then relationship is bf:subject; if 700–730, then if
second indicator is 2, the relationship is bf:hasPart, else relationship is bf:relatedTo;
if 8XX, then relationship is bf:hasSeries; if 760–788, then relationship is determined
by field and second indicator as indicated in the conversion specification for Fields
76X–78X – Linking Entries.43 Figure 9 indicates conversion specifications – pro-
cess notes – R2 ¡0.3.3 RDF for relationships.
The selected MARC21 to BIBFRAME 2.0 Conversion Specifications published
by the Library of Congress on March 13, 2017 document the element to element
12 A. XU ET AL.
Figure 9. LC conversion specifications “Process Notes R2 – 0.3.3 RDF for Relationships”44 (Word,
28 KB, 07/27/2017).
mapping decisions for the conversion of RDF names, titles, relationships and sub-
jects for the BIBFRAME Work and Instance classes and their associated properties.
Together with other LC Conversion Specifications, they are the building block for
the development of MARC to BIBFRAME 2.0 conversion.
Hierarchy, object, and logical view resolution

Most metadata standards organize the metadata hierarchically. The MARC21 model at
a high level has three main components: Bibliographic, Authority and Holdings. The
data in the bibliographic component is the description of the resource being described,
including conceptually the FRBR/RDA work and expression, and its physical embodi-
ment, the FRBR/RDA manifestation.45 FRBR/RDA work and expression can be related
to BIBFRAME Work class, bf:Work, which is the conceptual essence of the cataloged
resource. FRBR/RDA manifestation can be related to BIBFRAME Instance class, bf:
Instance, which is the physical embodiment of a Work.
The authority class is eliminated from BIBFRAME 2.0. But the controlled com-
ponent of the data still contains the authorized forms of: (1) named entities such
as persons, corporate bodies, meetings; (2) subjects, including topics, time periods
and geographic names; and (3) uniform titles whose data is incorporated into the
description of the BIBFRAME Work.
The data in the holdings component provides information on what copies and
parts of the resource an institution holds, where they are located, availability, etc.;
this corresponds to the RDA item.46 BIBFRAME Item class relates to RDA item
and bears information such as location (physical or virtual), shelf mark and bar-
code.47 Figure 10 below is the overview of the BIBFRAME 2.0 Model.48
Figure 10. Overview of the BIBFRAME 2.0 model.
MARC is the single object metadata standard, which is often associated with one
item per use. BIBFRAME conversion generates multiple objects (work, instance,
item, etc.) within the chunk of RDF statements. In theory, BIBFRAME is going to
replace the MARC format with a data interchange framework that makes library
data more readily available on the Web.
Since the key building block for BIBFRAME is RDF, the logical view of BIB-
FRAME Vocabulary 2.0 can be found in Category view, List view, RDF view and
LC Extension list view, which enable easy implementation for different user com-
munities. The hierarchical structure of BIBFRAME 2.0 Ontology in BIBFRAME
RDF and Extension RDF can be visualized using WebVOWL.49 Figure 11 is the
WebVOWL visualized bibframe.rdf.
Since LC Extension RDF imports bibframe.rdf and relators.rdf, one can open LC
Extension RDF, explore and visualize bibframe.rdf as external resources. Figure 12
is the portion of bf:Agent ontology visualized through LC Extension.
Content conversion
LC released the MARC2BIBFRAME 2 converter on March 13, 2017. The converter
uses XSL stylesheets developed by Index Data, and is being continuously evaluated by
LD4P (Linked Data for Production) and other library communities. It converts
MARCXML to BIBFRAME 2.0. The code is split into 20 XSL files, each corresponding
to a conversion specification published as Excel sheets at the Library of Congress
http://www.loc.gov/bibframe/mtbf/. In addition, there are corresponding unit tests
written in XSpec that verify that the conversion produces the desired result.50
The previous conversion utility for BIBFRAME 1.0 used XQuery, which was sig-
nificantly slower to process and difficult for partners to understand how to extend
14 A. XU ET AL.
Figure 11. WebVOWL visualized BIBFRAME RDF.

since XQuery is not a very popular programming language. On the other hand,
since XQuery is a complete programming language it was able to handle in-line
active conversion, e.g., resolving URIs for elements of the RDF/XML output from
authoritative sources like Library of Congress Authority File, while the XSLT style-
sheet only does a static conversion with no URI resolution.
For active conversion of records with BIBFRAME 2.0, YAZ51 was updated with
a new yaz-record-conv utility, which uses a separate configuration file for resolving
URIs.52 In addition, both static and active conversions can be integrated into Index
Data’s Metaproxy53 if preferred to the conversion using command lines. Figure 13
is the screenshot of LC MARC2bibframe2 converter.54 The converter in XSLT
stylesheets can be downloaded from GitHub and also plugged into Oxygen XML
Editor for static conversion.
Figure 12. WebVOWL visualized LC extension RDF for bf:Agent ontology.

Figure 13. LC MARC2BIBFRAME2 converter.
Evaluation of the mappings and converter — what works and what doesn’t
The Crosswalk Project team reviewed LC MARC2BIBFRAME 2.0 ontology, converter
and specs, collaboratively investigated the mapping issues through sample testing, and
discussed the issues through weekly meetings via Google Hangouts. We also explored
the visualization of BIBFRAME Core and Extension vocabularies and compared them
with sample records resulting from the converter at Work, Instance, Item, and Agent
level. The preliminary findings that we identified for mappings and converter are mov-
ing targets, since LC updates its MARC2BIBFRAME 2.0 ontology, converter and con-
version specifications every day as it develops and refines its BIBFRAME pilot input
system.
The intent of the converter is to get good enough mappings for the second
LC Pilot project and for communities. LC has indicated it will continue to
work with communities, particularly RDA cataloging and PCC, and get their
feedback on what they might add to the mappings, e.g., fields that LC didn’t
use but others may find useful. LC releases tools like the converter as open
source so libraries may modify it for their own institutions, and still build
valid BIBFRAME.
16 A. XU ET AL.
The Crosswalk Project team initially enhanced 1000 MARCXML records by

resource format and language using MARCEdit, converted them to BIBFRAME2
RDF/XML using Oxygen XML Editor, and then validated the selected few via W3C
RDF Validation Service.55 The following is a summary of our preliminary findings.
Conversion tools and process

Preprocessing required to force normalization to NFC as part of the conversion
for basic RDF validation: Processing a converted file containing accented characters
in W3C’s RDF validator resulted in warning message “String not in Unicode Normal
C,” as the standard requires NFC in W3C documentation.56 When we export MARC
in UTF-8, then convert it to MARCXML, is it NFC (Normalization Form Canonical
Decomposition) or NFD (Normalization Form Canonical Composition)? If NFD, we
have to convert it to NFC. LC is doing this as part of the conversion as a preprocessing
step. It might be possible to treat it as part of the export depending on individual inte-
grated library systems. Conformance to standard is mandatory, however, we recog-
nize that some applications may support NFD better.
Use of rdf:value for URIs may be problematic: Tools in our BIBFRAME RDF
pipeline convert a URI in rdf:value to a literal. It is cumbersome for applications in
the down streaming process to disambiguate rdf:value mixed with literals and
URIs, but actually tagged as literals for both. Tools used in the BIBFRAME conver-
sion pipeline by this evaluation are MARCEdit, Oxygen XML Editor, RDF Transla-
tor (http://rdf-translator.appspot.com/), and RDFa validator (https://www.w3.org/
2012/pyRdfa/Validator.html).
Whitespace as part of the minted URI is problematic: Running the XSLT con-
verter using the tool like Oxygen XML Editor may add whitespace for minted
URIs, and the whitespace often occurs between record identifier and hash (#), the
element name (e.g., bibframe.example.org/5226 #Topic650-22) as part of the
minted URI. We understand that The Library of Congress is addressing this
problem.
Partial representation from the URI lookup: Tools like MARCEdit can batch
insert URIs found from LC ID Service, and other vocabulary gateways into 100,
700, etc. fields using MARC $0. But MARCEdit VIAF URI lookup for MARC 700
$a and $t only applies to MARC 700 $a for personal name, which results in the
loss of representation of the MARC 700 $t. A fix of the MARCEdit VIAF URI
lookup to cover both author and title is needed.
Improvements from BIBFRAME 1.0 to 2.0 conversion

Comparing MARC records to BIBFRAME 2.0 converted records and other
conversions: The Crosswalk Project team found the BIBFRAME Comparison
Tool useful for side by side viewing of MARCXML to BIBFRAME2, e.g., http://id.
loc.gov/bibframe/compare-id/full-ttl?findD5226. We compared the conversion
with OCLC WorldCat linked data implementation http://www.worldcat.org/oclc/
48163899. We noticed the OCLC conversion includes a two-letter language code
for the title, e.g., schema:name “Snoopy on wheels”@en. According to Jeff Young
from OCLC Research (2017),57 the language codes are assigned when the language
of cataloging is the same as the language of the material. If they don’t match, then
the language code is generally omitted. Java has a Local class that can be used to
convert between ISO2 and ISO3 language codes. We think this is worth investigat-
ing for libraries planning BIBFRAME conversions. The two-letter code is an attri-
bute for the language code. The supposition is that if you know the language of the
bf:Work, you would tag the literal values with that language code.
Language code issues: We checked into the conversion of MARC 041 field for a
language part issue initially reported by Osma Suominen.58 Language information

from the 041 fields could be mixed up when converting multiple records in the
same batch. We contacted Osma Suominen and through email discussions and
experiment reached a proposed solution with Ray Denenberg from LC. LC fixed
this and just pushed the fix recently.
Need a label for the work: The team noted that BIBFRAME 1.0’s “work authority
key” element was no longer created in 2.0. This was derived from the combination
of the agent and title in rdfs:label for bf:Work, which can be integrated as madsrdf:
authoritativeLabel, which is a skos:prefLabel in authoritative sources such as LC
Authority file and VIAF. The example we looked at is: Mozart, Wolfgang Ama-
deus, 1756–1791. j Nozze di Figaro, available from http://viaf.org/viaf/308699110.
The team will give some guidance on how to form a skos:prefLabel based on the
other values in an element, and address the issue with the Library of Congress.
Status of URI retrieval from authorities: BIBFRAME 1.0 converter could gener-
ate URIs for entities consistently. For BIBFRAME 2.0 active record conversion
includes the retrieval of URIs from MARC Authorities for bf:agent. YAZ and
Metaproxy are recommended tools for this.
At the time of writing, we discovered that LC had just recently developed con-
version routines for URIs for subjects. As a result, subject headings including com-
mon free-floating subdivisions, e.g., “Congresses” as used with “Aerial
photogrammetry–Congresses” will have a URI like http://id.loc.gov/authorities/sub
jects/sh2009113810. The converter will automatically associate the URI retrieved
from authorities with bf:subject. If the entire heading including the subdivision is
not established in LCSH, the heading will be a blank node—for now. Library of
Congress is investigating possibilities for minting URIs for these combinations
and/or capturing the URIs for subdivisions from LCSH when all subdivisions have
18 A. XU ET AL.
an authority record. We did not have time to fully evaluate the current process but
it seems to be working.
Include more human readable labels? Files converted using LC MARC2BIB-

FRAME converter should be both Linked Data application friendly and HTML
application friendly. Linked Data applications identify the thing, not the string.
When such data is output and stored for use in HTML applications, additional
processes would be needed to do the crosswalks between the thing and string from
sources outside the MARC record, for indexing and display purposes. Examples
are language code, country code, contributor code, issuance code, etc. Having the
labels already provided in converted data along with the URIs would make its use
in such applications simpler and could make it easier for those “reading the RDF”
to spot issues. Keeping the labels up to date in stored data would be the responsi-
bility of the user.
Unmapped fields: Converting from MARC 852 to bf:Item and MARC 86X for
serials are still a manual process or converter fix. Only a partial mapping is
provided for these fields. Many institutions store their item information this
way, but others utilize xx9, x9x, and 9xx locally defined fields in their MARC
output for item information. Examples from the community for item mapping
will be needed, and it would be helpful for the Library of Congress to provide
advice and methods for combining local item mapping with their BIBFRAME
conversion programs. Figure 14 indicates elements in an item are listed as
“nac”, also known as no attempt to convert and Figure 15 indicates elements
in serials are listed as “nac”.
As we reviewed the mapping documentation, we noted that in BIBFRAME 2.0

there are still many MARC fields that are not included in the BIBFRAME conver-
sion e.g., labeled as “ignore” or “nac” (no attempt to convert). Elements marked
“ignore” are ones that probably do not need to be converted. Others may have
importance for a particular community. Rather than suggesting that Library of
Congress add data to the BIBFRAME output for which it anticipates no future use,
these omissions may point to needs of particular metadata communities to develop
(and share) augmented versions of the conversion specifications and tools, once
they have been stabilized. We have not investigated all of the unmapped fields to
see if there are BIBFRAME 2.0 elements to which they could be mapped; that
might be investigated in the future.
We highlight here just a few of many examples of unconverted data which
might be of interest to add to a local or community BIBFRAME conversion:
031 Musical Incipits Information – not mapped at all. LD4P Project for
Music59 may be able to address it. The Performed Music Ontology may pro-
vide solutions for the better ways to do it in Linked Data than in MARC.
Figure 14. LC conversion specifications “ConSpec-841-887-R1p” (Excel, 14 KB, 06/01/2017)61.
034 Coded Cartographic Mathematical Data – many subfields are not

mapped – basically only those for four coordinates. LD4P Project for Cartog-
raphy60 may be able to address it. The LD4P Projects are working on
Figure 15. LC conversion specifications “ConvSpec-841-887-R1p” (Excel, 14KB, 06/01/2017)62

20 A. XU ET AL.
Figure 16. LC conversion specifications “Process Notes R2 – Process 6 Series Processing” (Word,
28KB, 07/27/2017)63.
solutions for better ways to do it in Linked Data than in MARC in their

extensions to BIBFRAME 2.0.
1xx, 7xx Personal Names $u (Affiliation) – ignored. Defined as “Affiliation or
address of the name.” We understand that its use has been mainly with tech-
nical reports. Are there institutions which have used $u to record an institu-
tional affiliation for other types of material? Might this affiliation be
important information that is not recorded in an authority record?
Series relationships: The current BIBFRAME structure and mapping do not provide a
way of associating series numbering with particular series statements, identifiers, etc.,
so Instances that were published in multiple series result in confusing data.
The Library of Congress is actively working on modifications to BIBFRAME for the
very difficult mapping of series and series access points in 490 and 8xx. The conversion
involves two steps with additional instructions. The first step is to convert 490 and 8XX
together. The conversion program needs first to break a 490 with a repeating $a into
multiple 490 fields with $a($x)($v) in each. Keep 490s in the same order as $a’s in the
field. Then if more than one 490/8xx, pair them assuming they are in the same order,
e.g., first 490 goes with first 8XX, etc. Figure 16 is the snapshot of the second conversion
step to process series as of June 9, 2017.
AdminMetadata relationship: The relationship of the AdminMetadata section

(see Figure 2 above) to bf:Work continues to be, at the least, very awkward and
problematic. This section maps elements relating primarily to the source MARC
record’s provenance and characteristics, including bf:changeDate, bf:creationDate,
bf:descriptionConventions; bf:identifiedBy (the LCCN), etc. A number of blank
nodes are used. LC’s RDF Conventions state that “BIBFRAME takes no position
on the issue of URI vs. blank node. While it is recognized that URIs are linked-
data friendly and blank nodes64 are not, both are acceptable in BIBFRAME and
the choice is an implementation decision”.65 More importantly, this data does not
relate to the BIBFRAME work! Most of it is about the MARC record—or parts of
it—from which the BIBFRAME graph (or a subset of it) was produced—for the
most part, provenance for that graph. While this seems like a simple and expedient
way of putting the data somewhere in the BIBFRAME model, the consequences if
BIBFRAME data is accessed and used out in the world, perhaps by non-library
applications, could be troubling.
There may also be concerns with batch conversion and association of multiple
Instances with a single bf:Work. Use of blank nodes could risk the AdminMetadata
getting “lost” or un-associated with the specific set of triples it is about. Would we
be able to distinguish the multiple AdminMetadata “blank node” sections from
converted MARC records with the particular triples to which the AdminMetadata
refers? The URI generation function in the full conversion is creating a Work URI
based on Library of Congress’s system. This means every MARC record gets a sep-
arate work URI. However, there are many situations where bibliographic records
describe multiple instances of the same BIBFRAME Work (which combines FRBR
Work and Expression elements). An example: a print book, a microform made by
scanning the books, and an electronic version derived from either the microform
or a new scan of the print book.
We don’t know how these separate BIBFRAME Instances will get linked to the
same Work, but it will need to happen. The flat conversion of the MARC record is
only the first step in the building of a BIBFRAME modeled file of descriptions, and
we understand that the Library of Congress is actively completing the process as
they condition the BIBFRAME files. But in this case, it could be unclear within a
system storing BIBFRAME output from multiple record conversions as to which
triples were being referenced by which AdminMetadata section. It becomes appar-
ent that this data really refers to the provenance of the Instance data, rather than
that of the Work. But the issue remains that this is data about the RDF data source,
not about the Instance.
One alternative to mapping this data to a BIBFRAME element would be to use
Named Graphs.66 Then the adminMetadata property could be associated with and
describe a graph URI, or context, for the appropriate element triples, which would
be the fourth element of every such triple converted from a particular MARC
record. The Named Graph approach does not have W3C recommendation status,
but perhaps it would be preferable to this awkward, “MARC-y” construction.
There could be other solutions to consider; even providing a reified version of the
applicable triples with its own identifier to which the AdminMetadata and other
provenance information could refer, is a possibility.67 Different systems may han-
dle this kind of information differently, but in the workflow of the future, prove-
nance information about linked data “graphs” or groupings will be just as
important (or more so) as it is in the current MARC based system, and its model-
ing should be clear and unambiguous.
Conclusion
The current state of the BIBFRAME 2.0 conversion tools provided by the Library
of Congress is improved from the version 1.0 conversion. The tools are openly
available for the development community to experiment with and the explanations
22 A. XU ET AL.
for mapping decisions are, for the most part, clear. A large majority of the 2,000
MARC elements have appropriate mappings to BIBFRAME statements.
However, we find many changes are still needed. Some of these relate to how the
MARC data is mapped—issues such as URI formation, Unicode normal forms,
problems with particular conversion tools and literals, need for more human-read-
able labels, etc. are issues we expect and hope will be addressed in the near term by
LC’s ongoing modifications to the conversion process.
Other issues point to problems with the nature of BIBFRAME 2.0 as currently
constituted. We can characterize many of these as needs to clarify the definitions
of entities (“resources” in RDF), the relationships between them, and the data
describing each entity. These include series relationships and numbering, lan-
guages and their relation to parts of a work, instance, or even parts of a description,
and provenance data coming from the MARC record. Our experience points to a
need to re-conceptualize and more clearly identify how this data is structured in
the BIBFRAME model. The use of blank nodes continues to be problematic; mint-
ing URIs for series as BIBFRAME Instances (if URIs from authorities are not avail-
able), for example, would do much to clarify that situation.
The continued absence of mapping for some MARC elements, particularly local
ones, leads to questions about how best to provide for the needs of libraries other
than the Library of Congress. Should its BIBFRAME mapping be the canonical
one? Or, could there be a “super mapping” contributed to by the community that
would capture all usable data? Or, is there a need for different flavors supported
locally (and possibly leading to confusion and lack of standardization when the
data is shared and consumed)? We will make some suggestions in the next section.
Future suggestions
In future, we feel the Library of Congress could greatly improve the process of
work on BIBFRAME and its conversion. The following are some suggested services
that we would like to see the Library of Congress support in the near term.
Validation: We understand that The Library of Congress is addressing OWL
validation of the BIBFRAME ontology, and will address RDF validation of
conversion output as well. This will be very helpful, enabling them to catch
some problems before release, as the BIBFRAME ontology and conversion
tools continue to evolve.
Formal workflow for issues and suggestions: Provide a more formal and
transparent method for members of the interested communities to submit
corrections, suggestions for improvements, and requests for variations on
BIBFRAME and its conversion. This web-based interface would not supplant
the email BIBFRAME discussion list and the issues submitted to GitHub, but
would provide points of reference for concerns, suggestions and responses so
that issues do not get lost. One suggestion would be a place on the Web where
larger issues and context for BIBFRAME can be stated, with links to GitHub
issues and/or BIBFRAME list postings if needed, and where status of the con-
cern and responses from the community and, if appropriate, Library of Con-
gress can be posted.
Facilitation of community variants: Provide, or link to, platforms for com-
munities to describe and present their own variant conversion specifications.
This needs further discussion, but the idea would be that “one size doesn’t
necessarily fit all”, as long as the output follows the essential BIBFRAME
structure. We can imagine a group such as music librarians who might want,
for example, a mapping for the musical incipits, while others do not. RDF
graphs can easily be expanded and added to by including additional classes
and properties from other vocabularies, including those specifically desig-
nated as “BIBFRAME extensions”. The Library of Congress or some other
organization could greatly facilitate the adoption and success of BIBFRAME
in the community by providing the platforms and working with community
leaders to develop processes for sharing.

In the future, communities (plural!) of metadata users and developers who have
specific needs and who should be vitally interested in the future of RDF metadata
using BIBFRAME should do the following.:
Come together: Organize, work together, and have decision processes (note
that these communities may not necessarily be represented by existing formal
organizations).
Keep abreast of changes: Review future developments in the BIBFRAME
standard and mapping, respond to positive or negative changes from their
point of view, and make their needs and plans known.
Share: Share additions to BIBFRAME and custom mappings so that, as in the
past, libraries can reap benefits of collaboration and some degree of
standardization.
Acknowledgments
The authors would like to thank the following people, universities, and organizations:
University of Iowa Libraries, particularly Paul Soderdahl, the Associate Uni-

versity Librarian; Leo Agnew, Director of Human Resources & Diversity Pro-
grams, and Sue Julich, Head of Library Information Technology.
Cornell University, particularly Jason Kovari, Head of Metadata Services; Sim-
eon Warner, Director of IT for Library Linked Data and Repository Architec-
ture; Rebecca Younes, Semantic Web Developer; and Adam Chandler,
Director, Automation, User Experience, and Post Cataloging Services.
Library of Congress, particularly Ray Denenburg and Sally McCallum, Chief,
Network Development and MARC Standards Office for their guidance and
support.
24 A. XU ET AL.
Roy Tennant and Jeff Young for their help with our questions regarding lan-
guage tags implemented for Linked Data in WorldCat.
Igelu-SIWG-LOD, Zepheira and ExLibris Linked Data Collaboration
Program.
ORCID
Amanda Xu http://orcid.org/0000-0002-2091-8244
Notes
1. Library of Congress, Bibliographic Framework as a Web of Data: Linked Data Model and
Supporting Services (Washington, DC: Library of Congress, November 21, 2012), 3, http://
www.loc.gov/bibframe/pdf/marcld-report-11-21-2012.pdf.
2. Ibid.
3. Sally McCallum, “BIBFRAME Specifications and Conversion Programs Made Available,”
Listserv Bibliographic Framework Transition Initiative Forum (March 13, 2017), https://list
serv.loc.gov/cgi-bin/wa?A2Dind1703&LDBIBFRAME&PD2931.
4. Osma Suominen, “First Impressions of New MARC to BIBFRAME 2.0 Converter,” Listserv
Bibliographic Framework Transition Initiative Forum (March 23, 2017), https://listserv.loc.
gov/cgi-bin/wa?A2Dind1703&LDBIBFRAME&PD12413.
5. Osma Suominen and Nina Hyv€onen, “From MARC Silos to Linked Data Silos?” (Presenta-
tion, Semantic Web in Libraries, Bonn, Germany, November 30, 2016), http://swib.org/
swib16/slides/suominen_silos.pdf.
6. Adam Horvath, “BIBFRAME at the Library of the Hungarian National Museum,” Listserv
Bibliographic Framework Transition Initiative Forum (May 18, 2017), https://listserv.loc.
7. Roy Tennant, “MARC Must Die,” Library Journal 127, no. 17 (October 15, 2002): 26–28,
http://lj.libraryjournal.com/2002/10/ljarchives/marc-must-die/.
8. Angela J. Kroeger, “The Road to BIBFRAME: The Evolution of the Idea of Bibliographic
Transition into a Post-MARC Future,” Cataloging & Classification Quarterly 51, no. 8
(2013): 873–890. doi: 10.1080/01639374.2013.823584.
10. Ibid., 3.
11. Sally McCallum, “BIBFRAME Specifications and Conversion Programs Made Available,”
Listserv Bibliographic Framework Transition Initiative Forum (March 13, 2017), https://list
serv.loc.gov/cgi-bin/wa?A2Dind1703&LDBIBFRAME&PD2931.
12. MacKenzie Smith, et al., BIBFLOW: A Roadmap for Library Linked Data Transition (Davis,
CA: University Library, University of California-Davis, 2017), 24, https://bibflow.library.
ucdavis.edu/wp-content/uploads/2017/03/bibflow_roadmap_revised_3_14_2017.pdf.
13. Simon Spero, “Open Bibframe Project,” Listserv Bibliographic Framework Transition
Initiative Forum (March 14, 2017), https://listserv.loc.gov/cgi-bin/wa?A2Dind1703&LD
BIBFRAME&PD4727.
14. Linked Data for Production (LD4P), the Andrew W. Mellon Foundation supported proj-
ects, piloting the production of linked data for library resources, https://wiki.duraspace.
org/pages/viewpage.action?pageIdD74515029.
15. Sofia Zapounidou, Michallis Sfakakis, and Christos Papatheodorou,”Library Data Integra-
tion: Towards BIBFRAME Mapping to EDM,” in Metadata and Semantics Research: 8th
Research Conference, MTSR 2014, Karlsruhe, Germany, November 27-29, 2014, eds. S.
Closs, R. Studer, E. Garoufallou, M. Sicillia (New York: Springer, 2014), 262–273.
16. Sally McCallum, “BIBFRAME and Linked Data for Libraries,” in Linked Data for Cultural
Heritage, eds. Ed Jones and Michele Seikel (Chicago: American Library Association, 2016),
105–123.
17. MacKenzie Smith, et al., BIBFLOW: A Roadmap for Library Linked Data Transition (Davis,
CA: University Library, University of California-Davis, 2017), 5, https://bibflow.library.
ucdavis.edu/wp-content/uploads/2017/03/bibflow_roadmap_revised_3_14_2017.pdf.
18. Steven Holloway, “Life after MARC: The Future of Discovery,” Listserv Bibliographic
Framework Transition Initiative Forum (March 31, 2017), https://listserv.loc.gov/cgi-bin/
wa?A2Dind1703&LDBIBFRAME&PD17707.
19. Amanda Xu, “Collaborative Linked Data Project for BIBFRAME 2.0 for Library Informa-
tion Spotlight” (Presentation, LITA/ALCTS Linked Data Interest Group, ALA Midwinter,
Atlanta, January 21, 2017), http://connect.ala.org/node/262645.
21. Margaret St. Pierre and William P. LaPlant, Jr., Issues in Crosswalking Content Metadata
Standards (Bethesda, MD: NISO Press, 1998), http://www.niso.org/publications/white_pa
pers/crosswalk/.
22. Library of Congress, “BIBFRAME 2.0 Vocabulary List View,” http://id.loc.gov/ontologies/
bibframe.html (accessed September 9, 2017).
23. Library of Congress, “BIBFRAME 2.0 Vocabulary Category View,” http://id.loc.gov/ontolo
gies/bibframe-category.html (accessed September 9, 2017).
24. Library of Congress, “LC BIBFRAME 2.0 Vocabulary Extension List View,” http://id.loc.
gov/ontologies/bflc.html (accessed September 9, 2017).
25. Sally McCallum, “BIBFRAME and Linked Data for Libraries,” in Linked Data for Cultural
Heritage, eds. Ed Jones and Michele Seikel (Chicago: American Library Association, 2016), 105–
123.
26. Amanda Xu et al., “Initial BIBFRAME 2.0 Modeling for the Library Information Spotlight
‘Opera Planet,’” Journal of Library Metadata 16, nos.3/4(2016): 202–227, doi:10.1080/
19386389.2016.1258910.
27. Library of Congress, “BIBFRAME 2.0 RDF Conventions,” https://www.loc.gov/bibframe/
docs/bibframe2-rdf-conventions.html (accessed August 17, 2017).
28. Library of Congress, “BIBFRAME 2.0 URIs and Guidelines,” https://www.loc.gov/bib
frame/docs/bibframe2-guidelines.html (accessed August 17, 2017).
29. LC MARC2BIBFRAME2 Converter Github, “marc2bibframe2,” https://github.com/lcnet
dev/marc2bibframe2 (accessed August 17, 2017).
30. Library of Congress, “MARC 21 to BIBFRAME 2.0 Conversion Specifications,” https://
www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
31. Ibid.
32. Ibid.
33. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 001–005, 007
– Control, physical description – R1 (Excel, 36 KB, 06/07/2017),” in MARC21 to BIB-
FRAME 2.0 Conversion Specifications, https://www.loc.gov/bibframe/mtbf/ (accessed Sep-
tember 9, 2017).
26 A. XU ET AL.
34. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 648–662 –

Subjects – R1 (Excel, 14KB, 06/01/2017),” in MARC21 to BIBFRAME 2.0 Conversion Speci-
fications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
35. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 1XX, 6XX,
7XX, 8XX, X00, X10, X11 – Names – R0 (Excel 12KB, 03/07/2017),” in MARC 21 to BIB-
FRAME 2.0 Conversion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed Sep-
tember 9, 2017).
36. Library of Congress, “MARC Bibliographic Conversion Specifications: Process Notes – R2 -
0.3.1 RDF for Names (Word, 28KB, 07/27/2017),” in MARC 21 to BIBFRAME 2.0 Conver-
sion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
37. Library of Congress, “Usage Notes,” in MARC21 to BIBFRAME 2.0 Conversion Specifica-
tions,, http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
38. Ibid.
39. Ray Denenberg, “Relation 1:1 work/instance in BIBFRAME 2.0?” Listserv Bibliographic
Framework Transition Initiative Forum (April 13, 2017), https://listserv.loc.gov/cgi-bin/
wa?A2Dind1704&LDBIBFRAME&PD23793.
40. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 240, X30, etc.
- Uniform Titles –R1 (Excel, 12 KB, 06/09/2017),” in LC MARC 21 to BIBFRAME 2.0 Con-
version Specifications, , http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
41. Library of Congress, “MARC Bibliographic Conversion Specifications: Process Notes – R2-
0.3.2 RDF for Titles (Word, 28 KB, 07/27/2017),” in MARC21 to BIBFRAME 2.0 Conver-
sion Specifications, , http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
42. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 200-24X,
except 240 - Titles –R1 (Excel, 12 KB, 06/09/2017),” in MARC21 to BIBFRAME 2.0 Conver-
sion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
43. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 76X-78X -
Linking Entries -R0 (Excel, 14 KB, 03/07/2017),” in MARC21 to BIBFRAME 2.0 Conversion
Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9, 2017).
0.3.3 RDF for Relationships (Word, 28 KB, 07/27/2017),” in MARC21 to BIBFRAME 2.0
Conversion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9,
2017).
45. Sally McCallum, “BIBFRAME and Linked Data for Libraries,” in Linked Data for Cultural Heri-
tage, eds. Ed Jones and Michele Seikel (Chicago: American Library Association, 2016), 105–123.
46. Ibid.
47. Library of Congress, “Overview of the BIBFRAME 2.0 Model, April 21, 2016,” 2017, http://
www.loc.gov/bibframe/docs/bibframe2-model.html (accessed September 9).
48. Ibid.
49. WebVOWL: Web-based Visualization of Ontologies, http://vowl.visualdataweb.org/web
vowl.html (accessed August 17, 2017).
51. YAZ - programmer’s toolkit supporting the development of Z39.50/SRW/SRU clients and
servers, http://www.indexdata.com/yaz (accessed August 16, 2017).
52. See LC marc2bibframe2.xml, https://github.com/lcnetdev/marc2bibframe2/blob/master/
metaproxy/filters-available/marc2bibframe2.xml (accessed August 16, 2017).
53. Metaproxy - a proxy for front end server that presents a single Z39.50/SRW/SRU front end
to multiple back end database servers, http://www.indexdata.com/metaproxy (accessed
August 17, 2017).
54. LC Marc2bibframe2 converter, https://github.com/lcnetdev/marc2bibframe2/tree/master/

xsl (accessed September 9, 2017).
55. W3C RDF Validation Service, https://www.w3.org/RDF/Validator/ (accessed August 17,
2017).
56. W3C RDF 1.1 Concepts and Abstract Syntax, “A literal in an RDF graph consists of two or
three elements: a lexical form, being a Unicode [UNICODE] string, which should be in
Normal Form C [NFC],” https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
(accessed September 9, 2017).
57. Jeff Yong, “How was the 2-letter language code derived in the statements with which it
appears?” e-mail message to author, May 30, 2017.
59. LD4P Project for Music, https://wiki.duraspace.org/display/LD4P/PerformedCMusicC
Ontology (accessed September 9, 2017).
60. LD4P Project for Cartography, https://wiki.duraspace.org/display/LD4P/HarvardC
CartographicCMaterials (accessed September 9, 2017).

61. Library of Congress, “MARC Bibliographic Conversion Specifications: Fields 841-887-
Holdings, Location, Alternate Graphics, etc. – R1 (Excel, 14 KB, 06/01/2017),” in MARC21
to BIBFRAME 2.0 Conversion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed
September 9, 2017).
62. Ibid.
Process 6 Series Processing (Word, 28 KB, 07/27/2017),” in MARC21 to BIBFRAME 2.0
Conversion Specifications, http://www.loc.gov/bibframe/mtbf/ (accessed September 9,
2017).
64. W3C RDF 1.1 Primer, W3C Working Group Note 24 June 2014, “A resource without a
global identifier can be represented in RDF by a blank node. The blank nodes are like sim-
ple variables in algebra. They represent something without say what their value is. Blank
nodes can appear in the subject and object position of a triple. They can be used to denote
resources without explicitly naming them with an IRI,” https://www.w3.org/TR/rdf11-
primer/ (accessed September 9, 2017).
65. The Library of Congress, “BIBFRAME 2.0 RDF conventions,” https://www.loc.gov/bib
frame/docs/pdf/bf2-conventions-march2017.pdf (accessed August 17, 2017).
66. Named Graphs: web page, hosted by the World Wide Web Consortium, maintained by
Jeremy Carroll, and updated 2008-01-17, https://www.w3.org/2004/03/trix/ (accessed May
31, 2017).
67. RDF Primer, W3C Recommendation 10 February 2004, Section 4.3 RDF Reification,
https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#reification (accessed May 30,
2017). This document contains a link to “RDF 1.1 Primer: W3C Working Group Note 24
June 2014” which has not become a W3C Recommendation but which addresses named
graphs and their syntax in several sections.

From MARC To Bibframe

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

From MARC To Bibframe

Uploaded by

Copyright:

Available Formats

Cataloging & Classification Quarterly

ISSN: 0163-9374 (Print) 1544-4554 (Online) Journal homepage: http://www.tandfonline.com/loi/wccq20

From MARC to BIBFRAME 2.0: Crosswalks

Amanda Xu, Kirk Hess & Laura Akerman

To link to this article: http://dx.doi.org/10.1080/01639374.2017.1388326

Published online: 13 Nov 2017.

Submit your article to this journal

View related articles

View Crossmark data

Full Terms & Conditions of access and use can be found at

Download by: [DUT Library] Date: 14 November 2017, At: 18:23

From MARC to BIBFRAME 2.0: Crosswalks

ABSTRACT ARTICLE HISTORY

replacement for the library community’s current model/format, MARC. It is the

renders MARC bibliographic information in a coherent and usable way.

way” to propose changes, extensions, or even alternative models to BIBFRAME

Semantic mapping methodology

Element to element mapping

MS Excel spreadsheets and accompanied by processing instructions in Word as

Figure 1. LC MARC21 to BIBFRAME 2.0 conversion speciﬁcations.

Hierarchy, object, and logical view resolution

Figure 10. Overview of the BIBFRAME 2.0 model.

Figure 11. WebVOWL visualized BIBFRAME RDF.

Figure 12. WebVOWL visualized LC extension RDF for bf:Agent ontology.

Figure 13. LC MARC2BIBFRAME2 converter.

The Crosswalk Project team initially enhanced 1000 MARCXML records by

Conversion tools and process

Improvements from BIBFRAME 1.0 to 2.0 conversion

language part issue initially reported by Osma Suominen.58 Language information

Include more human readable labels? Files converted using LC MARC2BIB-

As we reviewed the mapping documentation, we noted that in BIBFRAME 2.0

Figure 14. LC conversion speciﬁcations “ConSpec-841-887-R1p” (Excel, 14 KB, 06/01/2017)61.

 034 Coded Cartographic Mathematical Data – many subﬁelds are not

Figure 15. LC conversion speciﬁcations “ConvSpec-841-887-R1p” (Excel, 14KB, 06/01/2017)62

solutions for better ways to do it in Linked Data than in MARC in their

AdminMetadata relationship: The relationship of the AdminMetadata section

leaders to develop processes for sharing.

 University of Iowa Libraries, particularly Paul Soderdahl, the Associate Uni-

34. Library of Congress, “MARC Bibliographic Conversion Speciﬁcations: Fields 648–662 –

54. LC Marc2bibframe2 converter, https://github.com/lcnetdev/marc2bibframe2/tree/master/

CartographicCMaterials (accessed September 9, 2017).

You might also like

034 Coded Cartographic Mathematical Data – many subﬁelds are not

University of Iowa Libraries, particularly Paul Soderdahl, the Associate Uni-