Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

Attendees

Part 1: 

  1. Danny Bernstein 
  2. Peter Winckles
  3. Jared Whiklo 
  4. Bethany Seeger 
  5. Thomas Bernhart 
  6. Aaron Birkland
  7. Andrew Woods  
  8. Ben Pennell (star)
  9. Ben Cail
  10. David Wilcox
  11. Peter Eichman

Agenda

  1. Announcements 
    1. Sprint 2
    2. ?
  2. See if we can get a unified vision for how we want Fedora to interact with OCFL, so that we can propose one of the following to the leadership group:
    1. Recommend pushing for changes to the OCFL spec (i.e. a mutable head), so that both versioned and un-versioned content can be "in" OCFL
    2. Accept the immutability of object versions in OCFL, and recommend one of the following
      1. Fedora shall store un-versioned content outside of OCFL in a fedora-specific layout
      2. Fedora shall disallow un-versioned content entirely
    3. Recommend Fedora use something other than OCFL for Fedora's persistence layer, and create external tools for exporting/publishing to OCFL when desired.
  3. This document describes the core issues and outlines the pros and cons of the implementation possibilities described in the preceding agenda item. Recommending a particular implementation is beyond the scope of the document; it simply seeks to provide an objective (to the degree possible) analysis to serve as a baseline for an informed discussion. Comments and suggestions are welcome, but please respect the scope of the document.
  4. Other questions to be answered
    1. “When making a request during a transaction, should the ACL of the HEAD version of the resource be evaluated, or the ACL of the version of the resource that exists in the transaction?”
      1. Related to https://github.com/fcrepo4/fcrepo4/pull/1559
      2. from Decisions and Open Questions
    2. What is the approach we want to take for adding digests to external binaries?
      1. Reference: 2019-09-26 - Fedora Tech Meeting (Notes: 3.a.)
    3. What do we want our approach to be for loading Fedora6 resources? lazy or eager?
      1. Related to https://github.com/fcrepo4/fcrepo4/pull/1557 
  5. <add topics here>

Tickets

  1. In Review

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Loading...
    Refresh

  2. Please squash a bug!

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  3. Tickets resolved this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  4. Tickets created this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

Notes

1. Announcements

  • Islandoracon was great, there was a fedora special interest group that met during lunch and did fedora presentations
    • Bento boxes and preservation. Drupal 8
    • Can pop in and out components like Fedora. For some, its considered "in" the repository once it is in fedora.
    • A lot of people looking forward to Fedora 6
    • Workshop to get people to migrate to Islandora 8, which required moving from F3 to F5 went well.
  • Sprint 2 - It would be helpful to try to decide some of the Open Questions before the next sprint Decisions and Open Questions

2. Uniform vision for how Fedora should interact with OCFL

  • Jared - it does not make sense to store fedora objs in two different places. It puts a burden on Fedora for the sake of OCFL
    • he likes OCFL, but wants a transparent file layout from the application perspective.
    • Fedora deals with so many in motion objects, it may not be worthwhile
  • Andrew - historically users have not differentiated between in-motion and preserved
  • Bethany - could there be multiple clients operating on the OCFL?
    • Andrew - we should be very clear that only multiple read clients
  • Is option A a change to the spec?
    • That is what Andrew as thinking, that there would be a HEAD version in the spec
    • As compared to rewriting the most recent version
  • There are four options, as outlined in the agenda subpoints and the document
    • Jared: A => C (falling back to C if A fails)
    • BenP: A => C or B1
    • Bethany: A => B2 => C
    • AaronB: A => B2 => C
    • BenC: A => B1 with encouragement to users to version or B2 (doesn't like C)
    • PeterW: A (cleanest but seems unlikely) => C
    • Thomas: A => C
    • DannyL: C (unless vociferously opposed by leaders) => A
    • AndrewH: Doesn't feel like he can voice an opinion about what fedora should do
    • AndrewW: A (wants fedora to be as close to OCFL as possible)
  • PeterW - Another option is to serialize to non-OCFL and periodically push to OCFL
    • Jared - similar to B1 in that there are two places where content is stored
  • Andrew - Not clear that having a mutable head directory would take away from the value of the version directories
  • Aaron - A is somewhat out of our control, since it depends on the OCFL editors. It is not so much a technical issue.
  • David was suggesting that we might just do A even if it wasn't in the spec
    • PeterW - Fine if you don't care about validation, but the bigger issue might be that the inventory would be referencing content that isn't allowed, so the object might not be readable.
    • Assuming  that the root inventory file would point to HEAD as the current version
    • Aaron - since the version inventories are the canonical inventories, then might not even need to add anything to the root inventory.
  • RECOMMENDATION: Option 'A', if supported by the OCFL specification

4. Other questions to be answered

  • a. “When making a request during a transaction, should the ACL of the HEAD version of the resource be evaluated, or the ACL of the version of the resource that exists in the transaction?”
    • Jared - it would require two actions, first updating ACL and then starting transaction and doing work
    • BenP - it seems like a special behavior to only work against the HEAD of the ACL versus everything else in the repo
    • DECISION: Treat ACL's as normal, so use the version in the transaction unless this causes significant technical issues
  • b. What is the approach we want to take for adding digests to external binaries?
    • We talked about this some on Sept 26, Andrew remembers that we wanted fedora to retain fixity for internal binaries. For external, users can add their own. For internal, users can't override the internal digest.
    • Fedora has its own internally managed checksum for internal content
    • Users can add digests to external content
    • Should fedora try to fill in a checksum if none is provided?
    • Jared - spec says that ext's must respond to want-digest. So do we need to store it internally? How do we fulfill
    • DECISION
      • Fedora to retain fixity for internal binaries
      • For internal, users can't override the internal digest, but can add supplemental digests
      • For external, users can add their own

Actions

  • Aaron Birkland  to look explore notion of OCFL client with database as authoritative metadata source + asynchronous writing of the inventory.json file
  • David Wilcox will review the NDSA matrix and pull out the concrete technical requirements that could be considered during the Fedora 6 development.