Difference between revisions of "User:Inga/container tocs"
Jump to navigation
Jump to search
| Line 11: | Line 11: | ||
The CoLab provides some more details <ref name="core_services">[[ESciDoc_Services:core_services]] shortly describes the Container Handler service and introduces the terms "Container", "TableOfContents" and "StructuralMap"</ref>: | The CoLab provides some more details <ref name="core_services">[[ESciDoc_Services:core_services]] shortly describes the Container Handler service and introduces the terms "Container", "TableOfContents" and "StructuralMap"</ref>: | ||
The information of the aggregated Items and Containers is saved within the StructuralMap of the | The information of the aggregated Items and Containers is saved within the StructuralMap of the Container. | ||
The information of representation of the aggregated Items and Containers is saved within the TableOfContents | |||
of the Container. The StructuralMap and the TableOfContents of the Container are not necessarily same [...] | |||
and<ref name="containertoc">The [[ESciDoc Container Toc]] article introduces a TOC representation based on RSS 1.0 which is probably no longer in consideration. The [[ESciDoc_Container_Toc#Questions_.26_Discussion|Questions & Discussion section]] may be of further interest.</ref> | and<ref name="containertoc">The [[ESciDoc Container Toc]] article introduces a TOC representation based on RSS 1.0 which is probably no longer in consideration. The [[ESciDoc_Container_Toc#Questions_.26_Discussion|Questions & Discussion section]] may be of further interest.</ref> | ||
In eSciDoc hierarchical structures are build by means of container resources. A container | In eSciDoc hierarchical structures are build by means of container resources. A container resource refers | ||
to its members which are again containers or items. The set of references is represented as structural map | |||
(struct-map) inside the representation of a container resource. Additionally a container may contain a table | |||
of content (TOC) which contains an ordered selection of members. | |||
== Is there light at the end of the tunnel? == | == Is there light at the end of the tunnel? == | ||
Revision as of 19:22, 13 March 2008
Inga currently tries to understand the container discussion in the eSciDoc technical team and uses this page to structure results and thoughts.
Everything should start with a definition[edit]
Following definition of a Container is taken from the eSciDoc framework specification[1]:
Containers offer the concept of aggregation, i.e. they can contain other (simple and complex) objects.
Each container includes a structural map and can have a TOC and an AdminDescriptor. A container can be
a collection or a bundle."
The corresponding container XML schemas[2] slightly differs from this perception by allowing minOccurs=0 to structMap.
The CoLab provides some more details [3]:
The information of the aggregated Items and Containers is saved within the StructuralMap of the Container. The information of representation of the aggregated Items and Containers is saved within the TableOfContents of the Container. The StructuralMap and the TableOfContents of the Container are not necessarily same [...]
and[4]
In eSciDoc hierarchical structures are build by means of container resources. A container resource refers to its members which are again containers or items. The set of references is represented as structural map (struct-map) inside the representation of a container resource. Additionally a container may contain a table of content (TOC) which contains an ordered selection of members.
Is there light at the end of the tunnel?[edit]
- ESciDoc Container Toc states "Grouping of direct members is not necessary; a hierarchical structure is build by container resources wich are linked as members." -> isn't the toc something like a grouping?
- ESciDoc Container Toc states "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.
- One TOC per container?
- What is the difference between
The Result: Inga's assumptions and recommendations[edit]
- Container members are independent from their container, thus each item/container can be member of n containers.
-> The requirement that "non-editors" would like to provide individual TOCs for an existing container - The TOC is an optional, but integral component/member of the container
->Changes in the TOC object should version the container object
- 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 sync with the METS concpet "fileSec" -> renaming?
References[edit]
- ↑ API Documentation Container Handler, rest interface, framework release 0.9
- ↑ - XML schema Container rest interface, framework release 0.9
- ↑ ESciDoc_Services:core_services shortly describes the Container Handler service and introduces the terms "Container", "TableOfContents" and "StructuralMap"
- ↑ The ESciDoc Container Toc article introduces a TOC representation based on RSS 1.0 which is probably no longer in consideration. The Questions & Discussion section may be of further interest.