File Organization

Content in the OLRC is organized using Domains, Projects and Containers.

A diagram that shows how content is structed in OLRC 2.0. The top level is the domain, which contains projects, which have containers, which have files.


Every partner member has access to one domain, and members will only have access to their own domain. A domain will have a domain administrator, who can create users, projects, and manage permissions under that domain.


A project is a grouping of containers. A domain must contain at least one project, but can contain multiple projects.

Managing access to your content is most easily managed at the project-level. You can assign permissions to users on projects. For example, you could have a project called “preservation” to which only preservation staff have access, and another called “scanning” to which only your book scanning staff have access. Users will have access to all containers within their respective project(s). You can also specify whether a user should have admin, read/write (member) or read-only (reader) privileges. See the Administrator’s Guide for more information.

In Horizon, your current project will be shown in the top left corner.

When using the Swift CLI, your project variable will be OS_PROJECT_NAME.

If you need to delete a project, contact the Scholars Portal team. This feature has been disabled to prevent data from being “stranded” (data with no ownership attached).


Containers are a grouping of objects (files). By default, a user that has permissions on a project will have access to all containers within that project. However, it is possible to further restrict access to individual containers using Access Control Lists (ACLs) but these are more complex to manage. If you need assistance with this, please do ask.

It is also possible to make a container public.


Object storage does not work the same way as a traditional, hierarchical file system, and therefore, there is no concept of folders in Swift.

That said, clients that interact with object storage almost always “fake” the hierarchical concept, by making the name of the object the same as its original path.

Imagine I have a file on my laptop at:


If I were to upload this file using the Swift CLI…

swift upload container-name mystuff/folder1/folder2/movie.mp4

… Swift would NOT create a “mystuff” folder, and then create a “folder1” folder within it, and so on. It simply creates a single object called “mystuff/folder1/folder2/movie.mp4”.

Clients that interact with the storage are then typically able to parse the path, and present it to you as though it were a hierarchical file structure. This concept is know as “pseudo folders”.