MODS and RDF Call 2016-01-25

Time: 9am PDT / Noon EDT

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

Homework Reminder: 

• Individual Mappings of physicalDescription element:  PhysicalDescription Individual Institution Usage And RDF Conversion

Moderator: Steven Anderson (Boston Public Library)

Primary Notetaker:  Eben English (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20160125)

Attendees:

• sanderson (BPL)
• Eben English (BPL)
  
• jen young (Northwestern)
• Steve DiDomenico (Northwestern)
  
• Danny Pucci (BPL)
  
• ksgerrity (Amherst College)
• soriordan (Emory University)
  
• saverkamp (NYPL)
• Sara Rubinow (NYPL)
• Robert Cole (U. of Alberta)
• sonoe (UNC-CH)
• Melanie Wacker (Columbia / MODS EC)
  
• Eric O'Hanlon (Columbia)
  

Agenda:

1. Introductions
   
   
2. Conversion Code Update
   Not much to report, still in progress. Contributions welcome.
   
   
3. MODS OriginInfo Collaboration Document
   1. Remaining questions of:
      1. Importance of "Domain" in RDF definition for use of a linked data term. Essentially the following:
         1. bibframe:edition -- the domain is "bf:Instance",
            http://bibframe.org/vocab-list/#edition
            Used in: https://docs.google.com/spreadsheets/d/1UvtP_0JcHHvT7bpsvqgXJxEe40XeI6IsEoNJPGveU_0/edit?usp=sharing
            
            bibframe:providerRole -- domain is "bf:Provider"
            http://bibframe.org/vocab-list/#providerRole
            Used in: https://docs.google.com/spreadsheets/d/1hQjkd1NUn65aagRn-4HevCGYqU77kuGglMPcAGmwIqs/edit#gid=0
            
            Discussion of whether or not we need to pay attention to domain restrictions in vocabularies. Steven reported that this does not seem to be a big concern in Applied Linked Data group. Consensus seems to be that while most top-level objects will be PCDM:objects, as long as bf:Instance doesn't explicitly require certain properties to be present, our top-level objects wouldn't be invalid as bf:Instance objects, and therefore predicates with a domain of bf:Instance could be used. bf:Instance is a broad enough concept to cover all types of digital cultural resources.
            
            
         2. frequency -- in DC this is a class, not a property
            http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-Frequency
            Used in: https://docs.google.com/spreadsheets/d/1UvtP_0JcHHvT7bpsvqgXJxEe40XeI6IsEoNJPGveU_0/edit?usp=sharing
            
            Sonoe will investigate this issue further and report back to the group. We should also looks at the mods2bibframe conversion project for ideas. Some possible alternatives:
            1. dbpedia-owl:frequencyOfPublication (in BPL mapping: https://docs.google.com/spreadsheets/d/1hQjkd1NUn65aagRn-4HevCGYqU77kuGglMPcAGmwIqs/edit#gid=0)
            2. RDA:frequency (deprecated? http://metadataregistry.org/schemaprop/show/id/158.html)
            3. bf:frequency (http://bibframe.org/vocab-list/#frequency)
4. MODS Language Collaboration Document (https://docs.google.com/spreadsheets/d/1WeZY47GpJ2fPMa0SL5L2VlIqfqkTX2oe6njbT9dXxXA/edit?usp=sharing)
   Folks seem good with this and we can consider it "done" and add to the conversion code.
   
   
5. PhysicalDescription Individual Institution Usage And RDF Conversion
   
   1. Institution mappings
      
      1. UNC
         1. only has use case for mods:extent (some limited use of mods:form currently, but willing to drop support for this)
         2. suggest using bf:duration for mods:extent
         3. use of mods v1 predicates – are these URIs actively maintained?
      2. Amherst
         1. use cases for mods:extent, mods:internetMediaType, mods:note (physicalDescription-specific)
         2. suggest use of dcterms:extent, dcterms:format, and bf:note
         3. willing to drop support for mods:digitalOrigin
      3. BPL
         1. use cases for mods:extent, mods:internetMediaType, mods:digitalOrigin, and mods:note (physicalDescription-specific)
         2. suggest use of bf:extent, DCE:format, opaque:digitalOrigin, and opaque:note
      4. NYPL
      5. 1. use cases for mods:form, mods:extent, mods:note
         2. suggest use of dcterms:format, dcterms:extent, and skos:note
         3. interested in keeping mods:form values separate from previously established mods:genre mapping (edm:hasType)
      6. Emory
      7. 1. still working on mapping, have a lot of different technical and descriptive data, not sure what will be included
   2. Elements not needed
   3. 1. mods:reformattingQuality
   4. Use of dcterms:extent
      1. According to specs, this does not accept a literal as its range
      2. But, everyone is using it this way anyway (Europeana, DPLA)
      3. Steven will reach out to Dublin Core committee/body and see what the deal is with this – if no one uses it in the expected way, shouldn't it change?
   5. Note types
      1. Many institutions have use cases for distinguishing different note types.
      2. NYPL uses a single note element, but prepends a value indicating note type to actual value
      3. Could mint a note object related to main object via opaque:note
         1. Would have type and value properties
      4. BIBFRAME may have support for multiple note types in 2.0 version (https://www.loc.gov/bibframe/docs/pdf/bf2-draftspecidsnotes-10-29-2015.pdf)
   6. physicalDescription in MODS RDF
      1. See links: https://www.loc.gov/standards/mods/modsrdf/primer-2.html#physicalDescription; https://www.loc.gov/standards/mods/modsrdf/primer.html#physicalDescription (further explanation)
         
6. Assignments for next time:
7. 1. Review physicalDescription mappings and continue discussion at next meeting
   2. mods:abstract mappings (should be fairly easy)
8. Next meeting: Monday February 8th, 12:00 PM EST