Difference between revisions of "ESciDoc Container Toc"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{Out_of_date}}
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.
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.



Revision as of 21:39, 11 April 2008

Emblem-important.svg.png
The content of this article or section is probably out-of-date.
Please feel free to update the article and remove this tag afterwards. There may be more information on the talk page.


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.

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>

TOC Representation based on METS structMap[edit]

provided by FIZ after ESciDoc_Developer_Workshop_2008-03-11

<?xml version="1.0" encoding="UTF-8"?>
<toc:toc xmlns:toc="http://escidoc.de/toc" ID="meins" TYPE="PHYSICAL" LABEL="Table of Content"
  xml:base="http://localhost:8080"   
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://escidoc.de/toc TOC-v1.xsd">

	<!-- this example is derived from http://dfg-viewer.de/fileadmin/groups/dfgviewer/DFG-Viewer_Beispiel__minimal_.xml -->
	<!-- NOTE: It is planned to deny "xlink:href"s in the element "ptr" which do not point to members or members of members -->
	<toc:div ID="phys94775" TYPE="physSequence" LABEL="Vollstaendiges corpus gravaminum evangelicorum, Band 1">
		<toc:div ID="div109827" ORDER="1" ORDERLABEL="i" TYPE="page" LABEL="Blank page">
			<toc:ptr ID="img109827" LOCTYPE="URL" xlink:href="/ir/item/escidoc:275"/>
			<my:additional-metadata xmlns:my="http://my.domain.org">
				<my:description>xxx</my:description>
			</my:additional-metadata>
		</toc:div>
		<toc:div ID="div109828" ORDER="2" ORDERLABEL="ii" TYPE="page" LABEL="Page i: Half title page">
			<toc:ptr ID="img109828" LOCTYPE="URL" xlink:href="/ir/item/escidoc:276/>
		</toc:div>
		<toc:div ID="div109830" ORDER="3" ORDERLABEL="1" TYPE="page" LABEL="Seite 1">
			<toc:ptr ID="img109830" LOCTYPE="URL" xlink:href="/ir/item/escidoc:277"/>
		</toc:div>
		<!-- more pages -->
	</toc:div>
</toc:toc>

Differences to METS[edit]

  • The eSciDoc TOC points to items (which may have null or many components) while a METS structMap would refer to entries in the METS fileSec which would directly point to a file. The administrative metadata for the files or their intended use could be provided on the item level.
File pointer in the METS fileSec do point to "files". In my opinion that also may be an eSciDoc container XML. Just DFG-Viewer makes the restriction that file pointer in the fileSec did NOT point to files containing metadata, but to "Inhaltsdateien". Frank 11:42, 18 March 2008 (CET)
  • In eSciDoc additional grouping levels (e.g. for chapters) would be realized by a set of sub-containers. In this case, the TOC would include toc:ptr elements pointing to sub-containers as well as items.
  • The proposal includes an option to specify additional metadata with each toc:div element (= information which is only relevant for the item in the structure provided with the eSciDoc TOC). Please note that this requirement is not part of the current ViRR specification.
Primarily the metadata are from the requirement to be able to state a special description or title for a TOC entry. From my point of view that should hardly be used to make statements about the corresponding eSciDoc resource. Frank 11:42, 18 March 2008 (CET)
  • Due to the fact that the relevant information (dmdSec, admSec, fileSec, structMap, structLink) would be scattered over various eSciDoc items and containers, the framework wouldn't be able to provide an appropriate METS mapping, thus this would become the task of the solution

Questions & Discussion[edit]

Please check the talk page for discussion

Telco 26.02.2008 discussion[edit]

ESciDoc_Developer_Telco_2008-02-26

References[edit]