By Dr Patricia O’Connor, Irish Postdoctoral Researcher
It’s that time of the year when many people are decorating their homes and Christmas trees, and, with that fun and festive fact in mind, it might be an opportune time to note that some ogham stones also feature fascinating decorative elements. But how do you encode these decorative details or, indeed, any aspect of an ogham stone? In a previous blog post, I discussed the History of Encoding and concluded with the promise of delivering a detailed discussion of the OG(H)AM team’s approach to encoding the specific challenges that the ogham script and inscribed objects pose. If you’ve ever wondered how to encode ogham inscriptions as well as the other idiosyncratic characteristics of inscribed objects, then read on! For our December and January blog posts, the OG(H)AM team presents twelve coding challenges for the twelve days of Christmas. Through these twelve topics, we hope to demonstrate how encoding standards such as the EpiDoc Guidelines and controlled vocabularies help researchers to address these coding challenges. Commencing with challenge number 12 and continuing in descending order, this blog post covers six of the twelve challenges for Christmas and guides you through some explanatory examples for encoding everything from the decorative features on ogham stones to the carving techniques of the inscription, including how to encode the place of origin of these incredible monuments and objects, the different languages exhibited in the inscriptions, the function or purpose of the inscriptions as well as the direction in which the inscriptions were meant to be read.
12. Decoration
Although most inscribed stones are undecorated, there are some stones which exhibit an intriguing juxtaposition of text and decoration. The Inchyra slab (S-PER-003), for instance, has three ogham inscriptions occurring at five different places on the stone but it is also noteworthy for having zoomorphic designs which are connected to the ogham texts. The smooth face of the Inchyra slab features an incised fish as well as a notched Double-Disc decoration in Fig. 1, both symbols are framed by the second ogham inscription which shares the same carving technique and could therefore be potentially associated with the decoration. While the lack of clarity makes the interpretation of this ogham inscription difficult, the element “INE” and “INNE” at the beginning of both sections could mean ‘wealth’ or ‘private possessions’.
Similarly, the rough face of the Inchyra slab shows another sharply incised fish but accompanied by a serpent this time in Fig. 2. The third ogham inscription which reads “NETU” has a clear correlation with the fish symbol as it reoccurs on other ogham stones which also exhibit fish symbols and variations of the “NETU” element in their respective inscriptions: Golspie “NET-“ (S-SUT-001) and Latheron “NETU” (S-SUT-002).
Why else might the OG(H)AM team want to encode decoration? Apart from being worthy of study in its own right, sometimes this relationship between text and decoration can be too close for comfort and negatively impact the inscription. At Mountmusic in Cork (I-COR-087), an ogham stone was inverted, affecting the interpretation of the inscription, and a cross-of-arcs was deeply cut into the original butt, damaging the first two letters of the inscription (Fig. 3).
There is also a case in Cornwall where a stone purportedly bearing an ogham inscription in addition to two Latin inscriptions was later shaped into a cross (E-CON-X03). Near the south door of St Clement’s churchyard, what was once a granite pillar-stone, is now a large stone cross complete with a carving of a cross within a circle on each face at the top. As you can see from Fig. 4, the evidence that Macalister provided for the ogham inscription was extremely deteriorated at the time and is therefore very doubtful. The OG(H)AM team has since reviewed the 3D model of the cross and, unfortunately, there does not seem to be any traces of ogham letters extant today.
In addition to having a significant impact on the inscribed object, decoration is also important for dating purposes. The stone known locally as ‘Long Cross’ at St Endellion in Cornwall (E-CON-X04) features a chi-ro monogram with a curved foot which provided Elisabeth Okasha with sufficient evidence to date the stone “from the sixth to the eighth century” (1993, 235) (Fig. 5).
Given the variety of decoration from this small sample selection alone, it would be reasonable to assume that the encoding process would be complex. Fortunately, encoding the various decorative details is wonderfully straight-forward, thanks to the EpiDoc Guidelines. The EpiDoc Guidelines recommends two possible methods for researchers to encode decoration in the Description of decoration or iconography section. The OG(H)AM team adopts the recommended method of encoding decoration in prose using the <rs> element and @type attribute. The <rs> or referencing string is a very useful element as it contains a general purpose name or referring string. In this context, the <rs> element is used to mark-up or encode any descriptive information about the decoration of the object. To facilitate indexing within the description, a keyword is added to the opening element’s tag using the @type attribute with “decoration” as the value. In adopting this approach, the OG(H)AM team ensures that every reference to decoration is consistently encoded in each file as demonstrated in the following encoding example for the decorated and ogham-inscribed antler handle (E-NFK-001) from the Norfolk Museums Collections. (Fig. 6).
All the descriptive information or data pertaining to a text-bearing object is encoded in the <teiHeader> section of an EpiDoc document. For a reminder of the structure of an EpiDoc file, there is a sample available to view and download from the Structure of an EpiDoc edition section of the EpiDoc website. The object description is found within the <objectDesc> section of the <teiHeader> and gathers the descriptions of the object’s physical components. Within the <objectDesc> section, the descriptive data about decoration is usually found encoded within the prose description delimited by the <layout> element tags (Fig. 6). The <layout> element is a child element and is, therefore, found nested under the layout description <layoutDesc> element which collects all the relevant details concerning how a text is laid out on an object and includes any evidence for decoration. More information on the above-mentioned elements is available to view online on the Text Encoding Initiative Consortium’s website: Appendix C Elements of the TEI Guidelines.
11. Placenames
The <teiHeader> element also has a specific section for information about the history and origin of an object, which leads us to our next challenge: encoding the place where the object was found. As explicated in the Original location of the text-bearing object section of the EpiDoc Guidelines, the OG(H)AM team employ the “Linking place of origin to place of finding” encoding technique. But what elements and attributes does this encoding method involve? Within the <history> element, the <origin> element is used to group information relating to the place of origin <origPlace> as well as the date of origin <origDate>. The <origPlace> element contains the placenames associated with the object and the opening <origPlace> element tag also enables the OG(H)AM team to encode additional important information using the correspondence or @corresp attribute which clarifies that the place of origin corresponds to the object’s “findspot” (Fig. 7). The <placeName> element is used to encode both the townland and county in which the object was found but we also employ the @type attribute to specify which is the townland and which is the county name (Fig. 7).
Additionally, the OG(H)AM team make a concerted effort to encode the Irish and Welsh language townland placenames by including the <foreign> element within the <placeName> element. The OG(H)AM team relies on two resources to find the Irish and Welsh placenames: the Logainm website (Fig. 8) and the Historic Place Names of Wales website (Fig. 9). The link to the Irish and Welsh placename is encoded using the reference element <ref> with the @target attribute which wraps around the <foreign> element, creating a hyperlink that the user can access easily on the database (Fig. 7).
10. Different languages
While the <foreign> element indicates that the marked-up word or phrase belongs to a language other than that of the surrounding text, there is an additional step necessary for encoding the exact language. This might be a daunting obstacle for first-time encoders, but, thankfully, the EpiDoc Guidelines has a Languages and Scripts section dedicated entirely to this challenge. As you have probably already spotted in our encoding a placename example (Fig. 7), the <foreign> element contains within its opening tag an attribute that we have not discussed yet. The purpose of the @xml:lang attribute is to identify the language of the marked-up phrase or word and this is achieved by using a specific language code (Fig. 10). To ensure that languages are represented consistently by the Internet Community, there is a Best Current Practice (BCP 47) or a standard in place for identifying or tagging languages. As specified in the EpiDoc Guidelines, the OG(H)AM team encodes the languages in accordance with the language subtag registry of the Internet Assigned Numbers Authority (IANA).
There is also a specific section of the <teiHeader> that is reserved for detailing the languages used in a project, the profile description section which is represented by the <profileDesc> element. According to best practice, you will find the list of languages that the OG(H)AM team has encoded nested neatly within the language usage or <langUsage> parent element in the <profileDesc> section (Fig. 11). Each language is encoded using the <language> element and the identifier attribute (@ident) is included in each opening tag to supply the accepted language codes for the languages found in the inscriptions (Fig. 11). So, if you have ever wondered how to encode Primitive Irish, Old Irish, Middle Irish, Pictish, Latin, English or modern Irish, then the following encoding example in Fig. 11 presents the accepted language codes that you’ll need. If you’re interested in learning how to encode Arabic, Coptic, Egyptian, Ancient and Modern Greek or Hebrew, then there is another helpful reference example provided in the Languages and Scripts section of the EpiDoc website. Once the languages have been delineated within language usage section, each language can then be referenced using the @xml:lang attribute throughout the rest of the EpiDoc document, including other sections of the <teiHeader>, as we’ve already seen while encoding placenames, as well as the <text> section of the file which contains the edition of the inscription.
9. Function
The profile description section of the <teiHeader> also contains a specific sub-section for collecting information about the nature or topic of a text, the <textClass> section. For the next challenge, we will be demonstrating how the OG(H)AM team encodes the purpose or function of a given inscription with the assistance of ontologies. An ontology is a controlled vocabulary of accepted terms and definitions for describing and defining the function of an inscription. The FAIR Epigraphy Vocabularies supply a standardised set of terms that the OG(H)AM adheres to so we can share our research data with other epigraphic projects and different disciplines. In compliance with the EpiDoc Guidelines’ Description of the Text Type section, the OG(H)AM team encodes text type information in the <textClass> sub-section of the <teiHeader> and utilises the following two elements, <keywords> and <term>. The <keywords> element has a @scheme attribute that allows research projects to include the link to a controlled vocabulary or ontology, in our case, the FAIR Epigraphy Vocabularies (Fig. 12). The <term> element has a reference or @ref attribute for containing the link to the specific term being used to define the inscription’s function (Fig. 12). Quite a lot of the ogham inscriptions that we have encoded throughout the project have a commemorative function, but the OG(H)AM team have on occasion met with an inscrutable inscription where we were unable to determine its purpose. Fortunately, as you can see from our encoding example in Fig. 12, the FAIR Epigraphy Vocabularies have us covered for each scenario.
8. Carving technique or execution type
While we are discussing controlled vocabularies, the Europeana EAGLE project is another invaluable resource for the OG(H)AM team as it provides several controlled vocabularies, one of which supplies a standard for classifying the execution technique of inscribed objects. As outlined in the Description And Layout Of Text Field Or Campus section of the EpiDoc Guidelines, encoding the carving technique of inscriptions is quite similar to encoding decoration as we employ the tremendously useful referencing string <rs> element once again. However, there are some noticeable differences that ought to be kept in mind. First, information about the carving technique is found in a different section of the <teiHeader>: the hand description section which is delineated by the opening <handDesc> and closing </handDesc> tags. The <handNote> element is used to mark-up the description of the inscription, as illustrated in this following encoding example in Fig. 13 from Ballynabortagh in Co. Cork (I-COR-005). Second, although the term conveying the manner in which the inscription was carved is enclosed by the <rs> element, you can see that the @type attribute has a different value. Instead of decoration, the @type attribute value is specified as “execution” to denote that the referencing string encoded corresponds to the execution technique of the inscription (Fig. 13). Furthermore, an additional reference or @ref attribute is included within the opening <rs> tag to contain the link to the precise term from the EAGLE project’s controlled vocabulary (Fig. 13).
7. Direction of inscription
Turning our attention from encoding information about the inscription in the <teiHeader> section, we will now focus on encoding the inscription itself within the <text> section of an EpiDoc document. Determining the direction in which an inscription was written and ought to be read is a crucial first step for interpreting ogham texts correctly, since two groups of the ogham alphabet, the B aicme and the H aicme, are interpreted according to which side of the stem line they are positioned. Usually, ogham inscriptions are read upwards from the bottom, like the inscription from the Crinnaloo stone (I-COR-082) depicted in Fig. 14.
However, there are exceptions to this and there are also examples of longer ogham inscriptions which continue across the top of a stone and read downwards on the other side, such as the inscription found in Garranes (I-COR-030) shown in Fig. 15.
For the final coding challenge of this blog post, we will be showing you how to encode the direction of an inscription following the EpiDoc Guidelines. The edition or the encoding of the actual inscription is located within the <body> of the <text> section. The edition is subdivided into two divisions using the <div> element: the @subtype attribute is used to denote that the first division is for the ogham script and the second division contains a transliteration of the ogham text (Fig. 16). Both divisions have an anonymous block <ab> element nested within to mark-up the inscription and the transliteration as textual components (Fig. 16). As stipulated in the Line Breaks: Direction of Text section, the respective beginnings of the ogham and transliterated texts are indicated by the line beginning <lb> element and it is within this element’s opening tag that we can specify the direction of the inscription using the style attribute (@style). The <lb> element in the encoding example in Fig. 16 has two attributes, the number attribute (@n) and the style attribute (@style). The @n attribute numbers the element, in this case, it specifies that this is the beginning of the first line of text. The @style attribute enables us to encode the stylistic information concerning the rendering or presentation of the source text. For the Crinnaloo stone (I-COR-082) in Fig. 14, the ogham inscription reads upwards from the bottom and this is indicated by the @style attribute value “text-direction:up” which is included in both the ogham and transliteration sections of the edition (Fig. 16). The inscription contains a personal name and is correspondingly encoded using the personal name or <persName> element and the name <name> element. The @nymRef attribute within the <name> element contains the reference to a canonical form of the name mentioned in the inscription.
For longer ogham inscriptions, like the ogham stone in Garranes, Co. Cork in Fig. 15, where the inscription occupies both angles as well as the top of the stone, we would encode the style value as “text-direction: up-across-down”. As you can see from the encoding example in Fig. 17, this inscription is a little more complex because some of the letters have been lost due to damage but there are some elements and attributes that we have already encountered in our previous examples. Hopefully, your keen eyes will have spotted that the @xml:lang attribute, which we previously discussed, is present in the opening <div> tags for both the ogham and transliteration divisions of the edition (Fig. 17). The @xml:lang attribute is used to encode the language code of the inscription. In these two previous examples, the @xml:lang value is “pgl”: the language code for Primitive Irish. Similarly, the <persName> and <name> elements as well as the @nymRef attribute are again present. There is a new element being employed throughout this example that is incredibly useful in respect to worn or damaged inscriptions. The supplied <supplied> element wraps around a letter that has been supplied by an editor and the @reason attribute value “lost” is self-evident in this scenario, representing letters that have been lost due to physical damage and later supplied by an editor (Fig. 17).
This last example is a fitting one on which to bring this blog post to a close as it effectively illustrates just how detailed the encoding process can be for inscriptions that have been affected by the ravages of time. Of course, we have many more complex examples but, alas, explaining the intricacies of encoding those inscriptions cannot be adequately addressed within this blog post. I hope that this blog post has piqued your interest and that you will look forward in anticipation to next month’s blog post on the final six coding challenges of Christmas where I will be covering: how to encode ligatured letters; how to handle errors in an inscription and how to add the corrected forms within the encoding; what to do when the letters in the inscription cannot be discerned; how to handle alternative readings of an inscription; how to adapt the encoding of the edition section to accommodate bi-lingual inscriptions; and lastly, what perhaps has been the most testing coding challenge of all, encoding the historical ogham characters. Until then, on behalf of the OG(H)AM team I would like to wish you all a very Happy Christmas. Nollaig Shona daoibh go léir!
References:
Elliott, Tom, Gabriel Bodard, Hugh Cayless et al. (2006-2024), EpiDoc: Epigraphic Documents in TEI XML. Online material, available: <https://epidoc.stoa.org/>.
Okasha, Elisabeth. (1993): Corpus of Early Christian Inscribed Stones of South-west Britain. Leicester University Press.
Text Encoding Initiative Consortium (TEI-C), “Appendix B Attribute Classes”. URL: https://tei-c.org/release/doc/tei-p5-doc/en/html/REF-CLASSES-ATTS.html.
Text Encoding Initiative Consortium (TEI-C), “Appendix C Elements”. URL: https://tei-c.org/release/doc/tei-p5-doc/en/html/REF-ELEMENTS.html.