Difference between revisions of "ESciDoc Committer Meeting 2009-09-29"
Jump to navigation
Jump to search
| Line 48: | Line 48: | ||
== PubMan Customizing == | == PubMan Customizing == | ||
* CSS-Classes, Style files, etc. | * 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= | =Follow up Topics of Meeting München= | ||
Latest revision as of 13:20, 29 September 2009
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
Next committer meetings
Topics[edit]
PIDs and PID Manager[edit]
- 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[edit]
- discuss it and create Colab page
Content model definition[edit]
- 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[edit]
- should be defined and discussed
- current CModel implementation is very simple
Read-only core services[edit]
- 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[edit]
- CSS-Classes, Style files, etc.
Outcome[edit]
- 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
- not everything is in the stylesheet
- 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[edit]
http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Developer_Workshop_2009-07-29/30
Fundamental changes[edit]
- 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[edit]
- 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[edit]
- 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[edit]
- short-term 6 months
Long term issues[edit]
Release 1.2[edit]
- a first release candidate is scheduled for end of september
PubMan clean-Up[edit]
- beginning of november the MPDL-solutions (like PubMan, Faces,....) will run in the same JBoss as the core services
Topics for joined development[edit]
- start the two groups
eSciDoc Colab[edit]
- domain-redirection for the eSciDoc-colab
- set up the colab and move the eScoDoc pages from MPDL colab