-
Notifications
You must be signed in to change notification settings - Fork 14
2019.03.20 Editors Meeting
Rosalyn Metz edited this page Mar 20, 2019
·
9 revisions
https://duraspace.zoom.us/my/fedora
- Andrew Woods (DuraSpace)
- Julian Morley (Stanford)
- Rosy Metz (Emory) *
-
Simeon Warner(Cornell) - Andrew Hankinson (Bodleian Libraries)
- Neil Jefferies (Bodleian Libraries)
(* indicates the notetaker)
- Open Issues
-
Use Cases - These are "resolved". Once all editors provide +1 on them, the use cases can be closed.
- https://github.com/OCFL/Use-Cases/issues/31
- https://github.com/OCFL/Use-Cases/issues/26
- https://github.com/OCFL/Use-Cases/issues/25
- https://github.com/OCFL/Use-Cases/issues/17
- https://github.com/OCFL/Use-Cases/issues/12
- https://github.com/OCFL/Use-Cases/issues/11
- https://github.com/OCFL/Use-Cases/issues/9
- https://github.com/OCFL/Use-Cases/issues/6
- https://github.com/OCFL/Use-Cases/issues/3
- Conferences
- CNI Session planning: Monday, April 8th @5:00pm to 5:30pm
- NDSA / DLF
- iPres presentation proposal
- All Beta Issues
-
Use Cases - We went through the below use cases and closed. Reviewed remaining use cases:
- Object stores: Use Case #2 - we should create an issue indicating that we don't support empty directories because object stores don't support empty directories. #322 created. Discussion about if there is more we can do to the spec because we talk a lot about hierarchy and directory (around 74 references to that), but object stores don't support those. Add directory as a term to the spec saying that the common implementation utilizes directory structure, but when we refer to this, we mean hierarchical organization. #323
- Open Issues
- #306 - We agreed that we would go with @zimeon 's original recommendations (from Feb 15.), sequential starting with v1 and incrementing up. In the next version of the spec will handle distributed versions.
- #313 - Start with spec then move to implementation notes.
- #212, #284, and #285 - Waiting on PR #317 to be updated.
- #320 - Discussion of how Moab handles this; creates a deposit directory where the work happens and then a move happens where the final version moves into the object and then the inventory is updated. There may be other approaches as well. Let's create a section of the implementation notes that discusses how to accession content into an OCFL object. We agreed to create the deposit directory at the storage root level.
- Andrew W.: send email asking how they think OCFL might fit into this OAIS-IF, will cc everyone