Flat mapping of Fcrepo to OCFL

gistfile1.txt

Fedora structure:
obj1 -> LDPC
    └── file.txt -> LDPNR -> reference to memento 20190130120000
    └── subdir -> LDPC
        └── file1.txt -> LDPNR
        └── file2.txt -> LDPNR
            ...
        └── file1000000.txt -> LDPNR
        
[storage root]
    ├── 0=ocfl_1.0
    ├── ocfl_1.0.txt
    ├── ocfl_layout.json
    └── uuid_1 (obj1)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── obj1.ttl
    └── uuid_2 (file.txt)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── file.txt
            └── file.txt.ttl
    └── uuid_3 (subdir)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── subdir.ttl
    └── uuid_4 (file1.txt)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── file1.txt
            └── file1.txt.ttl
    └── uuid_5 (file2.txt)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── file2.txt
            └── file2.txt.ttl
        ...
    └── uuid_1000000 (file1000000.txt)
        ├── 0=ocfl_object_1.0
        ├── inventory.json
        ├── inventory.json.sha512
        └── content
            └── file1000000.txt
            └── file1000000.txt.ttl

This supports the scenario of mapping Fedora resources onto OCFL.
However, it is not clear that this mapping supports the "drop Fedora over an existing OCFL structure"... since we can not count on the existing OCFL structure to comply with this layout.