Talk:ESciDoc Content Model Object

Content Model Properties initial state and status transitions

MPDL suggests to store this in context because e.g. the initial state of a resource may depend on the creation method (e.g. create vs. ingest).

See also http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Content_Model_in_Fedora.

Rule Document

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

This would not be possible, as the validation schema depend not only on CModel, but also on metadata version and the context.

CModel can only store some very generic validation schema (i.e. default validation points) --Natasa 13:32, 10 November 2008 (UTC)

Moved to descussion

---

• schema 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)

Custom name should be possible. Default value may be "escidoc". Frank 17:23, 10 November 2008 (UTC)

---

Maybe flags, if specific methods create new version.

do not understand what this means--Natasa 13:30, 10 November 2008 (UTC)

The idea was to have something like "submitting creates new version or not" (maybe submitting is a weak example). Frank 14:22, 24 July 2009 (UTC)

---

Maybe flags, if specific methods create new version.

do not understand what this means--Natasa 13:30, 10 November 2008 (UTC)

Probably we should also add a flag if a content-stream is allowed or not for resources of this CModel--Natasa 13:30, 10 November 2008 (UTC)

In my opinion if content-streams are allowed or/and restricted by occurrence or name etc. should be stated like as for components (not key/value section!?). Frank 17:23, 10 November 2008 (UTC)

Frank, my understanding was that it is only 1 (one) content stream possible. If it is not, then certainly it is the same pattern definition like for components. --Natasa 09:24, 11 November 2008 (UTC)

I see! Yes, several content-streams are possible. Frank 10:27, 11 November 2008 (UTC)

---

Lists

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

At ESciDoc_Developer_Workshop_2009-03-17 discussed; content-model-specific is needed by MPDL for "local tags" and will remain in item and container properties. I would educe local tags are not handled by the infrastructure from storing them in c-m-s element!? Maybe we just should provide a XML Schema for c-m-s element instead of a key-value list? Frank 08:45, 17 March 2009 (UTC)

Because content-model-specific is deprecated, now, there will be no specialized part to define the content. But it should be possible to define/validate content by rule- or modeling language. Frank 14:33, 24 July 2009 (UTC)

Removed model specific properties from proposal. Frank 15:08, 27 July 2009 (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)

Yes, name and occurrence may be in conflict, because name of a metadata record must be unique inside one object. Frank 10:37, 11 November 2008 (UTC)

Obviously we need name-schema pairs (a md-record with name name must be conform to schema). Additionaly it would be nice to state if a md-record is optional or mandatory (a md-record with name name must exist and must be conform to schema). Additionaly, for the entire object, it should be possible to state if it is allowed to add md-records not defined in the content model (a flag to allow additional unspecified md-records; default should be not allowed) Frank 08:52, 17 March 2009 (UTC)

Removed occurrence of metadata from proposal. Frank 15:12, 27 July 2009 (UTC)

---

• allowed formats (Item only)

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

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)

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)

So, should we skip allowed formats at all and just define the mandatory/optional components together with mime-type, md-records etc.? As I understand we had a requirement for a list of valid mime-types as we do for the entire system in one list, for now. But maybe such a list should be in the Context Object??? Frank 08:59, 17 March 2009 (UTC)

Changed description of "allowed formats". Frank 07:40, 28 July 2009 (UTC)

---

• aggregation / description of members (Container only)

Reduced cardinality to 1 or 0. Now: "optional or mandatory" Frank 07:41, 28 July 2009 (UTC)

---

Max Planck Digital Library

Publication Management

Coordinated Universal Time

Enhanced Scientific Documentation

Extensible Markup Language