Page tree
Skip to end of metadata
Go to start of metadata

Decisions

Functional Decisions

  1. Drop the Single Subject Restriction
  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.

 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

Design Decisions

  1. Refactor FedoraResource and its sub-classes to serve primarily as data encapsulation objects.
    1. Refactor modification operations into separate service classes.

Open Questions

  1. With the proposal of removing the SSR are we thinking that we will also support out of domain subjects?
  2. OCFL
    1. Will OCFL versions map directly to Fedora versions? Or will Fedora versions be tags of OCFL versions?
      1. Will past versions be able to be deleted?
    2. How will unversioned changes be be persisted?
    3. Where will changes within a transaction be stored prior to committing?
  3. What representation should be used for resources on disk?
    1. Some examples here https://gist.github.com/bbpennel/3dd2ec19d3545e0417071958177baa93
  4. Automatically generated checksums
    1. If the user does not supply any digests, should Fedora generate any automatically like it has done with sha1's in fcrepo4?
    2. OCFL will generate a digest automatically for storage reasons (not necessarily always the same algorithm), should this be surfaced in Fedora?
    3. Should the digests included in existing OCFL objects be surfaced in fedora?
  5. Canonicalization of RDF,  checksumming metadata, and the possibility of byte-for-byte I/O of metata resources.
    1. Is this of use: http://json-ld.github.io/normalization/spec/index.html
  6. Converter framework:  should it stay or should it go?
  7. 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?


  • No labels

2 Comments

  1. Regarding Nearly Decided
    > Drop support for import of historic mementos in OCFL

    Why was this decided? My understanding is if the starting OCFL contains past versions they would be "imported" or is this just via the API?

    1. I was just referring to the API. I will clarify the point.