MODS and RDF Call 2017-06-12
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:
@Eben English
@Chuck Schoppet
@Danny Pucci
@Emily Porter
@soriordan
@Johanna Radding
@ksgerrity
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.