Talk:ESciDoc Container Toc

ViRR as new TOC use case

We have discovered a new use case (coming up from VIRR project, for more info please check VIRR Pages).

Deep-level TOC

For table of contents (the TOC for e.g. scanned books should contain the whole structure of a container i.e. there is one single TOC for the whole top-level container e.g. book)

Isn't the requirement of an "deep-level TOC" for the top-level container an indicator that a digitized book should be better represented as an individual item? I'm not sure if the same requirement would be true for other kinds of containers as well. In addition, the idea of a "deep-level TOC" sounds to me like container sub-structure is no longer used as the main browse entry, but the TOC is. Keeping TOC and container structure in sync could create a massive overhead (see alternatives provided below) and I would recommend to avoid these dependencies at this point in time --Inga 23:00, 15 March 2008 (CET)

I really agree with that concern about container sub-structure. This should certainly be discussed once more. Frank 10:52, 17 March 2008 (CET)

Synchronization of TOC objects with the Container structure

• alternative: generated TOC is not automatically in sync with the real structure of the container. Utility for validating the TOC structure based on the container structure can be provided. The modification of a container is not automatically changing/invalidating the TOC.
• alternative: generated TOC is always in sync with the real structure of the container. Modification of a container validates related TOC objects (is not modifying them but marks them as invalid). Users who are then responsible for TOC object editing should re-generate the TOC object by using a system utility.
• alternative: generated TOC is always in sync with the real structure of the container. Modification of a container validates related TOC objects, removes nodes no longer existing in the container structure and adds nodes new in the container structure. Users who are then responsible for TOC object editing may manually remove TOC object node(s) if they do want some object nodes NOT to appear in the Toc after the automatic generation.

Separating TOC object from Container

We would probably need to remove the TOC datastream from Containers (as it is valid for a single level only) and count with a separate "TOC object"

In case we create separate TOC objects that can be related to a container, we should also provide a utility to "generate initial TOC" based on the Container structure (starting from a specific container node and traversing through all other nodes). The utility in fact can generate (RSS lists as depicted already with the toc-view? METS document?).

TOC as user-readable structural map

We would probably need to reconsider current TOC as being treated as "user-readable structural map" of a container (actually the RSS channel is very good idea for this)

What is meant with "user-reabable"? --Inga 23:00, 15 March 2008 (CET)

Logical order

Another requirement coming up from the same project: we need to establish "logical" order of elements in the container (in addition to the "structural" grouping. The logical order should depict something like book with book pages (both sides of a page in case the page is printed only one-sided and on the back side there are some remarks, comments):

• previous object
• current object
  • current object-recto
  • current object-verso
• next object
  • next object-recto
  • next object-verson

In a real example, this would mean that the logical order is the "labeling" (in the example marked with bold), and the physical order is the "numbered order as understood by a machine" (in the example marked with italic) e.g. :

Example 1:

• Book (top level node, no labeling, no numbering yet)
  • Book Chapter I - 1
  • Book Chapter II - 2
    • Page A - 2.1
    • Page B - 2.2
    • Page B-1 - 2.3
  • Book Chapter III -3

Note: user requirement when navigating is to be able to directly go to page "B-1", or to list pages A through C.

Example 2:

• Encyclopedia (top level node, no labeling, no numbering yet)
  • Part A-M - 1
  • Part N-T - 2
  • Part U-Z - 3

Note: user requirement when navigating is to be able to directly go to part "A-M" (to list parts A through Z would be to my understanding too ambitious, but listing parts A-M through N-T can be requirement)

Example 3a:

• Architectural drawings collection of N.N. (top level node, no labeling, no numbering yet)
  • • Drawing XII - 1.1 - foreface - recto
    • Drawing XII - 1.2 - backface - verso

Example 3b:

• Architectural drawings collection of N.N. (top level node, no labeling, no numbering yet)
  • • Drawing XII - 1 - (image of foreface, image of backface)

Note: example 3 (a, b) is here not very well thought trough: as we are not yet certain if both foreface and backface would be considered as separate objects like depicted above or as separate components of a same object.

Whether we do it in a container or we try to depict it with the TOC object only - it is something we need to clarify.

Are digitized books (ViRR) a good container show case?

Following conclusions have been copied from User:Inga/container_tocs and only represent my personal view.

• Considering the ViRR requirements I believe that digitized books are VERY strong entities and that individual scanned-in pages are no independent resources. Thus every change in the description of one page or in the table of contents should create a new version of the book. Therefore, I would suggest to implement digitized books as items with an structural map datastream. This would also help us providing METS exports at a later stage because we would operate on the same granularity. Anyway, the ViRR project still could be a test bed for containers, because books need to be grouped to multivolumes as well as books and multivolumes need to be grouped in the ViRR collection. Anyway, on that level "no deep level TOC" is required, it's fine to provide a grouped list of direct members first.

• The TOC is an optional, but integral component/member of a digitized book
  =>Changes in the TOC object should version the container object in any case

• Members are independent from their container(s), thus each item can be member of many containers.
  => In cases where users would like to provide an additional TOC for an existing container for which they have no privilege ("non-editor"), they still could create their own container including the same set (or subset) of the items.

• I would strongly vote for synchronizing definitions, re-considering terms used and harmonizing notations
  • container, i.e. in regard to hierarchical structure
  • table of contents/tableOfContents/TOC/toc - if the escidoc toc is an ordered and grouped overview of [selected] members, it may be semantically in sync with the METS concept "structMap" -> renaming to avoid confusion?
  • StructuralMap/struct-map - if a structural map is the "flat" list of item reference, it may be semantically in accordance to the METS concept "fileSec" -> renaming?

--Inga 23:31, 15 March 2008 (CET)

How may TOC per container?

The only reason to provide more than one TOC for a container resource would be to have different selections of the container resource members. It is assumed that there is no use case for different selections of members of one single container.

This assumption is probably out-dated by know. The ViRR use cases show that various types ("physical", "logical") may be provided --Inga 23:16, 15 March 2008 (CET)

Yes indeed, it is out-dated. For me it's not clear if there is a "physical" and a "logical" TOC or one single TOC should be transformed into a METS with a "physical" and a "logical" structMap, in the ViRR use case. Frank 10:46, 17 March 2008 (CET)

Virtueller Raum Reichsrecht

Table of Contents

Virtueller Raum Reichsrecht

Central European Time

Really Simple Syndication

Metadata Encoding and Transmission Standard