Generating Slides From Topic Maps

Robert Barta

Abstract

Slide shows are a frequent method to transport concepts to a live audience. Due to the limited space and the presence of a speaker slide shows typically contain topics, together with a short description and how they are related to other concepts. Exactly this kind of knowledge can also be denoted in Topic Maps. This document describes the setup how slide shows can be generated from Topic Map-encoded knowledge using a SAX handler.

Table of Contents

Motivation

Overview

The Intake

The Smile Namespace
Formats

The Exhaust

Example

The Distribution

Backends

A. Appendix: SlideML DTD

Motivation

Topic Maps have been designed to hold flat knowledge. They can contain topics, their place in an ontology (type system), some description and references. And they usually relationships between these topics.

As such, they have some similarity with slide shows with the exception that these documents are presented for a particular purpose for a particular audience and for a particular presenter. Still, it seems inefficient to store flat knowledge into a slide show if it already exists in Topic Maps.

Overview

Let us assume that we already have a number of Topic Maps and that these contain topics and concepts which we would like to map into a slide show. Obviously this process cannot be fully automated as

slides have to appear in a specific order
due to size limitations of a single slide, one specific topic has to be continued on the next slide
for every particular topic maybe different information is relevant

The author of the slide show must specify what he wants, while the slide generator should fill in the required content from the pool of Topic Maps.

In this light, the slide generator is a TM query engine which is used to extract the requested information. The query engine, though, will be specialized and tailored for the generation of slides.

For obvious reasons the generated output is an XML language (called here SlideML) to allow conversion into other XML languages. The conversion is thus controlled via namespaces:

Involved Namespaces

http://topicmaps.bond.edu.au/smile/1.0/: Elements from this namespace define what topic information should be included for a particular topic. These elements will be detected in the intake XML instance and will be interpreted.
http://topicmaps.bond.edu.au/SlideML/: Elements from this namespace may or may not be in the incoming document. They will be passed transparently through the generator. In every generated slide elements from this namespace will be used to structure topic information.

The Intake

The slide generator will first consult an incoming XML document about the modalities of the slide show. To allow for a maximum of flexibility, the generator does only process XML elements from the http://topicmaps.bond.edu.au/smile/1.0/ namespace. All other elements will be passed through transparently. This allows to use the smile elements in any XML document whether this is now slide-oriented or not.

The Smile Namespace

Following incoming elements belong to the smile namespace and are detected by the generator:

Smile Elements

slide

This signals the begin of a slide.

The mandatory attribute is tid, which must contain a topic id. If this particular topic does not exist in the current topic map, an error is flagged.
Optionally, the attribute format can be used to control the content of this slide.

default

With this tag, default values can be set via attributes which apply to all slides which may follow this tag:

The value of the map attribute will be interpreted as tau expression according to the CPAN package XTM::Virtual.
The value of the format attribute will be used to control what every slide will contain from the topic in the topic map. This format can be overridden for every individual slide. Formats are described below.

Formats

A format string describes what exactly should be included in the generated slide. The default format is

  "%ti %ty %rd %ins %res"

and takes care that a title, types, inlines (resourceData), instances and references (occurrences) of that particular topic are included on a slide in that particular order.

One format specifier is introduced with a '%' character, several such specifiers are separated bu one or more blanks. Following specifiers are honored:

Format Specifiers

ti: Include a <title> tag containing the title of the slide. This is generated from the baseName of the topic. (Sorry, no scoping yet)
ty and tys: This includes the types (instanceOf, to be exact) of the topic enclosed by a <types> tag. In case of ty, every instanceOf is embedded with its own <type> tag. In case of tys all these instanceOfs are concatenated to one string separated by ','.
rd and rds: This includes the resourceData occurrences enclosed by the tag <inlines>. In case of rd, every such occurrence is wrapped into its own tag, <inline>. In case of rds, all strings are concatenated into one character string (again, separated by ',').
in, ins and inrds: This includes the instances of this topic (i.e. all topic which have an appropriate instanceOf of this topic) using the tag <instances>. In case of in, the individual instances are wrapped into separate <instance> tags. In case of ins, they are concatenated via ',' into one string. inrds behaves like in except that for every individual instance also its resourceData is included via nested <description> tags.
res: This includes the resourceRef occurrences via a <references> tag. Every individual occurrence is included via a <reference> tag. This tag is empty, but contains an xlink:href attribute containing the reference link.

Since most final slide formats have space limitations for slides, there is also a way to limit the number of things which are added to a particular slide. A typical scenario is to start with a topic, its explanation and the various instances of this topic. If that topic has too many of these instances to fit onto a slide, then the remaining instances can be moved to a second slide:

  <!-- first two instances -->
  <astma:slide astma:tid="client-side-presentation-technology" astma:format="%ti %in[1-2]"/>

  <!-- same but as a followup slide, all other instances and with continue -->
  <astma:slide astma:tid="client-side-presentation-technology" astma:format="%ti %in[3-]" astma:continue="yes"/>

</slides>

Ranges are specified via a lower and an upper bound in [n-m]. If the lower bound is omitted, 1 will be assumed. If the upper bound is omitted, then 5 is the default.

Following format specifiers can have a range modifier:

ty and tys
rd and rds
in, ins and inrds
res

The Exhaust

Once the slide generator has detected an element in the smile namespace, it will retrieve the topic information from the backend Topic Map database. As result, the generator will format this information into SlideML elements. (You can find the DTD in the appendices.) SlideML instances can then be converted into other formats (see Backends).

Example

Let us assume we had a topic map covering web programming in an AsTMa file called webprogramming.atm. A slide show can be defined via the following XML document:

<?xml version="1.0" standalone="yes"?>
<slides name="The Mystery Tour, 2002" 
	xmlns = "http://topicmaps.bond.edu.au/SlideML/"
        xmlns:astma = "http://topicmaps.bond.edu.au/astma/1.0/"
        xmlns:smile = "http://topicmaps.bond.edu.au/smile/1.0/">

  <institution>Bond University</institution>

  <astma:default astma:tau_expr="file:webprogramming.atm"/> <!-- this loads the map(s) -->

  <!-- first slide, no detailed specification, so the default format will be used -->
  <astma:slide astma:tid="web-programming"/>

  <!-- second slide, explicit format, first two instances -->
  <astma:slide astma:tid="client-side-presentation-technology" astma:format="%ti %in[1-2]"/>

  <!-- same but as a followup slide, all other instances -->
  <astma:slide astma:tid="client-side-presentation-technology" astma:format="%ti %in[3-]" astma:continue="yes"/>

</slides>

The generator will remove all astma:* elements and will produce (modulo formatting):

<slides name="The Mystery Tour, 2002" 
	xmlns = "http://topicmaps.bond.edu.au/SlideML/"
        xmlns:astma = "http://topicmaps.bond.edu.au/astma/1.0/"
        xmlns:smile = "http://topicmaps.bond.edu.au/smile/1.0/">

  <institution>Bond University</institution>

  <!-- first slide, no detailed specification, so the default format will be used -->
  <smile:slide smile:tid='web-programming'>
      <smile:title>web programming</smile:title>
      <smile:types>
         <smile:type>programming</smile:type>
      </smile:types>
      <smile:inlines>
         <smile:inline>web programming implements a particular application in a client/server scenario</smile:inline>
      </smile:inlines>
      <smile:instances>server side programming, client side programming</smile:instances>
      <smile:references />
   </smile:slide>
 
  <!-- second slide, explicit format, first three instances -->
  <smile:slide smile:tid='client-side-presentation-technology'>
      <smile:title>client-side presentation technology</smile:title>
      <smile:instances>
         <smile:instance>XHTML</smile:instance>
         <smile:instance>CSS, Cascading Style Sheets</smile:instance>
      </smile:instances>
  </smile:slide>
 
  <!-- same but as a followup slide, all other instances -->
  <smile:slide smile:tid='client-side-presentation-technology' smile:continue='yes'>
      <smile:title>client-side presentation technology</smile:title>
      <smile:instances>
         <smile:instance>HTML4</smile:instance>
         <smile:instance>Dynamic HTML</smile:instance>
      </smile:instances>
  </smile:slide> 

</slides>

This XML document can then postprocessed with various backends.

The Distribution

The distribution consists of a Perl binary stm2sml.pl which makes use of a specific SAX processor to perform the transformation. This binary comes with its own documentation, but basically it is invoked like

  cat slidedefinition.stm | stm2sml.pl --urlbase=/where/are/topic/maps/ > slides.xml

Backends

Aside from transforming SlideML instances into other XML based slides presentations such as

Prestimel, or
PerlPoint

these instances can also be converted into HTML and PDF (via LaTeX and Prosper) using the Makefile in the backends directory. This file makes use of xsltproc which comes with the libxslt package.

A. Appendix: SlideML DTD

<!ELEMENT slide     (title|types|inlines|instances|references)*>
<!ATTLIST slide     title CDATA #REQUIRED
                    topic CDATA #REQUIRED>

<!ELEMENT title     #PCDATA>

<!ELEMENT types     (type+|#PCDATA)>
<!ELEMENT type      #PCDATA>

<!ELEMENT inlines   (inline+|#PCDATA)>
<!ELEMENT inline    #PCDATA>

<!ELEMENT instances (instance+|#PCDATA)>
<!ELEMENT instance  (description|#PCDATA)>

<!ELEMENT references reference+>
<!ELEMENT reference EMPTY>
<!ATTLIST reference href  CDATA #REQUIRED
                    type  CDATA 'simple' #FIXED>

]