Talk:ViRR Scope

Open questions concerning R2

General

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)

Advantages of webapplications:

• No extra software has to be installed (big advantage when multiple/external people are working with ViRR)
• Software can be updated on only one server (compared to several client installations)
• We can make sure everybody works with the same, up to date version
• We can make sure everybody works with up to date items, no or minimal version control is needed

--> For R2, we can only offer an online editor. In the next meeting with the institute, we will discuss this topic in detail.

Specification

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?

Virtueller Raum Reichsrecht

Coordinated Universal Time

Metadata

Use Case

Table of Contents