ESciDoc Container Toc

TOC Representation based on RSS 1.0

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 wich 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. It is assumed that there is no use case for different selections of members of one single container.

A TOC consists of a RSS items element which is "an RDF table of contents" Template:Citation 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 referes 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

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

An item element contains information about the refered member (rdf:about attribute). At least an item contains the title, description and URL of the member resource as rss:title, rss:description and rss:link. Additionally all DC entries from the triplestore pertaining the refered 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

• we have discovered a new use case (coming up from VIRR project, for more info please check VIRR Pages) for table of contents
• The TOC for e.g. scanned books should be generated as a separate object and should be editable.
• we would probably need to pull-off the TOC datastream from Containers (as it is valid for a single level only) and count with a separate "TOC content model"
• in case we create a 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.
• 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).
  • alternative:

Table of Contents

Really Simple Syndication

Enhanced Scientific Documentation

Resource Description Framework

Uniform Resource Locator

Dublin Core

Virtueller Raum Reichsrecht