Difference between revisions of "ESciDoc Container Toc"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(38 intermediate revisions by 7 users not shown)
Line 1: Line 1:
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. The TOC does not allow the grouping of members. It contains only direct members of the container resource. <font color="red">Grouping of direct members is not necessary</font>; a hierarchical structure is build by container resources wich are linked as members.
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. The TOC does not allow the grouping of members. It contains only direct members of the container resource. <font color="red">Grouping of direct members is not necessary</font>; a hierarchical structure is build by container resources which are linked as members.


The only reason to provide more than one TOC for a container resource would be to have different selections of the container resource members. <font color="red">It is assumed that there is no use case for different selections of members of one single container.</font>
== Example of a eSciDoc TOC: ==


: This assumption is probably out-dated by know. The ViRR use cases show that various types ("physical", "logical") may be provided --[[User:Inga|Inga]] 23:16, 15 March 2008 (CET)
=== General Idea ===
The TOC of a books is divided into two sections.
*The physical section is generated during the ingestion and contains informations about the scans
*The logical section can be generated by the user and contains informations about the logical structure of the container. The physical pages are mapped to the logical structure via id.


== TOC Representation based on RSS 1.0 ==
=== Example xml ===
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<toc:toc ID="myFirstTOC" xml:base="http://localhost:8080"
        xmlns:toc="http://www.escidoc.de/schemas/toc/0.4"
                xmlns:xlink="http://www.w3.org/1999/xlink"
        xsi:schemaLocation="http://www.escidoc.de/schemas/toc/0.4 TOC-v3.xsd">
    <toc:div ID="rootDiv" VISIBLE="false">
<toc:div ID="toc1" TYPE="physical">
    <toc:div ID="item287" ORDER="4" ORDERLABEL="1">
                <toc:ptr ID="ptr1_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr1_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr1_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr1_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
    <toc:div ID="item289" ORDER="5" ORDERLABEL="2">
                <toc:ptr ID="ptr2_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr2_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr2_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr2_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
    <toc:div ID="item290" ORDER="6" ORDERLABEL="3">
                <toc:ptr ID="ptr3_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr3_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr3_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr3_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
    <toc:div ID="item291" ORDER="7" ORDERLABEL="4">
                <toc:ptr ID="ptr4_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr4_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr4_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr4_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
    <toc:div ID="item275" ORDER="8" ORDERLABEL="5">
                <toc:ptr ID="ptr5_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr5_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr5_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr5_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
    <toc:div ID="item277" ORDER="9" ORDERLABEL="6">
                <toc:ptr ID="ptr6_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
<toc:ptr ID="ptr6_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/> 
<toc:ptr ID="ptr6_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
<toc:ptr ID="ptr6_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
    </toc:div>
        </toc:div>
        <toc:div ID="toc2" TYPE="logical">
    <toc:div ID="rootNode" LABEL="[the containers title]" TYPE="monograph">
<toc:ptr ID="rootNodePtr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:10" xlink:type="locator" xlink:title="[the containers title]"/>
 
<toc:div ID="container1" ORDER="1" LABEL="[the containers title]" TYPE="chapter"> 
<toc:ptr ID="container1Ptr"  LOCTYPE="URL" xlink:href="/ir/container/escidoc:11" xlink:type="locator" xlink:title="[the containers title]"/>
<toc:ptr ID="item287Ptr" TYPE="page" xlink:href="item287" xlink:type="resource"/>
<toc:ptr ID="item289Ptr" TYPE="page" xlink:href="item289" xlink:type="resource"/>
<toc:ptr ID="item290Ptr" TYPE="page" xlink:href="item290" xlink:type="resource"/>
</toc:div>
 
<toc:div ID="container2" ORDER="2" LABEL="[the containers title]" TYPE="chapter">
<toc:ptr ID="container2Ptr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" xlink:title="[the containers title]"/>
 
<toc:div ID="container3" ORDER="1" LABEL="[the containers title]" TYPE="section">
<toc:ptr ID="container3Ptr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:13" xlink:type="locator" xlink:title="[the containers title]"/>
<toc:ptr ID="item275" TYPE="page" xlink:href="item275" xlink:type="resource"/>
<toc:ptr ID="item277" TYPE="page" xlink:href="item277" xlink:type="resource"/>
</toc:div>
</toc:div>
    </toc:div>
      </toc:div>
    </toc:div>
</toc:toc>
</source>
 
=== Attributes ===
toc attributes:
*TYPE:        The type of structure this TOC describes
*:PHYSICAL = The physical structure
*:LOGICAL =  The logical structure
 
 
div attributes:
*ORDER:        The physical pagenumber of the scan. The physical order must begin with number "1".
*ORDERLABEL:  The logical pagenumber of the scan
*ID:          The identification number of this scan (id of the item)
*TYPE:        The type of this structural element (see [[ViRR_Metadata#List_of_structural_element_types|List of structural element types]])
*LABEL:        The elements title
*VISIBLE:      Indicates if this div (and its sub-elements should be displayed when displaying this toc
 
 
ptr attributes:
*ID:          The identification of this pointer
*USE:        The type of the file described with this locator
*:MIN =      thumbnail size
*:DEFAULT =  Web size
*:MAX =      Full size
*:ITEM =      item which contains these files
*xlink:href:  The locator for this file
*LOCTYPE:    The locator type
*MIMETYPE:    The scans MIME type
 
===Relation between TOC, Containers and Items for different use cases===
Ingestion of Books:
*As it is now, for every scan an item is created that contains 3 file components for the different scan resolutions (thumbnail, web, full).
*These items do not need an metadata set, because only structural elements contain metadata. (Anyway, metadata can be provided or added in later stages if it is required).
*For each volume, an container is created. All items with the scans are added as members to this container)
*Additionally, a TOC with physical part is created and all scanned pages are added and linked (picture URLs and item references), as in the example above
*The TOC is added as member to the volume container using the "hasMember/isMemberOf" relationship.
 
 
Pagination:
*The orderLabel in the physical part of the TOC is changed
 
 
Creation of a new structural element:
*For each structural element that is added to the logical part of the TOC, an item is created with a metadata set and linked from the associated div in the logical TOC.
*(Optional: The created item is added as member to the volume's container (using the "hasMember/isMemberOf" relationship))  ????
**:I think here we have agreed that each newly created item (i.e. structural element) will be assigned as a member of a container. In this case the physical TOC needs to be updated as well. --[[User:Natasab|Natasa]] 10:11, 9 October 2008 (UTC)
*Item must have a relation to its TOC (either via container or direct relation)
:See my comment above --[[User:Natasab|Natasa]] 10:11, 9 October 2008 (UTC)
 
 
Searching for a structural element:
*If a search is performed, the user gets back the item that represents an structural element. Due to the "isMemberOf" relation, the volume's container can be retrieved and, thus, also the TOC. In the TOC, the scan(s) can be retrieved by searching for the item id in the logical part and using the mapping to its physical part.
 
Open questions:
*Workflow? when and how can a TOC be released?
**A TOC can be released any time user decides to do so. My proposal is - that until the TOC is released the user is able to only browse by the structural-map of the TOC. --[[User:Natasab|Natasa]] 10:15, 9 October 2008 (UTC)
**User can release the TOC at any time. The mandatory element to release the TOC should be the "physical" part. The "logical part" may not be fully finalized. --[[User:Natasab|Natasa]] 10:15, 9 October 2008 (UTC)
* VIRR User cannot create/release TOCs yet
**what are the blockers for it? --[[User:Natasab|Natasa]] 10:15, 9 October 2008 (UTC)
* Discussion of VIRR Application Profile for Structural elements
**what are actual open questions on VIRR App profile? --[[User:Natasab|Natasa]] 10:15, 9 October 2008 (UTC)
 
== Previous Ideas ==
=== TOC Representation based on RSS 1.0 ===
A TOC consists of a RSS items element which is "an RDF table of contents" <ref name="rdf">{{cite web| title = RDF Site Summary (RSS) 1.0 | url=http://web.resource.org/rss/1.0/spec#s5.3.5 | accessdate = 2007-09-26}}</ref> containing an ordered list of member resources. The items element contains an RDF sequence (rdf:Seq) with RDF list items (rdf:li). A list item refers to a member resource by the RDF resource attribute.
A TOC consists of a RSS items element which is "an RDF table of contents" <ref name="rdf">{{cite web| title = RDF Site Summary (RSS) 1.0 | url=http://web.resource.org/rss/1.0/spec#s5.3.5 | accessdate = 2007-09-26}}</ref> containing an ordered list of member resources. The items element contains an RDF sequence (rdf:Seq) with RDF list items (rdf:li). A list item refers to a member resource by the RDF resource attribute.


Line 17: Line 154:
</pre>
</pre>


=== toc-view ===
==== toc-view ====
If the '''toc-view''' of a container resource is requested, a RSS channel is generated for delivery. The channel's about attribute is set to the container's URL; title and description are set to the container's title and description. The link element of the channel contains the URL of the requested toc-view. Further the content of the container's TOC is added (rss:items) and a RSS item for each TOC entry is added.
If the '''toc-view''' of a container resource is requested, a RSS channel is generated for delivery. The channel's about attribute is set to the container's URL; title and description are set to the container's title and description. The link element of the channel contains the URL of the requested toc-view. Further the content of the container's TOC is added (rss:items) and a RSS item for each TOC entry is added.


Line 70: Line 207:


== Questions & Discussion ==
== Questions & Discussion ==
* we have discovered a new use case (coming up from VIRR project, for more info please check [[ViRR:_Virtueller_Raum_Reichsrecht|VIRR Pages]]) for table of contents (the TOC for e.g. scanned books should contain the whole structure of a container i.e. there is one single TOC for the whole top-level container e.g. book)
Please check the '''[[talk:ESciDoc_Container_Toc|talk page]]''' for discussion
: Isn't the requirement of an "deep-level TOC" for the top-level container an indicator that a digitized book should be better represented as an individual item? I'm not sure if the same requirement would be true for other kinds of containers as well. In addition, the idea of a "deep-level TOC" sounds to me like container sub-structure is no longer used as the main browse entry, but the toc is. Keeping toc and container structure in sync could create a massive overhead (see alternatives provided below) and I would recommend to avoid these dependencies at this point in time --[[User:Inga|Inga]] 23:00, 15 March 2008 (CET)
* we would probably need to remove the TOC datastream from Containers (as it is valid for a single level only) and count with a separate "TOC object"
* we would probably need to reconsider current TOC as being treated as "user-readable structural map" of a container (actually the RSS channel is very good idea for this)
: What is meant with "user-reabable"? --[[User:Inga|Inga]] 23:00, 15 March 2008 (CET)
* in case we create separate '''TOC objects''' that can be related to a container, we should also provide a utility to "generate initial TOC" based on the Container structure (starting from a specific container node and traversing through all other nodes). The utility in fact can generate (RSS lists as depicted already with the toc-view? METS document?).
* syncronization of TOC objects with the Container structure
** '''alternative''': generated TOC is not automatically in sync with the real structure of the container. Utility for validating the TOC structure based on the container structure can be provided. The modification of a container is not automatically changing/invalidating the TOC.
**'''alternative''': generated TOC is always in sync with the real structure of the container. Modification of a container validates related TOC objects (is not modifying them but marks them as invalid). Users who are then responsible for TOC object editing should re-generate the TOC object by using a system utility.
**'''alternative''': generated TOC is always in sync with the real structure of the container. Modification of a container validates related TOC objects, removes nodes no longer existing in the container structure and adds nodes new in the container structure. Users who are then responsible for TOC object editing may manually remove TOC object node(s) if they do want some object nodes NOT to appear in the Toc after the automatical generation.


* another requirement coming up from the same project: we need to establish "logical" order of elements in the container (in addition to the "structural" grouping. The logical order should depict something like book with book pages (both sides of a page in case the page is printed only one-sided and on the back side there are some remarks, comments):
Additionally discussed on [[ViRR_Development|ViRR Development page]]
** previous object
** current object 
***current object-recto
***current object-verso
** next object
***next object-recto
***next object-verson


In a real example, this would mean that the logical order is the '''"labeling" (in the example marked with bold)''', and the ''physical order is the "numbered order as understood by a machine"'' (in the example marked with italic) e.g. :
==Workshops==
 
[[ESciDoc_Developer_Telco_2008-02-26]]
'''Example 1:'''
*Book (top level node, no labeling, no numbering yet)
**Book Chapter '''I''' - ''1''
**Book Chapter '''II''' - ''2''
***Page '''A''' - ''2.1''
***Page '''B''' - ''2.2''
***Page '''B-1''' - ''2.3''
**Book Chapter '''III''' -''3''
 
''Note: user requirement when navigating is to be able to directly go to page "B-1", or to list pages A through C.''
 
'''Example 2:'''
*Encyclopedia (top level node, no labeling, no numbering yet)
**Part '''A-M'''  - ''1''
**Part '''N-T''' - ''2''
**Part '''U-Z''' - ''3''
 
''Note: user requirement when navigating is to be able to directly go to part "A-M" (to list parts A through Z would be to my understanding too ambitious, but listing parts A-M through N-T can be requirement)''
 
'''Example 3a:'''
 
*Architectural drawings collection of N.N. (top level node, no labeling, no numbering yet)
*** Drawing '''XII''' - ''1.1'' - foreface - recto
*** Drawing '''XII''' - ''1.2'' - backface - verso
 
'''Example 3b:'''
 
*Architectural drawings collection of N.N. (top level node, no labeling, no numbering yet)
*** Drawing '''XII''' - ''1'' - (image of foreface, image of backface)
 
 
Note: example 3 (a, b) is here not very well thought trough: as we are not yet certain if both foreface and backface would be considered as separate objects like depicted above or as separate components of a same object.


Whether we do it in a container or we try to depict it with the TOC object only - it is something we need to clarify.
[[ESciDoc_Developer_Workshop_2008-03-11]]
 
* '''TOC objects''' - to be considered as a possibility to have more than one TOC object for a container? What happens with TOC (html), TOC(rtf)? etc. Is this subject to the representation of the TOC only?
 
 
 
-------------------------
* TOC of a container should support
** possibility to give title and description to a member
** to give members an order
** grouping members
:probably this is a very good reason to really distinguish between structural map (the container members on the 1st level) as internal part of the container and the TOC (which can comprise any level of container members) as object which can be related to a container --[[User:Natasab|Natasa]] 16:50, 10 December 2007 (CET)
:: Did you mean members of members if you say ''comprise any level of container members''? See the next point but one.
::: Yes, i saw all points mentioned - (see also the reasoning under Questions and Discussion on this page) the idea is that we can treat TOC objects as any other objects i.e. content items that are related to container objects via content relations isTOCFor, hasToc. The users should decide up to which level they would like to go when they create the TOC (we may only give them some utility methods for that). Thus we keep the structural map intact - and it really contains only the members on first level(items, containers). So my point was to really make strict difference between struct map and TOC. --[[User:Natasab|Natasa]] 18:32, 10 December 2007 (CET)
 
* I see multiple TOCs as different views on the members of a container. Different representations (html, rtf ...) are transformations of a main format (xml).
 
* We should basically decide if the TOC of a container is about the container members or additionally about the members of all subcontainers. The latter one is very complex and doubles the object structure.
 
==Telco 26.02.2008 discussion==
[[ESciDoc_Developer_Telco_2008-02-26]]


==References ==
==References ==
<references/>
<references/>


[[Category: ESciDoc]]
[[Category: ESciDoc|Container Toc]]

Latest revision as of 11:29, 10 November 2011

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. The TOC does not allow the grouping of members. It contains only direct members of the container resource. Grouping of direct members is not necessary; a hierarchical structure is build by container resources which are linked as members.

Example of a eSciDoc TOC:[edit]

General Idea[edit]

The TOC of a books is divided into two sections.

  • The physical section is generated during the ingestion and contains informations about the scans
  • The logical section can be generated by the user and contains informations about the logical structure of the container. The physical pages are mapped to the logical structure via id.

Example xml[edit]

<?xml version="1.0" encoding="UTF-8"?>
<toc:toc ID="myFirstTOC" xml:base="http://localhost:8080" 
		         xmlns:toc="http://www.escidoc.de/schemas/toc/0.4" 
	                 xmlns:xlink="http://www.w3.org/1999/xlink"
		         xsi:schemaLocation="http://www.escidoc.de/schemas/toc/0.4 TOC-v3.xsd">
     <toc:div ID="rootDiv" VISIBLE="false">	
	<toc:div ID="toc1" TYPE="physical">		
	    <toc:div ID="item287" ORDER="4" ORDERLABEL="1"> 
                <toc:ptr ID="ptr1_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr1_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr1_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr1_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/287_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>									
	    <toc:div ID="item289" ORDER="5" ORDERLABEL="2">
                <toc:ptr ID="ptr2_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr2_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr2_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr2_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/289_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>
	    <toc:div ID="item290" ORDER="6" ORDERLABEL="3">
                <toc:ptr ID="ptr3_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr3_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr3_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr3_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/290_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>
	    <toc:div ID="item291" ORDER="7" ORDERLABEL="4">
                <toc:ptr ID="ptr4_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr4_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr4_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr4_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/291_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>
	    <toc:div ID="item275" ORDER="8" ORDERLABEL="5">
                <toc:ptr ID="ptr5_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr5_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr5_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr5_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/275_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>
	    <toc:div ID="item277" ORDER="9" ORDERLABEL="6">
                <toc:ptr ID="ptr6_item" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" USE="ITEM"/>
		<toc:ptr ID="ptr6_min" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_1.jpeg" xlink:type="locator" USE="MIN" MIMETYPE="image/jpg"/>  
		<toc:ptr ID="ptr6_default" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_2.jpeg" xlink:type="locator" USE="DEFAULT" MIMETYPE="image/jpg"/>
		<toc:ptr ID="ptr6_max" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12/277_2.jpeg" xlink:type="locator" USE="MAX" MIMETYPE="image/jpg"/>
	    </toc:div>
        </toc:div>
        <toc:div ID="toc2" TYPE="logical">	
			
	    <toc:div ID="rootNode" LABEL="[the containers title]" TYPE="monograph">																	
		<toc:ptr ID="rootNodePtr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:10" xlink:type="locator" xlink:title="[the containers title]"/> 

		<toc:div ID="container1" ORDER="1" LABEL="[the containers title]" TYPE="chapter">   					
			<toc:ptr ID="container1Ptr"  LOCTYPE="URL" xlink:href="/ir/container/escidoc:11" xlink:type="locator" xlink:title="[the containers title]"/>
			<toc:ptr ID="item287Ptr" TYPE="page" xlink:href="item287" xlink:type="resource"/>		
			<toc:ptr ID="item289Ptr" TYPE="page" xlink:href="item289" xlink:type="resource"/>		
			<toc:ptr ID="item290Ptr" TYPE="page" xlink:href="item290" xlink:type="resource"/>														
		</toc:div>

		<toc:div ID="container2" ORDER="2" LABEL="[the containers title]" TYPE="chapter">						
			<toc:ptr ID="container2Ptr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:12" xlink:type="locator" xlink:title="[the containers title]"/>

			<toc:div ID="container3" ORDER="1" LABEL="[the containers title]" TYPE="section">
				<toc:ptr ID="container3Ptr" LOCTYPE="URL" xlink:href="/ir/container/escidoc:13" xlink:type="locator" xlink:title="[the containers title]"/>
				<toc:ptr ID="item275" TYPE="page" xlink:href="item275" xlink:type="resource"/>	
				<toc:ptr ID="item277" TYPE="page" xlink:href="item277" xlink:type="resource"/>	
			</toc:div>
		</toc:div>
	    </toc:div>
       </toc:div>
    </toc:div>
</toc:toc>

Attributes[edit]

toc attributes:

  • TYPE: The type of structure this TOC describes
    PHYSICAL = The physical structure
    LOGICAL = The logical structure


div attributes:

  • ORDER: The physical pagenumber of the scan. The physical order must begin with number "1".
  • ORDERLABEL: The logical pagenumber of the scan
  • ID: The identification number of this scan (id of the item)
  • TYPE: The type of this structural element (see List of structural element types)
  • LABEL: The elements title
  • VISIBLE: Indicates if this div (and its sub-elements should be displayed when displaying this toc


ptr attributes:

  • ID: The identification of this pointer
  • USE: The type of the file described with this locator
    MIN = thumbnail size
    DEFAULT = Web size
    MAX = Full size
    ITEM = item which contains these files
  • xlink:href: The locator for this file
  • LOCTYPE: The locator type
  • MIMETYPE: The scans MIME type

Relation between TOC, Containers and Items for different use cases[edit]

Ingestion of Books:

  • As it is now, for every scan an item is created that contains 3 file components for the different scan resolutions (thumbnail, web, full).
  • These items do not need an metadata set, because only structural elements contain metadata. (Anyway, metadata can be provided or added in later stages if it is required).
  • For each volume, an container is created. All items with the scans are added as members to this container)
  • Additionally, a TOC with physical part is created and all scanned pages are added and linked (picture URLs and item references), as in the example above
  • The TOC is added as member to the volume container using the "hasMember/isMemberOf" relationship.


Pagination:

  • The orderLabel in the physical part of the TOC is changed


Creation of a new structural element:

  • For each structural element that is added to the logical part of the TOC, an item is created with a metadata set and linked from the associated div in the logical TOC.
  • (Optional: The created item is added as member to the volume's container (using the "hasMember/isMemberOf" relationship))  ????
    • I think here we have agreed that each newly created item (i.e. structural element) will be assigned as a member of a container. In this case the physical TOC needs to be updated as well. --Natasa 10:11, 9 October 2008 (UTC)
  • Item must have a relation to its TOC (either via container or direct relation)
See my comment above --Natasa 10:11, 9 October 2008 (UTC)


Searching for a structural element:

  • If a search is performed, the user gets back the item that represents an structural element. Due to the "isMemberOf" relation, the volume's container can be retrieved and, thus, also the TOC. In the TOC, the scan(s) can be retrieved by searching for the item id in the logical part and using the mapping to its physical part.

Open questions:

  • Workflow? when and how can a TOC be released?
    • A TOC can be released any time user decides to do so. My proposal is - that until the TOC is released the user is able to only browse by the structural-map of the TOC. --Natasa 10:15, 9 October 2008 (UTC)
    • User can release the TOC at any time. The mandatory element to release the TOC should be the "physical" part. The "logical part" may not be fully finalized. --Natasa 10:15, 9 October 2008 (UTC)
  • VIRR User cannot create/release TOCs yet
    • what are the blockers for it? --Natasa 10:15, 9 October 2008 (UTC)
  • Discussion of VIRR Application Profile for Structural elements
    • what are actual open questions on VIRR App profile? --Natasa 10:15, 9 October 2008 (UTC)

Previous Ideas[edit]

TOC Representation based on RSS 1.0[edit]

A TOC consists of a RSS items element which is "an RDF table of contents" [1] containing an ordered list of member resources. The items element contains an RDF sequence (rdf:Seq) with RDF list items (rdf:li). A list item refers to a member resource by the RDF resource attribute.

<rss:items>
	<rdf:Seq>
		<rdf:li rdf:resource="http://localhost:8080/ir/item/escidoc:234"/>
		<rdf:li rdf:resource="http://localhost:8080/ir/container/:111"/>
	</rdf:Seq>
</rss:items>

toc-view[edit]

If the toc-view of a container resource is requested, a RSS channel is generated for delivery. The channel's about attribute is set to the container's URL; title and description are set to the container's title and description. The link element of the channel contains the URL of the requested toc-view. Further the content of the container's TOC is added (rss:items) and a RSS item for each TOC entry is added.

An item element contains information about the referred member (rdf:about attribute). An item contains at least title, description and URL of the member resource as rss:title, rss:description and rss:link. Additionally all DC entries from the triple store pertaining to the referred member are added.

<?xml version="1.0"?>
<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
    xmlns:rss="http://purl.org/rss/1.0/" 
    xmlns:dc="http://purl.org/dc/elements/1.1/">

  <rss:channel rdf:about="http://localhost:8080/ir/container/escidoc:123">
    <rss:title>The containers title</rss:title>
    <rss:link>http://localhost:8080/ir/container/escidoc:123/resources/toc-view</rss:link>
    <rss:description>A selected list of the members of the container.</rss:description>

    <!--
      From RDF Site Summary (RSS) 1.0 (http://web.resource.org/rss/1.0/spec#s5.3.5)
  
      5.3.5 <items>
      An RDF table of contents, associating the document's items [5.5] 
      with this particular RSS channel. Each item's rdf:resource {item_uri}
      must be the same as the associated item element's rdf:about {item_uri}.

      An RDF Seq (sequence) is used to contain all the items rather than an 
      RDF Bag to denote item order for rendering and reconstruction. 
    -->
    <rss:items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://localhost:8080/ir/item/escidoc:234"/>
        <rdf:li rdf:resource="http://localhost:8080/ir/container/:111"/>
      </rdf:Seq>
    </rss:items>
		
    <rss:item rdf:about="http://localhost:8080/ir/item/escidoc:234">
      <rss:title>Title of the refered resource</rss:title>
      <rss:link>http://localhost:8080/ir/item/escidoc:234</rss:link>
      <rss:description>Description from the refered resource</rss:description>
      <!-- All dc metadata entries from triplestore. -->
      <dc:title>Title from DC</dc:title>
      <dc:identifier>Identifier from DC</dc:identifier>
    </rss:item>

    <rss:item rdf:about="http://localhost:8080/ir/container/escidoc:111">
      <!-- ... -->
    </rss:item>

  </rss:channel>
</rdf:RDF>

Questions & Discussion[edit]

Please check the talk page for discussion

Additionally discussed on ViRR Development page

Workshops[edit]

ESciDoc_Developer_Telco_2008-02-26

ESciDoc_Developer_Workshop_2008-03-11

References[edit]