Talk:ESciDoc Container Toc
Jump to navigation
Jump to search
Are digitized books (ViRR) a good container show case?[edit]
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[edit]
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)