...
- Drop the Single Subject Restriction and allow out of domain subjects
- Only enforce referential integrity on server generated triples
- No automatic enforcement or cleanup of user supplied RDF
- Add Archival Group interaction model
- Permissions are checked on staging content but not on commit.
- Implications
- User can commit anything that they were permitted to write when they staged it.
- Thus it is possible that a userA would start a transaction at 10:00, update some resources at 10:01, subsequently find they no longer have permission to write at 10:03 because of a restrictive ACL change by userB at 10:02. userA's attempt to commit the transaction at 10:04 will succeed.
- This behavior is consistent with Fedora 4.7.x and 5.
- Implications
- Search service should be synchronous
- For a request made within a transaction, access control decisions will be made against the state of WebACs as they exists within that transaction.
- OCFL versions will map directly to Fedora versions
- past versions will be deleted (at some point) when the OCFL client supports deleting versions.
- Unversioned changes will be stored in the Mutable HEAD.
- Transactional state will be stored in a scratch space and will not be rebuildable.
- We need to store a digest for binaries regardless of whether the user supplies one.
- Converter framework: should it stay or should it go? We are moving towards phasing it out as much as it is practically possible
- We are evaluateing a "Minimal" Fedora 3 migration, where all datastreams from a fcrepo3 object are placed into a single OCFL object with no modifications
- Autoversioning -
- Configurable repository wide? Yes we will support setting a repository wide default.
- We will support a per object versioning policy object, similar to fedora 3 ( REST API#modifyDatastream (versionable param)) if there is community desire for this feature.
Nearly Decided
- Drop support for import of historic mementos in OCFL via the API
- Allow or disallow in other backends?
- 1:1 mapping between Fedora info URIs and LDP paths
- This means fedora 3 objects migrated to single OCFL objects would inherently have LDP path http://example.org/fcrepo/rest/${pid}
- Containment and membership relations will be interpreted from repository structure and indexes, not persisted to disk.
...
- What representation should be used for resources on disk?
- Some examples here https://gist.github.com/bbpennel/3dd2ec19d3545e0417071958177baa93
- Automatically generated checksums
- OCFL will generate a digest automatically for storage reasons (not necessarily always the same algorithm), should this be surfaced in Fedora?
- We probably want to do this but we should check in with Aaron Birkland first to verify that this is what we want.
- Should the digests included in existing OCFL objects be surfaced in fedora?
- OCFL will generate a digest automatically for storage reasons (not necessarily always the same algorithm), should this be surfaced in Fedora?
- Canonicalization of RDF, checksumming metadata, and the possibility of byte-for-byte I/O of metata resources.
- Is this of use: http://json-ld.github.io/normalization/spec/index.html
- Converter framework: should it stay or should it go?
- Should we evaluate a "Minimal" Fedora 3 migration, where all datastreams from a fcrepo3 object are placed into a single OCFL object with no modifications?
- Autoversioning -
- Configurable repository wide?
- Or configurable by object, similar to fedora 3? REST API#modifyDatastream (versionable param)=
- Is there a use case for minting multiple versions within a transaction? Are the technical challenges for supporting that worth the effort?
- Tombstones handling:
- If you delete an AG, does the whole OCFL object go away?
- We will continue to support Tombstones no? In that case, the OCFL Object would only go away once all the tombstone's were deleted.
- If
/my-ag
is deleted, would we expect/my-ag/binary1/fcr:tombstone
to exist? - Then if we delete
/my-ag/fcr:tombstone
would we expect all tombstones of the children also to be deleted, ie/my-ag/binary1/fcr:tombstone?
...