Proposed extension for object structure

[lindareijnhoudt]

We are considering writing an OCFL extension for the following scenario:
In order for an OCFL Repository to be self contained, it might want to explicitly define and declare the format with which an Object is packaged. This might not be the same for each Version in an Object.
The definitions of the Packaging Formats are placed in the storage_root extension, and the declarations of which Version uses which Packaging Format are placed in the object_root extension for each object.

Is it recommended to have this as one extension, or would it be advisable to have two extensions that work in tandem?

[rosy1280]

@lindareijnhoudt, out of curiosity, are these extensions already in production for DANS as a local extension?

[rosy1280]

We made a change to the title of this ticket so as not to cause confusion with the use case Package per version storage #33

[julianmorley]

Hi @lindareijnhoudt , thanks for such a thoughtful extension.

Reading #90 , #89 and #91, it sounds like you are trying to describe how preserved data in /content is structured ("These are Bagit files", "This object was accessioned on ", "here are some custom properties about this object version", etc), so that an extension-aware repository can programmatically extract metadata from the objects.

This sounds very similar to the application profile use case (OCFL/Use-Cases#50). We noted in that use case that OCFL, by design, takes no position on the data stored in /content, and that whilst we wouldn't be targeting application profile support in the main specification, a well-crafted extension could fulfill that role.

My one suggestion is that you fully embrace the idea that you are describing how a repository that uses these extensions is defining the layout and files that go into /content. That is, you should say "Objects that use this extension will have a content/object-version-properties directory in each version, and it shall contain these files", etc.

i.e., using your example from #89 :

[storage_root]
  ├── 0=ocfl_1.0
  ├── ocfl_1.0.txt
  ├── ocfl_layout.json
  ├── object-version-properties.md
  ├── 0de
  |   └── 45c
  |       └── f24
  |           └── item1
  │               └── 0=ocfl_object_1.0
  │                   ├── inventory.json
  │                   ├── inventory.json.sha512
  |                   └── extensions
  └────────────────── v1/
                      ├── inventory.json
                      ├── inventory.json.sha512
                      └── content/
                          └── object-version-properties/
                          |    ├── object_version_properties.json
                          |    └── object_version_properties.json.sha512
                          └── ... files ...

This approach ensures that your object-version-properties and any other technical metadata you wish to record about an object is properly cataloged and preserved by OCFL. You might also find utility in further segmenting content into data/ and metadata/ directories, but again, that's a local repository decision and OCFL takes no position on what goes into content.

This approach would also have the advantage of providing versioning to the object_version_properties.json and any other property files you wish to add to the content.

[lindareijnhoudt]

Thank you for your response.

In our use case, we maintain a front-end web repository for live access and a back-end OCFL repository for long-term preservation. When an object is deaccessioned from the live repository, we want to ensure this change is also reflected in the OCFL repository.

However, since objects in OCFL are immutable, we can’t modify the content folder after the object has been initially stored. That’s the main reason we chose to use the extensions directory to record this information.

An other solution would be to have the object_properties within the content folder, as you suggest, and a separate extension solely to record the deaccessioning in the extensions folder. We thought to be practical to combine the two, but that might be an optimization step that loses functionality (like versioning) for a small gain (one less extension). This solution would then look something like:

[storage_root]
  ├── 0=ocfl_1.0
  ├── ocfl_1.0.txt
  ├── ocfl_layout.json
  ├── object-properties.md
  ├── deaccessioned.md
  └── 0de
      └── 45c
          └── f24
              └── item1
                  ├── 0=ocfl_object_1.0
                  ├── inventory.json
                  ├── inventory.json.sha512
                  ├── extensions
                  |   └── deaccessioned/
                  |       ├── deaccessioning.json
                  |       └── deaccessioning.json.sha512
                  └── v1/
                      ├── inventory.json
                      ├── inventory.json.sha512
                      └── content/
                          ├── metadata
                          |   └── object-properties/
                          |       ├── object_properties.json
                          |       └── object_properties.json.sha512
                          └── data
                              └── ... files ...

with deaccessioning.json consisting of a list of deaccessioned versions and metadata relevant to that.

[rosy1280]

@lindareijnhoudt There are a number of ways that this could be solved -- for example, by including access metadata in your object; creating a new version of the object and "deleting" the content; etc. However, we would need to better understand what your limitations are to provide you with advice. We have a community meeting on Thursday, September 18th at 12pm ET / 6pm GMT+2 if you can make it to that it would be great to connect there or we can set up a special time to meet if that's easier.