...

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. 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.
   What representation should be used for resources on disk?
   1. Some examples here https://gist.github.com/bbpennel/3dd2ec19d3545e0417071958177baa93
2. 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?  ? 

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. What representation should be used for resources on disk?
   1. Some examples here https://gist.github.com/bbpennel/3dd2ec19d3545e0417071958177baa93
2. 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
   Tombstones handling:
   1. If you delete an AG, does the whole OCFL object go away?
   2. We will continue to support Tombstones no? In that case, the OCFL Object would only go away once all the tombstone's were deleted.
   3. If /my-ag is deleted, would we expect /my-ag/binary1/fcr:tombstone to exist?
   4. 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?