Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

No Format
[object root]
    ├── 0=ocfl_object_1.0
    ├── inventory.json
    ├── inventory.json.sha512
    └── v1/
        ├── inventory.json
        ├── inventory.json.sha512
        └── content/
            ├── .fcrepo/
            │   ├── image.tifffcr-root.json           <-- Required "header" file holding system metadata about the binary. See description below.
            │   ├── image.tiff~fcrfcr-root~fcr-desc.json  <-- Required "header" file holding system metadata about the binary's description. See description below.
            │   └── image.tiff~fcrfcr-root~fcr-acl.json   <-- Optional, only present if this Fedora resource has its own ACL.
            ├── image.tiff
            ├── image.tiff~fcr-desc.nt        <-- Required "binary description". See description below.
            └── image.tiff~fcr-acl.nt         <-- Optional, only present if this Fedora resource has its own ACL.

Fedora stores system metadata about the binary (image.tiff) and the binary's description (currently, https://host/rest/image.tiff/fcr:metadata) in respective JSON files that contain elements such as the creation date and creator, as well as its interaction model (i.e. type), whether the object is an archival group, etc. Additionally, Fedora resources can optionally have their own ACLs, which if present also have their own JSON header file. The full contents and format of the JSON header file and ACLs are detailed later in this document. 

...

  • The binary: the filename provided during ingest of the binary is retained in the OCFL persistence. ("image.tiff", in this example)
  • The binary's description: the filename is the name of the binary with the addition of the suffix, "~fcr-desc.nt". ("image.tiff~fcr-desc.nt", in this example)
  • The binary's ACL: the filename is the name of the binary with the addition of the suffix, "~fcr-acl.nt". ("image.tiff~fcr-acl.nt", in this example)
  • The binary's header file: the filename is the name of the binary with the addition of the extension, "always "fcr-root.json". ("image.tiff.json", in this example)This allows Fedora to find the header file without know if the resource is a binary, container or archival group.
  • The binary description's header file: the filename is the name of the binary description with the appropriate extension, ".json". ("image.tiff~fcralways "fcr-root~fcr-desc.json", in this example).
  • The binary ACL's header file: the filename is the name of the binary's ACL with the appropriate extension, ".json". ("image.tiff~fcralways "fcr-root~fcr-acl.json", in this example).

Fedora Atomic Resource - Container

...

No Format
[object root]
    ├── 0=ocfl_object_1.0
    ├── inventory.json
    ├── inventory.json.sha512
    └── v1/
        ├── inventory.json
        ├── inventory.json.sha512
        └── content/
            ├── .fcrepo/
            │   ├── fcr-root.json           <-- Required "header" file holding system metadata about the binarycontainer. See description below.
            │   └── fcr-root~fcr-acl.json   <-- Optional, only present if this Fedora resource has its own ACL.
            ├── fcr-container.nt           <-- Required "binary description" file for holding user-properties describing the container. See description below.
            └── fcr-container~fcr-acl.nt         <-- Optional, only present if this Fedora resource has its own ACL.

...

Naming conventions

  • The container user-properties: the filename is always "fcr-container.nt".
  • The container's ACL: the filename is always "fcr-container~fcr-acl.nt".
  • The container's header file: the filename is always "fcr-root.json". This allows Fedora to find the header file without know if the resource is a binary, container or archival group.
  • The container ACL's header file: the filename is always "fcr-root~fcr-acl.json".

Basic OCFL Structure

The following is an example of an OCFL object that contains one version, consisting of a hierarchy of files and directories. For more information on OCFL, see the specification.

...