MODS and RDF Call 2016-10-17

Time: 9am PDT / Noon EDT

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

Homework Reminder: 

• Issue voting: https://goo.gl/forms/ROMklm8isWH3rKzK2

• part, extension, and recordInfo 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-20161017)

Attendees:

• sanderson (BPL)

• Eben English (BPL)

• Jennifer Liss (Indiana University)

• Melanie Wacker (Columbia)
  

• Eric O'Hanlon (Columbia)
  

• soriordan (Emory University)
  

• Emily Porter (Emory)
  

• Danny Pucci (BPL)

• Johanna Radding (Amherst College)

Agenda:

1. Conversion Code Update

• • Not much new work to report, there were some server/hosting issues that have caused delays. These have been resolved, and development should be starting again soon.
    

1. part, extension, and recordInfo mapping discussion

   1. Indiana
      1. recordInfo
         1. bibframe:descriptionLanguage for <mods:languageOfCataloging>, with iso639-2 language URI as object
      2. part
         1. schema:caption for <mods:part><mods:detail><mods:caption>
      3. extension
         1. Using for instrumentation of musical works
         2. rdae vocabulary (http://rdaregistry.info/Elements/e/)
   2. Columbia
      1. recordInfo
         1. Is this even necessary any more in Linked Data world?
         2. Language qualifiers can be used on specific triples to indicate language of cataloging
         3. Paper on associating provenance and annotations on the level of single statements: http://dcpapers.dublincore.org/pubs/article/viewFile/3669/1892
         4. Some discussion of continuing need for provenance and trustworthiness/authority for aggregated data contexts
      2. part
         1. Don't use this, would suggest bf:Part and bf:isPartOf as possibilities, where objects of triples are other RDF resources
            
      3. extension
         1. Only use at CUL is RIOXX to record grant funding information. Appears to be some work in the Hydra community on this: http://e2eoa.org/2016/04/04/open-access-technical-workshop-lancasters-experience/
   3. Emory
      1. Haven't done mappings yet, only gathered existing use cases in legacy data
      2. recordInfo
         1. Could be tracked using audit trails or using PREMIS events?
      3. part
         1. Some use for journal article pages, or "side" information on audio recordings
      4. extension
         1. Used for degree and discipline info on ETDs – will look at using VIVO properties to record this
      5. Will continue work and hopefully have mappings ready for next meeting
   4. BPL
      1. recordInfo
         1. edm:dataProvider for <mods:recordContentSource>, with minted institution/corporate name as object
         2. edm:provider possibly inserted into RDF returned from aggregate/SPARQL requests, with minted institution/corporate name as object
            
         3. modsrdf:recordOrigin for <mods:recordOrigin>, with literal as object
            
         4. bibframe:descriptionLanguage for <mods:languageOfCataloging>, with iso639-2 language URI as object
         5. bibframe:descriptionConventions for <mods:descriptionStandard>, with URI from http://id.loc.gov/vocabulary/descriptionConventions vocabulary as object
      2. No use of <part> or <extension>
   5. No further work on <extension>
      1. Use of this is too idiosyncratic to come up with any standardized generic mapping to RDF
   6. Steven will try and create collaboration document for <recordInfo> to be discussed/approved at next meeting
      
      
2. Initial remaining issues voting results
   1. Results: https://docs.google.com/spreadsheets/d/1myLYmUoOX5i1FKBjDat39ZR8cEZ644lATNj6juCQ5xA/edit?usp=sharing
   2. Only 2 institutions have voted so far – hold off on further discussion until we have more votes
   3. If you haven't voted, vote here: https://goo.gl/forms/ROMklm8isWH3rKzK2
      
3. Other Collaboration Document discussion
   1. No comments at this time
      
      
4. Hydra Connect 2016 report back
   1. Session was well-attended, lots if interest in our work and approach
   2. Announced that draft of conversion spec would be available by end of 2016
   3. Some concern expressed about complexity added by minting objects
      1. Adam Wead mentioned that Fedora4 is not well suited to handle this level of complexity, might be better to use Blazegraph or other triple store for metadata.
         
         

5. Next meeting: Monday October 31st at 9:00 AM PST / Noon EST

   1. Homework: modeling collections, series, subseries, and institution properties