Difference between revisions of "ESciDoc Logical Data Model/Context"
| (11 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
==Model description== | ==Model description== | ||
A '''Context''' represents an administrative unit for the management of content resources in eSciDoc repository. It is related to an organizational unit, to point which organization or institution is responsible for management of content in that context. | |||
Each context may have associated sub-resources named admin descriptors. An '''Admin Descriptor''' can be created to define various settings that may be used by end-user applications (solutions) to precise the e.g. workflows, validation mechanisms, metadata profiles etc. The content and the structure of the admin descriptors is not pre-defined i.e. it may be defined based on specific user requirements. | Each context may have associated sub-resources named admin descriptors. An '''Admin Descriptor''' can be created to define various settings that may be used by end-user applications (solutions) to precise the e.g. workflows, validation mechanisms, metadata profiles etc. The content and the structure of the admin descriptors is not pre-defined i.e. it may be defined based on specific user requirements. | ||
Context are entities that are mostly referenced resources in an eSciDoc repository to define: | |||
*'''managing scope for content''': each content resource (being [[ESciDoc_Logical_Data_Model/Item|Item]] or [[ESciDoc_Logical_Data_Model/Container|Container]]) is managed within one single context | |||
*'''authorization''': as being an administrative unit for the management of content, context objects play an important role in the definition of authorization mechanisms. Most of the authorization policies can be defined on a context level such as: | |||
**who are users who may deposit content in the repository (Depositors, context level only) | |||
**who are users who may curate the content in the repository (Moderators, context level only) | |||
In some cases users would like to split the management of particular kinds of content resources e.g. publication items from face items into separate context. The eSciDoc repository allows for tagging a context object (as well as tagging the admin descriptor object) with a label that may actually point to the type of the context (or respectively, the admin descriptor) e.g. PubMan, Faces etc. In some cases users would like to define various workflows for same type of items within a single repository (even when managed by same end-user solution). Therefore, there is no limitation on the number of context or types of contexts that may exist in an eSciDoc repository. For better handling, application developers may choose to structure the admin descriptor based on the "type" of the context (or type of the admin descriptor). | |||
==UML Diagram== | ==UML Diagram== | ||
| Line 17: | Line 24: | ||
*For simplicity reasons properties of the objects are not represented on the diagram. Properties are managed by the escidoc repository itself and may change during time. For more information on the properties and ther usage please check the documentation available at [https://www.escidoc.org/JSPWiki/en/ | *For simplicity reasons properties of the objects are not represented on the diagram. Properties are managed by the escidoc repository itself and may change during time. For more information on the properties and ther usage please check the documentation available at [https://www.escidoc.org/JSPWiki/en/ObjectManager#section-ObjectManager-Context eSciDoc Context Service]. | ||
==Examples== | ==Examples== | ||
[[Category:ESciDoc_Logical_Data_Model|Context]] | |||
Latest revision as of 09:38, 10 November 2011
Introduction[edit]
This page provides general overview on the Context resources within the eSciDoc repository. General introduction available at eSciDoc Logical Data Model page.
Model description[edit]
A Context represents an administrative unit for the management of content resources in eSciDoc repository. It is related to an organizational unit, to point which organization or institution is responsible for management of content in that context.
Each context may have associated sub-resources named admin descriptors. An Admin Descriptor can be created to define various settings that may be used by end-user applications (solutions) to precise the e.g. workflows, validation mechanisms, metadata profiles etc. The content and the structure of the admin descriptors is not pre-defined i.e. it may be defined based on specific user requirements.
Context are entities that are mostly referenced resources in an eSciDoc repository to define:
- managing scope for content: each content resource (being Item or Container) is managed within one single context
- authorization: as being an administrative unit for the management of content, context objects play an important role in the definition of authorization mechanisms. Most of the authorization policies can be defined on a context level such as:
- who are users who may deposit content in the repository (Depositors, context level only)
- who are users who may curate the content in the repository (Moderators, context level only)
In some cases users would like to split the management of particular kinds of content resources e.g. publication items from face items into separate context. The eSciDoc repository allows for tagging a context object (as well as tagging the admin descriptor object) with a label that may actually point to the type of the context (or respectively, the admin descriptor) e.g. PubMan, Faces etc. In some cases users would like to define various workflows for same type of items within a single repository (even when managed by same end-user solution). Therefore, there is no limitation on the number of context or types of contexts that may exist in an eSciDoc repository. For better handling, application developers may choose to structure the admin descriptor based on the "type" of the context (or type of the admin descriptor).
UML Diagram[edit]
- For simplicity reasons properties of the objects are not represented on the diagram. Properties are managed by the escidoc repository itself and may change during time. For more information on the properties and ther usage please check the documentation available at eSciDoc Context Service.