http://www.fedora.info/presentations/cmodel-intro.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 3.0, content model definitions formalized in the Fedora system using CModel objects. For more information see "Content Model Architecture ." They can be used to enable object creation, object validation, service binding, 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)
  • Community Sharing
    • institutions can publish their content models in a standard way
  • No labels