...
This guide represents a starting point for thinking about modeling content in Fedora.
Table of Contents
Scenario
We want to store a book in Fedora:
...
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.
REST Examples
Identifiers
The topic of identifiers overlaps somewhat with that of "Structure". In Fedora, you can have any number of identifiers stored as properties on a resource; however, the identifier by which a resource is retrieved is the location path at which the resource is stored within the repository. Therefore, if a resource is stored in the repository at the location: "<host>/<context>/rest/book/page0", then the external identifier of that resources is the same: "<host>/<context>/rest/book/page0".
That is both good and bad, from the perspectives of readable URLs as well as performance. Having an identifier that is semantically meaningful, clearly describing something about the nature of the resource (e.g. this resource is the first page of a specific book), can be nice at first. But invariably, the resource will either have to be relocated within the repository, or migrated to a different system, or in one way or another need to change the semantics that were embedded in its identifier.
The performance considerations (specifically for the case of adding new resources to the same parent) have been described above.
Generally speaking, within Fedora, opaque identifiers that hold no semantics should be favored over semantically meaningful identifiers. There are justifiable reasons for having structural hierarchies of resources in your repository, but having meaningful identifiers is likely not one of them.
REST Examples
Properties
REST Examples
Relationships
REST Examples