ESciDoc Developer Workshop 2008-11-24-25

ESciDoc

Date: 11.18.2008 Start time: 15:00 (moved from 14:30 for this day only)

Location: Karlsruhe, München (Video conference)

Participants MPDL: Wilhelm Frank, Natasa Bulatovic, Michael Franke

Participants FIZ: Harald Kappus, Matthias Razum, Frank Schwichenberg, Steffen Wagner, Rozita Fridman, Michael Hoppe

Next workshop

 * ESciDoc_Developer_Workshop_2008-12-02

Previous workshop

 * ESciDoc_Developer_Workshop_2008-11-18

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

 * Service descriptor - sets up behaviour of services
 * new CModel.mm map
 * content-model-specific properties are removed from the CModel for now
 * MPDL uses these for things like:
 * bibliographic citation inserts into item-xml during export
 * local tags
 * was not clear why local tags are not additional metadata records?
 * TODO: MPDL to think on it and assess the implementation issues

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