Wrapping it Up: TeiDisplay and Collaborative Mentoring with UT/UVa

I’m very excited to announce that my colleague Zane and I have completed our work on the TeiDisplay plugin for Omeka! It’s been a little while since I last posted, so if you’d like some background, check out our previous posts on this collaboration between the Scholars’ Lab and the University of Texas School of Information. We have made several changes/additions, though the final product isn’t quite ready for release yet.

– We fixed a few bugs in the import process from the TEI Header to Omeka’s Dublin Core fields. Additionally, we created a map detailing which fields correspond to which elements. This map also explains how users can customize the import process if the current setup is not optimized for their documents.

– The main XSLT stylesheet now supports every element in the TEI Lite customization. We also reorganized it, adding headers to correspond with the headers in the TEI Lite documentation where particular elements are discussed, so that those who are familiar with XSLT can find and edit elements easily. At a minimum, in the transformation process each tag is given a <span class=”TagName”>, and many have additional styles as well. This way, we guarantee that a defined set of elements will render in the document. Users unfamiliar with XSLT can also use these span classes to customize the style of their documents using CSS.

– Some of the elements that have been styled for more than just a span class may special requirements in order to render, such as specific attributes that need to be included in the TEI text. We have written a series of formatting tips to help users understand what the XSLT is looking for when it attempts to render the documents.

– The plugin now has functionality to link TEI text to corresponding page images. This is done using the @facs attribute with the <pb> element. Further details on how to use this feature are provided in the documentation.

– We outlined a number of small changes that a user can make outside of the plugin code itself in order to improve functionality. For example, when displaying longer documents, users might wish to create an anchor that allows readers to jump directly from the top of the page to view the item metadata, which is usually at the bottom. This is done on one of the Omeka PHP documents, so it isn’t officially part of the TeiDisplay package, but we include the appropriate code in our documentation and describe where to put it.

– We’ve written a number of troubleshooting tips, as well as a more detailed guide to installing the plugin and updating documents.

I’m very happy with the changes we made to the plugin, but I think that overall, they were not as extensive as I expected going in. I think the real value added with this project was the extensive documentation we’ve created, as well as a demo site that gives examples of the plugin in action. Armed with this documentation, users will not only be able to better understand how the plugin works with their documents out of the box, but they will also be better able to customize it to fit their needs.

Over the coming months the Scholars’ Lab will be conducting more rigorous testing of the plugin as well as making some other additions. Hopefully, the final product will be ready late this summer.

Thanks very much to Wayne and Bethany at the Scholars’ Lab, and to our adviser Tanya Clement at UT, for giving us the opportunity to be a part of this project!

Carin Yavorcik is an information studies graduate student at the University of Texas at Austin, where she is especially interested in archives and digital collections. She is currently working with the Scholars' Lab on a TEI plugin for Omeka.


  1. Hi Carin,

    We are interested in this plugin and would like to know if you have any plan to upgrade it to Omeka 2.x.


  2. Ah.. I see you’ve already addressed both issues in your documentation (which I should have read first!).

  3. It’s great to see renewed work on this plugin as support for text centric archives & exhibits is something that is still quite weak in Omeka. It’s much better (in my view at least) for image based collections in a model where the lowest common denominator, or better, base unit of research is a single image accompanied by some metadata.

    On my personal wish list for someone to take this work further would be:

    1. The ability to use Omeka’s standard full-text search for items inside Exhibits. This currently (AFAIK) does not work. Take the Wuthering Heights Exhibit demo for example. Vol. 1 Chp. 1.13 includes the word “crocuses”. But you can’t search on this word in Omeka’s default search.

    2. The ability to view facsimile and transcription (or rendering) side by side (or perhaps alternately via tabs) and to have next/previous page selections on one representation be reflected in the other ones as well. That is, if I forward a page in the facsimile the adjacent transcript should forward as well.

    Fixing/adressing these two issues is not the responsibility of the TEIplugin of course! From what I gather from responses in the Omeka Forums the former would require some significant changes to Omeka while the latter might (I’m guessing) be doable via a new layout in the Exhibit Builder plugin.

    Regardless.. the TEI plugin gets several steps closer to being able to use Omeka for many text based digital edition projects. I’m looking forward to playing around with it some more to better learn how it works.

  4. Hi Carin and Zane, congratulations on the site and the documentation. I think this raises many issues concerning the interaction of TEI (a text-based system at its heart) with Omeka (which seems inherently image-based).

    As I mentioned in our email correspondence, the project group in which I was involved faced some similar issues, having chosen Omeka as a presentation layer for a correspondence project (rather different in handling many small TEI files, with matching images).

    I find it very interesting now to look at your documentation, as there are two issues in particular which arose for us as well but which we handled differently.

    The first concerns the images corresponding to the text. As Omeka expects to find them in a particular place and renames them on upload, I decided simply to provide them with the meaningful names expected by my encoding collaborators, and to place them outside the Omeka ingester (so far, this hasn’t caused any issues, but there are only 130 or so image files). We also decided to use the ‘facsimile’ tag rather than the @facs attribute on the milestone.

    The other workflow issue was concerned with bulk import of the xml files. After a long struggle (!) I finally abandoned an attempt to use a modified csv plugin and instead modified the Dropbox plugin to call the TEI import routine (anyone who wants the code is welcome to it! there are conceptual issues involved in the way I asked the code to handle the files, but it could easily be made to work a slightly different way).

    We were using a custom schema, and we addressed a lot of the presentation and linking in the XSLT. In fact, this began to make us think that perhaps we were trying to make Omeka behave more like an eXist-based system, and just using the presentation and search layer as a springboard to provide a user interface…

    I shall be very interested to see where the plugin goes from here! I feel that it should be possible to construct (programmatically) a custom element set based on each schema and so retain the richness of the TEI metadata, but perhaps this would just make life complicated!

    I don’t want to post the url for our site publicly as it isn’t ‘live’ yet, but please feel free to let anyone who expresses an interest have it privately.