Talk:ESciDoc Content Model Object
Agenda discussion 24.11.2008[edit]
Brainstorming[edit]
- Validation
- Classification of objects (typization)
- agreed by all
- CModel should be defined in XML (XSD, Schematron, RDF, RelaxNG, proprietary)
- agreed by all
- (Formal) structure of objects "festlegen"
- agreed by all
- CModels to their digital objects are what classes are to instances
- discussion, MRa point: to stick as much as possible to Fedora CMA and the new developments coming out from Fedora
- questioning why eSciDoc is "hiding" Fedora (besides more complex security model, support for aggregations and object graphs)
- example: OAI-PMH had to be re-worked (eSciDoc have more requirements on set definition and specific version of objects, not last versions, but released versions)
- CModels describe the semantic of instances (textual, context information, content category, metadata profile etc.)
- semantic defined as meaning of objects of certain CModel
- semantic is described with a certain formal structure
- semantic is described by syntax such as XSD, Schematron, RDF etc.
- Define type-specific methods
- all agreed there can be type-specific methods even though not always clear where/how
- discussion on Resource (Object manager) handler
- at end agreed that type-specific methods are not necessarily equal to Fedora disseminators (can be defined by users of the CModel i.e. for purpose of certain solution)
- Container handler is convenient even though it is apparently clear Items are very similar to containers
- independent from the implementation
- CModels should not contain implementation specific details
- why?
- E.g. CLARIN
- can contain link to e.g. WSDL, REST interface (as contracts for type-specific operations)
- Shall we go for WSDL, other description?
- resource behaves as a service (with contracts for it's own specific operations)
- evtl. other alternatives, but always "web service"
- interoperable
- related to Implementation non-specific
- MRA: CMX
- Namespaces for CM+Formats+MD-Profiles+URIs
- inheritance from CModels
- each cModel should be self-contained
- might be more complex for self-archiving
- discussion
- inheritance might be good (OPEN)
- revisit again, not initial implementation
- templates can be used to define similar CModels
- CModels define the behavior of Services (search, Relations, technical metadata-extraction, presentation, PID?)
- not for presentation, as it is implementation specific
- search: to reference the stylesheet for indexing the content and search configuration
- technical metadata extraction (possibiility to configure how it is triggered or a record must have technical metadata extraction)
- verbindung zu life-cycle methoden? (OPEN)
- cache -> what to cache and when?
- consider it vice-versa (services->cModels)
- metadata profiles
- exact version in CModel
- when new version of metadata is created then whether to create new version of CModel?
- check migration possibility?
- how to deal with referenced objects such as metadata profiles, web services (behaviours) etc. (OPEN)
- allowed relations
- first to clarify Relations, then check if valid for cModel discussion
- life-cycle (status-transitions, initial status)
- removed from CModel
- CModel is versioned
- check events that make the versioning
- Templates
- can be done, they will be useful
- File formats
Agenda discussion 25.11.2008[edit]
- Service descriptor - sets up behaviour of services
- new CModel.mm map
Prioritization[edit]
- definition of CModel representation (eSciDocXML)
- Container/Toc issue (Cm specific methods?)
- handler interface
- validation+service descriptor (search)
- cm specific methods
- working with referenced data
- inheritance/templates