MODS and RDF Call: 2018-12-10

Time: 9 AM PDT / Noon EDT

Call-In Info: 712-775-7035 (Access Code: 960009)

Documents/Homework:

Mapping recommendations (original)
Mapping recommendations (clean, sent for comment)
Feedback form

Moderator: Eben English

Notetaker: TK (Etherpad: https://etherpad.wikimedia.org/p/MODS_and_RDF_Call__2018-12-10)

Attendees:

Julie Hardesty (Indiana)
Emily Porter (Emory University)
Simon O'Riordan (Emory University)
Kate Gerrity (Amherst College)
Danny Pucci (BPL)
Eben English (BPL)

Agenda (with notes)

Feedback Form Responses (no new entries as of 10/29)
1. https://docs.google.com/spreadsheets/d/1DRAzr3ExEAjK2RUs63gxcymoDwprQjVRPDsU_3dDGVU/edit?usp=sharing
Email Responses (no new entries as of 10/29)
1. https://docs.google.com/spreadsheets/d/146uvvKt5ZVvWjm9WV28fWHgCP8fYQ_JXkc5GcMv98Wc/edit?usp=sharing
MODS Editorial Committee comments
1.     1. Regarding MODS and Bibframe - The MODS Editorial Committee is about to start work on a MODS/BIBFRAME application profile (possibly with a limited MODS/RDF extension where/if necessary) rather than maintaining a complete MODS/RDF ontology going forward.
  
      White paper already has a footnote with this information. No actions needed
  
      2. Regarding future of this mapping reccomendation document? - Are there plans in place to maintain and update these mapping recommendations?
  
      TBD. Will be discussing after PDF of document is created. Might add additional information in the document itself about maintenance and future of the recommendations.
  
      3. "The instructions should clarify why one namespace was chosen over another, e.g. foaf over schema.org"
  
      This information is already included in the Process of Analysis section of the document
  
      4. "It would be helpful for implementers to see what the MODS RDF will look like. Could the working group add full examples?"
  
      More clarity on what this means? What format do they wish to see these full examples in? MODS XML?
  
      5. MODS RDF and Blank Nodes - Issue addressed on document
  
      6. "The document offers a lot of choices. There are direct mappings and minted objects mappings or sometimes properties have been chosen that could point to a string or a URI. It would be worthwhile recommending in the introduction that any implementation following these recommendations needs to be accommodated with an institution specific application profile."
  
      This has been addresed in the document. (page 7 on google doc)
  
      7. "Explanation of Minted Object Mapping: Another point to include is that maintaining the objects allows us to associate information that belongs to an object with that object. See issue discussed on page 52 (on google doc), where a local identifier cannot be associated with the institution it originated from."
  
      Point is implied in document. Additional clarification regarding minted object mapping can be added to the document
  
      8. "The examples in the direct mapping sections include cases where either two statements should be used or the complex mapping (e.g. page 10). We noted a few other instances in the document where the example should be reviewed for correct encoding and marked those in the document."
  
      Issues have been addressed in the document.
  
      9. "If there is no role associated with a name, it’s better to default to contributor rather than creator because there is really no way of knowing if the agent is in fact the creator. It could also raise copyright issues."
  
      Issue has been corrected in the document
  
      10. "dce:format (page 27)-- consider using ebucore:hasMimeType or dct:format (pointing to an object)"
  
      Footnote on that page address the issue
  
      11. "Page 26: Change the example to one that represents only one item and its format or break up into separate examples, so that it does not violate the 1:1 principle."
  
      No changes needed. Examples are using MODS records that group members contributed
  
      12. "Subject (page 33)--Consider using more current geonames (https://www.w3.org/2003/01/geo/wgs84_pos#) over DCMI specs"
  
      Warning included in document about using the DCMI specs
  
      13. "Regarding the minted object mapping: Is there a reason for bibo:edition to be used in the relatedWork description versus bf:editionStatement in the originInfo mapping section? Other predicates also differ between the descriptions of the “main object” and the related object. If those are all objects within our system, shouldn’t the mapping match?"
  
      Document no longer uses bibo:edition for relatedWork. Using bf:editionStatement
  
      14. "Examine the need for having the predicate indicate attributes of the collection or item, e.g. the need for having the predicate indicate attributes of the collection or item, i.e. the need for separate properties to describe the same relationship because of the format they're in."
  
      On page 41, there is a footnote about collection membership use cases
  
      15. "bf:seriesStatement: It is very problematic to use this predicate for archival series. The definitions indicates that bf:seriesStatement is reflecting a commercial publisher series"
  
      Issue has already been corrected in document
  
      16. "Page 44: Update example to make it less confusing? It appears that the same URI is used to represent the physical and the digital collection."
  
      Issue has been adressed. Relating to Samvera software functionality - Administrative set membership definition might be clarified for example 6. There is a definition early on the document regarding administrative sets. Repeat the link for example 6 on page 44
  
      17. "Identifiers (starting page 49): There is no minted object mapping for identifiers, even though minting an object for an identifier can solve many of the problems encountered with this section"
  
      There was a vote for this issue early on in the groups history. Will add additional clarification to this to hopefully address this comment.
  
      18. "Page 50 -- use identifiers:uri instead of schema:url to be more consistent in the use of vocabularies? A URL is a subset of a URI."
  
      Has been addressed
  
      19. "Location (page 54): edm:isShownAt, edm:preview and edm:object are subproperties of edm:hasView. That means, that the rdf:Domain is ore:Aggregation. Might this become a problem when validating the data?"
  
      Group does not view this has a problem
  
      20. "recordInfo (page 59) -- use “description” or “description set” instead of “record” in the usage notes? Since RDF doesn’t really have records … The example doesn’t make quite clear if the metadata or the item is being described. The BIBFRAME properties have the domain of bf:AdminMetadata, but the class is apparently not used here.
  
      There is a paragraph describing group's usage of this property.
  
      21. Title -- minted object (starting page 62): Use primarily BIBFRAME here? The mapping are already uses the class bf:Title. Why not also the BIBFRAME title properties? bf:title, bf:mainTitle, bf:variantTitle. It is modeled to use them together. It would solve the “alternative title” problem commented on for example 5.
  
      Issue has been looked at and addressed
  
      22. Name -- minted object (page 66): Consider providing an option to parse out personal names into last name, first name. It’s required by many organisations that IRs share data with. Options are foaf:familyName and foaf:givenName.
  
      Examples are from MODS records provided by group membership. Additional information can be added via footnote.
  
      23. Notes (page 84)-- Using bf:noteType is not encouraged. It is better practice to define note types as subclasses of bf:Note in external name spaces. Also, in the minted object section it is important to point out that once you have a minted object for a title (for example) the note describing the title source should be associated with that object, not with the item being cataloged.
  
      Issue has been addressed. Footnote has been added.
  
      24. "Consider using MADS/RDF for this to parse out the pieces of pre-coordinated subject headings."
  
      Issue has already been addressed
Looking forward
1. Update version to 1.0 and cut a PDF release
  1. If PDF is hosted on the wiki, information about the maintenance (future scheduling, updates for example) can be kept on that website (MODS RDF section of the wiki), not the document itself?
  2. Could include a brief section within the document itself referencing back to the wiki (the subgroup page, not the Samvera Metadata Interest Group page).
  3. Could version the document through the wiki.
  4. Will also link this nformation to the Samvera Metadata Interest Group wiki as well.
  5. Roadmap council may issue template for final documentation
2. Report to Samvera Metadata Interest Group
  1. Next Samvera Metadata Interest Group meeting is January 27th to report out on progress of this group - can discuss future meetings, scheduling
3. Future meeting schedule
  1. still TBD, discuss next meeting
4. Updates/changes/revisions schedule
  1. still TBD, discuss at next meeting
5. Opaque predicate requests, update as they become available
  1. Julie sent out an email to the Samvera Steering group - They are interested but need more information about the "cost" in setting this up, cost estimate for the vocab manager (variety of options, could be something like GitHub, or a more specialized service) - Group needs to discuss this and will ask Ryan to provide more clarity and assistance in this.
TODOs:
1. Submit opaque predicates to URI WG
Next meeting: Monday January 7