Difference between revisions of "Talk:ViRR Scope"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 5: Line 5:
1. The institute wants to have an '''offline editor''', not an online one, because their service providers who will create the structural data will work from several different places, e.g. at home.
1. The institute wants to have an '''offline editor''', not an online one, because their service providers who will create the structural data will work from several different places, e.g. at home.
: When offering an offline editor, we have to offer a versioning tool, too, so that several users can work with the ViRR data.
: When offering an offline editor, we have to offer a versioning tool, too, so that several users can work with the ViRR data.
: That sounds like a major endeavor to me. Solving data synchronization between local and central databases is far from trivial. In any case, if going for an offline tool, i'd still make it browser based. [[User:Robert|Robert]] 08:51, 22 July 2008 (UTC)
:: That sounds like a major endeavor to me. Solving data synchronization between local and central databases is far from trivial. In any case, if going for an offline tool, i'd still make it browser based. [[User:Robert|Robert]] 08:51, 22 July 2008 (UTC)


==== Specification ====
==== Specification ====

Revision as of 08:51, 22 July 2008

Open questions concerning R2[edit]

General[edit]

1. The institute wants to have an offline editor, not an online one, because their service providers who will create the structural data will work from several different places, e.g. at home.

When offering an offline editor, we have to offer a versioning tool, too, so that several users can work with the ViRR data.
That sounds like a major endeavor to me. Solving data synchronization between local and central databases is far from trivial. In any case, if going for an offline tool, i'd still make it browser based. Robert 08:51, 22 July 2008 (UTC)

Specification[edit]

1. Modification of released pagination/structural content/bibliographic metadata

Currently changes can not be saved for a further modification but can only be released immediately.
Pro:
  • Easy handling, because only one version is needed (instead of at least two).
  • The institute has no further requirements.
Contra:
  • It would be user friendlier, if also modification can be saved bevore the will be released.

2. General:

  • If more editor accounts exists, the different actions have to be locking when someone is touching them so that not two users try to edit the same action.
Should the locking be part of the use cases? If yes, where, how?
  • The state of the bibliographic MD is unclear for me, why isn't it created? released is for me something where an editor intentionally released the MD
  • Confusion between published and released in the spec. Same or different states?

3. Pagination:

  • UC_VR_ED_01 Edit pagination: We should provide an UNDO function (practically a button where i can go back if i don't want to save the change)
    • Should we provide some kind of validation? E.g.: logical we have 1000 pages therefor a physical pagination from 1233-1333 would make no sense? Any other validation rules?
    • Can we be sure that the pagination is always ascending?

4. Structuring content:

  • UC_VR_ED_05 Edit structural element (Step 4): What happens to the elements MD? can we try to map them to the new element or are they deleted?
  • UC_VR_ED_04 Create structural element (Step 3): Is it enough to provide only the physical pagenumbers? if there is no pagination defined we can't map them to the logical page numbers for browse and display from the TOC. Probably its better to let them enter the logical page numbers, therefor we can support browse/display from TOC even when no pagination is specified and we can map the logical to the physical page numbers for TOC if pagination is specified

5. Browse and Display:

  • UC_VR_BD_04 Browse volume or monograph: Just for clarification, why start with the first content page, and not just first page?