2.1. General goal

As TSL is born out of the practical necessity of creating electronic corpora of hieroglyphic texts in a principled way (see Section 1), its first aim is to document the functions attested for individual signs in order to indicate which standardized character may be used in which context. To meet this goal, two non-trivial steps must be taken.

First, ancient sources have to be identified for as many functions as possible. Referenced sign lists (such as Gardiner 1957: 438–549, Cauville 2001, Kurth 2009, I: 3–453, Schenkel 1983, I: 45–83, or Borghouts 2010, II: 10–195) greatly helps in this respect, but finding an actual image or accurate facsimile of individual sources – a prerequisite for a proper scientific approach of the written material, since handwritten transcriptions and glyphs in fonts are unfortunately not reliable enough (Meeks 2013) – can turn out to be a challenge. Luckily enough, the situation is quickly improving thanks to the digital turn in the field illustrated for instance by the Karnak project and the open access policy of several Egyptological museums.

Second, among the available signs in modern lists and fonts, one has to identify glyphs that are actualization of the same character (or grapheme) and as such share the same function(s). This was the original intention of the Manuel de Codage (Buurman et al. 1988: 51) that states explicitly: “there is a clear distinction made between graphemes and graphic variants. Code written as letter + figure (+ figure, + figure) refer to graphemes – i.e. hieroglyphs differing one from the other in their reading or meaning. Codes written as letter + figure (+ figure, + figure) + letter refer to graphic variants – i.e. hieroglyphs differing neither in their reading nor in their meaning from those they come from”. With the Latin alphabet, this amount to state that ‘a’ and ‘a’ are both instances of an abstract grapheme <a>, which is rather uncontroversial. However, defining and identifying graphemes is a notoriously difficult task (Klinkenberg & Polis 2018: 69–81) and is even more problematic for iconic scripts, like the hieroglyphic one, where minor figurative variations can turn out to be significant.

In the example of Fig. 1 (coming from the Manuel de Codage), one can deduce based on the codes that A6A, A6B, A6C, and A6D are groups of graphic variants of A6, which is identified as the standard grapheme. Each group is illustrated by a number of tokens (between 1 and 7) that are characterized by iconic differences: A6 [vase on top of the head], A6A [water backwards], A6B [vase in the hand(s)], A6C [water in both directions], A6D [libation vase with several trickles of water]. Note that such descriptions have to be inferred from the catalogue and that some tokens (e.g., the 4^th of A6) do not fit the proposed analysis. Despite the iconic differences, these groups of variants should share the same reading (or have the same meaning), here presumably wꜥb ‘(to be) pure’, but such information about the signs’ function is not part of the Manuel.

Fig. 1. “Hommes assis versant de l’eau”
(Buurman et al. 1988: 57)

Note however that the Manuel is not systematic here. A first illustration is D7 (eye with painted lower lid) and D7A (eye with painted upper lid). According to the abovementioned principles, the latter should be a variant of the former. However, the signs are not only different from an iconic point of view, they also have distinct functions: D7A is apparently not used as phonogram ꜥn(ty) or as a classifier with the semographic value [adornment, beauty] like D7, but rather as a [sight] related grapheme. The opposite scenario also occurs (this time inherited from Gardiner): D19 (𓂉) and D20 (𓂊) receive two different codes, while Gardiner states explicitly that the latter is a ‘semi-cursive variant of last (…) Use as last, but seldom in careful sculptures or paintings’ (Gardiner 1957: 452). Accordingly, both hieroglyphs should rather be envisioned as ‘graphic variants’ than as distinct graphemes (as would seem to be the case based on their codes).

Fig. 2a. D7 vs. D7A
(Buurman et al. 1988: 89)

Fig. 2b. D19 vs. D20
(Buurman et al. 1988: 90)

Furthermore, problems arise due to the fact that various influential sign lists display different sign shapes or even different glyphs under one an the same code (cf., e.g., A7/A7A, N13, or M3A in Hieroglyphica vs. JSesh [default installation]).

2.2. TSL data model

The TSL data model has been designed in order to tackle these challenges in a principled way. The most straightforward way to explain it is assuredly to describe the encoding process in a bottom-up fashion (in what follows, conceptual entities of the database are capitalized). One starts from a Document (temple, stela, etc.) in which ancient hieroglyphic Sources can be recognized. The Documents and the Sources are described with metadata provided by the Thot thesauri). A Source contains hieroglyphic Tokens, a label that refers to actual hieroglyphic signs that are materialized on a medium. In this specific context, each Token has one Function (or ‘reading’, for instance, a phonographic function x or a logographic function y) and participate in one Class – defined as a group of Tokens with similar iconic features; Classes are therefore conceptually identical to coherent groups of ‘graphic variants’ in the Manuel de Codage. Finally, a Sign is a second-degree abstraction, a grapheme envisioned as a cluster of Classes whose Tokens share the same Functions. The basic data model of Fig. 3 visualizes the textual description provided above.

Fig. 3. Basic visualization of the TSL data model

Three remarks are in order. (1) The encoding workflow cannot follow (systematically) the bottom-up process outlined above. Indeed, it is only after having collected several Tokens for a given Sign that different Classes can be identified: the creation of Classes calls for an analysis of the written variation. As such, Tokens are usually first connected to a (highly abstract) Sign (dashed-line in Fig. 3), and Classes are only identified later on. Consequently, if Signs are essentially clusters of Classes, they may include Tokens that belong to the Sign from a functional point of view, but are not categorized in specific, subordinated, Class. Fig. 4 represents this state of affair.

Fig. 4. Basic visualization of the TSL data model

(2) Classes and Signs are both generalizations over empirical observations: there is no ontological distinction between the two categories that share identical features (they can be represented by a prototypical glyph, have a code, be described with tags, etc.). Therefore, it was decided to represent Signs with a Class 00 (cf. Fig. 4). Note that the IDs in TSL have either a prefix 1 for abstract Signs and Classes (e.g., TSL_1_82 for A1 or TSL_1_630_01 for A4C, etc.), or a prefix 3 for concrete Tokens.

(3) A Function is first and foremost a property of an individual Token in context (Fig. 3), and only indirectly a feature of the Sign to which the Token belongs. However, in order to be able to document Functions that are not (or not yet) documented ancient Sources (either because we did not yet manage to find an actual example or because the said function is found in the modern literature but has been proven wrong), Functions are also directly connected to Signs (see the dotted line in Fig. 3).

2.3. Targeted audience

As should appear from the above, while including a paleographical dimension (since images and facsimiles of ancient sources are provided whenever possible), the primary goal of TSL is not to provide Egyptologists with a paleographical analysis of the hieroglyphic material. There are specific projects devoted to this question (such as the volumes of the Paléographie hiéroglyphique at the French Archaeological Institute in Cairo, initiated by Meeks 2004) and TSL does not intend to (and will not) replace them. Rather, we principally have the following users in mind:

• Text editors, encoders, software developers, and others who look for stable IDs for hieroglyphic graphemes and sign shapes, with precise indications about their meaning and uses.

• Students, for whom TSL can be a convenient resource for learning about the possible readings and functions of hieroglyphic signs.

• Font specialists, who will find here a list of Classes that are duly documented and can safely be integrated in standards like Unicode.

References

For first release of TSL (version 1.0), the goal has been to have the digital repertoire ‘Gardiner-ready’, which means that the hieroglyphic Signs and Functions found in Gardiner’s (1957: 438–548) sign list should be documented with at least one Token coming from an ancient Source. The scope of version 1.0 is however not limited to Gardiner (1957): if an interesting Sign, Class or Function was documented in a Source processed for TSL, it has been encoded.

Data available online is as follows: 1203 Signs (vs. 7051 in total), 4842 Functions (vs. 5838 in total), 21834 Tokens (vs. 22328 in total).

There are two basic ways to explore TSL: (1) Browsing (§3.1) or (1) Searching (§3.2). Both approaches present the users with Signs – displayed bigger, with darker border – and Classes – displayed smaller, with lighter border. This distinction (Fig. 5) shows in a straightforward way which specific Class has been selected to represent a Sign (see Section 2.2 for more details about the data model).

When clicking on the code associated with a Sign or Class, the user opens a new tab in the browser, which displays the relevant Sign, with its Functions, Classes and Tokens (Section 3.3). Note that clicking on a Class (e.g., A7A in Fig. 5) will open the Sign to which this Class belongs (represented by A7 in Fig. 5)

Fig. 5. Sign vs. Class in TSL

Depending the user’s level of access (Section 3.4), the quantity of information that can be visualized vary, but is essentially the same in qualitative terms.

3.1. Browsing TSL

When browsing TSL, two types of filters are available: (1) the category to which a Sign belongs, and (2) its basic shape. Both organizing principles are standard in Egyptology since Gardiner (1957), but for the thematic categories we follow the new structure suggested by Meeks (2004: XIX–XXII). Both filters may be combined: in Fig. 6, the Signs and Classes belong to the ‘Loafs and cakes’ category and have a ‘low narrow’ shape.

Fig. 6. Filtering the signs in TSL

The codes displayed when browsing TSL are meant to help the user identify quickly a sign based on the codes that (s)he knows. They are based, in hierarchical order, on Gardiner (1957), JSesh, Hieroglyphica, Unicode, and the IFAO catalogue. This means, for instance, that a code from Unicode will only be displayed at this level if the hieroglyphic sign did not receive a code in Gardiner (1957), JSesh or in the Hieroglyphica.

If the mouse is positioned over the code of a Sign (or Class), an overview of the functions associated with the Sign is shown. Fig. 7 illustrates this point. Two functions are available for the Sign linked to Gardiner code A35: it can be used as classifier with the meaning ‘building’ and as logogram with the reading qd ‘to build’.

Fig. 7. Mouseover while browsing

3.2. Searching TSL

Users can resort to the search engine in order to look for a Sign or Class with any combination of features relative to its functions (type, phonetic, and semantic value), description (plain text, tag, basic form, and type), and codes. Furthermore, operators (equals, contains, does not contain) can be used for any feature so as to specify the search. Accordingly, one can build queries such as: Function type equals ‘logogram’ and Tag contains ‘foreigner’, or Phonetic value contains ‘mr’ and Description does not contain ‘canal’, etc.

Fig. 8. Search with Function type = logogram and Phonetic value = nṯr

The search of Fig. 8 lists all the Signs (bigger) and Classes (smaller) in TSL that are attested as logogram with the phonetic value nṯr. The results are sorted according to Gardiner codes and TSL IDs give access the relevant Sign.

3.3. Visualizing a Sign, its Classes and Tokens

Fig. 9 illustrates how information is structured in TSL for individual Signs (here TSL_1_2177 = Gardiner D33). Four drop-down menus (on top) give access to the Description, Codes, Bibliography, and Credits for this Sign, while (up to) four tabs (below) gather information about the Functions, Classes, and Tokens, as well as how to cite data from TSL.

Fig. 9. Sign TSL_1_2177

Description includes a plain text description of the iconic features (and referent) of the Sign. Follow its Category (based on Meeks 2004: XIX–XXII, see Section 3.1), Tags (coming from a non-hierarchical thesaurus) that describe the Sign (and its components) with keywords that are intended to helps users finding hieroglyphs easily, and Type (we distinguish between ‘simple’, ‘compound’, and ‘composite’ signs; see Polis 2018: 328, Fig. 35). If a Sign is analyzed as a compound or composite hieroglyph, its component(s) are given (in Fig. 9, TSL_1_5126 is a component of TSL_1_2177).

Codes list the codes attributed to the Sign in Gardiner (1957), Hieroglyphica, Jsesh, and Unicode (when available).

Bibliography cites references that are relevant for the entire Sign. If references are dealing with specific aspects (e.g., a Function, a Class, etc.), they are quoted under the relevant entry.

Credits. See Section 4.

Every Sign is accompanied by three tabs (Functions, Tokens, Cite as), and a fourth tab (Classes) when several Classes are available for the Sign.

Functions. The functions are grouped by type (classifier, logogram, radicogram, phonemogram, interpretant, phono-repeater; see Polis & Rosmorduc 2015 and Hafemann 2018) and receive a phonetic and/or semantic value. Fig. 9 shows that three functions are documented for TSL_1_2177 (as of November 2019): classifier ‘movement by boat’, logogram for ḫnj ‘to row, to convey by water’, and phonogram ḫn.

Fig. 10. Tokens for TSL_1_2177 as logogram

Every function is illustrated by at least one token, i.e., an actual example, for which a context of use is provided (with an hieroglyphic transcription, a transliteration, and a translation) as well as an image for the registered users (see Section 3.4). For more information about a token, registered users can access the Source by clicking on ‘view source’ (see Section 3.5).

Classes. If a Sign has more than one Class, they can be visualized in the dedicated tab ‘Classes’. A Class is illustrated by a prototypical hieroglyphic sign (vector graphics) and is described exactly like the main Sign (which is actually Class 00, see above), with codes and literature (if relevant).

Fig. 11. Classes for TSL_1_2177

Tokens. The Tokens of a Sign can be visualized in the tab Tokens. The number in the lower-right corner corresponds to the Class to which this Token belongs to (see Fig. 12). Lack of number means that the Token belongs to Class 00 (which represents the Sign).

Fig. 12. Tokens of TSL_1_2177

Details about individual Token can be displayed on click, providing with its Function and value as well as its context of use (see Fig. 13). For more information about a Token, registered users can access the Source by clicking on ‘view source’ (see Sections 3.4 and 3.5).

Fig.  13. Details about Token TSL_3_22302 of TSL_1_2177

3.4. Registration and levels of access

There are two levels of access to TSL (for users who are not collaborators of the project): unregistered and registered. Registration is free (https://thotsignlist.uliege.be/Account/Register) and emails are collected exclusively in order to update users about evolutions of the database and website.

Unregistered users have access to all the Signs and Functions in TSL, but cannot:

• Visualize the Classes: they are redirected to the main Sign when clicking on a Class.
• Visualize the Tokens: standardized vector graphics is displayed instead.
• Visualize the Sources from which the Tokens are extracted.

3.5. Visualizing a Source

Registered users may access the Sources that are validated (after an internal reviewing process). A Source is a section of a hieroglyphic (cursive hieroglyphic or hieratic) inscription; its length is not fixed in advance, its purpose being to visualize a token in context so as to assess its function and value. As such, it corresponds at least to a word, and more often to a phrase or (usually) a predication.

Fig.  14. Source ID 1978

As illustrated by Fig. 14, a Source consists of (at least) one image (picture, facsimile, etc.), accompanied by its standardized hieroglyphic transcription, transliteration and English translation. It is documented with metadata coming from the Thesauri and Ontology for Documenting Ancient Egyptian Resources (https://thot.philo.ulg.ac.be/). Metadata values are hyperlinked to the hierarchical thesaurus of Thot (see Fig. 15 for the concept ‘Hatshepsut Maatkare’ in Thot).

Fig.  15. Concept thot-371 (Hatshepsut Maatkare) in the thesaurus ‘Dates and dating systems’

3.6. Technicalities

The hieroglyphs in TSL are displayed with the JSesh (https://jsesh.qenherkhopeshef.org/) wrapper developed by Dmitry Nikolaev (https://github.com/macleginn/jsesh-web) and the Sources are described with the Thot metadata (http://thot.philo.ulg.ac.be/concept/) using APIs developed by Vincent Razanajao. The TSL database and front-end have been implemented by Luc Desert (CIPL / ULiège).

References

In TSL, credits are mentioned at three levels: Signs, Functions, and Sources. For each level, we identify the ‘creator’, namely the person who created a Sign, Function or Source in TSL, and the ‘editor(s)’, i.e., the scholars who modified the content of the said entry at some point.

When information about an entire Sign is quoted, please follow the pattern below:

Model. Sign TSL_1_ID <http://thotsignlist.org/mysign?id=ID>, in Thot Sign List, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Example. Sign TSL_1_82 <http://thotsignlist.org/mysign?id=82>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Additional information about the creator and editor(s) of signs may be quoted:

Example. Sign TSL_1_82 <http://thotsignlist.org/mysign?id=82> (created by L. Seelau and edited by J. Grotenhuis, I. Hafemann, L. Seelau, A. Weber, M. Bader, T. Kunze, D.A. Werning), in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

When referring to a specific Function , the following citation system should be followed:

Model. Function FunctionName with value ‘values’ of Sign TSL_1_82 <http://thotsignlist.org/mysign?id=82>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Example. Function Logogram with value ‘z(j) – man’ of Sign TSL_1_82 <http://thotsignlist.org/mysign?id=82>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Additional information about the creator and editor(s) of individual Functions may be quoted:

Example. Function Logogram with value ‘z(j) – man’ (created by TSL and edited by I. Hafemann, J. Grotenhuis, and D. Werning) of Sign TSL_1_82 <http://thotsignlist.org/mysign?id=82>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

When referring to Source , the following citation system should be followed:

Model. Source SourceID <http://thotsignlist.org/mysource?id=SourceID>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Example. Source 375 <http://thotsignlist.org/mysource?id=375>, in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Additional information about the creator and editor(s) of individual Sources may be quoted:

Example. Source 375 <http://thotsignlist.org/mysource?id=375> (created by I. Hafemann and edited by I. Hafemann and J. Grotenhuis), in: Thot Sign List <http://thotsignlist.org>, edited by Université de Liège and Berlin-Brandenburgische Akademie der Wissenschaften.

Below is a full list of the persons who contributed to TSL so far:

2022

·   Peter Dils (Sächsische Akademie der Wissenschaften zu Leipzig)

·   Åke Engsheden (Stockholm University)

·   Jorke Grotenhuis (University of California, Berkeley)

·   Stéphane Polis (F.R.S.-FNRS / University of Liège)

·   Philipp Seyr (F.R.S.-FNRS / University of Liège)

·   Daniel Werning (Berlin-Brandenburg Academy of Sciences and Humanities)

2023

·   Zacharie Cochin (ULiège)

·   Peter Dils (Sächsische Akademie der Wissenschaften zu Leipzig)

·   Åke Engsheden (Stockholm University)

·    Jorke Grotenhuis (The Hebrew University of Jerusalem)

·   Stéphane Polis (F.R.S.-FNRS / University of Liège)

·   Philipp Seyr (F.R.S.-FNRS / University of Liège)

·   Daniel Werning (Berlin-Brandenburg Academy of Sciences and Humanities)