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.

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.

Following definition for StructuralMap and TableOfContents are derived from the logical data model and have been provided by Natasa

StructuralMap is defined for a Container and holds references to all directly aggregated Items/Containers
within that Container. 
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. 

Why 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)

Containers and members

Aggregation of digital items introduces potential dependencies between containers and members, e.g. it could be reasonable that the release of a member object creates a new version of the container object or that the release of a container object automatically releases the last version of its members as well. Anyway, this stuff is tricky and complicated - especially because items could belong to several containers and this information is not part of the item object.

More information is available in the eSciDoc Content Model and the concept paper on versioning

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 container they can be

As some example, check: http://echo.mpiwg-berlin.mpg.de/content - this is the "overall" Toc of all collections (that represent so to say first level collection of ECHO repository. This would mean that whenever any of the collection of ECHO is changed, and each has its own editor, somehow this would have immediately to affect this TOC - maybe this is very nice automatism, but to use it in "network" like environment may become very complicated :). --Natasa 11:04, 14 March 2008 (CET)

• 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

absolutely necessary :) --Natasa 11:04, 14 March 2008 (CET)

• • container, i.e. in regard to hierarchical structure

container is not necessarily hierarchical structure it was originally thought of as aggregation (which may aggregate other items/containers (e.g. aggregations). It again, depends on how one understands the hierarchical structure. In SWB scenarios we've had the case of: CollectionA (member container C1, member container C2, member item I1, member itemI2). In addition (member container C2 of collection A is also a member of the container C1). The only thing which was to be restricted was that we can not have smth like (A has member C2, C2 has member C3, C3 has member C4 and C4 has member C2 (or C4 has member C3). --Natasa 11:04, 14 March 2008 (CET)

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

(--Natasa 11:04, 14 March 2008 (CET)) Dear, 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.--Natasa 11:04, 14 March 2008 (CET)

Enhanced Scientific Documentation

Table of Contents

Extensible Markup Language

Collaboration Laboratory

Central European Time

European Cultural Heritage Online

Scholary Workbench

Metadata Encoding and Transmission Standard

Really Simple Syndication