MODS and RDF Call 2015-09-21

Owned by Bill Branan
Jun 16, 2017

Time: 9am PDT / Noon EDT

Call-In Info: 712-775-7035 (Access Code: 960009)

Homework Reminder: 

Moderator: Steven Anderson (Boston Public Library)

Primary Notetaker:  Kelcy Shepherd (etherpad link: http://etherpad.wikimedia.org/p/RDF-MODS-20150921)

Attendees:

Notes:

  1. MODS Title Collaboration Document (https://docs.google.com/spreadsheets/d/1cEfOtXJWPib8rjuYa7J48JvtKDVuOEQ9RVHD1iceAJI/edit#gid=0)
    1. Simple:
      1. All titles map to DC:title or DC:alternative (exception for uniform titles)
        1. The usage="primary" maps to DC:title as a string literal.
        2. All other titles map to DC:alternative as a string literal.
      2. Uniform titles map to a DCE:title that points to the uri and also has a DC:title string literal value.
      3. No objections to this mapping.
         
    2. Complex:
      1. Each non-uniform title gets a custom minted URI (a "title" object is stored in Fedora 4).
        1. Consists of a skos:prefLabel that is the full title to display (nonSort, title, subtitle, partNumber, partName all concatenated together).
        2. Consists of a titleForSort that is the full title minus what one doesn't want to sort on.
        3. Consists of an supplied element that indicates if this title is supplied.
      2. These minted URI's are linked to via the properites "DCE:title", "opaque:alternativeTitle", and "opaque:tanslatedTitle".
      3. One uses skosxl:prefLabel to select the title that is the "best" to use if one can only show one DCE:title element.
      4. Uniform titles work the same as in the simple model.
         
    3. Is it ok to use this as a rough alpha draft?
      1. No objections were raised.
         
    4. Steven will work on getting some test coding working against Fedora 4 to see how this works in that system.
       
  2. MODS Name Element (links from:  MODS Name Individual Institution Usage And RDF Conversion)
    1. Boston Public Library:
      1. Based on UCSB. If name is from an authority, use the marc relator as a predicate of your RDF triple.
        1. If the name is from an external authority, use the URI from that authority as the object of your triple.
        2. If the name is a local name, then mint a local URI for the name as the object of your triple.
          1. Local names represented using foaf:name, schema:birthDate, schema:deathDate, rdf:type, etc.
          2. If birth and/or death date is not parseable as just a straight numerical year date, then concat to the foaf:name and don't use the birthDate and deathDate properties.
        3. Willing to give up the seperation of birth and death dates.
        4. Willing to give up support for affiliation.

    2. Indiana University:
      1. Group reviewed since no one from Indiana on the call. Using dcterms:creator to point to a label or URI in the Library of Congress.

    3. University of Maryland:
      1. Used UCSD as a model for their work.
      2. Liked that the Library of Congress had the foresight to make the marc relators subproperties of dcterms:creator or dcterms:contributor.
      3. Don't have a widespread use of roles so usually mapped to dcterms and used marcrel otherwise.
      4. Did invesitigate schema:role and schema:name but didn't like how that would work in Fedora with Blank Nodes.
      5. Steven: Like that they used dcterms and marcrel at the same time, since dcterms may be more supported, but how would that work? 
        1. Bria clarified this reflects their data now, but may in the future use just all marcrel and opposed to both. 
          1. Will talk with their developers to see if that's an issue. 
             
    4. Emory:
      1. Needs some interpretation so will ask about it during the next call.

    5. Amherst College:
      1.  Provided some examples, but punting on RDF mapping. <roleTerm> is something we use heavily and would want to retain, both for existing use cases and for potential for things like social networking for correspondents in the future. Only use affiliation with our IR and don't feel strongly about ability to retain it. We don't have a use case for granular names, and are probably okay with concatenating names. 

    6. New York Public Library:
      1. Following DPLA's lead in using edm:Agent, but also minting a local URI for every single name.
        1. Storing the string they will use to display as skos:prefLabel.
        2. If the name belongs to an external authority, using skos:exactMatch in that local minted resolution to indicate that external authority.
      2. Provided three possible mapping options to use as the predicate to their local minted name.
        1. Not sure if marcrel vocab is a good fit for role predicates.
        2. One potential issue is if we need to worry about a primary creator.
      3. Their final example is what all locally minted names would look like. They will mint all names because they'll need to cache all strings locally anyway, they may want to override authority files with their own represenation, and they have use cases outside of digital library (a curator who's been developing a local authority file of photographers, for example). 

  3. General Discussion:
    1. Will there be different simple and complex mappings? 
      1. Maybe a three tier system: creator/contributor; using marcrel terms if they have them; locally mint some or all names? 
        1. No one said they were just using creator/contributor, so should simple model just be marcrel terms with local things not captured as URIs and complex include minting own URIs. 
        2. Decided on sticking with just one simple and one complex. 
           
    2. Need some more research/discussion, investigation into how this will play out in Fedora before continuing discussion.
       
    3. Question about whether anyone is handling portrayal as well as role? An extra level of complexity that WGBH is wrestling with. At BPL may address that as a subject instead of trying to connect it with a person.
       
    4. Steve at Northwestern wondered if we could come up with some sample records and put them in Fedora 4? BPL may be able to set up shared test Fedora 4 instance for people to  work with. Either have a set of records that we're all working with that look identical, or right some software that can do a transformation from MODS into RDF to have some data to work with. Could write something to take MODS XML and transform it into RDF according to proposed MODS/RDF mapping. 

  4.  Action Items:
    1. All go through mappings that have been proposed for names and consider various options.
    2.  Think about issue of ordering of elements. 
    3. Steven will work with our proposal for title mapping to see how it works in Fedora/Hydra.