Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Drop the Single Subject Restriction and allow out of domain subjects
  2. Only enforce referential integrity on server generated triples
    1. No automatic enforcement or cleanup of user supplied RDF
  3. Add Archival Group interaction model
  4. Permissions are checked on staging content but not on commit.  
    1. Implications
      1. User can commit anything that they were permitted to write when they staged it.  
      2. 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.
    2. This behavior is consistent with Fedora 4.7.x and 5.
  5. Search service should be synchronous
  6. For a request made within a transaction, access control decisions will be made against the state of WebACs as they exists within that transaction.
  7. OCFL versions  will map directly to Fedora versions
  8. past versions will be deleted (at some point) when the OCFL client supports deleting versions. 
  9. Unversioned changes will be stored in the Mutable HEAD.
  10. Transactional state will be stored in a scratch space and will not be rebuildable.
  11. We need to store a digest for binaries regardless of whether the user supplies one.
  12. Converter framework:  should it stay or should it go?  We are moving towards phasing it out as much as it is practically possible
  13. 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
  14. Autoversioning -
    1. Configurable repository wide? Yes we will support setting a repository wide default. 
    2. 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.
  15. Minting versions within a transaction:
    1. Is there a use case for minting multiple versions within a transaction? No known use-case at this time.
    2. We will disallow minting versions within a transaction for starters.  We will revisit if there is community interest in supporting this feature.
    3. Transaction side-car spec will indicate that some operations may not be allowed within a transaction.
  16. Tombstones handling:
    1. What happens when you delete an AG?  A  new OCFL version is created  that contains only the tombstone
    2. We will continue to handle tombstones from the fedora client perspective in the style of Fedora 5:  When GETting the child of deleted parent,  the response will be a 410 with a reference to the parent's tombstone.
    3. We may consider exposing the  timemap of the deleted resource to administrators in order to allow them to restore a previous version.

 Nearly Decided

  1. Drop support for import of historic mementos in OCFL via the API
    1. Allow or disallow in other backends?
  2. 1:1 mapping between Fedora info URIs and LDP paths
    1. This means fedora 3 objects migrated to single OCFL objects would inherently have LDP path http://example.org/fcrepo/rest/${pid}
  3. Containment and membership relations will be interpreted from repository structure and indexes, not persisted to disk.
    1. See Containment/Membership triples management
    Tombstones handling:
    1. If you delete an AG, does the whole OCFL object go away? We need to get community input on this:  Danny Bernsteinand Ben Pennell support making a new OCFL version that contains only the tombstone, but more discussion needed.
    2. We will continue to handle tombstones from the fedora client perspective in the style of Fedora 5:  When GETting the child of deleted parent,  the response will be a 410 with a reference to the parent's tombstone.
  4. Automatically generated checksums
    1. OCFL will generate a digest automatically for storage reasons (not necessarily always the same algorithm), should this be surfaced in Fedora? 
      1. We probably want to do this but we should check in with Aaron Birkland  first to verify that this is what we want.
      2. Should the digests included in existing OCFL objects be surfaced in fedora? 

...