MPDL AB Meeting 2009-03-03

MPDL  Restricted Access to MPDL


 * Date: 04.03.2009
 * Participants:Natasa Bulatovic, Thomas Endres, Wilhelm Frank, Michael Franke, Tobias Schraut

=Agenda=

Maintenance tasks of core-service

 * see http://zim01.gwdg.de:8080/browse/AS-679
 * see http://zim01.gwdg.de:8080/browse/AS-678
 * see http://zim01.gwdg.de:8080/browse/PUBMAN-743
 * see http://zim01.gwdg.de:8080/browse/AS-677

OAI-PMH

 * Decision on the architectural approach
 * See core service OAI-PMH specification at OAI-PMH Core service interface
 * See internal discussion and requirements at PubMan_Func_Spec_Export/OAI_Data_Provider and Talk:PubMan_Func_Spec_Export/OAI_Data_Provider
 * See related discussion also at PubMan_Web_Syndication_Feeds

Outcome

 * We will use eSciDoc core service interface of OAI-PMH data provider
 * There should be mapping from Application profiles to simple DC to have OAI_DC as minimum
 * offering additional metadata format by core service as "escidoc" can not guarantee single metadata format across all oai-pmh records, but will be offered anyway
 * solutions to expose own oai-pmh data provider interface that functions as filtered eSciDoc repository oai-pmh data provider for solution-specific sets
 * BLOCKER: OAI-PMH core -service data provider

Clarification after VidConf 10.03.2009 with FIZ

 * There is no problem in having different metadata profiles in the core service, as the interface offers ONLY records available in the specified metadata format
 * Assumption (NBU): There is no need for solutions to expose own oai-pmh data provider interface, as according the OAI-PMH implementation, there is a possibility to define a set hierarchy, see ListSets response. In this case we can define sets as e.g.

pubman pubman:MPIPL pubman:MPDL etc.

Management of source data for ingested/harvested items

 * Decision on the architectural approach
 * See discussion at EsciDoc_Item_Origin

Outcome

 * Origin metadata will be saved as separate item, separate content model
 * This origin-metadata item will have "Premis" metadata record, and the metadata itself will be in the component, as there is no support for external schema display
 * the relation to the Original metadata record is kept in the escidoc item
 * Argumentation:
 * item.xml for normal items is not overloaded
 * search results are clearly separated (unlike when origin metadata are in item component)
 * access rights management can be separately managed
 * Origin-metadata item will be created and released and component that holds original metadata will always be public access, unless otherwise specified during import or by administrator
 * Automatic synchronization is not supported unless used via application service interface
 * relations are always on version level i.e. created target item version points to exact version of origin-item version
 * if created target item version is changed independently, new version is created that points to same origin-item version
 * if created target item version is changed via ingest/upload procedure, then the relation is overwritten to the new origin-item version
 * special transformations for e.g. SPIRES, ARXIV during export will be based on identifier prefix of the created target item, and not based on the information on origin (as this is anyway done for linking to source repositories such as arXiv, eDoc)

SWORD Protocol Implementation

 * see SWORD

Going Productive
After the next release, PubMan is considered to be "productive". What actions have to be taken to achieve this?
 * Define topics
 * AB proposes a "Going Productive Meeting" after feature freeze for PubMan 4.1
 * see also ESciDoc_Solutions_Going_Productive
 * Backup procedures

what means going productive

 * backup(1)
 * user management
 * proper role concept
 * granularity of access rights
 * missing roles?
 * workflow changes?
 * PIDs
 * versioning of PubMan, updates and maintenance - concept i.e. technical support
 * there should be clear management decision what do we want to offer i.e.
 * acceptable downtime
 * response to bug-fixes
 * performance(1)
 * reliability, availability, stability (1)
 * support, documentation, training, policies
 * time to respond
 * support-appointee


 * feature stability and scope

todos

 * rework the readiness list
 * define priorities
 * specify must, should
 * specify actors
 * specify real-possibility to implement/adopt

Solution development

 * discussion on pubman deployment and how to approach it
 * discussion on solution properties and how to approach it
 * discussion on service locator issue and how to approach it
 * discussion on development of own policy templates and checking the possibilities to define policies on our own
 * background: more roles coming up with further solution developments
 * see also Talk:ESciDoc_Solutions_summary

Definition of TODOs for AB

 * scope: until March 2009
 * Proposal: have JIRA project for AB tasks only not to loose track of

EA Documentation

 * issues with the documentation
 * presentation of EA Documentation

Authoriziation issues

 * check http://zim01.gwdg.de:8080/browse/AS-381

Presentation test suite / test cases

 * What to test?
 * page flow
 * CRUD of items
 * FT upload
 * genre specific test cases
 * page behaviour (field/group presentation)
 * logic behaviour (save, cleanup)
 * simple or sophisticated item creation (using list elements -> i.e. create more than one creator, or not?)
 * search tests possible?
 * Javascript Tests?


 * Maintenance and creation of tests
 * who will create tests
 * who will maintain them?
 * is a graphical test creation (i.e. browser based) necessary?