See also: Fedora Metadata Storage Philosophy, Current Behavior Implementations

Content models and asset actions are defined at slightly different levels. Asset actions are defined to promote interoperability between institutions and between types of repositories. A content model represents a particular type of object that is useful for a particular Fedora repository. A content model ensures that objects within the repository behave consistently; it may or may not be useful at other institutions. There should be a simple mapping between asset actions and content models, but this mapping depends on the actual content models used in a repository. Even though there will be differences between content models, it is worthwhile to share them. It is likely that some content models can be synchronized between institutions.

General principles for content models

Available content models

Standard disseminators apply to most objects.

Type-specific content models:

Resource Index relationships

All item-level objects will have a relationship in the Resource Index that ties the item to a collection object. It is possible for an item to be a member of multiple collections, with the PURL providing the indication of the "primary" collection. No other relationships are necessary for non-hierarchical items.

Notes about storage of media

We will let Fedora manage all of our datastreams unless there is a compelling reason to do otherwise. Managed content is the best way to take advantage of Fedora's versioning capabilities. Managed content also reduces the amount of work in tracking multiple files that represent the same item (page images and transcriptions, various sizes of photographs).

XML data will always be stored as managed content (M) rather than internal XML content (X). This will give us better long-term performance when making many changes to a document.

Master media files present a complication. In general, we will be unable to store master files directly in the repository, so they cannot be managed content. We will store master copies in HPSS and have metadata in Fedora that points to them. We are investigating methods (like SRB) to make this more transparent to Fedora.

Whenever possible, write your interfaces in terms of the disseminators instead of the datastreams. This will make the entire system more modular. Datastreams may change to suit the needs of the objects, but disseminators will remain relatively constant. In the future, it may be useful to write XACML policies keeping datastreams "private", but we have not resorted to this level of control yet.

Utility objects

We will use the "util" namespace in Fedora to store objects that can be used across collections. For example, util:DC-XSL contains XSL transforms that can be applied to DC records to produce simple results.

Dealing with non-digitized items

Sometimes, we want to store objects in the repository that have not been digitized. This can happen when:

There are two ways to handle cases like these:

  1. Implement only disseminators the object truly supports, and force all code that uses an object to check for its capabilities.
  2. Implement the "Null Object" pattern, creating disseminators that implement the same behavior methods as digitized objects, but don't actually do anything useful in response to these methods.

We will take the first approach. This has the disadvantage of making external applications/stylesheets responsible for checking that an object supports requested behavior, but there are several advantages over Null Objects:

There are exceptions to this approach. In the case of the Default disseminator, non-digitized objects will sometimes have to respond with "image not available" or the equivalent. There may be other cases in which we want to create cleaner code at the application level and introducing a Null Object is the best approach.