Page History

...

• 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 23.1.10, 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).using CModel objects. For more information see "Content Model Architecture ."

They 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.

...