Pottery class 1: Loading the kiln

This is the first installment of what is meant to be a case-study/learn-by-example/step-by-step tutorial on Kiln publication framework developed and maintained by a team at the Department of Digital Humanities (DDH), King’s College London. Introductory post on this subject is available here.

For the sake of familiarizing myself and the audience of this post (hello, Mum!) with the Kiln framework let’s embark on the quest of publishing the body of 16th century letters from the correspondence of Ioannes Dantiscus – taken from a project that I’ve been working on the past few years at the University of Warsaw.

First things first, we need a machine that has Java 1.7 running (or download it from here). Then we need to set up a directory for our Kiln instance and download there the Kiln files – either downloading the zip file from here  and unpacking it or cloning the Kiln’s git repository from gitHub

git clone https://github.com/kcl-ddh/kiln/

We should end up with directory structure like in the picture below so we can actually start the Jetty lightweight web server that comes with the Kiln running the build.sh script (build.bat in the Windows environment).

./build.sh

kiln-start

 

If we are successful the server’s response will be something like this:

Development server is running at http://127.0.0.1:9999
Quit the server with CONTROL-C.

This means that entering the address http://127.0.0.1:9999 in web browser should give us Kiln welcome page. A note of warning though – it may take any time from few seconds to couple of minutes until the server becomes responsive.

kiln-welcome

 

By default the Jetty server runs on the port 9999, which sometimes may cause trouble To change this we need to edit Solr and Sesame servers configuration in the webapps/ROOT/sitemaps/config.xmap file

kiln-port

editing the lines

       <sesame-server>http://localhost:9999/openrdf-sesame/</sesame-server>

       <sesame-server-repository></sesame-server-repository>

       <solr-server>http://localhost:9999/solr/</solr-server>

changing the 9999 port number into another (eg 8080) and running the Jetty server anew specifying different port number as a parameter

./build.sh -Djetty.port=8080

Next step is to upload our TEI files. These need to be placed in webapps/ROOT/content/xml/tei subdirectory. Kiln default expectation is these should be valid TEI/XML files that start with TEI element as a root element, with TEI namespace declared on it and in addition this TEI element has xml:id attribute with a value that is the same as the filename (without .xml extension). So the letter with xml:id of IDL0004 needs to be saved as webapps/ROOT/content/xml/tei/IDL0004.xml file. Hopefully you don’t mind the default settings so let’s proceed and download all our TEI files here.

kiln-filename

 

Now, returning to the web browser let’s click the Texts tab and we should see the list of all uploaded texts

kiln-textsdefault

 

Depending on the information in teiHeader part of the files some of the fields in the table  above  may be empty. To see individual file processed with default Kiln XSLT click on its name.

kiln-singletextdefault

 

Now we might want to try searching your files. Don’t be disheartened if this returns no results. For the Kiln to be able to query the files the collection needs to be indexed with the Solr engine that is a part of Kiln responsible for the searches. To do it, go to the Admin tab and choose Index all (search) button.

kiln-index

 

And with any luck we’ll be greeted with this:

kiln-indexresults

 

Happines abounds – now queries do return meaningful results

kiln-searchresults

 

Satisfied? Probably not. This is how Kilns look and feels straight out-of-the box. How to tweak it is another matter… I’ll keep you posted.

Posted in Uncategorized | 3 Comments

3 Responses to “Pottery class 1: Loading the kiln”

  1. Lou says:

    I get as far as that too — but when I click on the title of a document containing a hit (one of the blue lines in your last image above), something dies.

    Ah! The first line of the stacktrace says
    “java.io.FileNotFoundException: /home/lou/Downloads/kiln-master/webapps/ROOT/sitemaps/../kiln/sitemaps/../../sitemaps/../content/xml/tei/RID_0007.xml (No such file or directory)”

    could it be that, not content with wanting me to supply a redundant xml:id for each document, this pesky system also requires me to name the file after it ????

  2. Magdalena Turska says:

    Yes, that’s the idea – the files should be named after the xml:ids.

    • Lou says:

      That’s completely bonkers, as I am sure you agree. The file name has nothing to do with the XML structure. I might want to have lots of different (small) elements in a single file. I might have a (large) element split across multiple files and use xInclude to combine them. It also clutters up the interface : the list of documents now has two identical columns in it!

Leave a Reply