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

Components (optional)

Defines content category, multiplicity and format of content components (i.e. files) which can be associated with a resource of specific CModel.

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

Aggregation (optional)

• Specifies which resources (i.e. members) can be aggregated within a resource of a primary type Container e.g. container resource with CModel "FacesCollection" can aggregate item resources with CModel "FaceItem", container resource with CModel "FachBeiratReport" can aggregate any eSciDoc or non-eSciDoc resources
• Specifies how certain operations (i.e. submit, release, withdraw) on a container resource of this CModel affects the members of the container resource
• A resource of primary type Container may aggregate any number of other resources of primary type Container or Item
• The aggregation can be specified for resources of specific CModel or of any CModel (i.e. resource of type BestOfCollection can aggregate any other resources).

Restrictions:

• In case when a CModel of a primary type Container in its aggregation allows resources that themselves are of primary type Container, the system (i.e. respective resource handler) must take care that a resource does not aggregate itself (i.e. recursive aggregations are not allowed)
• CModel aggregation can define only the direct members of the container resource (i.e. if one of the members is a container, then its internal aggregation should be defined (if needed) in a separate CModel.

Note: in eSciDoc aggregation can be defined only for Containers

Aggregations and internal life-cycle of resources

eSciDoc repository defines an internal life-cycle for its content resources of type Item, Container. CModel allows to define how the internal workflow can be applied to the members of a container of that CModel.

In general, eSciDoc internal workflow is represented with the following table:

---

Stage	Action	Status	Description
Initial	create	pending	A resource is created and is in status "pending". A resource can be further updated, deleted or transferred to the next stage in the life-cycle.
Submission/QualityAssurance	submit	submitted	The resource is in "submission" stage. While in this stage the resource can not be deleted. It can be transferred to a "Release" stage or to Initial state again.
Release	release	released	The resource is released and becomes a valid resource in the repository, thus available for discovery, subject to preservation etc. From this stage the resource can only be transferred to the withdrawn state in exceptional situation
Withdrawal	withdraw	withdrawn	The resource is withdrawn and is no longer available for public use.
edit table

---

The following Aggregation settings applicable to the internal eSciDoc life-cycle are allowed in a CModel definition:

Release-rule

The table below depicts how the release action from the internal workflow is applied to the container and the container members:

value	container release	member release	container release success	member release success
required	yes	yes	must	must
tried	yes	yes	must	optional
none	yes	no	must	no
edit table

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-info

Possible values for this properties are: WOV, none.

eSciDoc supports versioned resources and non-versioned resources. Default setting is "versioned resources" (this mechanism is technically named WOV - Whole Object Versioning).

When a versioning information is specified on CModel level it actually gives the end user better fine-grained control on exactly how she would like to version the resources of specific CModel (i.e. PublicationItems should be versioned with every update operation, but e.g. FaceItems should not be versioned at all).

Note: as eSciDoc repository is based on Fedora Digital Objects Repository the versioning is provided as "native" functionality of Fedora (see more at Fedora versioning mechanism). However, Fedora versioning native versioning mechanism is not sufficient for an eSciDoc content resources due to:

• eSciDoc content resource version can be result out of a single update action on multiple components of a single resource
• eSciDoc content resources may comprise a "graph" of many Fedora digital objects

Primary-type

The primary type (or the category) of the content resources depicted with the CModel. At present this is an information which only allows CModel to be defined for Items or Containers, therefore allowed values are:

• Item
• Container

Enhanced Scientific Documentation

Flexible Extensible Digital Object Repository Architecture