Agenda:

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.

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
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
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
Other Collaboration Document discussion
1. No comments at this time
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.
Next meeting: Monday October 31st at 9:00 AM PST / Noon EST
1. Homework: modeling collections, series, subseries, and institution properties

Browser not supported