Time: 9am PDT / Noon EDT
Call-In Info: 712-775-7035 (Access Code: 960009)
Homework: White paper comments and Collaboration document spreadsheet clean-up
Moderator: Eben English
Primary Notetaker: TBD (Etherpad link: https://etherpad.wikimedia.org/p/MODS_and_RDF_Call_2017-06-12)
Attendees:
Agenda:
- White paper: https://docs.google.com/document/d/1ffCyIirUkESLefBehafbacsLb_Rq7KJbTxxeoQCyLpw/edit#heading=h.7y094mt5y4wo
- Emily revised some of the draft based on comments added in the last meeting, and added a summary of organizations (17) who have attended meetings
- Group is welcome to edit directly
- Collaboration Documents spreadsheet review and clean-up: https://docs.google.com/spreadsheets/d/1jhguUHc4ZbzhOwCvLppReepMu4pW3aNIdAkGQs4xA60/edit#gid=0
MODS: Note
Danny from BPL has been working on it; feels it's in good shape
Some questions about preference regarding Labels - and use of skos:prefLabel
For complex Notes and for other minted objects, we moved to using rdf:type to declare the model/class of the object.
For Notes, bf:Note is the class and bf:note is the predicate relating the two.
Will make some adjustments to namespace abbreviations for Complex Notes (related to above)
- MODS: RelatedItem - will discuss at future call
MODS: physicalLocation
ShelfMark and Enumeration
- enumerationAndChronology also does not accept a literal in 2.0, but there is an alternate we could use (editionEnumeration)
Discussed editionEnumeration, but several attendees noted this may be too specific for our usage needs.
Should we keep using BIBFRAME enumerationChronology and violate the constraints?
What level of demand or need do we have for the original MODS enumerationAndChronology component - does it need to be separate?
Suggestion: could be appended to end of shelfLocator statement instead, and remove enumerationAndChronology as a separate unit.
- shelfMark does not accept a literal in 2.0 (takes a URI)
There is also a holding ontology that may be of interest: http://dini-ag-kim.github.io/holding-ontology/holding.html
- Maintained by German Initiative for Network Information (DINI): https://dini.de/english/
- Has predicates like holding:label ("A call number, shelf mark or similar label of an item")
- But, we have tended to steer clear of non-US vocabs
- Eben will investigate further
Holding Institution
- This is OK (bf:heldBy)
Sublocation
bf:subLocation is deprecated; bf:sublocation does not accept a literal.
could use bf:physicalLocation instead, but would then need a diff. predicate for shelfMark
URL
- This is OK
- edm:preview for thumbnails, edm:isShownAt for "object on content" URL
Subject
Original mappings are incomplete; more work needed.
- We will discuss next time.
Classification
LC and Dewey were fine; changed how we work with other schemes
using LC classSchemes vocabulary, and then a string for the value
Identifier
Simon reports we are good except for needing a predicate for Accession Number type identifiers.
Discussion regarding keeping the old scenarios which were voted on.
Agreed to keep them, but need to consider how to manage the documents.
Do we keep the downvoted stuff for posterity?
- Should probably make a "clean" version without downvoted options
Record Info
- Overall solid.
Can delete the extraneous tabs for Part and Extension (neither were mapped)
Record creation and modification dates are not mapped - discuss at a future meeting
- These could be supplied by Fedora system info
- Some have use case for keeping track of legacy pre-Fedora4-migration record creation dates
- Minted objects: rdfs:label vs. skos:prefLabel
- skos:prefLabel is a subclass of rdfs:label.
- Proposed just using rdfs:label unless we need multiple/alternate labels.
- Next meeting: June 26 at 9:00 AM PST / Noon EST
Eben can't attend; other members note conflicts with ALA
Should we skip and resume on the 10th of July?
Eben will send out a poll.