...
A: (RM) OCFL assumes you are being intentional. Fedora does not assume the user is being intentional. It allows for a broader use case of individuals not thinking about what happens when they update content.
Q: (SP) Does the Fedora tech team have a preference from their technical point of view?
A: (DW)They do, but we're hesitant to introduce that this early in the discussion. We will share that later in the discussion, but we want to prejudice the discussion.
Comment
(SP) Repository owners will have 2 main concerns:
...
(AW) The above scenario was that there was a parent container that got version every time a child was modified or added. The act of creating a version in OCFL is the act of preservation. Indicating that it is ready for preservation. In Fedora the act of creating a version has been more about wanting to not lose a previous version.
(Mark (in chat)) Should "auto" not be determined further up the stack than Fedora? In other words, Samvera and Islandora, and other business logic layers, determine whether all changes result in new versions, or some contextual/configuration logic that makes this curatorial decision on behalf of the user. It is conceivable that multiple applications may be using Fedora, and some may want auto and some may not.
(DW) This is something I worry about too. If Fedora is too rigid in how we deal with it, it could dissuade other applications from adopting Fedora. We want to make it as easy as possible to adopt Fedora 6. So we want to limit how much work others will have to do to adopt Fedora. So, can we come up with a solution that aligns as much as possible with OCFL, but not make the change too complicated to adopt?
(DW ran through the options in the above document)
Action Items