Noted that Eben and Emily made some edits and cleaned up comments in the larger white paper.

Discussed formatting for final documentation. Based on discussion at last meeting, Eben worked with title element and separated out direct mapping and complex mapping. Within each, table of predicates used for that element appears first, followed by various examples of original xml and mapping to rdf. Eben also created a TOC (currently starts on p.5).

Positive feedback re: splitting out the two options into separate sections of the document and the inclusion of the table and the various examples. There was a comment on lack of contrast between text and background in the examples which makes it a bit hard to read them. Discussed and played with various options then decided to keep the font currently used and adjust to a slightly lighter background.

Discussed including the terminology “simple” and “complex” to clarify what “direct mapping” and “minted object mapping” mean. Group agreed it would be helpful to say more about how the two options differ and how each is intended to be used.

Discussed adding some explanatory text/overview for each element touching on what we chose to map and why (if an explanation is needed) and also what we did not map and why.

Emily created a worksheet of namespaces (exhaustive, thank you!) used for all the mappings.

Questions and inconsistencies she encountered when putting the sheet together are noted in it. Most inconsistency is around use of skos, Bibframe, DC, MARC relators and LoC identifiers. Confirmed that the Fedora namespace is for internal use only and that opaque namespace is for properties that need to be created, which is why it doesn’t currently resolve. Discussion around the use of Bibframe lite. Melanie confirmed that it will stop being maintained. We agreed we should look at another option for any elements where we had chosen to use it.

Q: will we still link out to collaboration worksheets? No. Given that we want to share white paper with larger community we should focus our efforts there but be aware that examples being pulled from the worksheets int the white paper will need corrections to some of the namespaces and prefixes used.

Discussed prefixes used v. RDFVocab gem. The latter is specific to the Samvera community so it could be confusing to others outside the community, especially metadata people (as opposed to programmers). Also doesn’t include all the namespaces we’ve used in the mappings.

Emily will bring over content from her namespaces sheet. We should all keep an eye on any changes needed to update it.

Confirmed overall arrangement of white paper. There will be separate sections for simple and complex mappings but in each section, every MODS element we’ve mapped will be repeated, even if only one mapping exists. In those cases, there will be a note indicating this and a link to the section containing the mapping. Elements will be arranges following the order of the MODS top-level elements. http://www.loc.gov/standards/mods/userguide/generalapp.html

Regarding the TOC, decided to change headings for examples to normal text in order to be able to remove them from the TOC. Under mappings, only element headings will remain. This makes the TOC less unwieldy.

Eben will reformat the title example and send out a message letting us know when it’s done. Suggested that easiest way to populate the document with examples will be to copy and edit the title example. Agreed the easiest way to split up the work is for those who reviewed specific elements in the collaboration worksheets to be responsible for adding those same elements to the white paper, following the model for the title element.

n.b. comments have been added to the white paper covering many of the of the issues above that need follow-up