User:Inga/container tocs

Inga currently tries to understand the container discussion in the eSciDoc technical team and uses this page to structure results and thoughts.

Hi dear,

For some more issues that you may consider eventually:

• longer time ago this page was created (i never managed to finalize it so far sorry: [[1]] )
• Some more definitions coming from the logical data model (i have revised as they were not very well precised, still polishing is necessary)
  • Def1: StructuralMap is defined for a Container and holds references to all directly aggregated Items/Containers within that Container.
  • Def2: TableOfContents is defined for a Container and defines (all or subset) of aggregated objects that should be presented in the table of content for the container.
  • Clarification: TableOfContent is different from the StructuralMap: TableOfContent uses the information from the StructuralMap but is not necessarily the same information e.g. information presented with the StructuralMap is not by definition an ordered aggregation - TableOfContent is always ordered; while a StructuralMap must contain information on "directly" aggregated objects, table of content not necessarily references all (directly and not directly) aggregated objects. While there is only one StructuralMap allowed for a Container - a content container can have more than one TableOfContents defined (depending on the purpose of use of the table of content).

--Natasa 10:40, 14 March 2008 (CET)

Everything should start with a definition

Following definition of a Container is taken from the eSciDoc framework specification:

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 slightly differs from this perception by allowing minOccurs=0 to structMap.

The CoLab provides some more details:

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

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?

• 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

• 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?

Do you here refer to the concept or the implementation? It may get even more confusing when we talk about METS concept imho, as there we have the following definition of fileSec element:

 <xsd:element name="fileSec" minOccurs="0">
    <xsd:annotation>
	<xsd:documentation>fileSec: Content File Section. 
		The content file section records information regarding all of the data files which comprise the digital library object.
	</xsd:documentation>
    </xsd:annotation>
...

"flat" list of item reference in eSciDoc is not semantically in sync with the fileSec concept imho as items are not files.

Enhanced Scientific Documentation

Central European Time

Table of Contents

Extensible Markup Language

Collaboration Laboratory

Metadata Encoding and Transmission Standard

Really Simple Syndication