don't call it a CONTENT MODEL

There are at least four different potential meanings to "Content Models", which has the potential to create confusion and ambiguity when it comes to content modelling discussions.

1. "content types", like books or ETDs, that users want to manage with a repository
2. Ruby models (the "M" in MVC) that are integral to Hydra
3. Fedora content models (now content model architecture in Fedora 3.x)
4. Atomistic v. compound content modelling strategies in Fedora

1. Content types
Definition: a type of digital object that Hydra and a repository should support. This includes both general content types (e.g., ETD's, archival images, articles) and specific implementations of those content types (e.g. Stanford ETDs, UVa images, Hydrangea articles).

This is also includes the notion of content type primitives, which are single, (near-) universal content types which may either stand-alone or be incorporated into higher order content types (in a book or ETD, e.g.).

• Image
  • static image
  • JPEG2000
• Moving Image
• Audio
• File asset (aka downloadable, aka blob, aka file, aka "other"--was "generic content")

2. Ruby Models
These content types are realized in Ruby on Rails code, aka the "M" in Ruby's MVC structure

• Ruby "models" – which decleares the data streams, metadata, custom methods in Ruby on Rails
• Blacklight (Rails views) and object-specific views
• Rails controllers to extend the Hydra REST API

... must explain
* where active-fedora models fit in
* primitives

3. Fedora content model architecture
Fedora content models, realized in the Fedora CMA (Content Model Architecture) as of Fedora 3.x, is a...

It comprises:

• cModel (declaring the structure)
  • data streams
  • metadata schema
  • relationships

• sDef (declaring the behavior of a service)
  • list of methods (interface)

• sDep (a specific implementation of a service)
  • implement sDef methods for a given cModel

4. Atomistic v. Compound Content Modelling Strategies

The Fedora community has identified three prominent content modelling patterns--simple, compound and atomistic. These are general strategies for modeling objects in Fedora, supported by Fedora cModels. For the purpose of Hydra end users and content contributors, these strategies are invisible, and abstracted away from the UI via the Fedora REST API, which sits below the Hydra Ruby model, which is manipulated by Hydra Ruby controllers, which communicate via the Hydra REST API with Hydra Ruby views.

The Hydra / Fedora stack is...

Hydra view
---- Hydra REST API ---
Hydra controller – figure out what to do
Hydra model – define content types
----Fedora REST API ---
Fedora Object
-> Fedora cModel
-> sDep
-> Fedora sDef

Note that solrizer leverages the Hydra models. If you don't have a Hydra model, the best way to use solrizer is to write a model or find an existing one (neither of which is overly technically challenging).

Note that disseminators are a shorthand for Fedora sDef with a sDep against a cModel.

Ruby Code or Fedora Disseminator?
We expect some functionality may migrate from Hydra code to Fedora disseminators over the course of time.

A function may best be coded in Ruby if it...

• traverses many objects, many relationships
• is very complex
• is immature--and may need more time to mature
• is more readily addressed by ruby code to start with

A function may best be coded as a Fedora disseminator if it is...

• simple web service that might move out of Fedora
• primitive, universal function, such as support for content type primitives (e.g., image)
• is more readily addressed by a Fedora-savvy developer

Whiteboard Notes from 11/6/10 Discussion on Hydra Models, cModels, Disseminators and Hydra Services