Difference between revisions of "ESciDoc Committer Meeting 2010-10-19"
(→Topics) |
(→Topics) |
||
(One intermediate revision by the same user not shown) | |||
Line 40: | Line 40: | ||
Since the item is versioned you could assigne a new PID to the modified content using the the number of the new released version (of the item). | Since the item is versioned you could assigne a new PID to the modified content using the the number of the new released version (of the item). | ||
This is NOT possible if the public-status of the item=RELEASED (see Jira issue INFR-1023). | *This is NOT possible if the public-status of the item=RELEASED, which means in our case it has already an object-PID (see Jira issue INFR-1023). | ||
So you would allow multiple versions of a content with individual PIDs. | So you would allow multiple versions of a content with individual PIDs. |
Latest revision as of 10:00, 15 October 2010
Date: 19.10.2010 Start time: 14:40 End time: 16:00
Location: Karlsruhe, München phone: +49-89-38602-223 VidCo-ISDN: 08938602595; alternate ip 192.129.1.132
Participants MPDL: Natasa Bulatovic, Wilhelm Frank
Participants FIZ: Steffen Wagner, Frank Schwichtenberg, Harald Kappus
Previous committer meeting
Next committer meetings
Topics[edit]
- component - content update for components of released items associated with a PID
- email with subject "A question on modification of the content in the item components, 27.09.2010"
MPDL is preparing to assign PIDs to all items and got into a small logical trouble, maybe you can help.
Willy noticed that in fact the PIDs shall be assigned to the content itself and not to the component. In eSciDoc data model, a content may belong to only one component. But it seems it is not vice-versa. A components's content may be modified -> if that is the case, then we are not in position to guarantee the PIDs for the content (which we assign on component level).
Here we talk about following kind of contents:
a) binary content managed in eSciDoc must not be modified within the component if it has a PID assigned , same goes for the checksum
b) the reference to external content in eSciDoc must not be modified within the component if it has a PID assigned (of course, here we are not talking about the content behind the external reference)
But if the content modification is allowed - then we are in "trouble". For the same PID we would have different content. Maybe actually content-update shall not be allowed at all, but shall be done via add/remove component always on the last item version. Thus we have all older versions ready.
- outcome of FIZ discussion
You mentioned that you would like to assign a PID to a content and if the content has to be changed the PID should be tied to the old (released) version and a new PID should be assigned to the new version. This can be done if you use for the handle system the full qualified URL including the number of the released version (of the item) containing this content.
Since the item is versioned you could assigne a new PID to the modified content using the the number of the new released version (of the item).
- This is NOT possible if the public-status of the item=RELEASED, which means in our case it has already an object-PID (see Jira issue INFR-1023).
So you would allow multiple versions of a content with individual PIDs.
Miscelaneous[edit]
others[edit]
- eSciDoc-Colab Page setup
- Alignment of tools and processes (e.g., Maven)
- Improved and harmonized communication of eSciDoc
- eSciDoc Blog
- service names and classification
- documentation of services
- installation guides
- eSciDoc Lab: Colab page gathering experimental modules