ESciDoc Committer Meeting 2009-09-29

Date: 29.09.2009 Start time: 14:30

Location: Karlsruhe, München (Video conference or TelCo)

Participants MPDL: Natasa Bulatovic, Michael Franke

Participants FIZ: Steffen Wagner, Frank Schwichtenberg, Matthias Razum, Harald Kappus

Previous committer meeting
 * ESciDoc_Committer_Meeting_2009-09-15

Next committer meetings
 * ESciDoc_Committer_Meeting_2009-10-06
 * ESciDoc_Committer_Meeting_2009-10-13

=Topics=

PIDs and PID Manager

 * configurable choice of PID System (instance) on a context level
 * we do host several external institutions on single core service instance, also several solutions on single core service instance
 * institutions may have different decisions on which PID system to use


 * multiple PIDs allowed for object or version
 * during ingestion, more or less at present PIDs are ingested as part of the metadata record
 * this prevents some linking and searching, as different metadata schema have different metadata element names where they keep the identifier (and sometimes it is not clear if it is indeed a PID or is a local identifier)
 * allowing for multiple PIDs where core services would be able to handle them indeed like PIDs (e.g. cross-check uniqueness in the repository)
 * allowing to assign any of these multiple PIDs without creating a new item version
 * allowing to assign any of these PIDs to any item version (not only to the latest version)
 * maybe special object relation types could be solution to the last problem? in this case delivery with the item.xml would not be an issue

Outcome

 * discuss it and create Colab page

Content model definition

 * shall we try to identify issues which are not clear if they indeed depend on the cModel?
 * should CModel contain structural and content specific behavior only or in addition it should contain settings for repository behavior and repository operations?

Outcome

 * should be defined and discussed
 * current CModel implementation is very simple

Read-only core services

 * based on requirement for read-only PubMan
 * interceptor for preventing modifications based on property value
 * only system administrator would be allowed to make modifications in this case


 * motivation: when some system actions are undertaken in which user are able to view, search and retrieve, but not able to make any modifications of data

PubMan Customizing

 * CSS-Classes, Style files, etc.

Outcome

 * input from Frank
 * created new skin
 * it is not so easy, the CSS classes could be better named or designed, so that people which are not in, could easily understand at what point to do what
 * first impression:
 * not everything is in the stylesheet
 * there are stylesheets in schema section and global stylesheets
 * users should really know how to do it


 * Documentation:
 * what to change
 * when to change
 * to find out how to e.g. give a line a new color
 * what is possible to change, what users would like to change
 * somehow try to mention the hierarchy of the classes in the class name


 * externalize

=Follow up Topics of Meeting München= http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Developer_Workshop_2009-07-29/30

Fundamental changes

 * dropping SOAP?
 * Replace atomistic model for Items/Components with compound model and RELS-INT
 * Replace DB-Cache with asynchronous Lucene Index and/or Object Database
 * synchronous Lucene Index
 * Persistent data objects in rel. DB
 * Drop latest-version from object representation
 * Remove mapping of "escidoc" MD-record to DC record in Components (set title directly)
 * Get rid of content-model-specific properties

Specifics

 * Search and administrative search
 * Admin Tools development
 * Large sets of data ingest
 * how to avoid downtime to recache and reindexing
 * Trying to add/remove members to a very large container fails with 500 Internal eSciDoc System Error
 * in Work

others

 * Alignment of tools and processes (e.g., Maven)
 * Improved and harmonized communication of eSciDoc
 * eSciDoc Blog
 * service names and classification
 * service-architecture board
 * documentation of services
 * installation guides
 * eSciDoc Lab: Colab page gathering experimental modules
 * Exchange of staff members for specific developments or share development

Planning

 * short-term 6 months

=Long term issues=

Release 1.2

 * a first release candidate is scheduled for end of september

PubMan clean-Up

 * beginning of november the MPDL-solutions (like PubMan, Faces,....) will run in the same JBoss as the core services

Topics for joined development

 * start the two groups

eSciDoc Colab

 * domain-redirection for the eSciDoc-colab
 * set up the colab and move the eScoDoc pages from MPDL colab