As libraries continue to move into the linked data spaces, one of the areas that I believe will become more and more important, is the ability to resolve against local control vocabularies.   These local vocabularies could be local to one’s institution, or they could be local to another institution, or, they could be large national vocabularies that have yet to be defined in the master list of Source Terms maintained by the Library of Congress: Subject Heading and Term Source Codes.  Since MarcEdit’s linked data resolution has been developed around the concept of a rules file and collections, the tool requires that each collection have a unique “term code” specified, for automatic resolution.  In MARC, these codes reside in the $2 in subject fields, or can be defined explicitly when processing against any other field utilizing the <vocab> rules element in MarcEdit.  But recently, this situation has come up while doing work at The Ohio State University (OSU), and in thinking about how we develop local terms and namespaces to enable MarcEdit’s linked data reconciliation services, we have developed a process that I would like to share.

Background

The OSU Libraries has had a long history of experimenting with different metadata conventions within the catalog.  Our head of technical services, Magda El-Sherbini, quite literally, wrote the book on RDA, so it should come as no surprise that she would be interested in working on strategies for embedding linked data.  As part of this experimentation, the Libraries began to work with linked data services and National Libraries that were not yet defined in the Subject Terms Codes, making it difficult to utilize MarcEdit as the method for handling automatic URI linking.  So, we started to think about the problem.

In MarcEdit, collections and linked data resolution are handled through the creation of rules.  On the field side, rules are created to tell MarcEdit which subfields may be utilized when resolving a specific element.  Likewise, special processing notes can be added to tell MarcEdit if an item is a subject, personal name, or mixed content.  So, for example, let’s take the 650 field in MARC21 as an example.  The current rule would look something like this:

    <field type=”bibliographic”>
      <tag>650</tag>
      <subfields>abvxyz</subfields>
      <ind2 value=”0″ vocab=”lcsh”/>
      <ind2 value=”1″ vocab=”lcshac”/>
      <ind2 value=”2″ vocab=”mesh”/>
      <ind2 value=”7″ vocab=”none”/>
      <index>2</index>
      <uri>0</uri>
      <special_instructions>subject</special_instructions>
    </field>

The field rules establish the processing guidelines that MarcEdit will utilize when evaluating a particular field.  In this case, the field rules are limited to bibliographic records, limit subfield processing to the named elements in the subfields tag, and then notes that specific indicators are utilized to name specific vocabularies.  In the final case, the second indicator of 7 sets no processing rules, and the subfield 2 (defined in the index tag), will be utilized to tell MarcEdit which vocabulary was utilized for the term.  It’s these vocab values that are linked to the collection definitions.  Here is an example of a collection definition for the Japanese Diet Library:

    <collection>
      <name>Japanese Diet Library</name>
      <label>jlabsh/4</label>
      <uri>http://id.ndl.go.jp/auth/ndla?query=PREFIX+rdfs%3a+%3chttp%3a%2f%2fwww.w3.org%2f2000%2f01%2frdf-schema%23%3e+%0d%0aPREFIX+xl%3a+%3chttp%3a%2f%2fwww.w3.org%2f2008%2f05%2fskos-xl%23%3e%0d%0aSELECT+%3fsubj+WHERE+%7b+%0d%0a+%7b%3fsubj+rdfs%3alabel+%3fheading%7d+UNION%0d%0a+%7b%3fsubj+xl%3aaltLabel+%5b+xl%3aliteralForm+%3fheading%5d%7d%0d%0a+filter+(%3fheading+%3d+%22{search_terms}%22)%0d%0a+%7d&amp;output=json</uri>
      <path>results.bindings[0].subj.value</path>
    </collection>
    <collection>

In this case, the label tag is the tag that must match the values being utilized in the $2 in the record.  So, for example, this field would automatically initiate resolution against the Japanese Diet Library linked data endpoint:

=880  07$6650-05$a日本-歴史-昭和時代(1945年以後).$2jlabsh/4

While this would not:

=880  07$6650-05$a日本-歴史-昭和時代(1945年以後).

The difference between the two fields in the $2, which includes the label for the collection.  In order for MarcEdit to automatically discover the vocabulary being utilized, it must be named, and then defined within the rules file.

Defining Local Namespaces

So let’s go back to the issue at OSUL.  The Korean National Library has established an endpoint that can be utilized to resolve Korean subjects and names.  However, there is currently no entry in the official terms list.  This means that no value has been established for use with the $2.  Since this is an important value for use within MarcEdit, and it is likely that this value will be established in the Master Terms list in the future, we developed a local namespace for use in our system that could be utilized to create a unified label structure for local or undefined vocabularies.  In our case, we established the following local namespace: local/OSU.  Using this, I created the following rule in the MarcEdit rules file: local/OSU/kdl.  This allows us to create rules for vocabularies not yet established in the national registry, while still being able to utilize MarcEdit for URI resolution.  Using this process, I created (and this is in the current rules file distributed in the tool), the following definition for the Korean National Library endpoint:

    <collection>
      <name>The National Library of Korea</name>
      <label>local/OSU/kdl</label>
      <uri>http://lod.nl.go.kr/sparql?query=select+%3Furi+where+%7B+%3Furi+rdfs%3Alabel+%22{search_terms}%22+%7D%0D%0A&amp;type=json&amp;request_method=get</uri>
      <path>results.bindings[0].uri.value</path>
    </collection>
  </collections>

Now, as catalogers create localized subject headings for terms, we can automatically go back and generate URIs as the final step in the process.  So, for this record:

I can now run the build links tool, utilizing the new rules file, and automatically generate URIs for all elements in the record:

The process allows us to integrate local control vocabulary resolution into our current workflow process, and provides a unit label that can then be utilized to update the $2 with the official Term Code when it is established (and we are assuming that it will be).

However, beyond this example, I’ve become convinced (through our own local work), that as libraries move into the linked data spaces, local vocabularies will be as or more important than those provided by the large national organizations.  Mostly, because this is where the expertise lives.  LCSH for example, is great for general subjects — but localized vocabularies for specific domain areas exist elsewhere, and enrich and enhance the description of our records.  Today, these tend to be placed into local subject fields — but imagine a linked data world where these vocabularies could be made available, and placed along-side their national cousins.  It could be an exciting future…and for those walking down that path, this the way that MarcEdit can be utilized to support it.