1.1 A critical mass of data

§ 3 Within the framework of DigiByzSeal, the standard established in SigiDoc is currently being updated and further developed, and, after an intermediate version 1.1 with some minor changes, its 2.0 version is currently in the process of being released. SigiDoc 1.0 was based on the personal experience of its developers, and only a very small number of seals (about 40) had been encoded. For that reason, it was of the utmost importance in updating it to take into account a large, but manageable, amount of data. The DigiByzSeal team plans to work on about 4,000 seals: of these, about 3,000 are unpublished, housed in two French public collections (the Zacos collection at the Bibliothèque nationale de France and the collection of the Institut français d’études byzantines, both in Paris) and one German private collection (that of Robert Feind, in Cologne); the remainder of the seals come from two published collections, the Seyrig collection (Cheynet, Morrisson, and Seibt 1991) and the Tatış collection (Cheynet 2019). It should be noted that, even though these collections are among the most important in the world, and scholars have been awaiting their publication, in some cases, for decades, the edition of these seals is not, in itself, the main focus of this project: these seals provide the data, case studies, and a long list of issues that are necessary for us to be able to enhance, amend, and expand SigiDoc. Half of the planned seals from the Institut français d’études byzantines are ready to be encoded, about 200 from the Feind collection have already been encoded, and the entirety of the paper published seals of the Seyrig collection has been digitally enhanced, while thus far only the editions of the legends have been encoded for the seals in the Tatış collection.

1.2 The challenges of digitally enhancing a paper publication: Some remarks

§ 4 Working on unpublished material is extremely different from working on published seals. With the former, the encoder can apply the SigiDoc recommendations more comfortably because they are working with an unexplored object, whereas when it comes to the latter, the encoder has to deal with the previous editor’s choices, which raises questions of the nature and the extent of any digital enhancement. The conversion of a publication into a digital form could be an appropriate moment for the creation of a revised edition; this would perhaps be especially useful for those publications that are not recent, as they could thus benefit from the contribution of material that had been subsequently published, in particular data from parallel seals, which would allow for the improvement of the edition and, in certain cases, also of our understanding and therefore of the historical commentary. But even taking a very conservative approach, and not producing a new edition, it is not possible to preserve the editor’s choices and at the same time to consistently use the SigiDoc recommendations because the former are not always consistent. Thus some ad hoc solutions must often be proposed, as we will see.

§ 5 Figure 2 gives an example of how an editor has transcribed the legend struck on the reverse of an 11th-century seal in the Tatış collection. This edition raises several problems from a SigiDoc point of view. First, at the beginning of the legend, the diacritical signs used reveal the difficulty of providing an appropriate interpretation because the beginning of the inscription was left outside the support when the seal was struck; but on the other hand, solutions such as the use of white space do not tell us much, especially if this is being read by a machine. Second, again at the beginning, the diplomatic transcription (first line of Figure 2) and the editorial interpretation (second line of Figure 2) do not seem to be aligned with each other. And third, the fact that the editorial interpretation is edited on one single line hinders the alignment with the diplomatic transcription and, especially in the case of lost and restored texts, does not show the reader where, in the editor’s opinion, the lines begin and end.

Figure 2

Example of the transcription of inscription from a seal from the Tatış collection (Cheynet 2019, no. 3.44).

§ 6 For these reasons, the solution currently adopted by the project is the following:

After its transformation using the EpiDoc stylesheets partially modified by SigiDoc, this inscription can be visualized as seen in Figure 3.

Figure 3

Example of the transcription of inscription from a seal from the Tatış collection (Cheynet 2019, no. 3.44) after transformation.

§ 7 This example, and many other similar ones, demonstrate why one of the major endeavours of DigiByzSeal is the enhancement of the SigiDoc guidelines, starting with the section devoted to the encoding of the legend, known as “leidenisation” (Sopracasa et al. 2023): as a text-bearing object, a seal requires the application of conventions for the representation of non-verbal information such as lacunae, abbreviations, and so on through the use of symbols, brackets, and dots. The set of conventions adopted by SigiDoc is directly inspired by EpiDoc, with variations intended to make some of them more suitable for Byzantine sigillographic routines. Note that this does mean that some solutions, such as those adopted at lines 1–3 in the example in Figure 3, are more familiar to epigraphers and are not widely used (to say the least) by Byzantine sigillographers; but their adoption was necessary in order to get a clearer and unambiguous edition, as the previous example clearly demonstrates.

1.3 Updating the guidelines and the template

§ 8 The current updating of the Guidelines relates to better explanations of when the various encoding recommendations should be used, giving many more examples (which come from the increasing number of digital editions produced by the project). For example, the use of <gap/> for lost lines has turned out to be not so self-evident, because <gap/> is also used for lost characters, which raises the question of which way of indicating a missing line or missing characters is the most appropriate in specific circumstances. What we recommend is to give as much information as possible: if a line is entirely lost or illegible, but the editor is able to state with certainty the number of characters that formed it, or can give a reasoned estimation, then the solutions would be to code either:

or

Otherwise, the part of the inscription relating to the lacuna should be encoded as a lost or illegible line:

In this case it is important to note that, if the loss involves a known quantity of lines—more than one—the tag should be repeated separately for each line. As well as the issues with <gap/>, the use of combined tags, such as <supplied/> for lacunae and <expan/> for expansion of abbreviations, needed to be clarified.

§ 9 But the encoding of a seal’s legend is just one part of a SigiDoc edition: the SigiDoc template, which provides the structure for an edition, has been prepared to encode all the necessary data, such as the seal’s physical description, its history and dating, the edition of its legend, the critical apparatus, any commentary and bibliography, and so on. The stylesheet responsible for the transformation of the template into a web page readable by the final user has undergone several changes in the update: some field names have been changed in order to make them clearer (for example, in describing the appearance of the text, “lettering” has become “epigraphy”), while others have been moved in order to be better grouped with similar fields. In addition, to enforce consistency, best practice for the use of the template involves controlled vocabularies for elements and attributes: some lists of terms or attributes have been expanded (for example, for the “object type” field, the original “seal” has been joined by “marker,” “seal [uniface],” and “token”), replaced (“lettering” was renamed “epigraphy,” as noted), or simply deleted, and the new attributes’ values have been added to the SigiDoc schema. More guidance on how and when to use each vocabulary item is currently being added to the Guidelines.

§ 10 Even more importantly, some redundancies have been deleted from the template itself in the upgrade to version 2.0: some data was stored in such a way that it needed to be encoded twice, once for the visualization after transformation through the stylesheet and once for the machine, so that it would be available for uses such as indexing and searching. This can be seen in the following example, from the unpublished seal Feind S-112:

As is clearly visible here, the element <interp/>, designed for displaying the information on a web page after transformation, encodes the same data as the @evidence attribute of the <origDate/> element. In the newly “polished” template, the use of <interp/> is now deprecated and the information, for both indexing and displaying, will be taken from @evidence, which has a predefined list of values added to the schema. For displaying on the web page, these values will be presented with an appropriate orthography (e.g., a value such as “historical-context” will be printed as “Historical context”) and translated into the modern language used by the editors of the corpus.

§ 11 In some other cases, redundancies existed because of the need to take into account the two faces of a seal: that is, some information relates to the whole object, while other information is about only the obverse or the reverse. Consider the following example. In the current SigiDoc template, the elements that are responsible for the description of the appearance of the whole seal, visualized after transformation in a field “General layout,” are:

Inside the <seg/> element the layout of the whole seal should be described according to a necessarily controlled list of terms describing the three recurrent features of the Byzantine seals: iconography, legend, and monogram (with the addition of an “undetermined” option). However, this same information is also encoded for each of the faces of the seal, using the same terms:

The only change here is the value of the @n attribute, which is “r” for obverse or “v” for reverse. This redundancy has been solved in the update by deprecating the use of the element <rs @type=”layout”/> inside <layout @n=”whole”/> and keeping it only in the <layout> element for obverse and reverse. On the final web page, the field “General layout” will be filled in with the information encoded in the latter two elements, again according to the same controlled vocabulary, such as “Iconography, Legend,” “Monogram, Iconography,” and so on.

§ 12 The few other redundancies have been solved in similar ways, thus allowing the complexity of the schema to be reduced. As a result, the editors can work more easily within the XML edition files, and the tagless editor (see Section 1.5) is also simplified by these measures. Improvements such as these seem simple from a technical point of view, but they require a lot of discussion within the team and, because they affect the data and the way it is collected, they must be done carefully, as they have a profound impact on the work of the editors.

1.4 A chained schema

§ 13 Another key component of SigiDoc is currently in the process of being modified: the schema. In its 1.0 version, the SigiDoc schema was aligned with EpiDoc schema 9.2: the latter was considered in its entirety; some of its parts were identified as the most appropriate for SigiDoc, and, in some cases, these were then adapted to the specific requirements of Byzantine sigillography. SigiDoc XML files have been successfully validated against EpiDoc schema 9.2 and the tei_all schema. However, since the intention is to maintain alignment with TEI through EpiDoc, the need arose to find an effective and reliable way of managing the SigiDoc schema.

§ 14 The chosen method is the preparation of a chained ODD (“One Document Does it all”) (TEI Consortium 2024a). The preliminary work was already done in preparing SigiDoc schema 1.0: this file was basically the file of EpiDoc schema 9.2, but modified for SigiDoc, and all the parts that were simply selected or were modified for SigiDoc had already been highlighted. A SigiDoc ODD chained to the EpiDoc schema is currently being edited accordingly, and it will be the first chained ODD of the EpiDoc schema: the work in progress is also aimed at aligning the SigiDoc schema with version 9.5 of EpiDoc (the latest version available at the time of writing this article), both subsetting and supersetting it.

§ 15 A very small example of this concerns the element <supplied/>, used in the edition of a seal’s legend to encode some restored text. This is a case where the SigiDoc schema is more restrictive than EpiDoc’s schema when it comes to the attributes, so it is worth presenting the whole “genealogy” of it, starting with the tei_all.rng schema below (available at TEI Consortium 2024b):

Compared to the broadness of this element in the TEI schema, the EpiDoc customization (following the EpiDoc ODD 9.5; see Bodard et al. 2023) introduced a major restriction, making the attribute @reason required and not optional (as it is in the TEI schema), and with a closed list of constraining values. In addition, EpiDoc explicitly introduced an optional usage of the attribute @evidence, with a list of suggested values, while in the TEI schema, @evidence was generically part of the editLike attributes. The EpiDoc customization is:

The SigiDoc ODD inherited the changes made by EpiDoc and has introduced one more value for @evidence, without changing the behaviour of the list:

§ 16 The Schematron language integrated into the ODD schema has also allowed additional constraints, in particular the use of conditional expressions. It sometimes happens, in particular with widely used attributes such as @type and @subtype, that a specific value of the one attribute implies the presence a selected list of values in the other, and a <constraintSpec/> element allows the encoding to focus on the appropriate values, as in the following example, relating to the element <provenance/>:

All of the relevant values are described in an <attList/> element right after the Schematron constraint cited here.

1.5 The authoring environment: A tagless editor

§ 17 A major step towards the creation of an authoring environment that is able to support the editorial work and consistency in the encoding endeavour has been the development of a tagless editor (see Figure 4) based on a BaseX database providing APIs in combination with a Vue.js Javascript front end, which is currently under development (SigiDoc Editor 2024). This tool, associated to the SigiDoc schema, template, and stylesheet, allows metadata (it is not yet possible to encode the legend) to be entered into the SigiDoc template without seeing the template itself, thus making it accessible to those who do not have specific training in XML and the SigiDoc standard. In addition, the tool provides a pre-visualization of the compiled fields, and more broadly, of the final web page. Note that the provision of this tool is by no means an invitation to avoid learning XML and gaining training in SigiDoc, because encoding is not a mere action of filling in empty fields. Rather it should be seen as an effective way to verify the completeness and the consistency of encoding that has already been done.

Figure 4

The interface of the tagless editor. On the left are the fields to be filled in with the edition data; on the right, the pre-visualization of them.

§ 18 The editor will support the editing of data by automatically integrating the various authority lists that are created and implemented during the editorial process (see Section 2.2). This will simplify the encoding thanks to the ability to use auto-completion and the suggestions that can be automatically made for at least a part of the annotation work. In order to be effective, it is important for this tool not to be too restrictive and intrusive to the point of overly restricting the variety of data that a user will need to enter. On the other hand, the fact that the controlled vocabularies for elements and attributes developed for SigiDoc are integrated into this tool, coupled with the automatic validation offered by the editor, will mean a reduction in the number of errors during the creation of the XML files.

2.1 EFES: Indexes and search form

§ 20 The tool that allows seal editions created with SigiDoc to become a proper digital publication is EFES. This was created as a customization platform for EpiDoc files, and was adopted by SigiDoc in 2017. EFES has since been adapted to the requirements of SigiDoc and of Byzantine sigillography and is the main way to present SigiDoc editions, with a web interface, indexes, and a search form. The platform thus allows extensive control over the editorial process at an individual level. Because EFES is the means by which the encoding work done with SigiDoc is presented to the final user, a great deal of attention has been paid to this platform from the beginning of DigiByzSeal. The list of indexes and the search form of the original EFES version created for EpiDoc had already been changed during the development process that led to SigiDoc 1.0, and these changes can be seen in the test corpus published then (now considered deprecated; see SigiDoc 2024a). These features have been changed again while preparing the version 2.0 of SigiDoc, as listed in Table 1. The major change that has been made so far to indexes for version 1.1 relates the first index, which is the prosopographical repertoire of the sigillographic edition: it has been renamed more appropriately as “Persons” instead of “Personal names” because it is not an onomastic list. In addition, there is only one index for “Offices,” which groups together the three types of functions of the Byzantine administration found on seals: the type of office—civil, military, ecclesiastical—is recorded for each entry.

§ 21 Perhaps more importantly, these indexes have been made interoperable with external data: columns have been added to the persons and place names indexes to link the data to external prosopographies, such as the Prosopography of the Byzantine World (PBW) (Jeffreys et al. 2017a), and to the Pleiades gazetteer (Stoa Consortium 2024); many other implementations of the same kind are planned during the next months.

§ 22 The decision was taken to limit the indexes to a short list covering the major features coming from the seals. Conversely, a more detailed list of search filters has been created in order to allow for a more granular search. Besides the topics already in the indexes, it is also possible to perform queries for repositories and collections, for onomastics, and for specific types of offices. On the other hand, topics such as invocations or lemmata have not been included because they offer limited possibilities of interaction with the other filters in order to refine the search.

2.2 Authority lists

§ 23 In order to create indexes and search filters, EFES uses authority lists in XML files. These lists contain all the data that a specific edition considers to be of importance: they are the essence of what legends offer to sigillographers and to historians. These lists contain a regularized version of names and terms and act as a set of controlled vocabularies to ensure consistency and interoperability within the same project and across projects: this is the reason that they cannot be the “possession” of a single project, but must be shared by all SigiDoc projects, each one enriching them for the use of all.

§ 24 All the changes to indexes and search filters mentioned above lead to changes to the corresponding authority lists. If one takes the index of “Offices,” for example, all the offices are listed in one single XML authority file, organized according to three <list/> elements, each with a different @type attribute (civil, ecclesiastical, military). The terms are nested inside the <list/> with <item/> elements, in which all the variants (excluding formal variants, i.e., different ways to write the same term) of a function are grouped together. This can be seen in the following example, in which the office of judge is recorded as such—under <list type=”civil”/>—but also together with the different types of judge and different geographical areas over which a judge might exercise their duties, each one having its own identification number:

§ 25 The management of prosopographical data is one of the most challenging aspects of Byzantine sigillography, both for “analog” as well as digital data sets. And, of course, information on persons is traditionally what specialists, and more broadly researchers, are most likely to be looking for in a sigillographic edition. Thus this has been an area of considerable work in the development of SigiDoc by the DigiByzSeal team.

§ 26 The first solution that was adopted by the project for the problem of processing this type of data was to enhance the authority list, in accordance with the use of EFES and with what has been done for the other types of data. Consequently, the prosopographical authority list of SigiDoc 1.0 has undergone a deep restructuring to make it responsible for the “Persons” index and for the search filters “Persons,” “Personal names,” and “Family names.” Let’s consider the example of Romanos Kourkouas, a military officer of the 11th century. In version 1.0 of the prosopographical authority list, there was nothing more than a regularized form of the forename and of the surname, encoded together, with the corresponding xml:id. In version 1.1, on the other hand, the DigiByzSeal team has encoded a lot more information: “forename” and “surname” together and separated, their original and regularized forms, the edition from which the data comes, gender, dates of birth and death or period of activity, and bibliographic references (in particular, links to external prosopographies):

With only one instance of markup and a single authority list, three different search filters and an index are generated. In addition, this allows two problems—of opposite types—to be avoided. On one hand, it avoids multiple duplicates in the onomastic list (the “Personal names” and “Family names” filters), where people with identical forenames or identical surname need to be grouped: for example, all the “George(s)” in the corpus need to be collected together by the “Personal names” filter as “George,” even if they are not the same person. On the other hand, in the prosopographical (i.e., real persons) list, there is the opposite problem, in that the homonyms that are different persons have to be separated: in this list, different “George(s)” must be separated if they are different persons just bearing the same forename but, conversely, grouped together when there are multiple mentions of the same person bearing the forename “George.”

§ 27 This solution solves several problems. However, the prosopographical list is far and away the most demanding list to maintain over the medium to long term, especially for a project that aims at sharing its foundation files with other endeavours using SigiDoc and EFES. This list is an ever-growing file, with an unpredictable input of data as the number of seals published and/or encoded increases: there are always new persons or new mentions of already known people to be encoded. In contrast, the other authority lists tend to be relatively stable, and, importantly, they do not present any challenge related to homonymy, disambiguation, or the identification of the same individual across multiple seals, whether those seals are parallel or span different phases of a person’s career. For this reason, the DigiByzSeal team decided to adopt a completely different approach: instead of bringing the seal to the authority file, the idea is to embed the authority information into the seal’s XML edition file. A list of the persons cited by the seal (i.e., the issuers or owners of the seal) is to be created in the TEI header, inside the <sourceDesc/> element together with the metadata of the edition—for example:

The <listPerson/> allows for more than a single issuer (i.e., there may be several <person/> elements within it); this is often the case with imperial seals or seals issued by fiscal agents known as kommerkiarioi. In the <person/> element, a @sameAs attribute is used to refer to the same person if they are already attested on other seals in the corpus; its value is the SigiDoc ID of these other seals (on which, see Section 2.3), and there can be more than one value.

§ 28 Note that within the XML edition file of the seal, the Greek spelling of the full name is presented only in its regularized form, followed by a translation (or transliteration) into modern languages. The prosopographical index will present the full name, in Greek, while among the search criteria there will be only onomastic lists—one for the first names and the other for the family names—to allow for a broader or, alternatively, for a more specific search as needed, since these filters can be applied individually or in combination. For accessibility purposes, these onomastic lists will be populated with the English versions of the names (this is the default translation into a modern language), while the translations into other modern languages will be available through the string search, allowing searches for, for example, Ἰωάννης, John, Jean, Giovanni, and so on. For example, to find Romanos Kourkouas, one would perform two queries, one for “Romanos” and the other for “Kourkouas”; otherwise, selecting “Romanos” only, the result will give all the persons with this forename, including the Romanos with “Kourkouas” as a family name (and similarly if one selected “Kourkouas” only). The “original” spelling of the name, as it appears on the seal’s inscription, will be taken directly from the edition. Finally, <listPerson/> being a prosopographical element, it is not only appropriate but also necessary to associate this kind of data to already existing prosopographies, referring to their own ID, and explicitly linking to them if they are online, or simply encoding their IDs if they are non-digital resources.

§ 29 Before going any further, it is important to point out that physical persons were not the only ones to use seals: many were struck by institutions or groups, in different milieus, such as the Church (e.g., the priests of Hagia Sophia, the patriarchal see of the empire, or individual monasteries), the civil administration (e.g., the kommerkia, i.e., the fiscal services), and so on. These issuers cannot be encoded with elements designed for persons, and so a <listOrg/> element—structured in a way mostly parallel to <listPerson/>—has been added to the schema and to the template:

§ 30 The other major decision recently taken about the prosopographical data is not to assign an identifier to persons in the XML edition files, for a number of reasons. First, despite the importance of this kind of data for Byzantine studies, we are not preparing a prosopographical repertoire; our starting point is the seal, not the person. Second, the choice made by the project to have shared and common authority lists raises a major problem of coordination, and this is much more important for the prosopographical data than for other authority lists: it is particularly difficult to ensure in the long term that there is consistency in the attribution of person identifiers and to avoid duplication of entries for the same person. In addition, even if this means that the prosopographical information must be encoded in every XML edition file, this solution is not a burden, and it does not really introduce redundancies across the different edition files. In fact, it makes the encoding simpler and quicker compared to the earlier solution. Previously, as explained above, a prosopographical authority list laid behind indexing and searching and, in the edition template, a now deprecated element <author/> was used to encode data on the issuer of a seal, specifically for the purposes of visualization on the web page after transformation. This introduced a coding duplication, in addition to not being an entirely satisfactory solution, as it had several limitations. In the new solution, both these tasks are dealt with by <listPerson/>. Now the issuers mentioned in the inscription are identified with their seals, which have IDs (see Section 2.3).

§ 31 However, discarding the prosopographical authority list and person IDs does not mean there is no persons list at all. Instead, the raw data encoded through the <listPerson/> elements now provides the foundation of the list. This data can be regularly extracted—at intervals based either on a fixed number of newly encoded seals (e.g., every 200 seals) or on a period of time (e.g., quarterly)—and a list compiled that associates the forename and surname of individuals from <listPerson/> with the SigiDoc ID of each seal on which they appear. The background work for this list is done by inserting a @sameAs (or alternatively a @corresp) attribute, as mentioned above, when there is a confirmed match with a person on another seal, whether that is within the same corpus or across different corpora—for example, when we know that Emperor Justinian I, who has seals in the Feind, Seyrig, and Zacos collections, is one and the same person. The list created in this process will be a versioned and public list, published as an ongoing data paper on a platform such as Zenodo, which automatically assigns a DOI and versioning, and so can be specifically referenced.

§ 32 As will be explained below (see Section 2.6), all the seals encoded with SigiDoc by different research teams will be made available through a federated search portal allowing the simultaneous perusal of all this material. This will enable an editor working on collection B to find—if available—a seal edited in collection A and issued by a person the editor considers to be the same as the one who issued the seal they are editing, and to point to it from that seal in collection B using the @sameAs attribute (whose value will be the SigiDoc ID of the seal from collection A). However, this solution must be considered merely as the first step, because the results to which it may lead are incomplete, for several reasons. First, the data encoded in the @sameAs attribute in collection B is one-way only, and cannot be applied—at least not automatically—to the relevant seal in collection A. Second, while collection B is being edited (or encoded), collection C may also be in preparation; thus neither collection B nor collection C is available through the common search portal, and so a possible match between them would be totally overlooked. Third, the possibility of a mere oversight cannot be excluded, of course, especially if names appear in different forms on different seals. One consequence, among others, is that the same person may appear several times associated with different IDs (the SigiDoc IDs of the seals on which the name is inscribed), and with no link between them, because the seals come from different collections that did not communicate with each other.

§ 33 These issues lead to an inevitable conclusion: data reconciliation and quality control of the extracted persons list need to be done manually. A community effort is necessary: the researchers involved in DigiByzSeal can be considered as the core from which a dedicated community needs to develop—and this is one of the objectives of the project itself—but under no circumstances should these researchers consider themselves, or be considered by others, as the arbiters of the work of their colleagues, imposing their own choices on them. As soon as new data is extracted that reveals a need for a reconciliation, the editors and encoders responsible for the new seal editions will be alerted and asked to give their opinion on whether, for example, two seals bearing the same name were actually produced by the same person. In this way, the freedom of editors to autonomously interpret their own material will be preserved, while at the same time, the examination of similar material that had not been previously taken into consideration will retrospectively help improve sigillographic editions.

§ 34 After this human effort of reconciling data, all the SigiDoc IDs belonging to a single person will be gathered together under this person’s name, and a meaningless and automatically generated identifier will finally be attributed to this name. This identifier then serves as the aggregating factor between identical individuals. Once the expert decisions have been made and any unique identifiers have been generated, so that the SigiDoc IDs of a recently edited collection are linked with any corresponding IDs in other collections, inside the EFES infrastructure, an index can be instantly generated that groups together any seals that refer to the same individual (whether there is only one such seal or many). There are cross-references between individuals and editions, enabling seamless navigation between the two. The prosopographical list and the index are constantly evolving, but they are versioned, allowing reference to the current version or any preceding version, and so can act as a prosopographical gazetteer.

§ 35 This is a more manageable solution than an authority list and an ID list that are left to individual projects or even to individual encoders. This would still require data reconciliation, but with a much greater degree of complexity and “messiness.” The community effort that will be demanded by the management of this list is no heavier than what already happens in comparable digital communities such as EpiDoc or Digital Classicist.

2.3 IDs

§ 36 In the previous section, we mentioned SigiDoc IDs. In order to have a proper digital existence, Byzantine seals need unique identifiers, which they certainly do not have today. Such identifiers, better than any other solution, would allow them to be integrated into the mass of data available online and, equally, to benefit from this same data; in short, they become linked open data. But IDs for seals are also an important tool for performing the most traditional and basic scientific activity during the edition of a seal: to find and gather together any parallels, that is, any seals struck with the same matrix. The SigiDoc edition of a seal includes a SigiDoc ID for the whole seal, considered as both the support and the imprint struck on it. The way that the DigiByzSeal team is currently implementing this is through a function that—when an XML edition record is created—randomly generates an alphanumerical string of six elements preceded by a prefix “s” (for seal), such as s-o5zje4 (or, once encoded, <idno type=”SigiDocID”>s-o5zje4</idno>). This “ID generator” will also be integrated into the tagless editor discussed in Section 1.5. Using this solution, the chance of identical IDs being created in different projects is virtually nil (as there are 62⁶ or over 56 billion possible combinations), and the need—the heavy burden—for a centralized list of available and “to be distributed” IDs is obviated. These IDs could also be converted into URNs.

§ 37 However, as well as the seals, the matrices used to create them also need IDs. These matrices—iron plier-like instruments known as boulloteria (sg. boulloterion) in Byzantium—were used to strike the inscriptions and images of the finished seal onto a blank mostly made of lead. The inner surface of the two ends was engraved with the negative imprints of the two faces of the seal, as can be seen in Figure 5. While Byzantine seals have never been uniquely identified, some of their boulloteria have received IDs within the Prosopography of the Byzantine World, with the concurrent creation of a permalink (see Jeffreys et al. 2017b). SigiDoc IDs for matrices will be generated following the same procedure adopted for seal IDs, with the difference that in the case of matrices the random sequence will be preceded by the prefix “m” (for matrix); so, for example, m-12rbX7. When a matrix is already in the PBW, a simple equivalence between the two IDs is established and shown on the web page of the edition. This information is encoded with the following elements:

Figure 5

Boulloterion. Obverse: Bust of Saint Nicholas. Reverse: Inscription with invocation and owner’s name and title. Object no. 1951.31.6, Harvard Art Museums collections online, https://hvrd.art/o/291105 (accessed December 13, 2023).

§ 38 Earlier in this section, we mentioned parallel seals. Thanks to the IDs assigned to both seals and the matrices that left their imprint on them, it is possible to gather together all the seals produced by the same boulloterion. This means that all the SigiDoc IDs of the parallel seals struck with a specific matrix will be brought together under the matrix’s unique ID. Seal IDs are not a problem, because each specimen has its own; in contrast, each matrix ID is “reusable,” in the sense that it should be applied to all the parallel seals struck with the same tool. Once the federated search portal is ready, an editor (or encoder) will be able to check for parallel seals already encoded in other collections and, once found, apply the same identifier to the matrix of their own seal(s). However, this solution raises issues similar to those already seen with the prosopographical list, and that is why the proposed solution is the same: periodically, matrix IDs will be extracted together with the SigiDoc IDs of the seals struck by them, and after a data reconciliation undertaken by a community of experts, the IDs of the parallel seals will be grouped under the same matrix ID (if this is necessary, of course, since seals not always have known parallels, so one matrix ID will correspond to only a single seal ID).

§ 39 As for the prosopography, a general index of matrices can be generated, thus fulfilling one of the ultimate aspirations of Byzantine sigillography: the virtual reconstitution of the matrices that produced those seals that have come down to us. An extremely small number of boulloteria (less than ten) still exist, which means that in the code cited above, the value of the @subtype attribute will almost always be “not-surviving.” Matrices are the best way to organize and aggregate seals, and to highlight their seriality, which is less obviously self-evident than it is for coins. They can also become a virtual object: with the juxtaposition of several parallel seals, it will be possible to develop a clearer idea of the appearance of a matrix, especially in case of seals in a bad state of preservation, for which a “virtual collation” can return the text and image in their entirety. The Sigilla project on seals from medieval France uses the close concept of “sceau-type,” defined as “the digital avatar of the matrix used to produce the impression,” the “ultimate and absolute virtual impression, as imagined, defined, and validated by the owner of the seal” (Baudin et al. 2024; our translation).

2.4 Special fonts and the epigraphy of the seals

§ 40 The legend inscribed on Byzantine seals is important as a meaning-bearing text, but equally there is a visual aspect that needs to be handled: the letters composing the inscribed text have specific shapes (a major dating criterion for sigillographers). This forces the researcher to choose between a typological and a visual rendering of the lettering, with specific fonts being required for the latter. The choice made for SigiDoc is visual rendering, through the adoption of an OpenType and Unicode-compliant font called Athena Ruby, which has been integrated into SigiDoc’s EFES version (for a discussion of why this choice was made, see Sopracasa, Filosa, and Stoyanova 2020, 113–118). This font, available at Dumbarton Oaks (Dumbarton Oaks Athena Ruby 2024), is used for the diplomatic transcription of the legend, but a definitive choice on how to encode it has not yet been made by the DigiByzSeal team. The alternatives are an extremely detailed encoding that includes all the characters or an encoding that is limited to characters considered to be “special”; the first solution promises the best results for searching within legends but is very time-consuming, while the second is more practical but raises the question of the criteria for making the selection. Thus far, Athena Ruby is being used primarily as a display font, with limited search possibilities: EFES now allows a basic search for specific characters in Athena Ruby thanks to a recently added keyboard (which needs to be expanded to include all the glyphs in the current Athena Ruby palette), as seen in Figure 6—in addition to the keyboard for polytonic Greek—but all character variants are mapped by default to the single corresponding letter (e.g., different variants of mu will give the standard μ as a result).

Figure 6

The Athena Ruby keyboard in the EFES search form.

§ 41 Athena Ruby’s palette is constantly growing: at time of writing, the current version is version 021, released in March 2021. This font can be freely modified; however, the developers of Athena Ruby, the research centre at Dumbarton Oaks (Washington, DC), have made themselves available to add any variants reported to them. Rather than creating local versions of the font, it is certainly preferable to adopt this second, more centralized solution, since in this way one can be certain that all potential users will have the same version available to them, accessible from a single place. For this reason, during the editorial process in the DigiByzSeal project, the sigillographers involved set themselves the task of listing any possible variants not found in the Athena Ruby palette. It turns out that the types of glyph that are most lacking are those for abbreviation signs and ligatures, plus some specific forms of letters such as omega or mu.

2.5 Visualization of geographical data: A Leaflet map

§ 42 Recently, the DigiByzSeal team started to address one of the major topics of the project: the management of geographical data. From a sigillographic point of view, this data is mainly of two kinds: places mentioned in the legend of a seal, and the place where the seal was found. The indexes and the search form take into account the first kind of place, while the second has a specific <provenance type=”found”/> element in the template. A major shortcoming of Byzantine sigillography is the lack of information concerning the circumstances (where, when, who, how) of the discovery of a seal. For this reason, among others, a collaboration between the DigiByzSeal project, on the one hand, and the Regional History Museum of Shumen and the National Archaeological Institute with Museum of Sofia in Bulgaria, on the other, is of particular interest for the development of the SigiDoc infrastructure. Contrary to what has just been said about seals in general, there is a lot of information about finds on Bulgarian soil, and this is a test bed of the utmost importance for implementing the parts of the template that are dedicated to these topics (several <provenance/> elements with different @type attributes) and which are currently underdeveloped. One of the first endeavours is the development, currently underway by the Bulgarian team (in particular Vasko Nikolov), of a Leaflet map gathering together findspots and places mentioned by the seals: this map is now part of the EFES version of the Bulgarian team and will be soon transferred to the standard EFES version available to all SigiDoc edition projects. This is certainly one of the best ways to add value to geographical data and to make it available as linked open data.

2.6 Federated search portal

§ 43 The ultimate goal of the DigiByzSeal project is to create a centralized hub for Byzantine sigillography, whose core will be represented by a federated search portal for all seals encoded with SigiDoc (on this portal, see also Neuefeind et al. 2024). It is not a matter of gathering all Byzantine seals in one hyper-corpus. Quite the contrary: the use of SigiDoc as a common and shared tool allows, on the one hand, the totally independent creation of several collections or corpora, and, on the other hand, the interoperability between each of them, as all the editions made with SigiDoc will be unified virtually by the use of this tool, and their content will be available for consultation through the common search interface.

§ 44 A major commitment during the middle half of 2023 was to lay the foundations of a common ground of materials, in order to make them available for all the projects interested in editing Byzantine seals with SigiDoc: these are the basis on which the upcoming search portal will be built. This has involved the structuration of Git repositories, in order for them to be centralized when they contain shared material, but also expandable in order to host new projects; the overall structure can be seen in Table 2.

§ 45 One centralized repository, called “SigiDoc” (a GitHub organization; SigiDoc 2024b) contains materials designed to be used in two different ways. On one hand, there is the foundation code (the schema, the template, and the EpiDoc stylesheets), which should not be altered by those working on individual SigiDoc-based projects and for which SigiDoc is the unique repository (column 1a in Table 2). Developments and changes to that code will be introduced by the owners of the repository, on their own initiative or based on suggestions and requests coming from individual projects, and they will be immediately available to each SigiDoc project without any delay and without any action required from the users.

§ 46 On the other hand, other parts of the code (column 1b in Table 2) are still centrally managed, but, for an effective workflow, individual projects should make this material their own. This means that SigiDoc makes available a centralized instance of an EFES customized version offering only the EFES software without any data or schemas: this is a “blank” version design-wise, from which several EFES instances, dedicated to the different collections, can fork for altering the design or adding specific features to meet the needs of individual projects. The other code in this category consists of the authority files and, among the centralized materials, the management of this is more delicate: what the DigiByzSeal team is currently doing is to “pre-prepare” long lists, full of data—taken from the major sigillographic publications and expanded even further—before the encoding of other sigillographic collections. These lists will then be available in the central SigiDoc repository, and can be forked together with the generic EFES-SigiDoc version by individual projects, which will then use their own forks of these materials (column 2a in Table 2).

§ 47 In order to create their own individual sigillographic edition projects, the members of the DigiByzSeal team created two GitHub organizations: the members based in Germany called theirs “byzantinistik-koeln” (Byzantinistik–Universität zu Köln 2024) while their colleagues based in France established “sceaux-byzantins-paris” (Sceaux-Byzantins-Paris 2024). Each of these sub-teams forked the central authority lists folder, and each one forked its own EFES-SigiDoc instances, one for each of the collections currently being worked on (for example, “EFES-SigiDoc-feind” or “EFES-SigiDoc-ifeb”).

§ 48 The crucial question is that of coordination. When a project team needs to change the authority files, they should first change their own authority files and then make pull requests to the central repository. At the same time, each project should make sure that they regularly update their files, that is, they pull from the central authority files repository, which potentially will have received new data from other projects. By using forked individual EFES-SigiDoc instances, each project will benefit from all the changes and improvements made to both the centralized EFES-SigiDoc instance and the “original” EFES instance for EpiDoc (EFES 2024), from which the SigiDoc version has in turn been forked.

§ 49 The last part of this structure is represented by the seals themselves; more precisely by the XML edition files containing all the sigillographic data to be published (column 2b in Table 2). Thus, for example, the previously mentioned GitHub organizations that contain the local authority lists and forked EFES-SigiDoc instances—“byzantinistik-koeln” and “sceaux-byzantins-paris”—also contain repositories bearing the XML files (such as “feind-collection” and “ifeb-collection”), which are the clearest expression of the work of an individual project. Unlike the code in column 1a, of course, the data in these XML file repositories can be independently modified by the individual project managers. Even though they show up as separate repositories on GitHub, each folder containing XML files has been integrated with the corresponding EFES-SigiDoc instance: for example, the “ifeb-collection” folder has the path EFES-SigiDoc-ifeb/webapps/ROOT/content/xml/epidoc.

§ 50 Having a structured working environment is of paramount importance for a project one of whose aims is to involve as many institutions, research centres, museums, and researchers as possible. As has been suggested, the SigiDoc and DigiByzSeal approach is not “Napoleonic”: in giving our colleagues tools and knowledge to independently develop their own projects, we also receive invaluable feedback, essential to further develop this knowledge, in a common effort to create a digital sigillographic community. Many researchers have shown interest in managing their own sigillographic material with SigiDoc, in collaboration with DigiByzSeal, as the map in Figure 7 shows.

Figure 7

SigiDoc in the world (Google My Maps). = DigiByzSeal members (Institut d’Histoire et Civilisation de Byzance, Paris, France; Department of Byzantine and Modern Greek Philology and Cologne Center for eHumanities, University of Cologne, Germany); ◆ = Active collaborators (Musée d’Art et d’Histoire, Geneva, Switzerland; Regional History Museum, Shumen, Bulgaria; National Archaeological Institute with Museum, Sofia, Bulgaria; University of Bologna, Italy); ● = Interested partners (Numismatic Museum, Athens, Greece; Carthage National Museum, Tunisia; Dumbarton Oaks, Washington, DC, USA).

§ 51 Keeping in mind that this infrastructure has not yet been implemented, we can give some indications of how the portal will work since, like the individual project pages, the federated search portal will also be based on EFES. Individual sigillographic projects that want to integrate their own material into the portal for a federated search must make their data available on a public Git repository and set up a webhook. Webhooks are functions that can be set up in the common Git systems and that are triggered when something is committed to a Git repository (i.e., when a new XML file has recently been added). This allows a newly created endpoint, living on the federated search portal server, to run a specific function, that is, to pull the last commits from the repository. Then, another endpoint, which already exists in EFES, will be called, and a function for the indexing of the data in EFES will run. This latter action will take place on the server hosting the EFES instance dedicated to the federated search portal, and thanks to it, any new XML editions of seals will be indexed and made available for search. In this way, all the data will be directly integrated into the portal as and when a seal is edited.

§ 52 For example, if someone committed the seal “feind_123.xml” into the “feind-collection” GitHub repository mentioned above, the webhook in this repository would make a request to the URL configured for the webhook, in our case the EFES federated search portal: this URL might perhaps be DigiByzSeals.search.uni-koeln.de/EFES/newpull/feind (note that this is a potential URL, not a real one, since the project team still has to decide where the federated search portal will be located). This would pull the new commit coming from the “feind-collection” repository onto the server hosting the EFES federated search portal. Once this action was done, the new seal would still need to be indexed: in order to do that, the URL defined in the EFES endpoint for indexing would run (this URL might perhaps be …/admin/solr/index/tei/feind-collection/feind_123.xml, for example).

§ 53 While the DigiByzSeal project does make extensive use of EFES, it should be remembered that the XML edition files prepared through the project can also be used outside this platform. This has a consequence for the centralized portal: projects can use EFES or some other software to present their collections, or they can simply use raw XML files. This choice has no impact on the effectiveness of the search performed by the portal, because the federated search operates on the basis of a list of online Git repositories (GitHub, GitLab, or something else), which it harvests. In the search results, a link is provided to the collection website (or to the source file, if the files are not displayed on such a website).

§ 54 With these upgrades to SigiDoc, we hope to put an end to the current dispersion of sigillographic editions and lay the foundations for a virtual Corpus Sigillorum Ævi Byzantini.

Authorial

Authorship in the byline is given in alphabetical order after the corresponding author. Author contributions, described using the NISO (National Information Standards Organization) CrediT taxonomy, are as follows:

Author names and initials:

• Alessio Sopracasa (AS)

• Jan Bigalke (JB)

• Numa Buchs (NB)

• Sima Meziridou (SM)

Authors are listed in descending order by significance of contribution. The corresponding author is AS.

• Conceptualization: AS

• Data Curation: AS, JB

• Funding Acquisition: AS

• Investigation: AS, NB, SM

• Methodology: AS, JB

• Project Administration: AS

• Resources: JB

• Software: JB

• Supervision: AS

• Validation: AS, JB

• Visualization: AS

• Writing – Original Draft: AS

• Writing – Review & Editing: AS, JB

Editorial