A Vocabulary for Content Models and Services

aggregation

a group of digital objects sharing some common characteristic(s) and having a declared semantic relationship (see RELS-EXT)

aggregation object

A Fedora digital object which acts as the 'parent' for a collection of digital objects. One use of an aggregation object is to define a collection of other objects.

atomisitc content model

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.

behaviour contract

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.

behaviour definition (BDef)

This is now call the service definition or SDef. See below.

behaviour mechanism (BMech)

This is now call the service deployment or SDep. See below.

bind / binding

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.

Content Model Dissemination Architecture (CMDA)

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.

content model

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.

data contract

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.

datastream

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.

disseminator

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.

external datastream

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

managed datastream

A datastream whose content, either data or metadata, is stored internally within the Fedora repository.

object model

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

object properties

a set of system-defined descriptive properties that are necessary to manage and track a digital object in the repository

ownerID

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.

FOXML

Fedora Object XML (FOXML) is a simple XML format that directly expresses the Fedora Object Model.

Persistent identifier (PID)

A persistent, unique identifier for a digital object. A PID may be user-defined or automatically defined by a repository

RDF

The Resource Description Framework. RDF is used to express relationships as "subject predicate object", where the predicate is the expression of a specific type of relationship that the subject asserts to the object. If Fedora, the subject is usually the PID of an object, while the object may be the PID of another object or a literal that is used to assert a metadata assribute for the subject.

redirected datastream

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

RELS-EXT

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.

RELS-INT

resource index

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.

service definition (SDef)

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 sdef object formally defines the terms of a behavior contract that must be upheld by a service deployment (sdep). A content model subscribes to a set of behaviors by linking to a sdef object and pairing it with a link to an appropriate service deployment (sdep) 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).

service deployment
(SDep)

A content model subscribes to a set of behaviors by linking to a sdef object and pairing it with a link to an appropriate service deployment (sdep) object that can enact the behaviors using mechanisms that are appropriate for the datastreams in the content model. One sdef object can be paired with different sdep objects for different content models. The sdep objects paired with the same sdef object differ in the type of underlying code mechanisms that it includes. The sdep 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 service definition may specify passing a jpeg file of a certain size to the browser. If the content model specifies Mr.Sid datastreams, the service deployment 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 service deployment is one that transforms the JP2K file into the desired jpeg. In both cases the content model is linked to the same sertvice definition, but links to a different service deployment as appropriate for the datastreams in the content model.

Uniform Resource Identifier (URI)

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)

versioning

XACML