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)

--