...

Attendees

Part 1:

1. Danny Bernstein     
2. Peter Winckles
3. Andrew Woods (out)
4. David Wilcox (out)
5. Peter Eichman
6. Joshua Westgard
7. Ben Pennell
8. Jared Whiklo
9. Bethany Seeger 
10. Aaron Birkland 
11. Paul Cummins

Part 2:

1. Danny Bernstein   
2. Peter Winckles
3. Ben Pennell 
4. Ben Cail 
5. Jared Whiklo 
6. Aaron Birkland
7. Bethany Seeger

Agenda

1. Announcements
2. Check-in regarding the double meeting format
3. Status of  https://github.com/pwinckles/ocfl-java-parent  move into ocfl Github repo
4. Opportunities to chip in:
   1. API Test Suite PRs
      
      1. https://github.com/fcrepo/Fedora-API-Test-Suite/pulls
   2.  Minimal 4 →5 migration needs testing  and code review:
      1. https://github.com/fcrepo4-exts/fcrepo-upgrade-utils/pull/17
5. Update on Fedora 6 Pilots 
6. Sprint Planning
   
   1. 6.0 Architecture Review
      1. Versioning review from last week:
         1. Clarification of the proposal: 
            1. OCFL transactions always result in new versions;  we will not support unversioned content in Fedora
            2. From Fedora's point of view, the current state of a resource is the most recent version (ie HEAD)
            3. By default Fedora will display only "significant" versions in the list of mementos.
            4. "Significant versions"  are OCFL objects that contain a marker file in the content directory (possibly something like content/.fcrepo/memento)
            5. Implication:  versions cannot be removed ( because removing content from OCFL is likely to be controversial).  Copy/Delete entire OCFL object would be the only way to remove version history.
         2. Questions: 
            1. Is it important to be able to have Memento timestamps synchronized across a multi-object transaction?  In other words, are users going to want to be able to version changes across a single time-slice? 
               Ie: 
                   http://localhost:8080/rest/object1/fcr:versions/20190822122001
                   http://localhost:8080/rest/object2/fcr:versions/20190822122001
                   http://localhost:8080/rest/object3/fcr:versions/20190822122001
      2.  Multi-object transaction implementation ideas
   2. Transaction Sidecar Spec Update
7. Status on organizing a Fedora documentation review
8. Your topic here...

...

1. In Review

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13100 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

4. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Notes

PART 1

OCFL Java Client  - let's get Peter Winckles and Aaron Birklandtogether for a discussion about a common java ocfl client interface / interaction model - hopefully we can discuss in part two of today's meeting.

...

Paul Cummins  raising the concern about bloat with respect automated versions.   He would have to change the client interaction with Fedora to prevent bloat.His Fedora 3 application performs frequent updates to binary content.   In a world of version on change,  he would quickly experience bloat.   "Copy into new OCFL object + Delete old OCFL object" mechanism for removing unwanted object history is an acceptable solution.

There was consensus shared on the understanding of the new versioning proposal and its implications. 

PART 2

Ben Pennell , Peter Winckles  and Danny Bernstein  continued the discussion of the new versioning proposal.

Everyone seemed concerned that this would represent a significant departure from the current interaction model of Fedora.

Also storing "significant version" files in OCFL seems a bit convoluted.  In order to restore a previous version,  clients would need to indicate whether or not to make the restored version "significant".   Fedora or possibly the client would then need to remove or keep that marker file accordingly.

Question:  What is the standard for rebuildability from OCFL?   Are we still in agreement that you should be able to take an OCFL layout,  copy it to a new location, stand up a new fedora instance against it, and have the state of Fedora be exactly what it was before the move?  Can any non-derivative state live outside OCFL? 

The meeting was adjourned early due to the low turnout.

Actions

•  Aaron Birkland  to look explore notion of OCFL client with database as authoritative metadata source + asynchronous writing of the inventory.json file
•  Peter Eichman   and maybe Ben Pennell to make recommendations re transaction side car specification.
•  Andrew Woods will look into java 11 transition

...