Agenda:

Conversion Code Update
1. No major updates
2. Next update is still coming soon and may be updated to utilize cloud storage. Apologies for the delay on progress for this.
Collaboration Document List and review

MODS title (two tabs)
MODS name (two tabs)
MODS typeOfResource
MODS genre
MODS originInfo (three tabs)
MODS language
MODS physicalDescription
MODS abstract
MODS tableOfContents
MODS targetAudience (only BPL and UNC-CH mapped this)
MODS note (two options - will need to do community voting on this?)
Notes discussion
MODS subject
MODS classification (only BPL and Columbia mapped this)
MODS identifier

1. Group decided not to go through each element during meeting. Steven will create a page on the wiki for feedback. Everyone should review elements and add comments, additional use cases, etc. that have arisen. [Steven sent link by email: Previous MODS to RDF mappings reflection and feedback ]
2. Discussed mods:note RDF mapping which has options for simple and advanced. Steven asked if any use cases that don't work with either option and if we should open this to community voting. Complex option uses bf:note and requires minting for every object but advantage is that same predicate is used. Simple option uses skos:note with note type prepended to string. No minting needed but more difficult for harvesters. Shawn pointed out that in last vote put to the community, the results were not in line with what NYPL will end up doing. Steven said vote results and collaborative mappings are more geared toward sharing data broadly, individual institutions should do what they need to make their data work with their internal systems.Danny asked if we can support both simple and complex options. Steven said yes but doing so increases the complexity for person writing parser. Steven will leave both options on the table for now.
Location of physical object collaboration document (https://docs.google.com/spreadsheets/d/1s3qHr55-z337buZT84gPrnbdWz8oH7sJrk5IZzrIFMQ/edit?usp=sharing)
1. Steven asked it anything was missing or could be better represented.
2. Re: Option #1 Holding: not sure how to represent "division_short_name" and "code" in BIBFRAME. (see row 8) Also, domain not being respected for this example.
3. Re: Option #2 shelfMark: dc:identifier is linked to bf:ShelfMark; Holding: sublocation becomes a unit of the organizationalUnit. Would support multiple layers of hierarchy.
4. Re: Option #3 shelfMark: seems like best way to represent; Holding: similar concept to NYPL's approach.
5. Steven will make Columbia's approach an additional option.Uses MARC relators.
6. Briefly discussed use of bf:shelfMark as predicate v. bf:ShelfMark as class
7. Steven will send out link to poll to this group and Hydra Tech.
Hydra Connect 2016 (https://github.com/projecthydra-labs/hydra-connect/issues/17)
1. Likely no update but a call for any additional comments.
2. None.
Danny asked if group will attempt to map mods:accessCondition. decided we should keep in mind for the future; will want to align with approach taken by DPLA.
Next meeting: Monday August 8th, at 9:00 AM PST / Noon EST.
1. Homework: review collaboration documents and comment: Previous MODS to RDF mappings reflection and feedback

Browser not supported