A vocabulary for content models and disseminators

Members of the Working Group have established a list of terms that we need agreed definitions for if we are consistently to describe content models and disseminators. The list is below; such definitions as have been provided are drafts and others are to follow shortly.

If you have suggestions for additional items please mailto.r.greenathull.ac.uk mail Richard Green - do not add them in here where we might not notice!

<dl>

<dt>atomistic content model
<dd>An approach to content models where there are content models for 'works' and for each of their component media objects. In such a model, work objects have "parent" relationships to atomistic media objects. Media objects must have at least one parent work object to provide context, but can be atomistic child components of many works. In this approach, there are potentially many media content models that vary by format type, datastream configurations, and functional requirements. There are fewer types of work content models, because the content model only presents the work and does not need to take into account the variability of component datastreams. The component datastreams are represented by the media object content models.

A work content model represents a single physical object (such as a volume of text, a dataset, or an episode of a television program), or a logical concept (such as an architectural or archaeological site, or a work of art). The datastreams for such a content model include descriptive and administrative metadata, and work-level content such as text transcriptions or finding aid collection descriptions.

A media content model represent parts of a work (such as individual page images, views of a site or work of art, component videos or b-reels from a television episode). The datastreams include descriptive and administrative metadata, one or more deliverable files (such as thumbnail, screen-sized, and large images), and possibly the master file for generating the deliverables.
<dt>behaviour contract
<dd>A behavior contract exists between behaviour definition (bdef) and behavior mechanism (bmech) objects. A content model subscribes to a set of behaviors by linking to a bdef object and pairing it with a link to an appropriate behaviour mechanism (bmech) object that can enact the behaviors using mechanisms that are appropriate for the types of datastreams in the content model. The behavior contract is the binding between the bdef and the bmech, where the bmech must be able to appropriately execute the behaviors defined in the bdef.
<dt>behaviour definition (BDef)
<dd>A defined set of one or more abstract behaviors that constrains a corresponding set of processes (or mechanisms) delivering the behavior described for a given object. A bdef object formally defines the terms of a behavior contract that must be upheld by a behaviour mechanism (bmech). A content model subscribes to a set of behaviors by linking to a bdef object and pairing it with a link to an appropriate behaviour mechanism (bmech) object. One bdef object can be paired with different bmech objects for different content models. Examples of behaviour definitions can be getXML (get the raw content XML from an object), getPreview (get a specific image object datastream), viewDC (return styled Dublin Core metadata), or getSizedImagepixelX, pixelY (get an image meeting size parameters specified as part of the request).
<dt>behaviour mechanism (BMech)
<dd>A content model subscribes to a set of behaviors by linking to a bdef object and pairing it with a link to an appropriate behaviour mechanism (bmech) object that can enact the behaviors using mechanisms that are appropriate for the datastreams in the content model. One bdef object can be paired with different bmech objects for different content models. The bmech objects paired with the same bdef object differ in the type of underlying code mechanisms that it includes. The bmech has a data contract with the content model, where the objects assigned to that content model are expected to conform to that content model's requirements.

For example, a behaviour definition may specify passing a jpeg file of a certain size to the browser. If the content model specifies Mr.Sid datastreams, the behaviour mechanism is one that transforms the Mr.Sid file into the desired jpeg to pass to the browser. For a content model that specifies JPEG2000 datastreams, the behaviour mechanism is one that transforms the JP2K file into the desired jpeg. In both cases the content model is linked to the same behaviour definition, but links to a different behaviour mechanism as appropriate for the datastreams in the content model.
<dt>bind / binding
<dd>
<dt>bytestream content
<dd>The deliverable of a datastream. This can be a physical file contained or referenced by a datastream, or the results of an action performed on a datastream through a dissemination. As examples, bytestream content might be a file that is in the datastream, or a PDF created on-the-fly from an XML file that is in the datastream.
<dt>collection
<dd>a group of digital objects sharing some common characteristic(s) and having a declared semantic relationship (see RELS-EXT)
<dt>collection object
<dd>A Fedora digital object which acts as the 'parent' for a collection of digital objects. AKA an 'aggregation object.'
<dt>Content Model Dissemination Architecture (CMDA)
<dd>The proposed Content Model Dissemination Architecture is intended to provide a looser binding of disseminators to digital objects by building disseminators around the notion of 'content models.' A pre-requisite for this strategy is the formalization of content models, and the registration of such content models as special Fedora digital objects known as Content Model (CModel) objects. A CModel object will hold the specifications about the number and types of datastreams that must exist in any 'conforming' digital object. In versions through 2.11, objects could have disseminators directly linked to them. In the proposed CMDA, objects will not carry their own disseminators. Instead, the objects will associated with a CModel object from which it will acquire compatible services. The looser binding will make it easier to update Bdefs and Bmechs, and the formalization of the content models will make it easier to validate the configuration of datastreams in objects against the model configurations.
<dt>complex (digital) object
<dd>
<dt>compound content model
<dd>
<dt>compound (digital) object
<dd>
<dt>content model
<dd>Content models represent classes of objects at various levels of atomicity, from individual media objects to aggregations of content. A content model describes 1) datastream composition, including numbers and kinds of files that make up an object, the formats for those files, where the files are required or optional, if the datastreams have cardinality constraints, and what kind of semantic identifiers are used for each datastream; 2) relationships to other content models, such as parent/child relationships between models; and 3) optional linkages to behaviors, if used.
<dt>control object
<dd>
<dt>data contract
<dd>A behavior mechanism us used to execute behaviors defined in behavior definitions. Behavior mechanisms are designed to work with specific content models, geared toward the configuration of datastreams defined for those content models. A bmech is said to have a data contract with the content model that it is linked to, because the objects assigned to that content model must provide the datastreams expected by the bmech to execute the required behaviors. For example, a behavior might be getTEIHeader. The mechanism must find a TEI file to be properly executed, so has a data contract with a TEI content model that requires a TEI datastream as part of its composition.
<dt>datastream
<dd>The component in a Fedora object that represents the MIME-typed content item. An object can have one or more datastreams. The content of a datastream can be either data or metadata, and this content can be stored internally in the Fedora repository, or stored remotely (in which case Fedora holds a pointer to the content in the form of a URL). Every object has one Dublin Core metadata datastream by default.
<dt>digital object (see also complex object and compound object)
<dd>
<dt>digital object graph
<dd>
<dt>digital payload
<dd>(see bytestream content)
<dt>disseminator
<dd>The (optional) component in a Fedora object that associates an external service with the object for the purpose of providing extensible views of the object or its datastream content. An object can have zero or more disseminators.
<dt>Dublin Core metadata
<dd>
<dt>element
<dd>(see DC, FOXML, metadata, xml etc)
<dt>external datastream
<dd>A datastream whose content, either data or metadata, is stored external to the Fedora repository and referenced by a URI. A user will be unaware that this data is not held within the repository
<dt>FOXML
<dd>Fedora Object XML (FOXML) is a simple XML format that directly expresses the Fedora Object Model
<dt>graph
<dd>see 'digital object graph' above
<dt>managed datastream
<dd>A datastream whose content, either data or metadata, is stored internally within the Fedora repository
<dt>metadata
<dd>(see also Dublin Core)
<dt>MIME type
<dd>
<dt>network of objects
<dd>
<dt>object model
<dd>the Fedora digital object model can be used to express many kinds of complex objects including documents, images, learning objects and many more. The Fedora object model also allows the assertion of relationships among objects to represent items in a collection
<dt>object properties
<dd>a set of system-defined descriptive properties that are necessary to manage and track a digital object in the repository
<dt>ownerID
<dd>a property of a Fedora digital object which identifies the 'owner' of the object for security purposes. At present an object can have only a single owner though it is hoped that future versions of Fedora will support multiple, simultaneous owners.
<dt>Persistent identifier (PID)
<dd>A persistent, unique identifier for a digital object. A PID may be user-defined or automatically defined by a repository
<dt>RDF
<dd>
<dt>redirected datastream
<dd>A datastream whose content, usually data but possibly metadata, is stored external to the Fedora repository. When the datastream content is called, Fedora transparently redirects to retrieve it from its source. A redirected datastream is used where, for instance, the digital content referenced requires special services such as multimedia streaming
<dt>RELS-EXT
<dd>Object-to-object relationships within a Fedora repository are stored as metadata within a special datastream, RELS-EXT (relationships-external). Each digital object may have zero or one RELS-EXT datastreams.
<dt>RELS-INT
<dd>
<dt>resource index
<dd>A service that provides the infrastructure for expressing relationships among objects and their components. The Resource Index Search interface is exposed in a REST architectural style, providing a stateless query interface that accepts queries by value or by reference. It provides a unified graph of all the objects in the repository and their relationships with each other.
<dt>Uniform Resource Identifier (URI)
<dd>a Uniform Resource Identifier (URI), is a compact string of characters used to identify or name an internet resource. The contemporary point of view among the working group that oversees URIs is that the terms URL and URN are context-dependent aspects of URIs, and rarely need to be distinguished. However, in nontechnical contexts and in software for the World Wide Web, the term URL remains ubiquitous. Additionally, the term web address, which has no formal definition, is often used in nontechnical publications as a synonym for URL or URI. (Adapted from Wikipedia)
<dt>version
<dd>(in the context of a datastream)
<dt>XACML
<dd>
<dt>XML
<dd>(see also FOXML)
<dt>XML datastream
<dd>

</dl>