User talk:Inga/container tocs
Jump to navigation
Jump to search
Natasa's feedback[edit]
Dependencies[edit]
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)
- Natasa, I have no clue what you mean with "this" - because my sentence/thought where you added it wasn't finished that time. If I understand you right, your point is that a TOC should be independent from its container and you have two arguments for this concept:
- TOCs should be producible by all users and not only by the editors of the specific digital collection.
Please note that I would interpret your example to be an "authoritative" TOC provided by ECHO (the producers of the digital content). The ECHO committee decides which items/collections to display and how to position them on the page. This is an implicit part of the ECHO site (= container) and changing this overview is in fact changing this specific container. If external users want to create their own TOC on the same content (or only a subset of it) they do so (e.g. http://www.ciera.fr/ciera/spip.php?article93), but this aggregation is not delivered as TOC for the original digital collection(s). - A change in the lower structure should not effect the superior TOC
I agree with that, but this question is more related to the dependencies eSciDoc would like to build between containers and items
- TOCs should be producible by all users and not only by the editors of the specific digital collection.
synchronizing definitions, re-considering terms used and harmonizing notations[edit]
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)
- This is true! The current eSciDoc structMap refers items (which may have components which are files) and not directly to files. Anyway, it's probably causing confusion if we use structuralMap for a simple/complete/unordered list of members because METS uses a similar term for the more-detailed/selective/ordered concept. --Inga 15:45, 14 March 2008 (CET)