Next meeting: Paths to a Linked Data Catalog

Join the next Metadata Discussion Group meeting, where we’ll welcoming in the new academic year with a discussion about the many possible paths to implementing linked library data. Participants will consider homegrown and vended solutions and think about the implications of when and where to introduce linked data into library data stream.

DATE: Tuesday, September 20
TIME: 9-10 am
PLACE: Wells Library Room 043
TOPIC: Paths to a Linked Data Catalog
MODERATOR: Jennifer Liss

We hope to see you there!

Save the Dates: Fall 2016 meetings

The Metadata Discussion Group at Indiana University Libraries welcomes anyone from the IU community to attend our upcoming meetings.

Meetings will be from 9:00 am – 10:00 am in Room 043 of the Wells Library.

September 20
Paths to a Linked Data Catalog
Moderator: Jennifer Liss

November 29
Moderator: Julie Hardesty

Round Robin Updates – March 2016 meeting summary

The discussion on Moving from MODS to usable RDF, originally planned for March 8, will be rescheduled (date TBD). Stay tuned!

Since the time was blocked off on everyone’s calendars (and since we hadn’t met in a while), group members participated in a round robin. Below is a summary of the updates. Errors and misunderstandings on my part may be corrected in the comments below and I’ll do my best to update the post.


  • Andrea Morrison reported seeing more and more ORCiD identifiers in Library of Congress Name Authority File (NAF) records

Browse Functionality in Progress for IUCAT

  • Rachael Cohen reported on the progress to implement browse for IUCAT
    • Working from code developed by Cornell (they also use Blacklight for their discovery layer)
    • Development team will start with author browse, then tackle Kinsey subject headings, then Library of Congress Subject Headings (LCSH)
  • Spencer Anspach clarified how browse will work:
    • Authorized access points in bibliographical records will be hyperlinked
    • Browse results will display all access points (authorized and unauthorized) that appear in bibliographic records–all results will have a number next to it, denoting how many times that access point is used in the bibliographic records database; some access points will have an icon next to them, which will denote that the access point is the authorized version (NAF, etc.)
      • Clicking on the icon will take a user to the authority record for that authorized access point (MARC 670 fields will NOT display to users)
    • Clicking on any of the access points will conduct a search on that access point
  • Concerns: batch loaded records from vendors (we won’t mention names) do not have authority control; one vendor in particular never includes dates (MARC subfield d) in authorized access points–this will certainly have an adverse impact on browse!
  • Shelf ready materials often do not have authority control–those errors are picked up in post-cataloging, by the Database Management team

Use of BoundingBox Tool Adds Value to Map Records

  • Heiko Mühr reported a pilot (and subsequent adoption) of the BoundingBox Tool
    • The tool allows catalogers to find geographical coordinates for an area and outputs longitude and latitude data in a number of formats (including–but not limited to!–OCLC MARC)
    • After piloting use of the tool in the month of December, catalogers determined that use of the tool did not adversely impact cataloging productivity–the quality of records increased
    • Coordinate data is now required in bibliographic records for sheet maps

Government Publications Metadata Update

  • Andrea Morrison reported on her collaboration with the new GIMMS librarian
    • Working on finding ways to streamline acquisitions and cataloging workflows and provide better metadata services for federal documents

Media Digitization and Preservation Initiative

  • Ronda Sewald reported on progress made in the Media Digitization and Preservation Initiative (MDPI) project
    • Tens of thousands of media objects have been digitized to date
    • Digitization is ongoing
    • Currently sorting out ways to determine the rights for digital objects and how to create metadata (at such a huge scale) for discovery

Medical Subject Headings (MeSH) Deconstruction Update

  • James Castrataro reported that the deconstruction of MeSH headings seems to be complete
    • It was uncertain whether or not MeSH access points could by subdivided chronologically before the December 2015 decision to deconstruct
    • No one present was sure whether or not MeSH access points can be subdivided chronologically at present

Using the Catalog to Support Teaching

  • Bob Noel sought recommendations from the group for providing access to individual vendor streaming video titles (records were batch loaded at the item-level, rather than the collection-level)
    • Participants came up with a handful of possible strategies including, creating a LibGuide where all updates to links, etc., would be handled in one place
    • Interesting discussion about making access as easy as possible for the user (faculty, researchers, and students)

More about MODS (and XML)

At the Metadata Discussion Group meeting on March 8 April 5, 2016, we will talk about some of the challenges of mapping a descriptive metadata structure standard (in this case, MODS) from a XML-based expression to one that is RDF-based. This post will explain what MODS is and what it’s used for.

MODS: the ‘Who, What, and When’

The Metadata Object Description Schema (MODS) was published in 2002 by the Library of Congress’ Network Development and MARC Standards Office. The standard is maintained by an editorial committee comprised of library metadata practitioners from North America and Europe.

MODS is a “bibliographic element set” that may be used to describe information resources. MODS consists of 108 elements and subelements (there are 20 top-level or “parent” elements). At this point, I’ll urge you to go read the brief overview of MODS on the Library of Congress’ Standards website.

Go ahead. I’ll wait.

You read that bit about MODS being more or less based on MARC21, right? In the example below, I’ve described a sheet map using MODS elements and MARC tags.

DATA (formulated according to AACR2, if that sort of thing matters to you) MODS ELEMENT MARC TAG (and mapped MARC data value, when applicable)
Campbell County, Wyoming title 245 $a
Campbell County Chamber of Commerce (Wyo.) namePart 110 $a
cartographic typeOfResource Leader/06 “e”
Gillette, Wyo. place 260/264 $a
Campbell County Chamber of Commerce publisher 260/264 $b
[1982?] dateIssued 260/264 $c
1 map ; 33 x 15 cm extent 300

Table 1. Data expressed in MODS elements and MARC tags.

There’s a full mapping of MARC21 tags to MODS elements available, if you’re really curious. This example demonstrates that, although there are a few divergences, MARC21 was built to map almost directly into a MODS element.

MODS encodes descriptive metadata, or information about resources (title, creator, etc.). MODS and MARC21 are examples of data structure standards. Elements or tags are meant to serve as containers for data. Structure standards do not give any directions about how to formulate data—those directions come from data content standards (AACR2, RDA, DACS, etc.). The main purpose for structure standards (Dublin Core, EAD, and TEI are other examples of metadata structure standards) is to encode data so that it can be manipulated by machines. Elements separate discreet information for use in search and browse indices. Data structure standard elements often convey the meaning of the data. The MODS:title element only contains the word or words that are used to refer to a resource. MODS:title will never serve as a container for the resource’s size.

MODS: the ‘Where, Why, and How’

MODS was built “for library applications.” MODS has been chiefly implemented to support discovery of digital library collections. At IUB Libraries, MODS is the metadata standard of choice for the digital objects that are ingested into our digital collections repository, Fedora.

MODS elements are expressed in XML. XML is a metalanguage, which means that XML is an alphabet, of sorts, for expressing other languages. The figure below illustrates the XML syntax (the “alphabet”) by which XML expresses another language. A fake language with a bogus element named “greeting” is encoded in Figure 1.

An XML statement is shown. The syntax components--start and end tags, element name, attribute name, attribute value, and content value--are highlighted.
Figure 1. Anatomy of an XML statement. [click image to enlarge]
HTML (the language responsible for displaying this webpage to you right now), EAD, and TEI are also expressed using XML.

From the beginning, MODS was designed to be expressed as an XML schema. Schemata are the sets of rules for how languages work: which elements are valid and what their semantic meanings are, which elements nest within others, whether or not an element can be modified by attributes (e.g., the MODS:titleInfo might have an attribute called “type”), and whether there is a controlled list of values for a given attribute (e.g., the MODS:titleInfo “type” attribute is limited to the values “abbreviated, “translated,” “alternative,” “uniform”).

MODS records are created in a number of ways. You could open up an XML editor and start creating a MODS/XML record. If you want to really get to the know the MODS standard, that wouldn’t be a bad idea. However, if you wish to create metadata for a half a million photographs, editing raw XML won’t be terribly efficient. At IU, we have a few different methods for creating MODS records for digital objects. My favorite is the Image Collections Online cataloging tool. Use of the tool is restricted but I’ve included a screenshot below.

Screenshot of the Image Collection Online cataloging tool. The web form include fields for title, subjects, etc. A thumbnail of the digital object (an image) and an option for transforming the metadata to MODS are included.
Figure 2. Screenshot of the metadata interface for the Image Collection Online cataloging tool. [click image to enlarge]
Once a collection manager decides which metadata elements are desired and has consulted with the metadata specialist for digital collections (our own Julie Hardesty), those elements will display in a web form. Data may then be entered without needing to know XML or MODS. In Figure 1, you’ll see a box in the lower right-hand corner “Transform metadata to…” Clicking on that link that says “mods” allows me to download the data that I input into the web form as MOD/XML. You may view the full record for this photograph below.

That’s the 5 cent tour of MODS, as it’s expressed in XML. Questions? Leave a comment below!


Sample MODS Record

<?xml version="1.0" encoding="UTF-8"?>
<mods:mods xmlns:xsi=""
 <mods:title>James Whitcomb Riley and Lew Wallace</mods:title>
 <mods:name type="personal">
 <mods:namePart>Hohenberger, Frank M.</mods:namePart>
 <mods:roleTerm authority="marcrelator" type="text">Photographer</mods:roleTerm>
 <mods:roleTerm authority="marcrelator" type="code">pht</mods:roleTerm>
 <mods:typeOfResource>still image</mods:typeOfResource>
 <mods:genre authority="bgtchm">Photographs</mods:genre>
 <mods:genre authority="">Group portraits</mods:genre>
 <mods:digitalOrigin>reformatted digital</mods:digitalOrigin>
 <mods:note type="citation">Hohenberger mss., Lilly Library, Indiana University, Bloomington, Indiana.</mods:note>
 <mods:subject authority="local-hohenberger">
 <mods:subject authority="lctgm">
 <mods:subject authority="lctgm">
 <mods:subject authority="local-geo">
 <mods:geographic>Crawfordsville (Ind.)</mods:geographic>
 <mods:subject authority="">
 <mods:name type="personal">
 <mods:namePart>Riley, James Whitcomb, 1849-1916</mods:namePart>
 <mods:roleTerm type="code" authority="marcrelator">dpc</mods:roleTerm>
 <mods:roleTerm type="text" authority="marcrelator">Depicted</mods:roleTerm>
 <mods:subject authority="">
 <mods:name type="personal">
 <mods:namePart>Wallace, Lew, 1827-1905</mods:namePart>
 <mods:roleTerm type="code" authority="marcrelator">dpc</mods:roleTerm>
 <mods:roleTerm type="text" authority="marcrelator">Depicted</mods:roleTerm>
 <mods:relatedItem type="host">
 <mods:title>Frank M. Hohenberger Photograph Collection</mods:title>
 <mods:relatedItem type="series">
 <mods:identifier type="local">Hoh051.000.0001</mods:identifier>
 <mods:identifier type="local-callnumber">Wallace/Riley, Item 1</mods:identifier>
 <mods:physicalLocation>Lilly Library (Indiana University, Bloomington)</mods:physicalLocation>
 <mods:url access="preview"></mods:url>
 <mods:url access="raw object"></mods:url>
 <mods:url access="object in context" usage="primary display"></mods:url>
 <mods:accessCondition type="restriction on access">There are no restrictions on access.</mods:accessCondition>
 <mods:accessCondition type="use and reproduction">Copyright and reproduction rights for all Frank Hohenberger photographs are held and administered by the Lilly Library, Indiana University, Bloomington, In 47405. Additional permissions may be required prior to any reproduction of images of works by artists and photographers other than Frank M. Hohenberger that are retained in the Hohenberger Collection.</mods:accessCondition>
 <mods:recordOrigin>MODS record generated by transforming the photo cataloging metadata</mods:recordOrigin>
 <mods:languageTerm type="text">English</mods:languageTerm>
 <mods:languageTerm type="code" authority="iso639-2b">eng</mods:languageTerm>