See also: Formalizing Content Models (ppt)

An important part of implementing a Fedora repository is modeling different classes or "genre" of digital object that will be created, stored, and managed in the repository. Whether the repository will store images, articles, books, journals, electronic records, or other entities, it is essential that an institution analyze its content, and design Fedora digital objects with care.

In Fedora, the term "content model" refers to a data model or a profile for a particular "genre" of digital object. The content model will typically describe the following:

• datastream composition
  • the number and kinds of datastreams that must be present in the digital object
  • the format(s) for those datastreams, either MIME or format identifiers
  • whether each kind of datastream is required or optional
  • whether each kind of datastream has cardinality contraints (how many of each kind)
  • semantic identifiers for each kind of datastream
• relationships
  • in the cases where a content model is a "graph" of related content models
  • parent content model has required relationships to child content models
    • example: journal <hasIssue> issue
    • example: issue <hasArticle> article
• behaviors (optional)
  • the types of behaviors (via Fedora BDef/BMech) that must be associated with the digital object

As of Fedora 2.1.1, content model definitions are not formalized in the Fedora system. As best practice, institutions define their content models outside of Fedora and establish an unique identifier for each content model. These identifiers can be used to classify Fedora digital objects (via the content model property defined in the FOXML schema for digital objects). Institutions typically maintain specifications about their content models outside of the Fedora repository system (in UML, in textual documents, in XML using their own definitional schemas).

Content models will be formalized in upcoming releases of Fedora. Currently, the Fedora development team, in collaboration with the Fedora community, is developing a "content model definition language" so that content models can be formalized. Once content models are able to be expressed in a formal manner, they can be used to enable object creation, object validation, service binding, and more. Specifications are under way to introduce an xml-based way to express content model specifications, rules, and constraints. These definitions can be stored in special "content model objects" that can be ingested into Fedora repositories (like BDef and BMech objects). Storing such content model objects is a way to register content model specifications in a Fedora repository. The formalization and registration of content models will be a first step to better enabling advanced object validation, new ways of binding services to objects, and more.

Uses of Content Models

• Object Typing:
  • Group identity for different kinds of objects
  • Facilitates discovery via query/search
• Object Validation
  • At ingest, check that object conforms to a model
  • At modification, make sure changes don't break conformance to model
• Object Creation
  • Templates for user interfaces enabling object creation
  • Drive workflows/creation of "batches" of like objects
  • Hooks for policy enforcement
• Service Binding (Behaviors)
  • http__--www.cs.cornell.edu-payette-fedora-designs-cmda- Proposal__ Content Model Dissemination Architecture
• Community Sharing
  • institutions can publish their content models in a standard way