Text and Graphics is one of currently 10 active Special Interest Groups (SIGs) within the Text Encoding Initiative (TEI). Although the TEI is concerned first and foremost, as its name suggests, with the encoding of text, users of the TEI Guidelines will often also want to encode information relating to graphics which occur either as digital facsimiles of the text pages or as inline figures within the text. The Text and Graphics SIG aims to “discuss, develop, and document various strategies and best practices for implementing the digital facsimile structures available in TEI P5, especially as relates to graphically rich texts, and for developing methods to extend the TEI when existing structures are not suitable” (https://wiki.tei-c.org/index.php?title=SIG:Text%26Graphic). The SIG usually holds an informal meeting during the annual TEI Conference and Members’ Meeting.
Accordingly, this year’s SIG meeting took place in Graz, Austria, on September 17. To a small but select audience, Uwe Sikora (Göttingen State and University Library, Germany) kicked off the meeting with a presentation of a software application he is developing for the “Ilanot – Maps of God” project (http://ilanot.haifa.ac.il/site/, SUB Göttingen / University of Haifa). In this project, kabbalistic parchment scrolls containing “divine topographies” will be edited in the form of interactive maps. Uwe’s tool, which is based on the VGG Image Annotator (VIA, http://www.robots.ox.ac.uk/~vgg/software/via/) and runs within the Virtual Research Environment TextGrid (https://textgrid.de/), enables users to select portions on a digital image in the shape of rectangles, polygons, paths, circles, ellipses and points.
These shapes are stored as SVG code that contains coordinates to record their position on the digital image.
The SVG shapes are linked to TEI code in which the selected scroll sections are encoded as tei:zone elements. Using a Graphical User Interface, semantic relations between these zones may be defined by arranging them in a hierarchical structure.
Furthermore each shape may be annotated by custom metadata and tagged according to a custom ontology:
Textual content of the scrolls can be transcribed and added to the resulting TEI document in the usual way, which may then be presented – in their respective positions, as indicated by the SVG code – as an annotation layer on top of the image. A standalone version of the application is going to be developed to provide non-TextGrid users the possibility to annotate image files on their own system and create TEI resources locally.
This approach ties nicely into a discussion that we have had in the SIG and the wider TEI community since at least the 2016 meeting in Vienna: are the current TEI Guidelines sufficient if we want to encode the position of zones in a non-TEI format? The corresponding GitHub Issue is https://github.com/TEIC/TEI/issues/1508, if anyone would like to weigh in. The idea is that some encoders prefer other formats such as JSON or SVG over the att.coordinated attributes (https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.coordinated.html) available in tei:zone (as well as in tei:surface and tei:line). One motivation behind this might be that other formats offer more options for defining shapes, e.g. circles which in SVG are simply encoded using x and y coordinates for the circle center and a third attribute for the radius. Another motivation might be interoperability: some applications may output coordinate data as e.g. JSON files which one would like to refer to directly from the TEI document, while some applications may require e.g. JSON as input – perhaps the most prominent example being IIIF applications – and one does not want to store the same coordinate data twice, in both TEI and JSON.
There are three possible solutions:
- Leave everything as it is. In the TEI document, semantically vague linking mechanisms such as @corresp may be used to refer to the non-TEI code, or in some cases it may be stored directly somewhere in the TEI file using its own namespace. Applications need to be configured on a case-by-case basis in order to make use of such coordinate data.
- Augment the TEI Guidelines so that TEI can express anything you want. For instance, if you would like to encode a circle in SVG style, a tei:circle element and @radius attribute need to be introduced. If other formats are still necessary for interoperability reasons, the TEI data can then be losslessly converted.
- Keep coordinate data in non-TEI files, but introduce a semantically strong linking mechanism so that the TEI code explicitly tells you what to expect at the other side of the link. For instance, a new attribute named @pointsRef would mean: “this link refers to coordinate points for the parent element”. Add some MIME type information, and relatively generic applications could be created that would know how to process e.g. SVG or JSON coordinates when they are explicitly referred to as such in a TEI document.
So far, no consensus has been reached about this issue, but questions of how TEI data and non-TEI data interact become more and more urgent as technologies such as IIIF rapidly rise in popularity.