Ajax Timelines and the Semantic Web

Evolution supports time events on a calendar display. Because Timeline is lightweight and completely browser-based it also can be used on many pocket-sized devices. It might be handy to export your Evolution calendar information into a Timeline file to take on the road with you.

I'm using Evolution version 2.6.3; later versions may have fixed some of the following issues.

To export your Evolution calendar, right-click on On This Computer/Personal, and choose Save to disk. There are two ways to arrive at an RDF result: directly exporting as RDF and exporting to iCalendar format and converting that to RDF later.

The major problem in exporting events from Evolution is exporting recurring events. In a direct RDF export, only the first instance of a recurring event will be present in the result. In an iCalendar export, you will have an RRULE tag for the event that contains the information about the recurrence. Unfortunately, the w3.org's fromIcal.py (which converts iCalendar to RDF) is confused by this RRULE.

When exporting directly to RDF, you might encounter the use of the deprecated RDF feature of not explicitly namespacing the rdf:about tag. Jena provides warnings about the implicit namespacing, and unfortunately, they are on stdout instead of stderr. We want stdout to contain only a valid RDF document from our query. The little bit of sed at the top of the commands in Listing 14 will properly namespace the about tag and thus silence Jena. The mycal.rdf is exported from Evolution.

$ sed 's/<Vevent about=/<Vevent rdf:about=/g' \
   mycal.rdf >|mycal-clean.rdf
$ java jena.sparql \
   --data mycal-clean.rdf \
   --query  evolution-to-timeline.rq \
   --results xml >| evolution.xml
$ xsltproc sparql2timeline.xsl evolution.xml \
   | tr '\n' ' '  >| evolution.json

The SPARQL query shown in Listing 15 uses the same names in the SELECT clause as the blog query SPARQL. Because many calendar events will have a duration, I have added the enddate to the SELECT clause.

By using the same names in the SELECT clause, we can use the same sparql2timeline.xsl file with a few minor modifications to produce our JSON data for the Timeline. The differences to sparql2timeline.xsl are shown in Listing 16.

...
<xsl:variable name="date">
  ...
</xsl:variable>
<xsl:variable name="enddate">
  <xsl:call-template name="escape">
  <xsl:with-param name="text"
 select="res:binding[@name='enddate']/res:literal"/>
  </xsl:call-template>
</xsl:variable>
...
</xsl:variable>
 {'start': '<xsl:value-of select="$date" />',
 'end': '<xsl:value-of select="$enddate" />',
 'title': '<xsl:value-of select="$title" />',
...

The driving HTML file can simply be a copy of the planet.html, modified to include evolution.json instead of planet.json.

Filesystem information could be written directly to an XML Timeline file as was done in the syslog section above. Generating RDF from filesystem searches allows you to use different SPARQL queries at a later time to refine your Timeline.

The results of the find command can be turned into RDF quickly with Perl and Redland. The Redland library follows the ./configure; make; make install; three-step process. Installing the Perl bindings requires that you configure the bindings package enabling the Perl wrapper, as shown in Listing 17.

tar xzvf redland-bindings-1.0.4.1.tar.gz
cd redland-bindings-1.0.4.1
./configure  --with-perl
cd ./perl
make
make install

The script shown in Listing 18 transforms null-separated output from a find invocation into an RDF file. The inode for each file forms the subject in the output RDF. The metadata for each file is associated with its inode subject. A few things of note: I create a shortened version of basename to serve as the label on the Timeline, and the mtime is converted into a string representation in RDF. Currently, Timeline doesn't display any label for time event labels that are too long. Also, the description will show the file's contents in the click bubble for each event.