Difference between revisions of "Talk:ESciDoc Content Model Object"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 1: Line 1:
==Agenda discussion 24.11.2008==
===Brainstorming===
*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==
==Agenda discussion 25.11.2008==
*Service descriptor - sets up behaviour of services
*Service descriptor - sets up behaviour of services

Revision as of 11:10, 26 November 2008

Agenda discussion 25.11.2008

  • Service descriptor - sets up behaviour of services
  • new CModel.mm map

Prioritization

  1. definition of CModel representation (eSciDocXML)
  2. Container/Toc issue (Cm specific methods?)
  3. handler interface
  4. validation+service descriptor (search)
  5. cm specific methods
  6. working with referenced data
  7. inheritance/templates