...

1. Peter Winckles
2. Peter Eichman  --
3. Joshua Westgard  --
4. Jared Whiklo 
5. Bethany Seeger
6. Youn Noh
7. Thomas Bernhart
8. Ben Cail  --
9. Rosie Le Faive  
10. Daniel Lamb
11. Aaron Birkland
12. Ben PennellPennel
13. Steve Lui

Part 2: 

Agenda

1. OCFL and Fedora: 
   1. inventory.json bloat and what to do about it.
   2. Is OCFL intended for a small number of versions?
   3. And if so, is that intention at odds with autoversioning in Fedora
   4. https://github.com/OCFL/spec/issues/367
   5. What about squashing versions?
   6. What about OCFL on S3 type filesystems?
2. Organizing Sprint work
   1. Review of Goals for Sprint 1
   2. Kick Off Meeting: Monday September 16 at 10am Eastern
   3. Major Areas of Work
      
      1. Design/Development
         1. Interface Definition
            1. Persistence API
               1. ?
            2. OCFL Client Development
               1. OCFL Java API
               2. OCFL Java Client Implementation
            3. Transactions
      2. Documentation
      1. Matrix of all the pages a la 5.x Documentation Updates
      2. Review of docs, flagging pages that will need to be changed, deleted, or added
      3. Testing
         1. Performance Testing
      4. Import/Export/Migration
         1. ?
3. Sprint Planning
   
   1. 6.0 Architecture Review
   2. Coming to consensus on:
   3. Transaction Sidecar Spec Update
4. Status
   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. 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

...

1. OCFL and Fedora: 
2. From the OCFL meeting yesterday 
   1. Potential of changing spec to allow mutable space
   2. Potential of changing spec to allow unversioned objects.
   3. Do they want to change the spec to accommodate the workflows around it (like Fedora's). We can offer use cases and experience. 
   4. Are they willing lot look at in-motion objects and consider them more?  
      1. If not, would we then rather have OCLF as a landing place and not the backend?  Thinking about workflow and preservation - maybe we need to think about and manage both slightly differently. 
   5. Anyone using OCFL - there was the group in Australia. Peter has done an implementation that's not in use yet.
   6. Maybe have 2 persistence
   7. stores – ie a db and OCFL.   Duplicate data space maybe, but possible to not. 
   8. Overwriting V1 - How would we use the OCFL identifiers to find things from the fedora size.  Moving is allowed in OCFL, but concerned about lots of moving of things. 
      1. From Virginia Beach planning - fedora would be able to assign an id - mapping from fedora to OCFL. 
      2. Notion of someone creating an object - ie, archive group. Would want users to have the ability to give an ID to the object.  It's not clear about what Fedora should do in terms of accessioning / deaccessioning of an  OCFL object. 
      3. Confusion around no versions / versus versions discussion from yesterday's OCFL meeting.  Seems like it'd have to be either one or the other for it to work successfully.
      4. Is OCFL identifier part of the identity of the location w/i the object route?  The identifier - it does make it easier if you can identify the root based on OCFL object path.   Still have a tombstone redirect on the OCFL objects in the case where OCFL path is relevant to the object.  There was something in the spec for creating object paths that need to be uniform / consistent.  Can one do whatever they want for identifier path?  https://ocfl.io/0.3/spec/#root-hierarchies
         1. There are a few should there, but looks flexible. 
         2. Looks like one can do what we want with paths, but should try to be consistent. 
         3. Whatever fedora ends up doing it should be written down so a client can understand what fedora expects in terms of identifiers/paths.
         4. Applies to any human read able format, not just OCFL. 
         5. Another option - id - > consistent location which may have any number of directories that are essentially versions of the objects. Then we pick the most recent version one. 
      5. What if we had a different OCLF layout – ie, we have a directory layout where we take you to a directory with OCFL objects.  Ie, we keep objects and can keep multiple copies of the objects, so one move the object and make sure we don't lose anything. 
      6. Aaron Birkland  talked about the design we discussed at Virginia Beach.  About how the paths in fedora would relate to paths in OCFL. 
      7. Was there a possible path for doing the layout in the way for reading directly from disk?  
      8. Fedora will have an index of fedora uri → OCFL uri, but it would be good for other clients to have a way to know to walk the data. 
         1. LDP path will be in the fedora data, as well as the hierarchy (children of containers, etc). The LDP hierarchy would be something fedora would construct based on the metadata.  The fedora index would contain this data (after reading the data).  Children pointing to parent, we don't have to worry about the parent being versioned every time a child is added.  (if they are separate OCFL objects, this works).  Is the child pointing to the OCFL parent or the Fedora path for parent.  Is it the logical (LDP path) or physical (OCFL)?
         2. In other words, it may not be easy, but it will be possible to recreate the information of what the layout is by not containing the physical layout w/i the object.  
         3. Modeshape limited us by pointing from parent to child (creating many members problem).   We will have a flat structure in OCFL. 
      9. Squashing for every un-versioned changed might be challenging - it's really a copy and add new changes to object.   Hopefully there will be another option to do this.
      10. There are some communities that will never use fedora versions 
      11. Having a HEAD directory could provide a space that's mutable and we can keep stuff there, edit it, and then version it at some point.  Might be easily ignorable by clients that don't want to know about it.  Would a HEAD always exist?  Advantage of having this there is for rebuild-ability.
      12. Having it outside the structure might have it's advantages as well. 
      13. A use case - for those that have warm storage where they can't delete anything, OCFL is nice and potentially very helpful. 
   9. Jared created a PR to start the flesh out the persistence API.
3. Organizing Sprint work

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
•  David Wilcox will review the NDSA matrix and pull out the concrete technical requirements that could be considered during the Fedora 6 development.
•  Jared Whiklo will try to do some work on the PersistentStorage Interface.

...