Difference between revisions of "Talk:ESciDoc Container Toc"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
== Are digitized books (ViRR) a good container show case == | == Are digitized books (ViRR) a good container show case? == | ||
Following conclusions | 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 | * 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<br> | * The TOC is an optional, but integral component/member of a digitized book<br>=>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 | * Members are independent from their container(s), thus each item can be member of many containers. <br>=> 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 | * I would strongly vote for synchronizing definitions, re-considering terms used and harmonizing notations | ||
Revision as of 10:55, 16 March 2008
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)