MODS and RDF Call: 2018-09-17

Time: 9 AM PDT / Noon EDT

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

Documents/Homework:

Moderator: Eben English

Notetaker: TK (Etherpad: https://etherpad.wikimedia.org/p/MODS_and_RDF_Call__2018-09-17)

Attendees:

Agenda (with notes)

  1. Feedback Form Responses 
    1. https://docs.google.com/spreadsheets/d/1DRAzr3ExEAjK2RUs63gxcymoDwprQjVRPDsU_3dDGVU/edit?usp=sharing
      1. No new entries as of 9/17

  2. Email Responses
    1. https://docs.google.com/spreadsheets/d/146uvvKt5ZVvWjm9WV28fWHgCP8fYQ_JXkc5GcMv98Wc/edit?usp=sharing
      1. No new entries as of 9/17

  3. Action items from last meeting:
    1. Possibly add more contextual information about scope and constraints (in implementation) in document introduction.
      1. Eben added additional information to the introductory section; group reviewed and accepted.
    2. Create talking points for Samvera Connect session to address realities of implementation
      1. See item f below.
    3. Change 3-letter to 2-letter language tags AND add a footnote to document that addresses the implementation issue.
      1. Group reviewed and accepted change.
    4. Add footnote related to EDTF revision, explaining new draft should be released later this year. Current examples are from existing draft (pre-revision).
      1. Group reviewed and accepted change. Note: we are not able to anticipate a date for the forthcoming specification change since it has been pending for some time.
    5. Add note about expression of datatypes for dates (representation of EDTF?). Syntax?
      1. Even added a footnote regarding how to express datatypes in the case of dates, but group noted that supplying datatypes in URIs was beyond the scope of other examples and our original use cases. 
    6. Emily will put together possible outline for Samvera Connect for group participants to review.
      1. Emily discussed the draft outline and requested comments from group members, especially regarding how their respective institutions are planning to adopt the recommendations. Eben noted that our presentation slot is 30 minutes so we should have plenty of material to fill the time.
    7. Look at wgs84 post for representing geographic data.
      1. Group discussed the submitted comment but felt that the original DC predicate is more appropriate to the use case.

  4. Outstanding Comments on Recommendations document - additional open comments were discussed for:
    1. Is Part Of
      1. Additional comments/context should be supplied to clarify why we have multiple predicates for collection membership.
      2. Group discussed this as an example of implementation-related concerns for predicate selection. There is a longstanding Hyrax issue related to use of the dcterms:isPartOf predicate.
    2. Series
      1. Discussed concerns that the BIBFRAME domain context for series references an ISSN/commercially published series, and is not likely appropriate for an archival series as the example requires. Group agreed to re-use and repurpose the predicate requested through opaque namespace, opaque:memberOfArchivalSeries (we will need to request it to be provisioned as accepting a literal or a URI)
    3. Identifiers
      1. Discussed the use of LC identifiers:uri as an alternative to schema:url and agreed the LC predicate is more appropriate for this context, and for consistency.
    4. recordInfo
      1. Group discussed questions and complexities for this mapping, in that with a URI representing a Fedora 4 object, the metadata is part of the object and it is hard to differentiate.

  5. Samvera Connect session
    1. See prior notes regarding presentation outline: will continue to discuss at upcoming meetings.

  6. Next meeting: Monday October 1

  7. Action Items
    1. Add a paragraph further explaining the rationale and background for relatedItem collections' predicates and why we have multiple instances of them
    2. Review use of opaque namespace predicates across Simple and Complex/Minted Object option (in case we need to expand predicate requests to serve both purposes)
    3. Revisit recordInfo discussion