NamAsTe is used to identify the OCFL root and object versions:
0=ocfl_1.0
0=ocfl_object_1.0
The inventory.jsonld
file is always located in the version directory. For the most recent version, it is also copied to the root of the OCFL Object. Because it is impossible to store a SHA512 hash of the file inside itself, the hash of the most recent version is kept in a inventory.jsonld.sha512 file in the root of the object.
The SHA512 of the ‘inventory.jsonld’ in the root is captured in the inventory.jsonld.sha512
file with the format:
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e inventory.jsonld
The ‘inventory.jsonld’ file contains the information necessary to identify the contents of the object, as well as its versions. It is structured as JSON-LD and features:
- A pointer to the most recent “version” in the ‘head’ key; this is implemented as a pointer to a local “@id”.
- A manifest of all files in the object. This will include all files in all versions.
- A list of the versions.
The JSON-LD shown is not shown as globally-accessible; hence the use of the ‘urn:ark’ value for the root @id. Rather, it was chosen as a way of accessing and defining the semantics of the keys within the versions file, and so that the file could be ingested into a triplestore.
An OCFL client would attempt to read the ‘versions.jsonld’ file, find the ID of the latest version and read the ‘members’ block, and then look up the paths for the files using the SHA512 in the manifest.
Versions can also be compared by doing set operations between two ‘members’ blocks to identify the files that have changed.
There are no requirements for the contents and structure of the ‘logs’ directories in both the disk root and object root. The contents shown are for illustration only.
A tar file is shown to illustrate how tarred objects may be implemented. One could imagine that an expanded tar block would look similar to the example shown.
Use of SHA512 can help identify problems quite quickly. If a file exists in a version folder for which there is no SHA512, or if the file at a given path in the manifest has a different checksum, an object validator can identify these as problems.
^^ Done