MODS and RDF Call 2015-10-19

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:  saverkamp (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20151019)

Attendees:

Agenda:

  1. Conversion code update
    1. Steven still working on conversion code, will hopefully have it up before the end of the week. 
    2. Will be publicly accessible on Fedora 4 instance, courtesy of Northwestern.
       
  2. MODS Name Collaboration Document
    1. Question about linking statements related to one person. Is this important? 
      1. An example is if a person has two name records due to two different affiliations... should one name have something similar to a "owl:sameAs" to the other name record?
      2. Christina H. volunteered to explore a VIVO approach to linking names with affiliations.
    2. As no objections raised to this document, Steven will add this to the fedora 4 conversion code so we can see what this model looks like.
    3. Question about using authorities from different sources, repeating authorities. Essentially can we skos:exactMatch more than once?
      1. Answer: yes
        1. LC already does this
           
  3. MODS Type of Resource
    1. Emory: uses mods typeOfResource with MODS value terms, moving to using dcterms:type with LC resource types.
      1. historically, have used MODS type as analogous to Fedora content models, but may not carry this forward into Hydra and Fedora 4.
      2. Question about using mods:genre to refine mods:typeOfResource?
        1. A note that they have a concern over using dcterms:type more than once.
        2. UTK also uses mods:genre to refine mods:form, has similar question "interesting constellation to untangle".
        3. genre/form is sticky and institutions use them differently, different value vocabs. Christina would like to see this group sort out discrepancies of use.
      3. Question: is anyone already using LC Resource Types?
        1. BPL is not currently as these we made available after their current Application Profile was created. 
        2. Comment that these terms are derived from MARC
    2. Amherst: Same as Emory, but added example using dcmitype terms. Uses manuscript attribute. 
      1. They use mods:genre for further refinement in their system.
      2. Question: preference for mapping?
        1. No, hadn't decided yet, but LC resource type sounds fine.
      3. Comment that assigning an object type of resource as both manuscript and text might be redundant since manuscript is just a more specific type of text.
    3.  BPL: Simlar to others. Uses /man for manuscript. Doesn't use typeOfResource in application, uses genre for faceting.
    4. Indiana: Similar to others. Uses type for faceting in system, so there are some dependencies. Does not use manuscript attribute, but does use genre to refine. Also has concern about using dcterms:type for genre as well. Tried MODSRDF transformation, but the LC resource type vocab may be new enough that it's not included in the transform.
      1. Steven suggests talking about LC genre form terms when we talk about the genre top level element or subject.
    5. NYPL: Similar to others, uses type for faceting in system. 
      1. Would not try to map manuscript attribute however. Notable as they have items with the attribute set but as it wasn't reliably used, want to drop it.

    6. Collaborative mapping:
      1.  Question: do we need simple and complex versions? 
        1. Most support one mapping--dcterms:type with LC Resource types vocabulary. 
        2. No opposition, but some hesitance to move to it until others commit to using it.
        3. Decided to use one mapping as suggested by most participants.
      2. Need agreement on term mappings from existing type of resource terms to the new Library of Congress resource types.
        1. Question about if everyone is using MODS terms currently. 
          1. All present are using MODS terms.
        2. Suggestion to use a single document and allow comments. Amherst will send their doc to Danni and BPL will post to group.
        3. Steven will try to include typeOfResource conversion in Fedora 4 sandbox, time permitting.
           
  4. Next Top-Level Element
    1. Agreed to discuss genre at next meeting. 
      1. Homework: post institution mappings for genre to wiki before next meeting.

  5. Other Business
    1. Question about workaround for affiliation. Has anyone found one. 
      1. A: in shared document, uses schema, but issues with multiple affiliations. Open to more feedback on how to represent, especially from those with strong use cases. 
        1. Emory only ever has one affiliation with their name record so support for multiple affiliations isn't really needed by anyone.
    2. Christina has draft document for v2 of MODSRDF, waiting for permission to share with group, hopefully within the next month or by end of year. 

  6. Action items:
    1. Genre documents
    2. Amherst and BPL will pull together typeOfResource mapping doc and share.
    3. Steven will finish conversion scripts and stand up Fedora 4 sandbox