You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 25
Next »
Decisions
Functional Decisions
- 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.
- 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.
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.
- See Containment/Membership triples management
Design Decisions
- Refactor FedoraResource and its sub-classes to serve primarily as data encapsulation objects.
- Refactor modification operations into separate service classes.
Open Questions
- OCFL
- Will OCFL versions map directly to Fedora versions? Or will Fedora versions be tags of OCFL versions?
- Will past versions be able to be deleted?
- How will unversioned changes be be persisted?
- Where will changes within a transaction be stored prior to committing?
- What representation should be used for resources on disk?
- Some examples here https://gist.github.com/bbpennel/3dd2ec19d3545e0417071958177baa93
- Automatically generated checksums
- If the user does not supply any digests, should Fedora generate any automatically like it has done with sha1's in fcrepo4?
- OCFL will generate a digest automatically for storage reasons (not necessarily always the same algorithm), should this be surfaced in Fedora?
- Should the digests included in existing OCFL objects 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?