Authority Control: MODS & MADS

I’ve been working on implementing authority control in our metadata editor for the past few weeks. I’ll spare you the painful details and just outline the process and direct you to a mostly working example of the MODS editor with name and subject suggest (the subjects suggest is still a bit buggy) functions.

I decided to use MADS for authority control. I choose MADS largely because since it was created with MODS in mind integration with our MODS records would be pretty easy. For example a MADS record for a name authority looks like this:

<mads xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mads="http://www.loc.gov/mods/v3"
      xmlns="http://www.loc.gov/mods/v3" xsi:schemaLocation="http://www.loc.gov/mads
     http://www.loc.gov/standards/mads/mads.xsd" version="beta">
     <authority>
      <name type="personal" authority="naf">
        <namePart>Burke, Thomas A</namePart>
        <namePart type="date">1898-1971</namePart>
      </name>
    </authority>
    <note type="source">America's town meeting of the air. Radio tributes to
     F.D.R, 1945: notes compiled by Recording Laboratory, Library of Congress
     (Mayor Thomas A. Burke, Cleveland)</note>
    <note type="source">Biographical directory of the United States Congress,
      1774-Present WWW home page, Feb. 28, 2001 (Burke, Thomas A, 1898-1971;
      Mayor of Cleveland, Ohio, 1945-1953, U.S. Senator from Ohio, 1953-1954)</note>
    <recordInfo>
      <identifier>n 2001064491</identifier>
      <recordContentSource authority="marcorg">DLC</recordContentSource>
      <recordCreationDate encoding="marc">010228</recordCreationDate>
      <recordChangeDate encoding="iso8601">20071029093022.0</recordChangeDate>
      <recordIdentifier source="OCoLC">oca05428503 </recordIdentifier>
      <languageOfCataloging>
        <languageTerm authority="iso639-2b" type="code">eng</languageTerm>
      </languageOfCataloging>
     </recordInfo>
</mads>

This makes inserting a name element into a MODS record pretty straight forward, I can simply select the child of the authority element and insert/copy it into my metadata record.

Step one in tying the MADS records to the MODS editor was to get all of the subject headings we currently use into MADS. We use OCLC to get our subject headings for voyager, and OCLC has a web interface that allows you (paying members that is) to search and download authority records. This is how I downloaded the first set for testing. It would be great to have an OAI (or even RSS) type service tied to the authority records so I could keep track of updates. (Or perhaps this exists already and I don’t know about it?)

OCLC provides several format options for downloading records including DCRDF, DCHTML and MARC. After some trial and error the easiest solution turned out to be downloading MARC records and then batch transforming them using MarcEdit. MarcEdit has a conversion directly from MARC to MADS, and the results look great. These new MADS records get uploaded into eXist, and are then available to the subject suggest function you see in the MODS form.

The next step after getting a set of authority records to experiment with was to get my subject suggest to insert/copy a whole node into the main instance. In the first iteration of the subject suggest (seen here), I was inserting a value not a nodeset. For the new suggest function to work I couldn’t see anyway around using xforms:copy, which I have found to be a little tricky in the past. To avoid the issues I ran into when using xforms:copy to insert directly into the main instance, I created a separate instance to hold the selections as the user makes them. These selections are then inserted into the the main instance via an xforms:insert.

Here is what it looks like for the name suggest function (seen on the first tab of the form):

<xforms:instance id="requestName">
  <query xmlns="">
    <term/>
  </query>
</xforms:instance>

<xforms:instance id="response">
   <temp xmlns=""/>
</xforms:instance>

<xforms:instance id="names">
   <dummy xmlns="">
     <nameSuggest/>
   </dummy>
</xforms:instance>

There are three instances, the requestName instance holds the search terms as you type them in and sends the request to an xquery that looks up names (this function uses contains() rather than starts-with so it searches more broadly). The response instance holds the response from the search query. The xform uses a xforms:select so that users can select multiple names, as each name is selected it is added (using xforms:copy) to the names instance, once they have selected the names they want they can click the “add names” button. This button inserts all of the selected names into the main instance via xforms:insert.

Here is the code in the body of the form:

<xforms:input ref="instance('requestName')/term" incremental="true">
   <xforms:label>Find Names:</xforms:label>
     <xforms:action ev:event="xforms-value-changed">
       <xforms:send submission="get-name"/>
     </xforms:action>
</xforms:input>

<xforms:trigger class="add">
  <xforms:label>Add Selected</xforms:label>
    <xforms:action ev:event="DOMActivate">
      <xforms:insert ev:event="DOMActivate" context="instance('metadata')"
        nodeset="instance('metadata')/mods:name[last()]" at="index('name')"
        position="after"  origin="instance('names')/child::*/child::*"/>
    </xforms:action>
</xforms:trigger>

<xforms:select ref="instance('names')/child::*" appearance="full">
   <xforms:label/>
     <xforms:itemset nodeset="instance('response')/child::*">
       <xforms:label style="display: block;" ref="child::*/child::*"/>
       <xforms:copy ref="child::*"/>
     </xforms:itemset>
</xforms:select>

Once the new names have been added you can then go in and add the appropriate roles to each. This works nicely for looking up names (try looking up adams, for example), it is a little bit buggy for looking up subjects. Part of the difficulty I’m having with subjects is that a subject has much more variation than names in how far down the values I want to use for my select label are nested, and also, the configuration of the child nodes.

Here are two examples:

<subject  xmlns="http://www.loc.gov/mods/v3">
  <topic authority="lcsh">Bonds</topic>
  <topic>Law and legislation</topic>
</subject>

<subject xmlns="http://www.loc.gov/mods/v3">
  <name type="personal" authority="naf">
    <namePart>Borah, William Edgar</namePart>
    <namePart type="date">1865-1940</namePart>
  </name>
</subject>

I’ve tried using descendant-or-self::* in the select/itemset/label but haven’t had any luck. Even if that did work, however, my labels would probably look like this: “BondsLaw and legislation,” rather than “Bonds — Law and legislation.” If I were generating the forms using xsl it would be a fairly easy fix, since I’m not one option could be create the labels in the xquery.

The final step to the form, once the kinks are worked out of the subject select would be to have a way of adding new authority records and a form for creating local authorities.