Difference between revisions of "ESciDoc Content Models"

From MPDLMediaWiki
Jump to navigation Jump to search
(edited by Natasab via TableEdit)
 
(62 intermediate revisions by 5 users not shown)
Line 1: Line 1:
'''''UNDER CONSTRUCTION'''''
== Definition and scope ==
== Definition and scope ==


Line 6: Line 5:
* in eSciDoc the CModel scope is at the moment limited to resources of primary type ''Item'' or ''Container''.
* 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.''
''Note: The primary types are subject to extension in eSciDoc e.g. to check if we would make the TOC separate primary type in accordance with last Workshop discussion'' --[[User:Natasab|Natasa]] 12:19, 10 November 2008 (UTC)


==eSciDoc Primary types==
==eSciDoc Primary types==
Line 14: Line 13:
*may be further specialized by use of a CModel definition  
*may be further specialized by use of a CModel definition  


''Note: at present  only Items and Containers are subject to CModel specialization''
''Note: at present  only Items and Containers are subject to CModel specialization, todo: check Relation resources''


== What cModel defines==
== 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'' .
[[Image:CModel.jpeg|eSciDoc Content Model structure]]


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


===Metadata profile (optional?)===
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).
*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)===
ESciDoc defines a common namespace for all properties applicable. See
*are described with property-name, property-type, multiplicity
*[http://www.escidoc-project.de/schemas/rest/common/0.4/properties.xsd Common properties schemas - REST]
*are additional properties (beside common properties) that can be associated with a resource of specific CModel
*[http://www.escidoc-project.de/schemas/soap/common/0.4/properties.xsd Common properties schemas - SOAP]
 
===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 [http://www.fedora.info/download/2.2.1/userdocs/server/features/versioning.html 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. Allowed values are:
*Item
*Container
*TOC
 
====Metadata profiles====
*A reference to metadata profile with which a content resource can be described
**example: publication metadata profile can be associated to CModel:PubItem, CModel:FacesCollection etc.
*As resources can be described with multiple metadata profiles, one is specified as a default (see also [[ESciDoc_Metadata_Records_Manipulation]])
 
====Specific object properties (optional)====
*are described with name, datatype, multiplicity
*are additional properties (beside common properties of a resource) 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
*usually are defined by the owner of the CModel to express some specifics that are not covered by the CModel definition
====Content-stream====
*to precise if the resources of this Content Model have or not a content stream


===Components (optional)===
===Components (optional)===
Line 38: Line 69:
''Note: in eSciDoc at present components can be defined only for Items''
''Note: in eSciDoc at present components can be defined only for Items''


===Aggregation''' (optional)===
===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
*'''members''' - to specify which resources (i.e. of which CModel) can be aggregated within a resource of a primary type Container  
*Specifies how certain operations (i.e. submit, release, withdraw) on a container resource of this CModel affects the members of the container resource
**''parent-unique'' (true, false) - defines if member must have a unique parent of this CModel type or not '''to be discussed'''
*A resource of primary type Container may aggregate any number of other resources of primary type Container or Item
*'''rules(optional)''' - to specify how certain operations (i.e. submit, release, withdraw) on a container resource of this CModel affects the members of the container resource
*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).
*'''ordered''' (true, false)- to allow for ordering of members of the aggregation. Note: this is to be considered attribute of the aggregation to allow for adding members in "native" order at begining, end or middle of the list of members. This is not to be considered as a "table of contents" navigational order (that order may be different).
 
''Example 1:''
A 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
 


'''Restrictions:'''
'''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)
*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)
:: I would presume that as a question of exporting an object graph. Otherwise a deep inspection of all content models (! not neseccarily from the same solution) is needed adding a new content model or modifing an existing content model. Because the recursion may appear in a very deep level. E.g. C1->C2->C3->...->C9->C1 [[User:Frank|Frank]] 09:19, 17 March 2009 (UTC)
*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.
*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.


Line 77: Line 114:
----
----


The following Aggregation settings applicable to the internal eSciDoc life-cycle are allowed in a CModel definition:
The following Aggregation settings applicable to the internal eSciDoc life-cycle may be allowed in a CModel definition:
=====Submit-rule=====
 
The table below depicts how the submit action from the internal workflow is applied to the container and the container members:
 
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197564364-->
<!--*** PLEASE DON'T EDIT THIS TABLE DIRECTLY.  Use the edit table link under the table. ***  -->
{|{{Prettytable}} id='25' class = 'sortable'
|- bgcolor = #ccccff
!submit-rule!!container-submit!!members-submit!!container-submit-success!!members-submit-success
|-
|members-required||yes||yes||must||must
|-
|members-tried||yes||yes||must||optional
|-
|container (default)||yes||no||must||n/a
|-
|members-first||yes||no||must||n/a
|-class='sortbottom'
|colspan='5'|[{{SERVER}}/mediawiki/index.php/Special:TableEdit?id=9d918c381310dd472203b251d1a85892.630.1197564364&page=630&pagename={{FULLPAGENAMEE}} edit table]
|}
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197564364-->
 
=====Release-rule=====
=====Release-rule=====


Line 86: Line 145:
{|{{Prettytable}} id='23' class = 'sortable'
{|{{Prettytable}} id='23' class = 'sortable'
|- bgcolor = #ccccff
|- bgcolor = #ccccff
!release-rule!!container release!!member release!!container release success!!member release success
!release-rule!!container-release!!member-release!!container-release-success!!member-release-success
|-
|-
|required||yes||yes||must||must  
|members-required||yes||yes||must||must  
|-
|-
|tried||yes||yes||must||optional  
|members-tried||yes||yes||must||optional  
|-
|-
|none||yes||no||must||no  
|container (default)||yes||no||must||n/a
|-
|members-first||yes||no||must||n/a
|-class='sortbottom'
|-class='sortbottom'
|colspan='5'|[{{SERVER}}/mediawiki/index.php/Special:TableEdit?id=9d918c381310dd472203b251d1a85892.630.1197562483&page=630&pagename={{FULLPAGENAMEE}} edit table]
|colspan='5'|[{{SERVER}}/mediawiki/index.php/Special:TableEdit?id=9d918c381310dd472203b251d1a85892.630.1197562483&page=630&pagename={{FULLPAGENAMEE}} edit table]
Line 98: Line 159:
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197562483-->
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197562483-->


===System settings (mandatory)===
=====Withdraw-rule=====
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:
The table below depicts how the withdraw action from the internal workflow is applied to the container and the container members:


====Versioning-info====
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197563100-->
<!--*** PLEASE DON'T EDIT THIS TABLE DIRECTLY.  Use the edit table link under the table. ***  -->
{|{{Prettytable}} id='24' class = 'sortable'
|- bgcolor = #ccccff
!withdraw-rule!!container-withdraw!!member-withdraw!!container-withdraw-success!!member-withdraw-success
|-
|members-required||yes||yes||must||must
|-
|container (default)||yes||no||must||n/a
|-
|members-first||yes||no||must||n/a
|-class='sortbottom'
|colspan='5'|[{{SERVER}}/mediawiki/index.php/Special:TableEdit?id=9d918c381310dd472203b251d1a85892.630.1197563100&page=630&pagename={{FULLPAGENAMEE}} edit table]
|}
<!--box uid=9d918c381310dd472203b251d1a85892.630.1197563100-->


Possible values for this properties are: WOV, none.
=====Issues=====
Note: the rules depicted above are derived and extended based on some previous discussions within eSciDoc team and are based on current Container limitation: only resources of type Item and Container can be members of a Container.


eSciDoc supports versioned resources and non-versioned resources. Default setting is "versioned resources" (this mechanism is  technically named WOV - Whole Object Versioning).
*how rules that define cascading operations on members (members-required, members-tried rules) apply if members are containers themselves?
:: I would assume as if they are items. In case of members-required, a container-member must be submitted/released/withdrawn too and if it has an own members-required statement, the members of the container-member must be submitted/released/withdrawn too and ... . It might be to submit ( or release or withdraw) such a container will fail because of rules of container-members but the content model may require that behavior. [[User:Frank|Frank]] 10:13, 17 March 2009 (UTC)


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).
These rules should not be defined in a manner that they are preventing each other i.e. specifying member cascading rules for an aggregation should be allowed only in case the members of the aggregation are of type Items (and not Containers).


Note: as eSciDoc repository is based on Fedora Digital Objects Repository the versioning is provided as "native" functionality of Fedora (see more at [http://www.fedora.info/download/2.2.1/userdocs/server/features/versioning.html Fedora versioning mechanism]). However, Fedora versioning native versioning mechanism is not sufficient for an eSciDoc content resources due to:
:: I can not see how they can prevent each other. Obviously the rule of a container-member can effect the success of the action on the (parent-)container but that is a question of, releasing the complete object graph is required or should be tried. That depends on functional requirements!? [[User:Frank|Frank]] 10:13, 17 March 2009 (UTC)
*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====
===Implementation===


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:
*see [[ESciDoc_Content_Model_Object]]


*Item
[[Category:eSciDoc|Content Models]]
*Container
[[Category:Content Models|ESciDoc Content Models]]

Latest revision as of 10:13, 17 March 2009

Definition and scope[edit]

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 e.g. to check if we would make the TOC separate primary type in accordance with last Workshop discussion --Natasa 12:19, 10 November 2008 (UTC)

eSciDoc Primary types[edit]

  • 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, todo: check Relation resources

What cModel defines[edit]

eSciDoc Content Model structure

Common properties[edit]

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).

ESciDoc defines a common namespace for all properties applicable. See

System settings (mandatory)[edit]

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[edit]

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[edit]

The primary type (or the category) of the content resources depicted with the CModel. Allowed values are:

  • Item
  • Container
  • TOC

Metadata profiles[edit]

  • A reference to metadata profile with which a content resource can be described
    • example: publication metadata profile can be associated to CModel:PubItem, CModel:FacesCollection etc.
  • As resources can be described with multiple metadata profiles, one is specified as a default (see also ESciDoc_Metadata_Records_Manipulation)

Specific object properties (optional)[edit]

  • are described with name, datatype, multiplicity
  • are additional properties (beside common properties of a resource) 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

Content-stream[edit]

  • to precise if the resources of this Content Model have or not a content stream

Components (optional)[edit]

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)[edit]

  • members - to specify which resources (i.e. of which CModel) can be aggregated within a resource of a primary type Container
    • parent-unique (true, false) - defines if member must have a unique parent of this CModel type or not to be discussed
  • rules(optional) - to specify how certain operations (i.e. submit, release, withdraw) on a container resource of this CModel affects the members of the container resource
  • ordered (true, false)- to allow for ordering of members of the aggregation. Note: this is to be considered attribute of the aggregation to allow for adding members in "native" order at begining, end or middle of the list of members. This is not to be considered as a "table of contents" navigational order (that order may be different).

Example 1: A 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


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)
I would presume that as a question of exporting an object graph. Otherwise a deep inspection of all content models (! not neseccarily from the same solution) is needed adding a new content model or modifing an existing content model. Because the recursion may appear in a very deep level. E.g. C1->C2->C3->...->C9->C1 Frank 09:19, 17 March 2009 (UTC)
  • 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[edit]

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 may be allowed in a CModel definition:

Submit-rule[edit]

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

submit-rule container-submit members-submit container-submit-success members-submit-success
members-required yes yes must must
members-tried yes yes must optional
container (default) yes no must n/a
members-first yes no must n/a
edit table
Release-rule[edit]

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

release-rule container-release member-release container-release-success member-release-success
members-required yes yes must must
members-tried yes yes must optional
container (default) yes no must n/a
members-first yes no must n/a
edit table
Withdraw-rule[edit]

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

withdraw-rule container-withdraw member-withdraw container-withdraw-success member-withdraw-success
members-required yes yes must must
container (default) yes no must n/a
members-first yes no must n/a
edit table
Issues[edit]

Note: the rules depicted above are derived and extended based on some previous discussions within eSciDoc team and are based on current Container limitation: only resources of type Item and Container can be members of a Container.

  • how rules that define cascading operations on members (members-required, members-tried rules) apply if members are containers themselves?
I would assume as if they are items. In case of members-required, a container-member must be submitted/released/withdrawn too and if it has an own members-required statement, the members of the container-member must be submitted/released/withdrawn too and ... . It might be to submit ( or release or withdraw) such a container will fail because of rules of container-members but the content model may require that behavior. Frank 10:13, 17 March 2009 (UTC)

These rules should not be defined in a manner that they are preventing each other i.e. specifying member cascading rules for an aggregation should be allowed only in case the members of the aggregation are of type Items (and not Containers).

I can not see how they can prevent each other. Obviously the rule of a container-member can effect the success of the action on the (parent-)container but that is a question of, releasing the complete object graph is required or should be tried. That depends on functional requirements!? Frank 10:13, 17 March 2009 (UTC)

Implementation[edit]