It is important to note that there is no one way, nor right way to model resources in Fedora. Different approaches will be more appropriate in different circumstances, and they all come with trade-offs.

This guide represents a starting point for thinking about modeling content in Fedora.

Scenario

We want to store a book in Fedora:

• Each page of the book is a single PDF
• The book's thumbnail is a single JPEG
• A METS description is a single XML document

Structure

Fedora resources can be structured physically or logically. Generally speaking, the repository will be more performant if resources are structured logically, given the increasing performance impact with the increasing number of *direct* children of a shared parent resource. In other words, if a parent resource ("book") has a thousand pages, and each of those pages were structured within Fedora as direct children of "book", that would probably impose negligible performance impact. However, if "book" had 10,000 children pages, then the creation of subsequent pages would likely be noticeably slower.

On the other hand, certain repository operations (e.g. authorization, move, export) are able to act over a tree of resources. For example, authorization policies can be defined to apply to all sub-resources within a tree of resources to the point until a descendant within the hierarchy overwrites the ancestor's policy.

Therefore, in some situations where the repository size is expected to be small and nested resources would be useful, it is possible that creating structural hierarchies could be advantageous.

Identifiers

Properties

Relationships