Difference between revisions of "ESciDoc Committer Meeting 2009-09-29"
Jump to navigation
Jump to search
(→Agenda) |
(→Topics) |
||
| Line 16: | Line 16: | ||
=Topics= | =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 | |||
=Long term issues= | =Long term issues= | ||
Revision as of 13:29, 22 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
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