MODS and RDF Call 2016-02-08
Time: 9am PDT / Noon EDT
Call-In Info: 712-775-7035 (Access Code: 960009)
Homework Reminder:
Individual Mappings of abstract element: Abstract Individual Institution Usage And RDF Conversion
Moderator: Steven Anderson (Boston Public Library)
Primary Notetaker: saverkamp (etherpad link: https://etherpad.wikimedia.org/p/RDF-MODS-20160208)
Attendees:
Agenda:
- Introductions
- Conversion Code Update
- Steven will work on it most of Wed to start figuring out how to handle language strings in ActiveFedora. In addition, will start other elements if time allows.
- Steven will work on it most of Wed to start figuring out how to handle language strings in ActiveFedora. In addition, will start other elements if time allows.
- MODS OriginInfo Collaboration Document
- Remaining issues:
- For advanced, preference of "opaque:origination" vs "bibframe:Provider" for a wrapper element to group creation events.
- "bibframe:Provider" (http://bibframe.org/vocab/Provider.html) is highly stable uri and gives you a descriptive statement. But we would only support "providerRole" from the potential elements listed within it.
- "opaque:origination" relies on opaquenamespace (or we could have a community one for MODS predicates) that could be less reliable. But we could resolve the URI to list all the "known supported" predicates under that wrapper.
- Suggestions for future conversations -- discuss advantages and disadvantages of different approaches.
- Limitation of bibframe approach: potential confusion, incompatibility between institutions. Pro: stability of URI
- Limitation of opaque or community wrapper: questionable sustainability of predicate URI. Pro: community agreement on predicates used within wrapper, easier to code for when consuming other institutions' data.
- Table until future discussion when more stakeholders are present?
- For advanced, preference of "opaque:origination" vs "bibframe:Provider" for a wrapper element to group creation events.
- Remaining issues:
- MODS Physical Description Collaboration Document
- Notes:
- NYPL style (skos:note of <note_type>: <note text>) vs bibframe 2.0 Note Spec (https://www.loc.gov/bibframe/docs/pdf/bf2-draftspecidsnotes-10-29-2015.pdf) vs a custom note wrapper?
- Table until MODS Note discussion.
- bibframe:extent vs dcterms:extent
- https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;e1a74336.1602
- Question of whether to disobey range restrictions of dcterms:extent in favor of existing community usage. Other major organizations are already using it "incorrectly." Bibframe would be more ontologically correct.
- Stephen will put the decision up to a poll over email.
- Is opaque:digitalOrigin still the best option for mods:digitalOrigin?
- Has anyone come up with other options? DPLA does not address digitalOrigin.
- In the absence of any better options, we will use opaque:digitalOrigin
- dcterms:format for uri's to loc formats (if needed like NYPL use case). Use DCE:format for text strings of mime type?
- No objections to using both properties to serve both URI and literal needs.
- For frequency, does the predicate "dbpedia-owl:frequencyOfPublication" work as it seems like dublin core doesn't have a usable one that means the same thing (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1601&L=DC-ARCHITECTURE&F=&S=&P=11240).
- Example in: https://docs.google.com/spreadsheets/d/1hQjkd1NUn65aagRn-4HevCGYqU77kuGglMPcAGmwIqs/edit?usp=sharing
- Agreed to use bibframe:frequency instead of dbpedia-owl (or dc)
- Notes:
-
Abstract Individual Institution Usage And RDF Conversion
- BPL -- use dcterms:abstract
- UNC -- modsrdf:abstract, but also agrees with BPL
- Amherst -- dcterms:abstract
- Emory -- dcterms:abstract or dcterms:description
- Indiana -- dcterms:abstract -- not always present
- NYPL -- dcterms:description to accommodate broader range of description
- Assignments for next time:
- Table of Contents
- Next meeting: Monday February 22nd, 12:00 PM EST