Documentation: Create and populate a MARC Relators vocabulary

[dannylamb]

• Create a taxonomy vocabulary for MARC relators.
• Create a migration to populate the vocabulary
  
  
  
  • Create a custom source plugin to issue a GET request to http://id.loc.gov/vocabulary/relators.rdf. This document contains a list of links for individual terms. Term URLs can be extracted with the /rdf:RDF/madsrdf:MADSScheme/madsrdf:hasMADSSchemeMember xpath. You'll want to append the .rdf extension to the end of each URL to get the RDFXML version.
  
  
  • The migration will have to iterate this list of term URLs, issue a GET request for each, and then parse the resulting document into a taxonomy term in Drupal.
  
  

Here's an example document:

<rdf:RDF>
    <madsrdf:Authority rdf:about="http://id.loc.gov/vocabulary/relators/abr">
        <rdf:type rdf:resource="http://www.loc.gov/mads/rdf/v1#Topic"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
        <madsrdf:authoritativeLabel xml:lang="en">Abridger</madsrdf:authoritativeLabel>
        <rdfs:subPropertyOf rdf:resource="http://id.loc.gov/vocabulary/relators/role"/>
        <madsrdf:isMemberOfMADSCollection rdf:resource="http://id.loc.gov/vocabulary/relators/collection_RDA"/>
        <madsrdf:isMemberOfMADSCollection rdf:resource="http://id.loc.gov/vocabulary/relators/collection_RDAExpression"/>
        <madsrdf:isMemberOfMADSCollection rdf:resource="http://id.loc.gov/vocabulary/relators/collection_BIBFRAMEWork"/>
        <madsrdf:isMemberOfMADSCollection rdf:resource="http://id.loc.gov/vocabulary/relators/collection_RDAContributor"/>
        <madsrdf:see rdf:resource="http://id.loc.gov/vocabulary/relators/aut"/>
        <rdfs:subPropertyOf rdf:resource="http://id.loc.gov/vocabulary/relators/role"/>
        <owl:sameAs rdf:resource="info:lc/vocabulary/relators/abr"/>
        <madsrdf:code>abr</madsrdf:code>
        <madsrdf:isMemberOfMADSScheme rdf:resource="http://id.loc.gov/vocabulary/relators"/>
        <madsrdf:definitionNote>A person, family, or organization contributing to a resource by shortening or condensing the original work but leaving the nature and content of the original work substantially unchanged. For substantial modifications that result in the creation of a new work, see author</madsrdf:definitionNote>
        <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
        <skos:prefLabel xml:lang="en">Abridger</skos:prefLabel>
        <rdfs:seeAlso rdf:resource="http://id.loc.gov/vocabulary/relators/aut"/>
        <skos:definition>A person, family, or organization contributing to a resource by shortening or condensing the original work but leaving the nature and content of the original work substantially unchanged. For substantial modifications that result in the creation of a new work, see author</skos:definition>
        <skos:notation>abr</skos:notation>
        <skos:inScheme rdf:resource="http://id.loc.gov/vocabulary/relators"/>
    </madsrdf:Authority>
</rdf:RDF>

In the least we'll want the code, preflabel, and description. If there's more you want in there, go ahead and add it. Be sure to make an RDF mapping for the vocabulary, too.

[ajs6f]

There is a MARC relators download at the usual page which would seem a bit crisper.

[seth-shaw-unlv]

How often does the MARC relators list change? Is this really something that needs to be dynamically loaded, or can we just hardcode a config (or migration import)?

Also, since relators describe a relationship between an agent and a resource, does it work to make it a taxonomy (since taxonomies can't be applied to a particular field, be it either a text field or an entity relationship)? It seems to me that we need a compound field that includes a value for the Agent being linked and another for the relationship.

[seth-shaw-unlv]

Something like this or this.

[rtilla1]

From Sprint Kick-off Meeting: These may now be included into the complex fields described by #889 , but we will also need some code that will scrape or request the URIs from a taxonomy, and then scrape all of the XML associated with each of those URIs.

We won't make this dynamic, because we don't expect the list to change more often than about once a year, so we are just going to scrape it into a text file, store internally, and then use it to populate a drop-down.

We can tell that some of the terms are going to be "deprecated" in a cataloger sense and replaced with new terms. We will just add a note that says deprecated to the terms, but as long as the list is available, it will be included in updates in Islandora.

[seth-shaw-unlv]

Oh, hey, here is a pipe delimited URI, authoritativeName list of the MARC relators.
marc_relators.txt

[seth-shaw-unlv]

Oop, and now with the three-character code in parens.
marc_relators.txt

[seth-shaw-unlv]

And now with deprecated terms! (There were three based on the LOC relators list.)
marc_relators.txt

[dannylamb]

Awesome @seth-shaw-unlv. Ok, let's figure out the best way to get your fields into the codebase and wire these up.

[seth-shaw-unlv]

Once we have the TypedRelator field coded then I can create an instance and paste it in the field config. I can then export the field definition and we can stick that in config/install. Won't be hard.