This is a protected page.

Note: The following is a reworked proposal for eSciDoc Developer Workshop on 14./15.10.08.

eSciDoc Content Model[edit]

In eSciDoc infrastructure a content model describes the specialization of an Item or Container object and is stored inside the infrastructure as Content Model Object. Content Model Objects are managed via ContentModelHandler.

The content of a Content Model Object consists of common object properties, as known for Item Objects and Container Objects etc., of a set of predefined content model properties, governing the behavior and form of an Item or Container (e.g. initial state), and a rule-document. The rule-document is stored as valid XML document inside the Content Model Object and contains restrictions to an Item or Container expressed in Schematron-XML (or maybe another rule-language, in the future).

Common Object Properties[edit]

id (objid)
name
description
creation date
creator (created by)
modification date (last-modification-date)
status (public-status)
context
content model (either defines a content model object for content models OR don't state this property; note: content model is not a special item)

Predefined Content Model Properties[edit]

There are predefined content model properties in form of key-value pairs and in form of lists of values.

Key/Value[edit]

initial state (pending, submitted or released)
status transitions
versioning enabled
name of main metadata record
schema of main metadata record

for sake of simplicity we could always name the main metadata record "eSciDoc"--Natasa 11:46, 10 November 2008 (UTC)

transformation description from main metadata record to DC metadata
applies to object pattern (if the content model is further specification of an Item or a Container)

and according last workshop a "TableOfContent - TOC"--Natasa 11:46, 10 November 2008 (UTC)

Maybe flags, if specific methods create new version.

Lists[edit]

model specific properties

defines which properties (key-value pairs) are allowed to put in the content-model-specific section of an Item or Container. An allowed property is defined with name, datatype, and occurence. (May be obsolete because content-model-specific in Item and Container is seen as metadata and may be removed.)

I would still not keep with this assumption. We have in content-model-specific properties in R4 put "local tags" i.e. those which are valid for publication items only, and are not indeed real Tag-relations.--Natasa 11:53, 10 November 2008 (UTC)

additional metadata records

Name, schema, and occurrence of additional metadata records. Maybe a flag to just allow additional unspecified metadata records.

Name and schema would be better, as the content model - beside descriptive information that holds only flag should also offer the possibility to map between differents chemas. --Natasa 11:53, 10 November 2008 (UTC)

What is meant by occurence of additional metadata records? not clear with this information, probably we should not keep this information. --Natasa 11:53, 10 November 2008 (UTC)

allowed formats (Item only)

In here would not agree. First we need to define if item in cmodel can have components or not, and then for the components define allowed formats. That is a bit more complex, but better structured. --Natasa 11:53, 10 November 2008 (UTC)

a list of mime-types. The binary content bound to a component of an Item must match one of these mime-types. (In conjunction with occurrence, metadata for a specific mime-type, type, type-label, etc., maybe better defined as rule or as set of properties applied to a component. See also content streams.)

What is the difference between allowed formats and a list of allowed mime-types?--Natasa 11:53, 10 November 2008 (UTC)

As content-category of the component is a component property, possible values should be defined within the cModel as well imho. --Natasa 11:53, 10 November 2008 (UTC)

aggregation / description of members (Container only)

content model of allowed members, occurrences

...

Questions:

Should number and kind of components of an Item be defined as property or in Rules?

What is the difference between property and Rules?--Natasa 11:53, 10 November 2008 (UTC)

Aha, after reading I got it. But i would think that the content model should be formally defined in a manner that is not implementation specific (but still conforming to a certain structure i.e. we started before to define a schema on this). Then the Rule document can be generated based on the content of this structure. That way, we could allow that our content models are really interoperable. The rules are needed for internal validation in eSciDoc (and evtl. could be offered as a service). But they are probably not so clear for the end user. --Natasa 11:56, 10 November 2008 (UTC)

Should cascade behavior be defined as standalone property or with aggregation description? See "Cascade" below.

Are values optional and if so, what is the meaning of no value?

Rule Document[edit]

The rule document of a content model is a valid XML document included in the Content Model Object.

A first approach can be, just to store validation schemas in use by PubMan inside the Content Model Object.

Components[edit]

The description of an Item should contain at least a list of mime-types of component content (see above "allowed formats" in "List").

For further specification the rule-document may be used (see above "Rule Document"). Or the description of an Item may include an extended list of allowed formats where an entry consists of

mime-type
content-category
occurrence
metadata records (name, schema, and occurrence)
...

Content Streams[edit]

Sould be described like component (list and/or rule-document) but just mime-type and occurrence. A name may be defined but may colide with occurrence. If mime-type is text/xml it should be possible to specify an XML schema.

Tech. note: Because content streams are not a seperate object inside the infrastructure they have no objid but a name as metadata records have.

Aggregation[edit]

The description of a Container may include an extended list of allowed member types where an entry consists of

content model (unique inside the list)
cascade information (see below "Cascade")
unique parent (see below "Unique Parent")
occurrence

The list itself may carry information like

order(ed)

What means ordered? Or should it be order and give a key for standard order?

...

Cascade[edit]

As attribute to aggregation.

The value of cascade can be one of SUBMIT, RELEASE, WITHDRAW, LOCK, UNLOCK or a comma separated list of combinations of these values or simply ALL. Additionaly the value RELAXED can be set to state that cascading is allowed to fail. An implementation MUST accept the values in lower case.

The value of cascade states if members of an aggregation MUST, SHOULD or MUST NOT be affected by state change or lock.

Unique Parent[edit]

As attribute to aggregation.

The attribute 'unique-parent' states if the container described by this content model is the only parent of its members or not, or if there is no other parent of its members with the same content model.

[unique-parent="false"] The members of the container described by this content model may have other parents.

[unique-parent="true"] The members of the container described by this content model are not allowed to have other parents.

[unique-parent="typed"] The members of the container described by this content model may have other parents but not of the same content model as the described container.

ESciDoc Content Model Object

Contents