Difference between revisions of "Talk:ESciDoc Container Toc"
Jump to navigation
Jump to search
| Line 3: | Line 3: | ||
Following conclusions has been copied from [[User:Inga/container_tocs]] and only represent my personal view. | Following conclusions has been copied from [[User:Inga/container_tocs]] and only represent my personal view. | ||
* Considering the ViRR requirements I believe that a digitized book is a VERY strong entity. 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. Anyway, the ViRR project still could be a test | * Considering the ViRR requirements I believe that a digitized book is a VERY strong entity. 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 multivolmes need to be grouped to 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>->Changes in the TOC object should version the container object in any case | * 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 | ||
| Line 13: | Line 13: | ||
** 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? | ** 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? | ** 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? | ||
--[[User:Inga|Inga]] 23:31, 15 March 2008 (CET) | |||
Revision as of 22:31, 15 March 2008
Are digitized books (ViRR) a good container show case? Inga's comment[edit]
Following conclusions has been copied from User:Inga/container_tocs and only represent my personal view.
- Considering the ViRR requirements I believe that a digitized book is a VERY strong entity. 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 multivolmes need to be grouped to 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 n 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)