...
- The user's content files
- Fedora-specific RDF files containing user-properties related to the OCFL object and/or user's content files
- Fedora-specific JSON "header" files containing system system-properties related to the OCFL object and/or user's content files
The full contents and format of the JSON "header" files, first two categories of files (user's content files and Fedora-specific RDF files) are detailed later in this document.
Atomic Resources
An atomic resource is either a single binary or a single container that maps to its own OCFL object. Below is a comparison between a plain OCFL representation of a single item object and Fedora's atomic resource representation.
Single-binary OCFL Object
The following OCFL Object has a single version, which holds a single binary: "image.tiff":
located in the "content/" section of the OCFL object. The last category of files (Fedora-specific JSON "header" files) are located in a sub-directory of the "content/" section of the OCFL object, named ".fcrepo/".
The full contents and format of the JSON "header" files, and Fedora-specific RDF files are detailed in the Specification of Fedora-specific OCFL Files section of this document.
Atomic Resources
An atomic resource is either a single binary or a single container that maps to its own OCFL object. Below is a comparison between a plain OCFL representation of a single item object and Fedora's atomic resource representation.
Single-binary OCFL Object
The following OCFL Object has a single version, which holds a single binary: "image.tiff":
| No Formatnoformat |
|---|
[object root]
├── 0=ocfl_object_1.0
├── inventory.json
├── inventory.json.sha512
└── v1/
├── inventory.json
├── inventory.json.sha512
└── content/
└── image.tiff |
...
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.
Naming conventions
System content (located in the ".fcrepo/" directory)
- The binary: 's header file: the filename is always "fcr-root.json". This allows Fedora to find the header file without knowing if the resource is a binary, container or archival group.
- The binary description's header file: the filename is always "fcr-root~fcr-desc.json".
- The binary ACL's header file: the filename is always "fcr-root~fcr-acl.json".
User content
- The binary: the filename provided during ingest of the binary is retained in the OCFL persistence. ("image.tiff 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 ACLdescription: the filename is the name of the binary with the addition of the suffix, "~fcr-acldesc.nt". ("image.tiff~fcr-acldesc.nt", in this example)
- The binary's header fileACL: 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 binary description's header file: the filename is always "fcr-root~fcr-desc.json".
- The binary ACL's header file: the filename is always "fcr-root~fcr-acl.json".the name of the binary with the addition of the suffix, "~fcr-acl.nt". ("image.tiff~fcr-acl.nt", 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 container. See description below.
│ └── fcr-root~fcr-acl.json <-- Optional, only present if this Fedora resource has its own ACL.
├── fcr-container.nt <-- Required 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
...
System content (located in the ".fcrepo/" directory)
- The container's ACLheader file: the filename is always "fcr-container~fcr-aclroot.nt".The container's header file: the filename is always "fcr-root.json". This allows Fedora json". This allows Fedora to find the header file without know knowing 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".
Archival Group Resources
User content
- The container user-properties: the filename is always "fcr-container.nt".
- The container's ACL: the filename is always "fcr-container~fcr-acl.nt".
Archival Group Resources
A Fedora archival group resource is container that contains a potentially nested hierarchy of zero or more children containers and/or binaries. Below is A Fedora archival group resource is container that contains a potentially nested hierarchy of zero or more children containers and/or binaries. Below is a comparison between a plain OCFL representation of a compound object and Fedora's archival group resource representation.
...
| 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 archival group.
│ ├── fcr-root~fcr-acl.json <-- Optional, only present if this Fedora resource has its own ACL.
│ ├── image.tiff.json <-- Required "header" file holding system metadata about the binary.
│ ├── image.tiff~fcr-desc.json <-- Required "header" file holding system metadata about the binary's description.
│ ├── image.tiff~fcr-acl.json <-- Optional, only present if this Fedora resource has its own ACL.
│ ├── foo.json <-- Required "header" file holding system metadata about the nested container.
│ ├── foo~fcr-acl.json <-- Optional, only present if this Fedora resource has its own ACL.
│ └── foo/ <-- Required nested structure within .fcrepo/ mirrors content structure
│ ├── bar.xml.json <-- Required "header" file holding system metadata about the binary.
│ ├── bar.xml~fcr-desc.json <-- Required "header" file holding system metadata about the binary's description.
│ └── bar.xml~fcr-acl.json <-- Optional, only present if this Fedora resource has its own ACL.
├── fcr-container.nt <-- Required file for holding user-properties describing the archival group container.
├── fcr-container~fcr-acl.nt <-- Optional, only present if this Fedora resource has its own ACL.
├── image.tiff
├── image.tiff~fcr-desc.nt <-- Required "binary description".
├── image.tiff~fcr-acl.nt <-- Optional, only present if this Fedora resource has its own ACL.
└── foo/
├── fcr-container.nt <-- Required file for holding user-properties describing the archival part container.
├── fcr-container~fcr-acl.nt <-- Optional, only present if this Fedora resource has its own ACL.
├── bar.xml
├── bar.xml~fcr-desc.nt <-- Required "binary description".
└── bar.xml~fcr-acl.nt <-- Optional, only present if this Fedora resource has its own ACL. |
Naming conventions
------------------------------>> start here
System content (located in the ".fcrepo/" directory)
- The archival group container's header file
- The container user-properties: the filename is always "fcr-container.nt".
- The container's ACL: the filename is always "fcr-container~fcr-aclroot.nt".The container's header file: the filename is always "fcr-root.json". This allows Fedora to json". This allows Fedora to find the header file without know knowing if the resource is a binary, container or archival group.
- The archival group container ACL's header file: the filename is always "fcr-root~fcr-acl.json".
- The binary archival part container's header file: the filename provided during ingest of the binary is retained in the OCFL persistenceis the name of the archival part container with the addition of the ".json". ("imagefoo.tiffjson" , in this example)
- The binaryarchival part container ACL's descriptionheader file: the the filename is the is the name of the binary the archival part container with the addition of the suffix, "~fcr-descacl.ntjson". ("image.tiff~fcrfoo~fcr-descacl.ntjson" , in this example)
- The binary's ACLheader file: the filename is the name of the binary with the addition of the suffix, "~fcr-acl.ntjson" extension. ("image.tiff~fcr-acl.nt", .tiff.json" and "foo/bar.xml.json" in this example)
- The binary description'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 filename is the name of the binary with the addition of the suffix, "~fcr-desc.json" extension. ("image.tiff~fcr-desc.json" and "foo/bar.xml~fcr-desc.json" in this example)
- The binary ACLThe binary description's header file: the filename is always "fcr-root~fcr-descfilename is the name of the binary with the addition of the suffix, "~fcr-acl.json" .The binary ACL's header file: the filename is always "fcr-root~fcr-acl.json"extension. ("image.tiff~fcr-acl.json" and "foo/bar.xml~fcr-acl.json" in this example)
User content
- The archival group container user-properties and sub-container user-properties: the filename is always "fcr-container.nt".
- The archival group container's ACL and sub-container's ACL: the filename is always "fcr-container~fcr-acl.nt".
- The binary: the filename provided during ingest of the archival part binary is retained in the OCFL persistence. ("image.tiff" and "foo/bar.xml" 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" and "foo/bar.xml~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" and "foo/bar.xml~fcr-acl.nt" in this example)
- The sub-container(s): the filename provided during ingest of the archival part container is retained in the OCFL persistence. ("foo/" in this example)
Storage Hierarchy Layout
The content that Fedora persists (user and system files) is a complete representation of the repository. These files are written to OCFL objects within a top-level storage hierarchy. This section describes the storage hierarchy layout and the algorithm for mapping an OCFL object identifier to its storage hierarchy path.
...
Specification of Fedora-specific OCFL Files
...