Difference between revisions of "ESciDoc Committer Meeting 2010-10-19"

From MPDLMediaWiki
Jump to navigation Jump to search
 
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