ESciDoc Content Models

UNDER CONSTRUCTION

Definition and scope

Content model (CModel) is a formal representation of set of structural, integrity, behavior rules associated with content resources managed in an eSciDoc repository.

• in eSciDoc content resources are categorized in several primary types: Item, Container, Context, OrganizationalUnit etc.
• in eSciDoc the CModel scope is at the moment limited to resources of primary type Item or Container.

Note: The primary types are subject to extension in eSciDoc.

eSciDoc Primary types

• are complex data structures holding the content resources of an eSciDoc repository and managed via respective resource handler i.e. ItemHandler, ContainerHandler, OrganizationalUnits Handler etc.)
• represent the highest level of generalization of eSciDoc resources (i.e. Organizational Units, Contexts, Items, Containers, Users, etc.)
• may be further specialized by use of a CModel definition

Note: at present only Items and Containers are subject to CModel specialization

What cModel defines

Each CModel is itself a resource in a eSciDoc content repository and as such should have some common properties (applicable for all resources in the repository). Note: at present there is not yet a namespace for common properties of all resources. Once this is done, the properties will become native part of each CModel resource as well .

Each CModel defines the following for respective content resources (Items, Containers) associated with it:

Metadata profile (optional?)

• A reference to a metadata profile with which a content resource can be described
• example: publication metadata profile can be associated to CModel:PubItem, CModel:FacesCollection etc.
• To clarify: if there are more than single metadata profile applicable to a resource of a specific CModel

CModel specific object properties (optional)

• are described with property-name, property-type, multiplicity
• are additional properties (beside common properties) that can be associated with a resource of specific CModel
• usually are defined by the owner of the CModel to express some specifics that are not covered by the CModel definition

Composites (optional)

Defines category, multiplicity and format of content components which can be associated with a resource of specific CModel

Note: in eSciDoc at present composites can be defined only for Items

Aggregation (optional)

Specifies which resources can be aggregated within a resource of a primary type Container

Note: in eSciDoc at present aggregation can be defined only for Containers

System settings (mandatory)

Each CModel definition has some internal system (eSciDoc) settings (necessary for the handling of resources via the respective resource handlers e.g. during execution of some resource handler methods). The following are system internal settings that can be defined on a CModel level:

Versioning

eSciDoc supports the possibility to have the resource level versioning and no versioning at all for a resource.

Note: as eSciDoc repository is based on Fedora Digital Objects Repository the versioning is provided as "native" functionality of Fedora. However, Fedora enables component-level versioning (see more at Fedora versioning mechanism) which is not sufficient for an eSciDoc content resource because:

• eSciDoc content resources have multiple components
• eSciDoc content resources may comprise a "graph" of many Fedora digital objects

Under consideration=

• publishing-method: todo
• pid-assignment-method: todo
• withdrawal-method: todo
• relations: todo (probably not necessary in content model definition)

Enhanced Scientific Documentation

Flexible Extensible Digital Object Repository Architecture