# DHARMA Encoding Guide for Diplomatic Editions

Dániel Balogh, Arlo Griffiths

► To cite this version:

Dániel Balogh, Arlo Griffiths. DHARMA Encoding Guide for Diplomatic Editions. [Technical Report] EFEO; Humboldt-Universität (Berlin); CEAIS - Centre d'Études de l'Inde et de l'Asie du Sud. 2020. halshs-02888186

HAL Id: halshs-02888186

https://shs.hal.science/halshs-02888186

Submitted on 2 Jul 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

dharma

# Encoding Guide
## for Diplomatic Editions

Dániel Balogh & Arlo Griffiths

Release Version 1, 2020-07-05

<figure><img src="image_3.png" /></figure>

erc

This project has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement No 809994).
<table>
  <tbody>
    <tr>
      <td>3.5.7.</td>
      <td>Full markup example for pagelike partitions</td>
      <td>39</td>
    </tr>
    <tr>
      <td>3.6.</td>
      <td>Gridlike Partitions: Text Runs Across Contiguous Zones</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.1.</td>
      <td>Overview</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.2.</td>
      <td>Encoding gridlike partitions</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.3.</td>
      <td>Gridlike milestone identification: unit and number</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.4.</td>
      <td>Gridlike partitions interrupting words</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.6.5.</td>
      <td>When to encode gridlike partitions</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.6.6.</td>
      <td>Full markup examples for gridlike partitions</td>
      <td>42</td>
    </tr>
    <tr>
      <td><b>4.</b></td>
      <td><b>Encoding the Originally Inscribed Text</b></td>
      <td><b>45</b></td>
    </tr>
    <tr>
      <td>4.1.</td>
      <td>Alphabetic Characters</td>
      <td>45</td>
    </tr>
    <tr>
      <td>4.1.1.</td>
      <td>Tagging transliterated characters as one akşara</td>
      <td>45</td>
    </tr>
    <tr>
      <td>4.1.2.</td>
      <td>Tagging parts of alphabetic characters</td>
      <td>45</td>
    </tr>
    <tr>
      <td>4.1.3.</td>
      <td>Unusual spatial arrangement in conjuncts</td>
      <td>46</td>
    </tr>
    <tr>
      <td>4.1.4.</td>
      <td>Complex characters split by an intervening feature</td>
      <td>46</td>
    </tr>
    <tr>
      <td>4.2.</td>
      <td>Non-alphabetic Characters</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.2.1.</td>
      <td>Overview</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.2.2.</td>
      <td>Numeral symbols other than decimal digits</td>
      <td>48</td>
    </tr>
    <tr>
      <td>4.2.3.</td>
      <td>Symbol tokens</td>
      <td>49</td>
    </tr>
    <tr>
      <td>4.2.4.</td>
      <td>Punctuation marks</td>
      <td>50</td>
    </tr>
    <tr>
      <td>4.2.5.</td>
      <td>Space filler signs</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.2.6.</td>
      <td>Miscellaneous symbols</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.2.7.</td>
      <td>Alphanumeric characters used for a different function</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.3.</td>
      <td>Space</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.3.1.</td>
      <td>Generic markup for original space</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.3.2.</td>
      <td>Space for semantic segmentation</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.3.3.</td>
      <td>Space left blank for subsequent filling</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.3.4.</td>
      <td>Space for visual layout</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.3.5.</td>
      <td>Spaces imposed by physical necessity</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.3.6.</td>
      <td>Binding holes in copper plates</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.3.7.</td>
      <td>Surface defects</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.3.8.</td>
      <td>Spaces imposed by other glyphs</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.4.</td>
      <td>Scribal Hands</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.5.</td>
      <td>Premodern Editorial Intervention</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.5.1.</td>
      <td>Premodern deletion</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.5.2.</td>
      <td>Premodern insertion</td>
      <td>56</td>
    </tr>
    <tr>
      <td>4.5.3.</td>
      <td>Premodern correction</td>
      <td>56</td>
    </tr>
    <tr>
      <td><b>5.</b></td>
      <td><b>Physical Condition and Legibility</b></td>
      <td><b>58</b></td>
    </tr>
    <tr>
      <td>5.1.</td>
      <td>Overview</td>
      <td>58</td>
    </tr>
    <tr>
      <td>5.2.</td>
      <td>Damage Not Affecting Legibility</td>
      <td>59</td>
    </tr>
    <tr>
      <td>5.3.</td>
      <td>Doubtful Readings</td>
      <td>60</td>
    </tr>
    <tr>
      <td>5.3.1.</td>
      <td>The EpiDoc element &lt;unclear&gt;</td>
      <td>60</td>
    </tr>
    <tr>
      <td>5.3.2.</td>
      <td>Tentative readings</td>
      <td>60</td>
    </tr>
    <tr>
      <td>5.3.3.</td>
      <td>Ambiguous characters</td>
      <td>61</td>
    </tr>
    <tr>
      <td>5.3.4.</td>
      <td>Reading difficulties below the akşara level</td>
      <td>61</td>
    </tr>
    <tr>
      <td>5.4.</td>
      <td>Lacunae</td>
      <td>63</td>
    </tr>
    <tr>
      <td>5.4.1.</td>
      <td>The EpiDoc element &lt;gap/&gt;</td>
      <td>63</td>
    </tr>
    <tr>
      <td>5.4.2.</td>
      <td>The reason for a lacuna: illegible or lost</td>
      <td>63</td>
    </tr>
    <tr>
      <td>5.4.3.</td>
      <td>Inline lacunae</td>
      <td>63</td>
    </tr>
    <tr>
      <td>5.4.4.</td>
      <td>Lacunae with known metre</td>
      <td>64</td>
    </tr>
    <tr>
      <td>5.4.5.</td>
      <td>Lacunae below the akşara level</td>
      <td>65</td>
    </tr>
    <tr>
      <td>5.4.6.</td>
      <td>Entire lines lost</td>
      <td>66</td>
    </tr>
    <tr>
      <td>5.4.7.</td>
      <td>Massive lacunae</td>
      <td>67</td>
    </tr>
    <tr>
      <td>5.4.8.</td>
      <td>Lost copper plates</td>
      <td>70</td>
    </tr>
    <tr>
      <td>5.4.9.</td>
      <td>Fractured inscriptions</td>
      <td>71</td>
    </tr>
    <tr>
      <td>5.5.</td>
      <td>Restoring Lacunae</td>
      <td>72</td>
    </tr>
    <tr>
      <td>5.5.1.</td>
      <td>Marking up restored text</td>
      <td>72</td>
    </tr>
    <tr>
      <td>5.5.2.</td>
      <td>The basis of restoration</td>
      <td>73</td>
    </tr>
    <tr>
      <td><b>6.</b></td>
      <td><b>Editorial Intervention</b></td>
      <td><b>74</b></td>
    </tr>
    <tr>
      <td>6.1.</td>
      <td>Correction and Normalisation</td>
      <td>74</td>
    </tr>
    <tr>
      <td>6.1.1.</td>
      <td>Correction versus normalisation</td>
      <td>74</td>
    </tr>
    <tr>
      <td>6.1.2.</td>
      <td>Markup methods for correction and normalisation</td>
      <td>74</td>
    </tr>
    <tr>
      <td>6.1.3.</td>
      <td>Good practice in editorial intervention</td>
      <td>75</td>
    </tr>
    <tr>
      <td>6.1.4.</td>
      <td>Correction and normalisation in verse</td>
      <td>75</td>
    </tr>
    <tr>
      <td>6.2.</td>
      <td>Encoding Correction</td>
      <td>77</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>6.2.1.</td>
      <td>Flagging erroneous and uninterpretable text</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.2.2.</td>
      <td>Correcting erroneous text</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.2.3.</td>
      <td>Editorial deletion</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.2.4.</td>
      <td>Editorial addition</td>
      <td>78</td>
    </tr>
    <tr>
      <td>6.2.5.</td>
      <td>Distinguishing correction from deletion and addition</td>
      <td>78</td>
    </tr>
    <tr>
      <td>6.2.6.</td>
      <td>Good practice in correction</td>
      <td>79</td>
    </tr>
    <tr>
      <td>6.3.</td>
      <td>Encoding Normalisation</td>
      <td>80</td>
    </tr>
    <tr>
      <td>6.3.1.</td>
      <td>Flagging non-standard usage</td>
      <td>80</td>
    </tr>
    <tr>
      <td>6.3.2.</td>
      <td>Normalising non-standard usage</td>
      <td>80</td>
    </tr>
    <tr>
      <td>6.3.3.</td>
      <td>Nesting normalisation and correction</td>
      <td>80</td>
    </tr>
    <tr>
      <td>6.3.4.</td>
      <td>Good practice in normalisation</td>
      <td>81</td>
    </tr>
    <tr>
      <td>6.3.5.</td>
      <td>How non-standard is non-standard?</td>
      <td>82</td>
    </tr>
    <tr>
      <td>6.3.6.</td>
      <td>Supplying punctuation</td>
      <td>83</td>
    </tr>
    <tr>
      <td>6.3.7.</td>
      <td>Automated normalisation</td>
      <td>83</td>
    </tr>
    <tr>
      <td>7.</td>
      <td>Encoding Additional Information in the Edition</td>
      <td>85</td>
    </tr>
    <tr>
      <td>7.1.</td>
      <td>Numeral Values</td>
      <td>85</td>
    </tr>
    <tr>
      <td>7.1.1.</td>
      <td>Generic numeral markup</td>
      <td>85</td>
    </tr>
    <tr>
      <td>7.1.2.</td>
      <td>Difficulties in reading numbers</td>
      <td>85</td>
    </tr>
    <tr>
      <td>7.1.3.</td>
      <td>Editorial intervention and numerals</td>
      <td>86</td>
    </tr>
    <tr>
      <td>7.1.4.</td>
      <td>Numbers expressed in words</td>
      <td>86</td>
    </tr>
    <tr>
      <td>7.2.</td>
      <td>Tagging Language in the Edition</td>
      <td>87</td>
    </tr>
    <tr>
      <td>7.2.1.</td>
      <td>Inscriptions consisting of sections in different languages</td>
      <td>87</td>
    </tr>
    <tr>
      <td>7.2.2.</td>
      <td>Inscriptions containing foreign words or phrases</td>
      <td>87</td>
    </tr>
    <tr>
      <td>7.3.</td>
      <td>Abbreviations</td>
      <td>88</td>
    </tr>
    <tr>
      <td>7.4.</td>
      <td>Optional Encoding of Semantic Features</td>
      <td>88</td>
    </tr>
    <tr>
      <td>7.4.1.</td>
      <td>Personal names</td>
      <td>88</td>
    </tr>
    <tr>
      <td>7.4.2.</td>
      <td>Adding ranks and roles to names</td>
      <td>89</td>
    </tr>
    <tr>
      <td>7.4.3.</td>
      <td>Place names</td>
      <td>90</td>
    </tr>
    <tr>
      <td>7.4.4.</td>
      <td>Measurements</td>
      <td>90</td>
    </tr>
    <tr>
      <td>7.4.5.</td>
      <td>Tagged semantic features interacting with text or markup</td>
      <td>90</td>
    </tr>
    <tr>
      <td>7.5.</td>
      <td>Visual Features</td>
      <td>91</td>
    </tr>
    <tr>
      <td>7.5.1.</td>
      <td>The scope of visual features encoded in attributes</td>
      <td>91</td>
    </tr>
    <tr>
      <td>7.5.2.</td>
      <td>Alignment</td>
      <td>92</td>
    </tr>
    <tr>
      <td>7.5.3.</td>
      <td>Directionality and orientation</td>
      <td>92</td>
    </tr>
    <tr>
      <td>7.5.4.</td>
      <td>Script</td>
      <td>93</td>
    </tr>
    <tr>
      <td>7.5.5.</td>
      <td>Lettering</td>
      <td>94</td>
    </tr>
    <tr>
      <td>8.</td>
      <td>General Guidance for Tidy XML Code</td>
      <td>95</td>
    </tr>
    <tr>
      <td>8.1.</td>
      <td>Spaces and New Lines in the Code</td>
      <td>95</td>
    </tr>
    <tr>
      <td>8.1.1.</td>
      <td>White space</td>
      <td>95</td>
    </tr>
    <tr>
      <td>8.1.2.</td>
      <td>Editorial spaces and markup</td>
      <td>96</td>
    </tr>
    <tr>
      <td>8.1.3.</td>
      <td>Editorial hyphens and markup</td>
      <td>98</td>
    </tr>
    <tr>
      <td>8.2.</td>
      <td>Top to Bottom Hierarchy</td>
      <td>98</td>
    </tr>
    <tr>
      <td>8.2.1.</td>
      <td>Block-level elements representing XML structure and extrinsic structure</td>
      <td>98</td>
    </tr>
    <tr>
      <td>8.2.2.</td>
      <td>Block-level elements representing intrinsic structure</td>
      <td>99</td>
    </tr>
    <tr>
      <td>8.2.3.</td>
      <td>Empty elements representing extrinsic structure</td>
      <td>99</td>
    </tr>
    <tr>
      <td>8.2.4.</td>
      <td>Empty elements representing local features</td>
      <td>99</td>
    </tr>
    <tr>
      <td>8.2.5.</td>
      <td>Phrase-level elements</td>
      <td>99</td>
    </tr>
    <tr>
      <td>9.</td>
      <td>Additional Content Divisions</td>
      <td>101</td>
    </tr>
    <tr>
      <td>9.1.</td>
      <td>The Critical Apparatus</td>
      <td>101</td>
    </tr>
    <tr>
      <td>9.1.1.</td>
      <td>Overview</td>
      <td>101</td>
    </tr>
    <tr>
      <td>9.1.2.</td>
      <td>Indicating location</td>
      <td>102</td>
    </tr>
    <tr>
      <td>9.1.3.</td>
      <td>Specifying a precise spot by a lemma</td>
      <td>103</td>
    </tr>
    <tr>
      <td>9.1.4.</td>
      <td>Alternative readings, restorations and emendations</td>
      <td>104</td>
    </tr>
    <tr>
      <td>9.1.5.</td>
      <td>Identical lemmas, identical readings</td>
      <td>104</td>
    </tr>
    <tr>
      <td>9.1.6.</td>
      <td>XML tags in lemmas and readings</td>
      <td>105</td>
    </tr>
    <tr>
      <td>9.1.7.</td>
      <td>Freeform apparatus notes</td>
      <td>105</td>
    </tr>
    <tr>
      <td>9.1.8.</td>
      <td>Textpart divisions in the apparatus</td>
      <td>105</td>
    </tr>
    <tr>
      <td>9.2.</td>
      <td>The Translation</td>
      <td>106</td>
    </tr>
    <tr>
      <td>9.2.1.</td>
      <td>Overview</td>
      <td>106</td>
    </tr>
    <tr>
      <td>9.2.2.</td>
      <td>Front matter in a translation</td>
      <td>107</td>
    </tr>
    <tr>
      <td>9.2.3.</td>
      <td>Attaching multiple translations</td>
      <td>107</td>
    </tr>
    <tr>
      <td>9.2.4.</td>
      <td>Reproducing a published translation</td>
      <td>108</td>
    </tr>
    <tr>
      <td>9.2.5.</td>
      <td>Structural markup in translation</td>
      <td>109</td>
    </tr>
    <tr>
      <td>9.2.6.</td>
      <td>Indicating correspondence to the original</td>
      <td>109</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>9.2.7.</td>
      <td>Phrase-level markup in translations</td>
      <td>110</td>
    </tr>
    <tr>
      <td>9.2.8.</td>
      <td>Foreign words</td>
      <td>110</td>
    </tr>
    <tr>
      <td>9.2.9.</td>
      <td>Additions to the translation</td>
      <td>110</td>
    </tr>
    <tr>
      <td>9.2.10.</td>
      <td>Indicating uncertainty</td>
      <td>111</td>
    </tr>
    <tr>
      <td>9.2.11.</td>
      <td>Indicating incorrect or unexpected text</td>
      <td>112</td>
    </tr>
    <tr>
      <td>9.2.12.</td>
      <td>Gaps in the translation</td>
      <td>112</td>
    </tr>
    <tr>
      <td>9.2.13.</td>
      <td>Blank space in the translation</td>
      <td>113</td>
    </tr>
    <tr>
      <td>9.2.14.</td>
      <td>Indicating bitextuality</td>
      <td>113</td>
    </tr>
    <tr>
      <td>9.3.</td>
      <td>The Commentary</td>
      <td>113</td>
    </tr>
    <tr>
      <td>9.3.1.</td>
      <td>Overview</td>
      <td>113</td>
    </tr>
    <tr>
      <td>9.3.2.</td>
      <td>Structure of the commentary and correspondence to the text</td>
      <td>114</td>
    </tr>
    <tr>
      <td>9.4.</td>
      <td>The Bibliography</td>
      <td>114</td>
    </tr>
    <tr>
      <td>9.4.1.</td>
      <td>Overview</td>
      <td>114</td>
    </tr>
    <tr>
      <td>9.4.2.</td>
      <td>The structured bibliography</td>
      <td>115</td>
    </tr>
    <tr>
      <td>9.4.3.</td>
      <td>Bibliographic sigla</td>
      <td>115</td>
    </tr>
    <tr>
      <td>9.4.4.</td>
      <td>The epigraphic lemma</td>
      <td>115</td>
    </tr>
    <tr>
      <td>9.4.5.</td>
      <td>Full markup example for the bibliography</td>
      <td>116</td>
    </tr>
    <tr>
      <td>10.</td>
      <td>Globally Available Markup Outside the Edition</td>
      <td>117</td>
    </tr>
    <tr>
      <td>10.1.</td>
      <td>Editorial Markup Outside the Edition</td>
      <td>117</td>
    </tr>
    <tr>
      <td>10.2.</td>
      <td>Formatting</td>
      <td>117</td>
    </tr>
    <tr>
      <td>10.2.1.</td>
      <td>Character formatting</td>
      <td>117</td>
    </tr>
    <tr>
      <td>10.2.2.</td>
      <td>Lists</td>
      <td>118</td>
    </tr>
    <tr>
      <td>10.3.</td>
      <td>Encoding Language</td>
      <td>118</td>
    </tr>
    <tr>
      <td>10.3.1.</td>
      <td>Tagging language with @xml:lang</td>
      <td>118</td>
    </tr>
    <tr>
      <td>10.3.2.</td>
      <td>Tagging language in pre-existing containers</td>
      <td>118</td>
    </tr>
    <tr>
      <td>10.3.3.</td>
      <td>Tagging foreign languages outside the edition</td>
      <td>119</td>
    </tr>
    <tr>
      <td>10.4.</td>
      <td>Notes, Quotations and References</td>
      <td>119</td>
    </tr>
    <tr>
      <td>10.4.1.</td>
      <td>Encoding notes</td>
      <td>119</td>
    </tr>
    <tr>
      <td>10.4.2.</td>
      <td>Encoding titles</td>
      <td>120</td>
    </tr>
    <tr>
      <td>10.4.3.</td>
      <td>Quotations without an encoded reference</td>
      <td>120</td>
    </tr>
    <tr>
      <td>10.4.4.</td>
      <td>Quoting published material</td>
      <td>121</td>
    </tr>
    <tr>
      <td>10.4.5.</td>
      <td>Bibliographic citations</td>
      <td>121</td>
    </tr>
    <tr>
      <td>10.4.6.</td>
      <td>Referring to inscriptions in the DHARMABase</td>
      <td>123</td>
    </tr>
    <tr>
      <td>10.5.</td>
      <td>Encoding Names</td>
      <td>124</td>
    </tr>
    <tr>
      <td>10.5.1.</td>
      <td>Tagging contemporary names</td>
      <td>124</td>
    </tr>
    <tr>
      <td>10.6.</td>
      <td>Attributes as Referencing Systems</td>
      <td>124</td>
    </tr>
    <tr>
      <td>10.6.1.</td>
      <td>Encoding authorship with @resp</td>
      <td>124</td>
    </tr>
    <tr>
      <td>10.6.2.</td>
      <td>Crediting publications with @source</td>
      <td>125</td>
    </tr>
    <tr>
      <td>10.6.3.</td>
      <td>Identifying persons and places with @key</td>
      <td>125</td>
    </tr>
    <tr>
      <td>10.6.4.</td>
      <td>Identifying elements with @xml:id</td>
      <td>125</td>
    </tr>
    <tr>
      <td>10.7.</td>
      <td>Punctuation and Style in Modern Languages</td>
      <td>126</td>
    </tr>
    <tr>
      <td>11.</td>
      <td>The TEI Header</td>
      <td>127</td>
    </tr>
    <tr>
      <td>11.1.</td>
      <td>Describing the XML Document</td>
      <td>127</td>
    </tr>
    <tr>
      <td>11.1.1.</td>
      <td>The title</td>
      <td>127</td>
    </tr>
    <tr>
      <td>11.1.2.</td>
      <td>The responsibility statement</td>
      <td>127</td>
    </tr>
    <tr>
      <td>11.1.3.</td>
      <td>The publication statement</td>
      <td>127</td>
    </tr>
    <tr>
      <td>11.2.</td>
      <td>Describing the Original Document</td>
      <td>128</td>
    </tr>
    <tr>
      <td>11.2.1.</td>
      <td>The hand description</td>
      <td>128</td>
    </tr>
    <tr>
      <td>11.3.</td>
      <td>Keeping Track of File History</td>
      <td>129</td>
    </tr>
    <tr>
      <td colspan="2">Appendices</td>
      <td>131</td>
    </tr>
    <tr>
      <td>Appendix A.</td>
      <td>Converting CII/EI Markup Conventions to EpiDoc</td>
      <td>131</td>
    </tr>
    <tr>
      <td>Appendix B.</td>
      <td>Metre (Prosody)</td>
      <td>132</td>
    </tr>
    <tr>
      <td></td>
      <td>Looking up Sanskrit metres</td>
      <td>132</td>
    </tr>
    <tr>
      <td></td>
      <td>Syllable length</td>
      <td>132</td>
    </tr>
    <tr>
      <td></td>
      <td>Prosodic code</td>
      <td>133</td>
    </tr>
    <tr>
      <td></td>
      <td>Sanskrit syllabic metres</td>
      <td>134</td>
    </tr>
    <tr>
      <td></td>
      <td>Notes on <i>anuştubh</i></td>
      <td>136</td>
    </tr>
    <tr>
      <td></td>
      <td>Notes on the <i>upajāti</i> family</td>
      <td>137</td>
    </tr>
    <tr>
      <td></td>
      <td>Notes on the <i>vaitāliya</i> family</td>
      <td>137</td>
    </tr>
    <tr>
      <td></td>
      <td>Vedic trimeter</td>
      <td>138</td>
    </tr>
    <tr>
      <td></td>
      <td>Sanskrit/Prakrit moraic metres</td>
      <td>138</td>
    </tr>
    <tr>
      <td></td>
      <td>Tamil metres</td>
      <td>139</td>
    </tr>
    <tr>
      <td>Appendix C.</td>
      <td>"Case Studies" in Encoding Complex Layout</td>
      <td>140</td>
    </tr>
    <tr>
      <td></td>
      <td>Case study 1: four-faced stele</td>
      <td>140</td>
    </tr>
  </tbody>
</table>
<table><tr><td>Case study 2A: copperplate charter with seal and other goodies</td><td>142</td></tr><tr><td>Case study 2B: copperplate charter with a lost plate reconstructed</td><td>144</td></tr><tr><td>Case study 2C: copperplate charter with a lost plate not reconstructed</td><td>145</td></tr><tr><td>Appendix D. Language Codes</td><td>146</td></tr><tr><td>Appendix E. Titling Conventions</td><td>147</td></tr><tr><td>Appendix F. Normalisation Suggestions</td><td>148</td></tr><tr><td><strong>References</strong></td><td><strong>150</strong></td></tr></table>
# 1. Introduction

## 1.1. Version History

<table><thead><tr><td>Author(s)</td><td>Version</td><td>Changes</td><td>Date</td></tr></thead><tbody><tr><td>Balogh, Griffiths</td><td>0.1</td><td>Redaction of the first draft</td><td>2019-07</td></tr><tr><td>Balogh, Griffiths</td><td>0.8</td><td>Expansion and revision for release</td><td>to 2019-12</td></tr><tr><td>Balogh, Griffiths</td><td>0.9</td><td>Redaction for release</td><td>to 2020-03-17</td></tr><tr><td>Balogh, Griffiths</td><td>1.0</td><td>Revision after feedback and discussion</td><td>2020-07-05</td></tr></tbody></table>

### 1.1.1. About this version

- this is the first definitive release version of this Guide

- in case of conflict with the working version in Google Docs,

- the contents of this document override the Google doc version 1.0

- but we may in future create a working version with a higher (fractional) version number in the process of working toward the next release, and the contents of such a document shall override the present one

- please at least skim through the guide cover to cover so that you have an idea of the topics addressed

### 1.1.2. Fundamental changes since version 0.9

- here follows a summary of major changes introduced in 2020

- **line numbering:**

- unique line numbers are now mandatory (§3.2.2)

- the line number 0 is no longer permitted; use 01 instead for specially placed initial lines (§3.3.3)

- **boxlike partitions** (textpart divs):

- the use of this type of encoding is now limited to specific cases and strongly discouraged elsewhere; use a pagelike partition for all other scenarios unless that seems impossible (§3.4.1)

- **space:**

- the use of `<space>` for blank copperplate pages has been discarded; encode only a `<pb/>` for the blank page (§3.5.2; §4.3.4)

- the use of `<space>` for blank lines and in general for visual layout has been discarded (§4.3.4)

- **premodern editorial marks:**

- all such marks are now encoded as `@rend="mark"` regardless of their location and number (§4.5.2)

- **clear characters** uncertainly read because of their shape:

- instead of `<unclear reason="form"/>`, use the TEI-sanctioned `<unclear reason="eccentric_ductus"/>`

- **location references** in apparatus:

- since unique line numbers are now mandatory, the prefixes `p` and `m` are no longer necessary (and no longer permitted) in `@loc` (§9.1.2)

- **editorial correction and normalisation:**

- the relevant guidelines (§5.5) have been revised and slightly simplified

- **encoding of symbols:**

- `@type="symbol"` is no longer used for any symbol (§4.2.6)

- all punctuation marks (§4.2.4) and space fillers (§4.2.5) are explicitly represented in transliteration in addition to being encoded
## 1.2. Introductory Remarks

### 1.2.1. Acknowledgements

- many people in addition to the authors noted above have helped in the creation of this guide; the most significant contributions have been the following

- the creation of §7.4 by Axelle Janiak and Emmanuel Francis

- repeated draft review and suggestions by Annette Schmiedchen, Axelle Janiak and Emmanuel Francis

### 1.2.2. Further reading

- if you are entirely new to XML or the idea of markup, we recommend

- “The Gentle Introduction to Mark-up for Epigraphers” (Roueché and Flanders, n.d.), available at http://www.stoa.org/epidoc/gl/latest/intro-eps.html

- “What is XML and why should humanists care? An even gentler introduction to XML” (Birnbaum 2015), http://dh.obdurodon.org/what-is-xml.xhtml

- for a more in-depth introduction, read the current version of the ur-text “A Gentle Introduction to XML” at https://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html

- a good general introduction to EpiDoc can be found in Bodard 2010, available at http://www.stoa.org/wordpress/wp-content/uploads/2010/09/Chapter05_EpiDoc_Bodard.pdf

- for any specific details beyond what we summarise here, consult

- the EpiDoc guidelines at http://www.stoa.org/epidoc/gl/latest/index.html

- the TEI guidelines at https://tei-c.org/guidelines/

- if you find any contradiction between this document and the above guidelines, please inform the authors of the Guide

### 1.2.3. Software

- the recommended XML editor is Oxygen

- but you are free to use any editor to produce your marked-up texts

- text editing software will usually be able to colour-code XML and may also be able to check the well-formedness of the markup or even to validate against a schema

- working in Oxygen, you will need to set a suitable font for the Editor at Options/Preferences/Appearance/Fonts

- we find that a suitable font

- can correctly display all the diacritical characters you work with

- is easy on the eye

- is preferably one in which the characters | (vertical bar), l (lowercase L) and I (uppercase i) are all easily distinguishable

- is preferably not too wide, so that you can see plenty of text even when not working on a full screen

- some fonts we have tested and liked include:

- Google's free Noto Serif and Noto Sans

- Microsoft's Cambria and Consolas

### 1.2.4. Miscellaneous

- this guide presupposes that you possess, and are at least superficially familiar with, the DHARMA Transliteration Guide

- the text fragments used for illustration are at present mostly Sanskrit from India

- contributors working with other languages and regions are welcome to submit samples more relevant to their work, especially if these may require a way of treatment different from the methods described here

- for the sake of brevity and simplicity, details irrelevant to the topic at hand may be silently normalised, restored, corrected or altered in illustrations drawn from actual inscriptions

- XML `<elements>` mentioned in discussion or used in illustrations are set apart from regular text by typeface, text colour and a shaded background
- for the sake of brevity and simplicity, details irrelevant to the topic at hand (such as end-tags, attributes and text content) are often omitted in illustrations even though they may be mandatory in actual practice

- XML `@attributes`, when mentioned on their own, are prefixed with an `@` sign and highlighted in the same way as elements

## 1.3. Terms and Definitions

### 1.3.1. Abbreviations

In addition to some straightforward abbreviations, this Guide uses:

- EGD the DHARMA Encoding Guide for Diplomatic Editions (the present document)

- TG the DHARMA Transliteration Guide<fnref n="1" />

- ZG the DHARMA Zotero Guide<fnref n="2" />

### 1.3.2. Basic terminology

Some technical terms related to encoding and epigraphy are explained as they are introduced throughout the text of this guide, while a few basic terms are gathered here for clarification.

- **markup** traditionally means annotation within a text to convey information about the presentation of the text, including among others

- markings in a manuscript to instruct a typesetter, e.g. *underline* to indicate conversion to italics

- various brackets and other signs used in philology and epigraphy, e.g. to indicate that certain parts of a text are tentatively read or supplied by the editor

- the TEI guidelines define **encoding** and **markup** as synonymous and applicable in a widely generalised sense to “any means of making explicit an interpretation of a text”<fnref n="3" /> and including typographic devices, punctuation marks and even spaces

- in the more circumscribed usage of this guide,

- **markup** may refer to editorial signs used in a printed edition or to XML encoding

- **encoding** refers specifically to the method of encoding texts in XML

- a **markup language** is a set of markup conventions used together

- **XML** (eXtensible Markup Language) is a machine-readable markup language used for a wide variety of purposes and independent of hardware or software platform

- **TEI** (the Text Encoding Initiative) is a standard for the machine-readable encoding of texts (understood in a very broad sense) to facilitate text documentation, text representation, text analysis and interpretation

- TEI has been developed and is maintained by the eponymous Text Encoding Initiative Consortium

- TEI defines a versatile and massive set of XML methods to mark up texts

- **EpiDoc** is a subset of TEI-compliant markup rules specifically devised for marking up epigraphic documents

- the word **structure** is used in three distinct senses in this guide:

- **intrinsic structure** refers here to the semantic and metrical structure of a text as abstracted from its physical medium, involving features such as

- stanzas and other prosodic units

- semantic units (“paragraphs” and “anonymous blocks”) in prose, demarcated by changes in topic

- **extrinsic structure** refers here to the physical structure of a particular manifestation of a text as a tangible creation, involving features such as

<footnote n="1">¹ Find the latest release version at https://halshs.archives-ouvertes.fr/halshs-02272407, and the latest internal (draft) version at https://github.com/erc-dharma/project-documentation/tree/master/guides/transliteration. The references to the TG in this document pertain to TG version 3, released simultaneously with EGD version 1.</footnote>

<footnote n="2">² Find the latest internal version at https://github.com/erc-dharma/project-documentation/tree/master/guides/zotero.</footnote>

<footnote n="3">³ https://tei-c.org/release/doc/tei-p5-doc/en/html/SG.html.</footnote>
- lines of a particular length that do not coincide with any intrinsic structural unit of the text as a rule, though they may do so

- various inscribed fields such as columns and object surfaces

- sides of copperplate inscriptions (which we call “pages”)

- XML structure or markup structure refers to the way in which markup elements are structured

### 1.3.3. XML terms and concepts

- the conceptual model of XML is based on structural units technically known as **elements**, which may be

- **empty**, containing neither text nor further elements; or

- **non-empty**, containing

- only text, or

- only further (empty or non-empty) XML elements, or

- mixed content, i.e. both text and further elements

- within an XML document, elements take the form of **tags**: words of code distinguished from the textual content by being always wrapped in angle brackets `<>`

- most text editing software will use **syntax highlighting** to make tags visually pop out from the content by colouring them differently

- in addition to elements and text, XML documents may contain a few other items which need not concern you generally, except for one item type that you should be aware of: XML allows the use of **character entity references**

- these are short code words preceded by an `&` (ampersand) and followed by a `;` (semicolon)

- the purpose of character entity references is to allow the typing, display and processing of characters which are

- not necessarily supported on certain platforms (such as accented characters, but this case need not bother you)

- reserved for a special function in XML (and this is what matters to us); thus,

- should you need to use the `<` character (which an XML processing engine would interpret as the beginning of an XML tag), you must instead use the entity reference `&lt;`; (where `lt` stands for “less than”)

- should you need to use the `&` character (which an XML processing engine would interpret as the beginning of an entity reference), you must instead use the entity reference `&amp;` (where `amp` stands for “ampersand”)

- so, if during validation in Oxygen you encounter unexpected errors, consider if you may have used the character `&` or `<` inadvertently

- to correct the mistake, type the `&` character, whereupon Oxygen will automatically suggest a list of pre-defined entity references (starting with `&amp;`) so all you need to do is select and accept the suggestion for the character you need

- in addition to being enclosed in angle brackets, every XML element must be closed with the character `/` (slash)

- **non-empty elements** must always consist of a pair of tags:

- a start-tag which names the element, e.g. `<unclear>

- and an end-tag which includes the slash and repeats the element name, e.g. `</unclear>

- the text and/or other elements between these two tags are the content of such an element

- as XML hierarchy is always nested, an end-tag always signifies the end of the most recently opened element

- the tags for **empty elements** normally include this closer sign, e.g. `<lb/>`

- but they may also be represented as a regular pair of tags with nothing between them: `<lb></lb>

- for our purposes, non-empty elements are distinguished into two basic types:

- **phrase-level** elements, which must be entirely contained within a block-level element and cannot appear except within one

- these serve to mark up local features of the text, for example uncertain readings, editorial alterations, segments in a different script and numerals
- **block-level elements** or chunks, which must contain all text within an edition

- these serve to encode the intrinsic structure of a text (§2)

- text structure is thus conceived of as **hierarchical**, consisting of "boxes within boxes within boxes" or more accurately an *ordered hierarchy of content objects*

- as an illustration

- the formatted text ABCDEFG can be encoded with XML tags marking the string BCDEF as bold and the string CDE within it as italic, since the italic string is nested within the bold one

- but the text ABCDEFG cannot be encoded with tags marking BCDE as bold and DEF as italic, since neither of these strings are fully nested within the other

- instead, one would have to encode the formatting in one of the following ways:

- BC as bold, DE as bold and italic, and F as italic

- BCDE as bold, DE (within the former) as italic, and F (separately) as italic

- BC as bold, DEF as italic, and DE (within the former) as bold

- every XML document must be wrapped in a **root element** which serves as a container for the document as a whole

- all other elements are **nested** (embedded) either directly within the root element, or at a lower level of embedding

- if an element is embedded directly within another element, then the former is referred to as a **child** of the latter, and the latter as the **parent** of the former

- if an element is embedded at any depth within another element, then the former is a **descendant** of the latter, and the latter is the **ancestor** of the former

- thus, in Example 1.3.3.A,

- B and E are children of A (the root element)

- C and D are children of B

- F is the child of E

- B, C, D, E and F are all descendants of A

- while such a conceptual model is eminently suitable for representing the structure of texts in general, it faces a problem when it is desirable to encode further dimensions, i.e. additional (non-coterminous) structures within the same text, such as the extrinsic structure of an epigraphic document as *well as* the intrinsic structure of the text inscribed there

- such situations are referred to as **overlapping hierarchies**: although either of these dimensions could be represented as an ordered hierarchy, the structures overlap (for instance, a stanza may begin in one inscribed line and end in the next)

- other overlapping hierarchies relevant to textual studies include

- syntactical structure

- semantically distinguished segments (such as names or colophons)

- the location of spots of damage in a physical support

- lemmas to which apparatus entries or commentarial notes may need to be anchored

- since XML elements **must never overlap**, the primary structure of an XML document can represent no more than one hierarchy relevant to the encoded text

- in our EpiDoc editions, the primary hierarchy is that of the text's intrinsic (as opposed to physical) structure

- any alternative hierarchies must be represented in XML using one of two basic methods:

- by using dedicated empty elements (called "milestones") as pointlike markers of transitions in the alternative hierarchy, instead of non-empty elements as containers for items of the hierarchy

- thus in our editions, transition points in physical structure are marked with empty elements instead of treating lines and other extrinsic units as elements of the primary hierarchy

- by deploying linking mechanisms to establish a connection between items located in disparate points of the primary hierarchy

<caption>Example 1.3.3.A: XML hierarchy</caption>

```xml
<A>
  <B>
    <C></C>
    <D></D>
  </B>
  <E>
    <F></F>
  </E>
</A>
```
- in our editions this method is most prominently used in the critical apparatus, which is built using **standoff markup**, where the apparatus is located in a section of the XML document separate from the text edition

- alternative hierarchies may also be disregarded in XML editions; thus

- we do not, at the present stage, use any markup to represent the syntactical structure of a text

- where physical features of the inscription, such as spots of damage which render the text unclear or illegible, overlap with the intrinsic structure, we use separate XML elements to mark up stretches of the same physical feature divided between two separate elements of the primary hierarchy (see §8.2), and do not use any linking to indicate that the two are in fact a single continuous spot of damage (though such linking would be possible)

- XML element names (technically known as generic identifiers) are case-sensitive: e.g. `<unclear>` cannot be substituted with `<Unclear>` or `<UNCLEAR>`

- XML elements often have **attributes**, whose function is to record additional information about an element

- attributes have a name (a code word) and a value, which are incorporated into the tag for an empty element, or into the start-tag of a non-empty element, e.g.

- `<space quantity="3" unit="character" />`

- `<unclear cert="low">...</unclear>`

- one element may have any number of attributes

- attributes must be separated by spaces from each other and from the element name

- attributes may appear in any order within an element

- e.g. `<space unit="character" quantity="3" />` is entirely identical in meaning to the above example with the same attributes in an inverted order

- the attribute name is followed by an equal sign and the value in double quote marks<fnref n="4" />

- note that these must be simple typewriter-style quote marks (i.e. `" "`)

- when typing code in a word processor instead of a dedicated XML editor or generic text editor, you must be careful not to allow your “smart” software to change them into prettier printer’s quote marks (i.e. “ ”)

- attributes always qualify only the element to which they belong and have no influence on any other elements such as neighbouring ones or elements of the same type elsewhere in the XML structure

- however, attributes may be inherited by elements further down in the hierarchy, so that if an attribute is used in an element that contains further elements to which that attribute can apply, then the attribute and value encoded in the ancestor element will also pertain to the descendant elements

- when attributes are discussed in human-readable text without being cited as full XML tags, they are conventionally not highlighted in any way, but are prefixed with an `@` (“at”, implying “attribute”) sign; thus, in the above examples

- the element `<space>` has the attributes `@quantity` and `@character`, while the element `<unclear>` has the attribute `@cert`

- in addition to text and elements proper, XML documents may contain some other items, among which you only need to use one:

- an **XML comment** is anything that is not considered to be part of the document and will be ignored by computers processing an XML file

- an XML comment must begin with the characters ` <!-- ` and end with the characters ` --> `

- comments may be added by editors as notes to other team members to explain their choice of code or to discuss problems in the edition, e.g. ` <!--I'm not sure how to mark this up--> `

<footnote n="4">⁴ The use of single quote marks (‘ apostrophe) is also permitted by the XML standard. However, for the sake of consistency, we shall always use double quote marks.</footnote>
- comments may also be used to "switch off" parts of an XML document without deleting them: any XML code placed within the comment opening and closing sequence will become invisible to computer processing<fnref n="5" />

- an XML document is said to be **well-formed** if it follows the above structural requirements, i.e.

- the entire document is enclosed in a root element

- there is no overlap between any elements

- the start and end of each element is explicitly marked with a tag

- a well-formed XML document may use any arbitrary element names in any particular order and hierarchy: there is no universal and fixed list of possible XML element names and definitions (which is why this is an eXtensible Markup Language)

- the set of rules specifying how certain elements must or must not appear in structural relation to other elements is called an XML **schema** (thus, our editions follow the EpiDoc schema)

- an XML document is said to be **valid** if, in addition to being well-formed, it is structured in such a way as to meet the requirements of a particular schema

### 1.3.4. Conceptual markup

- one of the key points in the "philosophy" of XML is the use of conceptual markup in order to facilitate a separation of the concerns of content and appearance

- **conceptual markup** (also called descriptive markup and semantic markup) essentially means tagging content for *what it is*, as opposed to other types of markup (which are only mentioned here for contrast, but which you need not worry about), namely

- presentational markup, which tags content for *what it should look like*, as in simple WYSIWYG word processing where you can apply bold, italic, font choice, colour, etc. to bits of text

- procedural markup, which tags content for *what an algorithm should do with it*, as for instance in TeX (as opposed to LaTeX, which mostly uses conceptual markup)

- as an illustration

- in a word-processor document you might use only presentational markup, such as

- 16-point bold for primary headings, 14-point bold for secondary headings, and you might italicise foreign words and book titles,

- whereas in an XML document you would tag these items as primary/secondary headings, foreign words and titles respectively<fnref n="6" />

- for presentation, your XML would undergo a transformation (according to separately encoded instructions) and then be displayed as dictated by a stylesheet (also separately encoded) which would determine all details of appearance for each kind of tag in your code

- in presentational markup, you would be prone to making mistakes, e.g. accidentally using 15-point text for a heading or forgetting to make a primary heading bold, which would at the least make your text look untidy

- using conceptual markup greatly reduces the chance of such mistakes

- in presentational markup, you would not have an easy way to manipulate your content selectively, for example to extract a table of contents, and you would have no way to selectively manipulate any kind of content that is not uniquely formatted: in the example above, you would have no means at all to extract a list of titles from your text, since titles are formatted in the same way as foreign words

- with conceptual markup, all these things are easily done

- in presentational markup, it would be difficult to change the appearance of items already formatted: to change all primary titles to a different font, you would have to search and replace a precise set of formatting instructions with another, and to underline all titles, you would have to check every piece of italic text manually and underline only if it is a title

<footnote n="5">⁵ In Oxygen, press CTRL + SHIFT + , (comma) to turn selected text into a comment or to uncomment text around the cursor.</footnote>

<footnote n="6">⁶ You are probably aware that advanced WYSIWIG word processing software usually also provides such a facility (the use of styles), which is indeed conceptual markup.</footnote>
- since formatting is handled by a separate stylesheet in conceptual markup, changing details of global formatting is an easy matter

## 1.4. The Structure of an EpiDoc Edition

- this section presents an overview of the elements comprising a digital edition in EpiDoc

- the code shown below is from the DHARMA EpiDoc template version 02 (as of May 2020), an adaptation of the generic EpiDoc template

- the template file is available at https://github.com/erc-dharma/project-documentation/blob/master/templates/DHARMA_EncodingTemplateInscription_v02.xml

- thus, you will not need to learn and produce this code, only to find your way around it and add contents

- the template contains XML comments (§1.3.3) with instructions on filling out contents, but these have been removed from the sample below, and replaced with XML comments clarifying the nature of various parts of the code

- should you find a discrepancy between the sample below and a later version of the template, the contents of the latest template shall prevail

- the explanatory comments in the sample below refer to sections of this Guide, and are not identical to the comments containing instructions in the actual template

```xml
<!--XML files begin with a declaration specifying the type of document, normally followed by some processing instructions. You will never need to touch this part of the code. -->
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://www.stoa.org/epidoc/schema/latest/tei-epidoc.rng"
schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://www.stoa.org/epidoc/schema/latest/tei-epidoc.rng"
schematypens="http://purl.oclc.org/dsdl/schematron"?>
<!--The element <TEI> must wrap all TEI-compliant content as a root tag. In our case this includes everything other than the XML declaration and processing instructions. -->
<TEI xmlns="http://www.tei-c.org/ns/1.0">
 <!--A header section identifying the digital document and containing additional descriptive information metadata about the encoded text is a mandatory component of every TEI document. The contents of the header are grouped into sections called statements and descriptions, discussed in §11. -->
<teiHeader xml:lang="eng">
<fileDesc>
<titleStmt>
<title>Encoding template for inscription</title>
<respStmt>
<resp>EpiDoc encoding</resp>
<persName ref="part:jodo">
<forename>John</forename>
<surname>Doe</surname>
</persName>
</respStmt>
<respStmt>
<resp>intellectual authorship of edition</resp>
<persName ref="part:jodo">
<forename>John</forename>
<surname>Doe</surname>
</persName>
</respStmt>
</titleStmt>
<publicationStmt>
<authority>DHARMA
<note>This project has received funding from the European Research Council ERC under the European Union's Horizon 2020 research and innovation programme grant agreement no 809994.</note>
</authority>
<pubPlace></pubPlace>
<idno type="filename">DHARMA_EncodingTemplateInscription</idno>
<availability>
```
```xml
<licence target="https://creativecommons.org/licenses/by/4.0/">
<p>This work is licensed under the Creative Commons Attribution 4.0 Unported Licence. To view a copy of the licence, visit https://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.</p>
<p>Copyright c 2019-2025 by John Doe.</p>
</licence>
</availability>
<date from="2019" to="2025">2019-2025</date>
</publicationStmt>
<sourceDesc><!-- At present, only handDesc needs your attention see §11.2; do not touch the rest of this section. -->
<msDesc>
<msIdentifier>
<repository>DHARMAbase</repository>
<idno/>
</msIdentifier>
<msContents>
<summary></summary>
</msContents>
<physDesc>
<handDesc>
<p></p>
</handDesc>
</physDesc>
</msDesc>
</sourceDesc>
</fileDesc>
<revisionDesc>
<change who="part:axja" when="2020-03-18" status="draft">Version 2: addition of handDesc and summary</change>
<change who="part:axja" when="2019-12-18" status="draft">Creation of the template</change>
</revisionDesc>
</teiHeader>
 <!-- All text-related content must be wrapped in the element <text>. In TEI, the text container may include elements other than <body>, but EpiDoc convention does not use any of these elements, so <text> and <body> are always opened and closed at the same point. -->
<text xml:space="preserve">
<body>
 <!-- The body container includes a mandatory division containing the edition. -->
<div type="edition" xml:lang="san-Latn">
 <!-- Edition encoded as per §2-§7. -->
</div>
 <!-- The edition may be followed by optional divisions. -->
<div type="apparatus">
 <!-- Apparatus encoded as per §9.1. -->
<listApp>
<app loc="line">
<lem></lem>
</rdg source="bib:AuthorYear_01"></rdg>
</app>
</listApp>
</div>
<div type="translation" xml:lang="eng">
 <!-- Translation encoded as per §9.2. -->
</div>
<div type="commentary">
 <!-- commentary encoded as per §9.3. -->
</div>
<div type="bibliography">
 <!-- Bibliography encoded as per §9.4. -->
<p></p>
<listBibl type="primary">
<bibl n="siglum"/>
</listBibl>
<listBibl type="secondary">
<bibl n="siglum"/>
</listBibl>
</div>
</body>
</div>
```
```html
</listBibl>
</div>
 <!--The elements <body>, <text> and <TEI> must be closed in a sequence opposite to the one in
 which they were opened. -->
</body>
</text>
</TEI>
```
## 2. Marking up Intrinsic Structure in the Edition

### 2.1. Block-level Containers for Intrinsic Structure

#### 2.1.1. Overview

- within `<div type="edition">`, all of the text in an EpiDoc edition must be wrapped in block-level container elements for intrinsic structure, namely

- `<p>` or `<ab>` for prose (detailed in §2.2)

- `<lg>` and `<l>` for verse (detailed in §2.3)

- any number of these elements may be used in any sequence as called for by the nature of the text, but these elements may never be nested in one another

- see §8 for further guidance on how markup elements must be structured

- these block-level elements must contain everything within your edition, except

- `<div>` elements encoding boxlike partitions (§3.4), which must always be outside block-level containers (§8.2.1)

- page beginnings and pagelike milestones (§3.5), which are normally inside block level containers but may in some special cases be outside them (§8.2.3)

- lacunae (§5.4), which are normally inside block level containers but may in some special cases be outside them (§8.2.4)

#### 2.1.2. Container boundaries and text segmentation

- when marking up the end of a block-level container for intrinsic structure and the start of the next block, the respective tags must be placed at word boundaries as accurately as transliteration allows, and may be inserted at any point where an editorial space can be used (as per TG §2.6.1)

- thus, emphatically, structural units may be split on a semantic or metrical basis at points across which the original text applies sandhi (without vowel fusion) and/or employs a single character of the original script, e.g.

- `<p> ... ājñāpayaty</p> <p>astu vo viditam ... </p>

- `<l>yasya yasya yadā bhūmis</l><l>tasya tasya tadā phalaṁ</l>

- optionally, you may flag (or flag and normalise) non-standard usage (§6.3) when sandhi is applied over a major semantic or metrical break

- to do so, employ the applicable markup on both sides of the break

- if a punctuation mark is present at a container boundary, the punctuation mark is to be included at the end of the earlier containing block

- a container boundary may be necessary at a point where an editorial space is not permitted, in the following rare and specific cases

- if the container boundary falls inside a compound,

- see §2.3.6 and text segmentation for the encoding of verse lines ending inside a compound

- avoid creating a prose block that ends inside a compound

- but should you find this absolutely essential, end one block at the desired point and place the editorial hyphen (for compound segmentation) at the beginning of the next block

- if the container boundary is obscured by sandhi involving vowel fusion, whether inside a compound or between independent words, proceed as follows:

- should this happen between one verse line (`<lg>`) and the next line of the same stanza, see §2.3.6 for the applicable encoding

- should this happen across the boundary of `<lg>`, `<p>` or `<ab>` elements, use the following workaround method

- put the end-tag of the earlier container and the start-tag of the latter container after the fused vowel

- begin the text of the latter unit with the consonant following the fused vowel

- add two separate editorial normalisations (§6.3.2) to restore two separate vowels as they would be if sandhi had not been applied:
- one at the end of the earlier block

- and one at the beginning of the later block

- you will need to resort to this workaround in the occasional cases where *iti* is fused in sandhi to the end of a stanza ending in -i, as shown in Example 2.1.2.A below

- it is strongly recommended that you avoid splitting prose containers at a point where vowel fusion is present, but if you find it essential to do so, you may use this workaround, as shown in Example 2.1.2.B below

<caption>Example 2.1.2.A: extraneous text fused to a stanza is split off</caption>

```html
<lg>
...
<1 n="d">pitṛbhiḥ saha majjat<choice><orig>ī</orig><reg>i</reg></choice></1>
</lg>
<ab><choice><orig>ti</orig><reg>Iti</reg></choice></ab>
<p>saṁvatsara-śate ... </p>
```

- the string *majjatīti* is resolved into *majjati Iti* to allow a container break between these words

- since *iti* does not belong semantically to the paragraph after the stanza (being used simply as an end-quote mark), a separate `<ab>` container is created for *iti* between the preceding `<lg>` and the following `<p>`

<caption>Example 2.1.2.B: paragraph boundary fused in sandhi</caption>

```html
<p> ... punye tithau muhūrtte c<choice><orig>ā</orig><reg>a</reg></choice></p>
<p><choice><orig>smin</orig><reg>Asmin</reg></choice> divasa-māsa-samvatsare ... </p>
```

- the string *cāsmin* is resolved into *ca Asmin* to allow a paragraph break between these words

## 2.2. Prose Containers

### 2.2.1. Paragraphs

- the basic container element for prose text is the paragraph, `<p>`

- short prose inscriptions consisting of at least one complete sentence should be wrapped in a single `<p>` element

- we shall break up longer prose sections into semantic paragraphs<fnref n="7" /> on the basis of their content:

- at any point where you feel the topic changes sufficiently to comprise a new semantic unit, end the current paragraph element and start a new one

- splitting a continuously inscribed text into semantic paragraphs is arbitrary and somewhat subjective; when exercising your own judgement, it may help to imagine translating the text and to put paragraph breaks where you would start a new paragraph in your translation

### 2.2.2. Anonymous blocks

- wrap prose text in the tag `<ab>` instead of `<p>` when a distinct unit of text does not constitute at least one complete sentence, as in the following cases

- if the entirety of your inscription (or the entirety of a textpart, for which see §3.4) constitutes less than a complete sentence due to its shortness or lack of syntax, e.g.

- a sealing with just a name; a label inscription on an image; a graffito

- a copperplate seal with just a name (in the genitive, nominative, or without a case ending)

- an auspicious word or symbol in a field set off from the rest of the inscription

- if a segment of the text is semantically or metrically distinct from adjacent containers (`<p>` or `<lg>`), and constitutes less than a complete sentence due to its shortness or lack of syntax, e.g.

- an opening invocation consisting only of the word *siddham* or an auspicious symbol

<footnote n="7">⁷ When representing original documents in TEI, the element `<p>` is normally used for paragraphs visually demarcated as such in the original physical manifestation of a text (i.e. units that start in a new line and may begin with an indent). Since our inscriptions seldom employ such visual paragraphs, yet often contain longer sections of coherent prose that lends itself to such segmentation, we refer to such units as semantic paragraphs and encode them with `<p>`. This editorial segmentation is analogous to segmenting *scripto continua* with editorial spaces and will be likewise helpful in display and interpretation.</footnote>
- a colophon not comprised of complete sentences

- a connective particle or phrase (e.g. *iti*, *api ca*) used to introduce or end stanzas and not functioning as an integral part of the unit adjacent to the stanza

- in addition to prose meeting the above conditions, sections of text so heavily damaged that you cannot determine whether they are in prose or verse should also be wrapped in <ab>

## 2.3. Verse Containers

### 2.3.1. Terminology and definitions

- the terms we use here to discuss metrical structure are as follows:

- **verse**: used as an uncountable noun to refer to text characterised by rhythmically iterated units (generally prosodic units in our case)

- to avoid ambiguity, this Guide never uses “verse” as a countable noun meaning “stanza” or “line” (as defined below), though both are legitimate meanings of this word

- **stanza**: a unit of verse characterised by a (prosodic) pattern and consisting of a (usually) set number of smaller units (lines) that do not, as a rule, occur in less than a full stanza

- in Sanskrit syllabo-quantitative verse, *stanza* is equivalent to *catuṣpadī*

- the term *quatrain* may be used as a synonym for a stanza consisting of four lines

- in Tamil verse, a *stanza* in the usage of this guide is equivalent to a “poem” (*pā*, *pāṭṭu*, *ceyyul*)

- **line**: a unit of verse characterised by a (prosodic) pattern, with several lines (which may have identical or different prosodic patterns) making up a stanza

- in Sanskrit syllabo-quantitative verse, *line* is equivalent to *pāda*

- in Sanskrit/Prakrit quantitative verse, *line* is for our purposes equivalent to *hemistich*, i.e. stanzas of the *āryā* family shall be marked up as consisting of two lines

- in Tamil verse, *line* is equivalent to *aṭi*

- **quarter** is used as a synonym of *line* in the context of Sanskrit syllabo-quantitative verse in order to reduce ambiguity by clearly distinguishing verse lines (an element of intrinsic structure) from physical lines (an element of extrinsic structure, §3.2)

- **hemistich**: a half-stanza, the first or the second pair of lines in a *quatrain*

- note that the term *hemistich* originates from European classical prosody where it is used in a different sense (a half-line), but the term has been widely applied in European discussions of Indic prosody in the sense in which we use it here

- **break** or line break: a boundary between lines or hemistichs, which usually coincides with a word boundary (not identical to a line break in the context of extrinsic structure, for which see §3.2.1)

- **enjambement** in our usage means the occurrence of a line break within a word (usually between members of a compound; rarely within a morpheme)

- **caesura**: a boundary within a line, which divides the line into smaller prosodic units (*cola*) and as a rule coincides with a word boundary

- **colon** (plural *cola*): a prosodic unit smaller than a line, a division resulting from the presence of a *caesura* in a line

- **foot**: a small prosodic unit that has no regard for word boundaries

- in the present Guide this term is only used as applicable to Sanskrit and Prakrit quantitative verse (*mātrāvṛtta*), where feet (*gaṇa*) consist of a set number of morae

- **mora** (plural *morae*): a unit of prosodic length defined as the length of a short syllable

- the length of all long syllables is conventionally counted as two morae in Sanskrit and Prakrit quantitative verse

- **metre**: a prosodic template for a stanza (a fixed pattern of syllables or feet), which has a conventional name

### 2.3.2. Overview

- verse must always be marked up as distinct from prose
- text in verse shall be marked up only for metrical structure, i.e. semantic paragraphs in a longer verse text must be ignored

- the scheme in this section applies to all verse forms in all languages relevant to our project

- should you have difficulties applying the scheme to a particular verse form, please contact the authors and the XML-TEI Data Manager with the details to devise a solution

- this section has been written primarily with Sanskrit syllabo-quantitative verse (varṇavṛtta) in mind; subsections below give guidance on some cases that are to be handled differently, but input is eagerly requested on the structure of non-Sanskrit verse and the special considerations it may need

- see §2.3.9 for various examples of verse encoding

- **stanzas as a whole** must be wrapped in the element `<lg>` (for “line group”), with the following mandatory attributes

- `@n` to assign a number to the stanza (see §2.3.3)

- `@met` to identify the metre of the stanza by a conventional name (see §2.3.4)

- **each line** must, in addition, be wrapped in the element `<l>` (for “line”), with the following attributes

- mandatorily, `@n` to assign a number to the line, with values as follows:

- in Tamil verse, always use Arabic numerals (1, 2, 3, 4)

- in Sanskrit/Prakrit quantitative verse, use pairs of lowercase Latin letters (ab, cd)

- in all other cases, use lowercase Latin letters (a, b, c, d)

- unless you are dealing with stanzas that have (or may have) 10 or more lines, in which case use Arabic numerals instead

- for stanzas anomalously consisting of more or fewer than the expected number of lines, simply encode the actual number of lines, numbering them in sequence (continuing the applicable numbering scheme as described above)

- as required, `@enjamb` with the value `"yes"` to encode the fact that the break at the **end of the line** does not coincide with the **end of a word**, i.e. enjambement is present in this line

- note that this attribute must be added to the `<l>` element containing the initial part of the broken word, not to the one containing the final part

- see also §2.3.6

- optionally, `@real` for lines that deviate from the metre of the stanza as a whole (see §2.3.5)

- **caesuras** shall not be marked up in quantitative verse

- however, if you notice a caesura that was disregarded by the composer or involves sandhi that blurs its location, you may optionally mark it up as follows: `<milestone type="yati" break="no"/>`<fnref n="8" />

- see Example 2.3.9.C for an illustration

- any **original punctuation and internal verse numbering** should be included at its actual locus within the `<l>` element for the line in which it appears

- all rules for marking up punctuation characters (§4.2.4) and numerals (§) apply

- **do not supply** editorial **numbers** or editorial **punctuation** at the ends of stanzas

- editorial numeration is handled through the `@n` attribute of the `<lg>` element, which must be used even when internal verse numbering is present

### 2.3.3. Numbering stanzas

- **every stanza** in your edition **must have a number** encoded in the `@n` attribute of the corresponding `<lg>` element

- this editorial numbering is mandatory whether or not text-internal numeration is present

- if the text includes original numeration, editorial stanza numbering shall follow the rules stated here even if this results in a discrepancy with the original numbering

<footnote n="8">⁸ The TEI element `<caesura>` does not take the attribute `@break` (nor `@type`). Since our use of conventional metre names leaves open the possibility to automatically determine the location of caesuras at the prescribed points, the only reason why we might want to encode them is to facilitate research on non-standard caesuras and *yatibhaṅga*, hence our suggestion to use `<milestone>`.</footnote>
- original stanza numbers should be encoded as part of the text, and tagged as any other number (see §7.1 about encoding the value of numerals, and §4.2.2 about numeral symbols other than decimal digits)

- stanza numbers shall always be Arabic numerals starting from 1

- when it comes to displaying editions, we may choose to auto-convert stanza numbers into Roman numerals throughout our corpus or for specific subcorpora

- by default, stanzas shall be numbered **consecutively** throughout an inscription, with the following exceptions

- if an inscription includes boxlike partitions (§3.4), then stanza numbering must be mandatorily restarted in each textpart division

- if an inscription includes pagelike partitions (§3.5), then stanza numbering may be optionally restarted after each division in order to follow the numbering scheme of a previous edition or the conventions of your specific field

### 2.3.4. Encoding metre for stanzas

- we encode the metrical templates of stanzas by using the traditional/conventional names of metres (e.g. *upajāti*, *śārdūlavikrīḍita*, etc.) as values for the `@met` attribute of `<lg>` elements

- consult the list of metres (Table 3 of Appendix B) for help with metre identification

- if you come across a stanza in a metre to which you can put a name, but that **name is not on the list**

- use the name as a value

- contact the authors and the XML-TEI Data Manager to have the name and template or definition added to the list

- if you find a stanza that follows a set metrical template, but **you cannot put a name to the metre**

- establish the prosodic template and record it in prosodic code as the value of `@met` (see Table 2 of Appendix B for the prosodic code used in attribute values)

- if a text is damaged and you cannot identify the metre with absolute certainty, but you have a **reasonably sound guess** (based on the prosody of the extant part, the length of the lacunose part and/or the metre of surrounding stanzas)

- add the element `<certainty match="../@met" locus="value"/>` directly after the opening `<lg>` tag (before the first `<l>` element), where

- `@match="../@met"` indicates that we are encoding uncertainty regarding the `@met` attribute of the parent element (i.e. `<lg>`), and

- `@locus="value"` indicates that the uncertainty concerns the value of this attribute (i.e. the identification of the metre)

- if a part of your text seems (with reasonable certainty) to be in verse, but it is **too heavily damaged to identify the metre even tentatively**, tag it as `@met="uncertain"`

- but for heavily lacunose verse where the stanza structure cannot be established with any certainty, consider encoding the text in an `<ab>` element (§2.2.2) instead of marking it up as verse

### 2.3.5. Encoding metre for individual lines

- the metre of individual verse lines shall not be encoded separately so long as they conform to the metre encoded for the stanza to which they belong

- however, the actual prosodic instantiation of lines may optionally be encoded when a line deviates from the standard pattern for the stanza,

- **including cases of**

- legitimate metrical variation or constraint of the conventional template, such as *vipulā anuṣṭubh* or *capalā āryā*

- licence, such as employing a short vowel followed by a stop and a semivowel (*muta cum liquida* in classical European prosody)

- lines with anomalous metre, including hypermetrical and hypometrical lines

- **but excluding cases of**
- presumable scribal error (e.g. omission, dittography) or non-standard usage which you as editor have corrected (§6.2) or normalised (§6.3), thereby restoring the expected metre (see also §6.1.4)

- the rare clerical/scribal quirk where the end of a verse is joined in sandhi to a closing *iti*

- unobserved caesuras (which cannot be marked up in this scheme, but may be encoded as mentioned under §2.3.2)

- to encode the actual prosody of a line, optionally add the attribute `@real` to the `<1>` element concerned

- the value of this attribute shall be the actual prosodic pattern of the line recorded in the notation described in Table 2 of Appendix B

- see Example 2.3.9.D, Example 2.3.9.E and Example 2.3.9.F for illustrations

- as a further option, legitimate variant *anuṣṭubh* lines (*vipulās*) may be explicitly encoded by adding `@met` to the `<1>` element concerned

- the value of this attribute shall be the name of the prosodic template for that particular line, as listed in Table 3 of Appendix B

- this, in effect, overwrites locally the value of `@met` encoded for the stanza as a whole

- if you choose to avail of this option, please use it in addition to, not instead of, the option of encoding `@real` on the irregular line

### 2.3.6. Verse lines and text segmentation

- as already stated in §2.1.2, the tags for structural elements must be at word boundaries even where a word boundary is separable only in transliteration and not in a native script

- thus, unlike editions in an Indic script, verse lines must be separated at the exact boundary

- e.g. `kṣaṇād</1><1>unmūlya` and `śambhor</1><1>gguhām`

- NOT `kṣaṇād</1><1>dunmūlya` and `śambho</1><1>rgguhām`

- note that so long as vowel fusion is not involved, non-standard sandhi is irrelevant to the placement of line markup, including

- the presence of hiatus where sandhi is expected, e.g. at the end of an odd line (`@n="a"` or `@n="c"`)

- the presence of sandhi where hiatus is expected, e.g. at the end of an even line (`@n="b"` or `@n="d"`), including sandhi between the end of a stanza and the next stanza or the following prose (for which see also the end of this subsection)

- however, feel free to flag such occurrences as non-standard (§6.3.1)

- where the break is **between** words that are **members of a compound** and vowel fusion sandhi is not involved:

- place the break as above

- add the attribute `@enjamb` with the value `"yes"` to the first `<1>` element involved

- if you are using editorial hyphens for compound analysis (see TG §2.6.2), put your editorial hyphen at the beginning of the second `<1>` element involved

- e.g. `<1 enjamb="yes">...</maṇḍal-ānta</1><1>-vyakta-bhrū-bhaṅga...`

- see Example 2.3.9.A and Example 2.3.9.C for full illustrations

- when **two lines of a stanza are joined in vowel fusion sandhi**, i.e. when the final vowel of a line merges into the initial vowel of the next line,

- put the line break after the fused vowel (do not type a hyphen anywhere)

- add the attribute `@enjamb` with the value `"yes"` to the first `<1>` element involved

- e.g. `<1 enjamb="yes">...</tathā</1><1>yam`

- the editorial normalisation described in §2.1.2 should not be used in this case

- when the **end of a stanza is joined in vowel fusion sandhi to text outside** that stanza, use the workaround described in §2.1.2

- do not use `@enjamb` in this case

- if the particle *iti* is fused in this way to the end of a stanza, and it is not semantically a part of the following paragraph of text (i.e. not translatable as e.g. "therefore" or "having said so," but appears simply in the function of a closing quotation mark), then preferably create a separate `<ab>` container for this word between the preceding `<lg>` and the following `<p>`
### 2.3.7. Verse markup versus other markup

- all **markup** applicable to text **can and must be used** within verse elements

- note in particular that the beginnings of physical lines and, if applicable, the beginnings of pagelike partitions (§3.5) must always be encoded, even if these coincide with the beginnings of verse lines

- if the beginning of a physical line (or page) coincides with the beginning of a verse line, place the `<lb/>` (or other applicable element) within the corresponding `<1>` element and before the text of that verse line, e.g. `<lg n="2" met="anuṣṭubh"><1 n="a"><pb n="5r"/><lb n="42"/><ṣaṣṭi-varṣa-sahasrāṇi...`

- remember that overlapping hierarchies (§1.3.3) must always be avoided

- when phrase-level markup (such as that for reading difficulties, §5.3; editorial intervention, §5.5; or additional features, §7) is applicable to a chunk of text that stretches across the boundary of an element for verse structure, create the applicable phrase-level markup in two parts, on both sides of the structural break (see also §8.2 for details)

- should you find it indispensable to split a stanza or a verse line across more than one structural container, contact the authors of this guide and the XML-TEI Data Manager to discuss how to encode this

### 2.3.8. Marking up structure in lacunose verse

- see §5.4 about marking up lost and illegible text in general, §5.4.4 about marking up lost text with a known metre, and §5.4.7 about dealing with massive lacunae

- the **structural framework** of stanzas (i.e. the `<lg>` and `<1>` tags) **must** as a rule **be fully encoded** even if a significant part of a stanza is lost; for instance

- if only the first three lines of a quatrain are extant, do not omit the last line, but add its markup structure and mark up the entire fourth line as a lacuna

- structural markup cannot be placed inside the markup for that lacuna, so if a lacuna extends from one line of a stanza to the next (or from one stanza to the next, or from a stanza into the preceding or following prose), create lacuna markup separately on both sides of the structural break

### 2.3.9. Markup examples for verse

<caption>**Example 2.3.9.A: varṇavṛtta verse structure with enjambement**</caption>

```xml
<lg n="1" met="pṛthvī">
<1 n="a">pradāna-bhuja-vikkrama-praśama-śāstra-vākyodayair</1>
<1 n="b">uparyyupari-sañcayocchritam aneka-mārggaṁ yaśaḥ</1>
<1 n="c" enjamb="yes">punāti bhuvana-trayaṁ paśupater jjaṭāntar-guhā</1>
<1 n="d">-nirodha-parimokṣa-śīghram iva pāṇḍu gāṅgaṁ payaḥ</1>
</lg>
```

<caption>**Example 2.3.9.B: āryā verse structure**</caption>

```xml
<lg n="42" met="āryā">
<1 n="ab">śaśineva nabho vimalaṁ kaustubha-maṇineva śārṇgiṇo vakṣaḥ</1>
<1 n="cd">bhavana-vareṇa tathedaṁ puram akhilam alaṁkṛtam udāraṁ</1>
</lg>
```

<caption>**Example 2.3.9.C: unobserved caesura (vipulā āryā), with enjambement**</caption>

```xml
<lg n="33" met="āryā">
<1 n="ab" enjamb="yes">smara-vaśaga-taruṇa-jana-va<milestone type="yati"
break="no">llabhāṅganā-vipula-kānta-pīnoru-</1>
<1 n="cd">stana-jaghana-ghanāliṅgana-nirbartsita-tuhina-hima-pāte</1>
</lg>
```

- the unobserved caesura is optionally encoded as per §2.3.2

- `@enjamb` is added mandatorily to the first pāda as per §2.3.6
### Example 2.3.9.D: muta cum liquida licence

```html
<lg n="12" met="anuṣṭubh">
  ...
  <1 n="c" real="++++++-" >yasya vittaṁ ca prāṇāś ca</1>
  <1 n="d">deva-brāhmaṇasād gatāḥ</1>
</lg>
```

* the word *ca* in *pāda* *c* is expected to be a short syllable, but by regular prosodic rules it is positionally long

* the encoding of @real is optional (§2.3.5)

### Example 2.3.9.E: vipulā anuṣṭubh

```html
<lg n="9" met="anuṣṭubh">
  <1 n="a" met="na-vipulā" real="+---+---+">śaurya-satya-vrata-dharo</1>
  <1 n="b">yaḥ prayāga-gato dhanī</1>
  ...
</lg>
```

* the encoding of @real and @met on an individual line are both optional (§2.3.5)

### Example 2.3.9.F: anomalous metre

```html
<lg n="1" met="āryā">
  <1 n="ab" real="----+---+---+---------++">jayati vibhuś catur-bhujaś catur-arṇṇava-vipula-salila-paryyaṅkaḥ</1>
  ...
</lg>
```

* there is syncopation from the second to the third foot: the foot boundary should be halfway through the long syllable *tu*

* mentally, the author's pronunciation may have been *caturabhujaś*, which would scan correctly: should be *jayati vi|bhuś catu|ra-bhujaś...*

* the encoding of @real is optional (§2.3.5)
### 3. Marking up Extrinsic Structure in the Edition

#### 3.1. Overview

- the basic unit of an inscription's physical structure is the line, and line beginnings must be represented in all encoded inscriptions as set out in §3.2 below

- many inscriptions are engraved within a **single**, more or less rectangular **field** as in the illustration below

- the only aspect of extrinsic structure that needs to be encoded in such cases is the sequence of line beginnings (§3.2)

> In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort.

- **slightly more complex** cases may involve

- text presented in a single field but sectioned by empty lines (§3.3.2)

- an auspicious opening symbol, word, phrase or invocation added outside or floated within the principal field (§3.3.3)

- a closing formula inscribed in a margin (§3.3.4)

- the presence of folio numeration (§3.3.5)

- when the principal field itself is **partitioned into several zones**, the methods for encoding partitions differ according to how this extrinsic structure relates to the text's intrinsic structure

- the crux is the **abstract functional pattern** by which the text manifests in multiple inscribed zones, since this is what determines the way in which it can be marked up for structure

<figure><img src="image_4.png" /><figcaption>A: text stops
boxlike partition, §3.4</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>B: texts flows on
pagelike partition, §3.5</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>C: text runs across
gridlike partition, §3.6</figcaption></figure>

- the question to ask yourself while deciding how to mark up partitions is this: what does the text do as it reaches the boundary of one zone?

- if it stops (scheme A), you have a boxlike partition: §3.4

- if it flows on to the next zone (scheme B), you have a pagelike partition: §3.5

- if it runs across into the next zone (scheme C), you have a gridlike partition: §3.6

- although the above abstract schemes show text zones side by side, the actual spatial pattern in which they are laid out relative to one another (e.g. one below the other, on separate faces of a three-dimensional object, etc.) is a metadata issue and has no bearing on the markup required

- the same markup method may be applicable to physically very different objects

- it is recommended that you read through at least the overview and the markup examples for each partition type to familiarise yourself with the possibilities

#### 3.2. Physical Lines

- to make the distinction from verse lines (§2.3.1) explicit, inscribed lines are referred to in this guide as **epigraphic lines** or **physical lines**
- for the purpose of encoding in our project, we define a physical line as a stretch of text whose characters comprise a physically and textually contiguous sequence while being physically distinct from characters belonging to other lines

- this definition includes no presumptions concerning a line's

- position (some lines of a text may be set off from other lines; see §3.3 for specific cases)

- directionality (e.g. some lines run right to left while others run left to right; see §7.5.3)

- orientation (e.g. some lines may be vertical while others are horizontal; see §7.5.3)

- shape (lines may bend in various ways to follow an uneven surface, or the ends of certain lines may bend upward or downward to accommodate extra characters before the margin or the edge of the support)

### 3.2.1. Marking up line beginnings

- since epigraphic lines do not necessarily coincide with the intrinsic structure of a text, the physical lines of an inscription are not treated in markup as units with content, but instead, line beginnings are marked as points, using the empty element `<lb/>`

- this element must always have the attribute `@n`; see §3.2.2

- keep in mind that this element stands for Line Beginnings, not Line Breaks, so even though the two are largely synonymous when used in the context of extrinsic structure, nonetheless

- `<lb/>` must be used at the beginning of the first line, not only for subsequent lines

- `<lb/>` must be present even in inscriptions (or textparts, §3.4) consisting of a single line

### 3.2.2. Numbering lines

- every physical line of text in your edition **must have a number** encoded in the `@n` attribute of the corresponding `<lb/>` element

- line numbering is mandatory even if an inscription (or textpart, §3.4) contains only one line

- line numbering will be utilised both for display and for machine-readable referencing

- in order to eliminate ambiguity in referencing (both human- and machine-readable), every line number in an XML document **must be unique**

- except that if your document has textpart divisions (§3.4), then line numbering must be restarted in each textpart, as the requirement of uniqueness only applies within such a division

- by default, **simple line numbers** shall be **Arabic numerals** starting from 1

- however, line numbers for visually separate incipits may be (or begin with) 0 (see §3.3.3)

- our project uses two schemes of line numbering in documents involving pagelike partitions (§3.5)

- the preference for either system shall be determined on the level of subcorpora, but may be overridden on a case-by-case basis

- in the **consecutive scheme**, all line numbers are **simple line numbers** as defined above

- in this system, the numbering of lines cannot be restarted in pagelike partitions, even though it must always be restarted in boxlike partitions

- in rare cases (namely, copperplate grants with a lost medial plate encoded without the use of textparts; §5.4.8) you will have to use complex line numbers (see below) even if you normally use the consecutive system

- in the **repetitive scheme**, line numbering is restarted for each successive pagelike partition

- to ensure uniqueness, **complex line numbers** must be used in this system

- these consist of a simple line number as above, preceded by a prefix that is the identifier of the current partition, i.e. the value of the `@n` attribute of the corresponding `<pb/>` or `<milestone/>` element in pagelike partitions, and of the containing `<div type="textpart"/>` element in boxlike ones

- for example,

- for a stele inscribed on faces A and B, the lines must be numbered "A1", "A2", etc., and "B1", "B2", etc. on these faces

- for a set of copper plates with pages 1v and 2r, lines must be numbered "1v1", "1v2", etc., and "2r1", "2r2", etc. on these pages
- should the number of your partitions be a numeral or end with a numeral<fnref n="9" /> (including Roman numerals), use a . (period, full stop) as a separator character between the partition number and the simple line number

- e.g. if your partitions are numbered A1, b1, etc., then your line numbers should be "A1.1", "A1.2", etc., and "b1.1", "b1.2", etc.

- if your subcorpus follows the repetitive scheme, then it is recommended that for consistency's sake you use complex line numbers even on copper plates with a single inscribed page

- also for consistency's sake, if your subcorpus follows the repetitive scheme, then complex numbers should be preferred for numbering lines across boxlike partitions

### 3.2.3. Placement of line beginnings

- the `<lb/>` element must always be on the same level as the text (see also §8.2.3), i.e. inside rather than outside block-level elements representing intrinsic structure; thus,

- the first line beginning must be encoded after all required block-level elements have been opened

- e.g. `<lg n="1" met="anuṣṭubh"><1 n="a"><lb n="1"/>Āsīt...`

- if the end of a block-level element coincides with the end of a physical line, the next line beginning element must come at the beginning of the next structural unit, not between the two

- e.g. ...śāntiM</1></lg><lg n="2" met="upajāti"><1 n="a"><lb n="2"/>guptānvaya...

- the only exception to this rule is a massive medial lacuna (§5.4.7), where reconstructed line beginnings may be encoded outside block-level containers

- if there is **lost text** both before and after a line beginning, then it may not be possible to determine the exact number of characters lost on either side of the transition

- if the lacuna is **not restored**, simply encode a gap (§5.4) of unknown or uncertain length at the end of the former and the beginning of the latter line

- if you **supply the lost text** (as per §5.5), encode the line beginning at its most likely position vis-à-vis the text, and if you feel that the uncertainty of this positioning matters, mention it in your commentary to the text<fnref n="10" />

- be careful with spaces and new lines in your XML code around encoded line beginnings; see §8.1.2 for further details

- never add a space between the `<lb/>` element and the following text

- adding a space or starting a new line in your XML file before each `<lb/>` is permitted (but not required), provided that the line beginning coincides with a word break (§3.2.4)

- it is, however, fully acceptable to start a new line within the `<lb/>` element (whether it interrupts a word or not), if this makes your XML document easier for you to scan while working

### 3.2.4. Line beginnings interrupting words

- a physical line beginning is deemed to fall inside a word if it occurs at a point other than between two independent words not fused in vowel sandhi, i.e. at a place where you would not be able to add an editorial space (TG §2.6.1), including cases where

- an initial vowel is fused to the end of the previous line in sandhi (e.g. tathā/yam, maha/rṣi, asā/v api; but not so/yam)

- the words before and after the interruption are compounded to one another (e.g. mahā/rāja)

- and even if there is another feature intervening between the two words separated by the line beginning, such as

- space filler signs (§4.2.5) at the end of the previous line

- a space imposed on the engraver by physical features (§4.3.5) either before or after the interruption

<footnote n="9">⁹ This will not be the case if you follow the numbering schemes recommended by this Guide, but other numbering schemes are permitted for all kinds of partition when there is good reason for their use.</footnote>

<footnote n="10">¹⁰ It is possible in TEI to encode uncertainty regarding the location of a line beginning in a machine-readable way, but the required markup is somewhat complex and we deem that the benefit is not worth the effort.</footnote>
- pre-modern deletion (§4.5.1) either before or after the interruption

- a lacuna (§5.4) before or after the line interruption, provided that the original presence of an interrupted word can be inferred with fair likelihood (see below for details)

- for such line beginnings, the `<lb/>` element signifying the start of the new line must take the attribute `@break` with the value `"no"` to encode the fact that the line beginning does not signify a break in the text

- this allows hyphens to be automatically displayed at the ends of lines where necessary, and it lets computer processing know that a word continues from one line to the next

- it **may not be possible to decide** for certain whether the line beginning interrupts a word **when text** at the end of the preceding line or at the beginning of the current line **is lost**, badly damaged **or unintelligible** for some other reason

- in such cases, always use `@break="no"` when you are reasonably certain that an interruption is present, but do not do so if you are uncertain, specifically:

- when the **end of the previous line is affected**,

- use `@break="no"` if the current line begins with an incomplete indivisible morpheme or with the final part of what you are certain was a compound word

- but do not use `@break="no"` if the text in the current line is intelligible (and plausible in context) as it is, even if there is some chance that the previous line contained a prefix or a compound member attached to the extant word

- the above also applies if the entire previous line, or all text above the current line is lost

- when the **beginning of the current line is affected**,

- use `@break="no"` if the end of the previous line is clearly not the end of an independent word

- but do not use `@break="no"` if the end of the previous line may be the end of an independent word, even if there is a chance that this word continued in the current line

- never start a new line of XML code for line beginnings interrupting words (see §8.1 for further details)

- **never add a hyphen, nor a space** before a line beginning inside a word

- however, if you use **editorial hyphens** for the segmentation of compounds (TG 2.6.2),

- treat boundaries marked by editorial hyphens as being inside words (as above)

- and put the editorial hyphen at the start of the new line instead of the end of the previous line

- e.g. `tomara<lb break="no" n="18"/>-bhindipāla-nārāca`

### 3.3. Not-quite Partitions

#### 3.3.1. Stuff in margins

- there can be many kinds of “stuff” written in the margins of an inscription, and their encoding requires an editorial decision about their nature

- **premodern additions and corrections** written in a margin shall be handled according to §4.5

- ** pagination or foliation** engraved in a margin comprises forme work, to be handled according to §3.3.5

- **auspicious words or symbols** engraved at the beginning of an inscription are spatially offset opening lines (incipits), to be handled according to §3.3.3

- **colophons** engraved below the principal text or vertically in the left or right margin are spatially offset closing lines, to be handled according to §3.3.4

#### 3.3.2. Sectioning with space

- if sections of a reasonably coherent text are separated by vertical (interlinear) space in what is otherwise a fairly well-defined single zone, then, depending on how semantically distinct these sections are, you may choose to

- encode such sections as pagelike partitions (§3.5), since the actual spatial arrangement of partitions one below the other is irrelevant

- encode the text as a single unit, ignoring the interlinear space in your edition and only describing it in the layout description

- in such cases the lines of the inscription must be numbered consecutively throughout the text
- if the first or last line or few lines of an inscription are set apart visually from the rest, see the following subsections (§3.3.3 and §3.3.4) for some further encoding options

### 3.3.3. Spatially offset opening sections (incipits)

- opening symbols, words, phrases or stanzas (called *incipit* in the Western tradition) shall need no explicit semantic markup in our practice

- enclose the contents of the incipit in one or more `<ab>`, `<p>` or `<lg>` elements as applicable (§2)

- if the text of an incipit is **within the regular field and line structure** of an inscription, then no further markup is necessary

- however, if an incipit is visually set apart from the body text,

- you may **optionally** use the numbers 01, 02 etc. for the `<lb/>` elements encoding the beginning of the applicable line

- and assign the number 1 to the first line after the invocation

- if applicable (i.e. if different from the body text), encode the orientation (§7.5.3) and/or script (§7.5.4) of the opening section

- all other details of presentation (e.g. line length, relative location, interference with the regular lines) shall be recorded for human readers in your metadata (layout description), but not encoded explicitly

- the same is applicable if an incipit **floats** partly or wholly **outside the principal field**, as in the examples below

<figure><img src="image_7.png" /><figcaption>Example 3.3.3.A: incipit of two lines inset in the top left corner</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Example 3.3.3.B: incipit written vertically, with upright characters, in the left margin</figcaption></figure>

<figure><img src="image_9.png" /></figure>

<figure><img src="image_10.png" /></figure>

### 3.3.4. Spatially offset closing lines (colophons)

- in some inscriptions, the last line or two may be written outside the principal field,

- either because the designer of the inscription wanted to separate a colophon visually from the rest of the text

- or, occasionally, because the engraver had simply run out of space in the principal field and engraved the final line(s) in a margin or interpolated between the regular lines

- as with incipits, colophons do not require explicit semantic markup

- if the last lines are visually set apart from the body text (whether they are colophons or not), treat them as any other part of the text

- numbering the lines consecutively after the last regular line

- the contents of the last line(s) may be incorporated in the last block-level container of the principal text if the two are semantically contiguous
- but if they are semantically distinct (as is the case with colophons proper), it is better to create a new container for the closing section, using `<ab>`, `<p>` or `<lg>` as called for (§2)

- if applicable (i.e. if different from the body text), encode the orientation (§7.5.3) and/or script (§7.5.4) of the opening section

- all other details of presentation (e.g. line length, relative location, interference with the regular lines) shall be recorded for human readers in your metadata (layout description), but not encoded explicitly

<caption>Example 3.3.4.A: last line inscribed vertically in the right margin</caption>

```html
<p>
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  <lb n="8"/>in it to sit down on or to
  <lb n="9"/>eat: it was a hobbit-hole
  <lb n="10" rend="bt-rotated"/>and that means comfort.
</p>
```

In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole and that means comfort.

### 3.3.5. Pagination or foliation: "forme work"

- if your inscription has a dominant field with one or more much smaller supplementary additions that cannot be integrated with the principal text, for the purpose of markup these supplementary items are classified as **forme work**

- the term is borrowed from printing, where *forme* means the frame constructed to hold the blocks of movable type that constitute a page

- epigraphic occurrences of forme work are primarily foliation or pagination marks on copper plates; if you encounter a different feature that you believe ought to be marked up as forme work, please discuss the issue with the authors of the Guide

- as in the case of boxlike partitions (§3.4), the content of forme work is a complete and meaningful unit in itself, but unlike boxlike zones, it is a supplement to (rather than a subunit of) the principal text of an inscription

- forme work items shall be wrapped in the element `<fw>`, with the following mandatory attributes

- `@n` (even if there is only one forme work item in your document)

- the value of `@n` shall be the same as the `@n` of the `<pb>` element marking the beginning of the page on which the forme work item appears

- `@place`, with values as shown on the right

- if applicable, encode the orientation (§7.5.3) of the forme work

- all other details of presentation (e.g. accurate position, interference with the regular lines) shall be recorded for human readers in your metadata (layout description), but not encoded explicitly

- the `<fw>` element shall appear immediately after the `<pb/>` element marking the start of the page on which the forme work item is found, therefore

- it must come before the first `<lb/>` element on that page

- it will normally appear inside block-level containers for intrinsic structure (§2), often interrupting the course of the text within such containers

- the occurrence of such an interruption is encoded in the page and line beginnings and does not affect the markup for forme work

- the `<fw>` element may be outside block-level containers when forme work is present on a page whose `<pb/>` element is outside block-level containers, i.e. in the rare but potentially possible cases where a page bears forme work, but the rest of the page is blank (§3.5.2) or lacunose (§5.4.7)

<table><thead><tr><th>top-left</th><th>top</th><th>top-right</th></tr></thead><tbody><tr><td>left</td><td>primary<br>inscribed<br>zone</td><td>right</td></tr><tr><td>bot-left</td><td>bottom</td><td>bot-right</td></tr></tbody></table>
- should your inscription have two (or more) foliation marks on a single page, encode two (or more) `<fw>` elements one after the other, in an order that seems most logical

- for practical purposes the `<fw>` element is a structural container, therefore do not wrap the contents of this element in `<ab>` (or any other container)

- moreover, since foliation marks are not an integral part of the text, **do not mark up line beginnings** within forme work<fnref n="11" />

- numbers used in foliation/pagination must be marked up as usual (§4.2.2, §7.1)

<figure><img src="image_11.png" /><figcaption>Example 3.3.5.A: foliation in the right margin</figcaption></figure>

In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort.

1

## 3.4. Boxlike Partitions: Self-contained Zones

### 3.4.1. Overview

- **if your text stops** at the end of a zone and something else begins in the next (as in the abstract scheme on the right), you have a **boxlike partition**

- here, there is a semantic discontinuity between the two zones, and there is no unit of intrinsic structure commencing in one and ending in another

- such spatial partitions of an inscribed text are called boxlike here, because each partition is a functional box enclosing a discrete segment of text

- since the hierarchy of such partitions does not overlap with the hierarchy of the text's internal structure, they can be encoded in XML as containing elements called textpart divisions

- in our practice, the encoding for boxlike partitions shall only be used in warranted cases, specifically:

- **copperplate sets with an inscribed seal** (regardless of whether the seal is soldered to a plate, attached with a ring to a set of plates, or currently detached)

- see Case study 2A in Appendix C for an illustration

- **non-contiguous fragments**, where the physical structure of the lost intervening fragments cannot be reconstructed, especially when even the order in which the fragments must be read is doubtful

- see Example 3.4.5.A for an illustration

- keep in mind that fragments for which it is possible to reconstruct the structure of the lost connecting section do not require encoding as textparts, nor do copperplate sets with a known number of medial plates lost

- see §5.4.7 for advice on encoding massive lacunae where the structure can be restored

- inscriptions consisting of **visually distinct parts that convey the same message in two (or more) languages**, if it is deemed necessary to encode these as a single inscription

- keep in mind that this does not apply to all bilingual (or multilingual) inscriptions: if different parts of a single text are written in different languages, then the use of textparts is not warranted

- see §7.2.1 about multilingual inscriptions

<figure><img src="image_12.png" /></figure>

<footnote n="11">¹¹ Should you come across a multi-line foliation mark, contact the authors and the XML-TEI Data Manager with the details to devise a solution.</footnote>
- beyond the specific cases set out above, boxlike partitions are only warranted when there is no obvious order in which the zones of text ought to be read, but there is nevertheless good reason for treating them as a single document

- in any other case where you think boxlike partitions may be relevant, consider carefully whether this encoding method is essential, or alternatives could be used

- if the connection between the texts is weak, preferably encode separate inscriptions (in separate XML documents), especially if there is reason to believe they were created on separate occasions

- if the connection between the texts is strong, encode a pagelike partition (§3.5) between them, especially if it makes sense to read them in a particular sequence

### 3.4.2. Encoding boxlike partitions

- each boxlike partition must be wrapped in the element `<div type="textpart">`

- note the mandatory presence and value of `@type`

- see §3.4.3 below about additional attributes and optional headers

- note that the markup represents only the fact that such text partitions exist, but contains no encoded information about their relative positions and sizes

- such information shall be described for human readers in the metadata of your inscription

- if your `<div type="edition">` includes a `<div type="textpart">`, then **all text** within the edition must be contained within textpart divisions

- the technical expression for this is that the textpart divisions must *tessellate*, i.e. cover the entire surface of the text with no gaps (and, of course, no overlaps)

- the practical purport is that if you create one textpart division for a section of an inscription, then you must also create another textpart division to wrap the remainder of the text

- note that in principle, textpart div elements *could* be nested within other textpart div elements; however, to avoid complications (in markup and referencing), our project policy is never to do so

- when encoding a structurally complex inscription, instead of resorting to textparts within textparts, try to make use of visually offset intrinsic units (§3.3) and pagelike partitions (§3.5)

- if you encounter a case where nested textpart divisions seem to be the best solution, please discuss it with the authors of the Guide and the XML-TEI data manager

- encode textparts in the order you deem to be the logical reading order

- for the sake of consistency throughout the corpus, inscribed **seals** of copper plates shall always be encoded **before the plates** themselves

- within each textpart division, use structural and other markup as you would elsewhere; this includes in particular

- wrapping all text in block-level containers to represent intrinsic structure (§2)

- marking up line beginnings (§3.2) even if a given partition consists of just one line

- numbering all line beginnings (§3.2.2) and any stanzas (§2.3.3) even if a given partition contains only one

### 3.4.3. Textpart identification: subtype, number and headers

- every textpart division must carry the **mandatory attribute** `@n`

- each textpart in an XML document must have a unique number

- uppercase Latin letters are generally recommended for numeration, but any scheme may be used depending on your preference and the conventions of your specific field

- in addition to numbering, the **optional attribute** `@subtype` may be used to encode the nature of textparts

- the use of this attribute is not mandatory, but it is strongly recommended when multiple textparts are of the same nature

- use any single word for the value of `@subtype`

- we recommend using values that describe the general nature of a unit rather than its function or appearance; preferably, use one of the following:

- "fragment" for fragments bearing non-contiguous text
- "face" for the surfaces of an object with no more than 4 sides

- "facet" for the surfaces of an object with a polygonal cross-section

- "faces" and "facets" in texts where each line of a text part continues across two or more surfaces such as the frontal and lateral face of a four-sided stele

- "zone" for visually distinct zones on a single two-dimensional surface

- "column" for zones placed side by side and generally taller than they are wide (as in newspaper columns)

- "item" for physically distinct objects such as architectural elements, e.g. when an inscription is engraved on two pillars

- if you are certain none of the above are satisfactory, you may use other values with the following constraints:

- the value should be in lowercase throughout to avoid inconsistencies; display can easily be rendered with a capital initial

- the value should not include spaces; if you absolutely need a multi-word value, use an underscore (_) instead of a space, which can be rendered as a space in display

- having introduced a custom value, try to use it consistently and send the value and a short definition/description of the case where you have used it to the authors of this Guide, so it can be included in later versions

- the above two attributes will be used in the generation of a title when your digital edition is displayed (see Example 3.4.3.A below), and @n may also be utilised for internal references that can be processed by a computer

- to add further flexibility to the titles displayed for text parts, you may also add the **optional element** <head xml:lang="eng"> immediately after the start tag of a text part division

- such elements in our editions will by default be regarded as editorial and therefore need not be marked up explicitly as such; the mandatory language attribute makes it sufficiently clear that their content is not part of the original text

- the use of this element is recommended when the text parts of an inscription are different in nature, so they cannot be conveniently described by a combination of subtype and number: in this case omit @subtype and add a <head>

- you are free to create headers as you deem best for the inscription you are editing, but for the sake of consistency it is generally recommended that you stick to concise headers in English, such as

- "Seal" and "Plates" for a copperplate charter with an inscribed seal

- "Head", "Halo", "Back" and "Pedestal" (etc.) on a statue

- the content of editorial headers will replace the title auto-generated from @n (and @subtype, if present) in display (see Example 3.4.3.B to Example 3.4.3.D below)

- however, the use of the attribute @n on the <div> element remains mandatory even if a <head> is present, and @subtype remains recommended when multiple text parts are of the same nature

- the contents of the editorial heading will not be altered in display, so

- please use a capital initial and feel free to include spaces, additional capitals and punctuation as necessary

- however, to avoid complications, do not use any further markup within this element, except the element <foreign> (§10.3.3), which you may employ if you deem necessary

<caption>**Example 3.4.3.A: text part identification, two or more fragments with non-contiguous text**</caption>

```html
<div type="textpart" subtype="fragment" n="A">
...
<div type="textpart" subtype="fragment" n="B">
...
```

<figure><img src="image_13.png" /></figure>

auto-generated headings will show "Fragment A", "Fragment B", etc.
### Example 3.4.3.B: textpart identification, two or more fragments with non-contiguous text

```html
<div type="textpart" subtype="fragment" n="1"><head xml:lang="eng">Upper left corner</head>
```

```html
...
<div type="textpart" subtype="fragment" n="2"><head xml:lang="eng">A small piece not adjacent to
any edge</head>
```

* explicitly encoded headings will show "Upper left corner", "A small piece not adjacent to any edge", etc.

### Example 3.4.3.C: textpart identification, faces of a quadrangular stele

```html
<div type="textpart" subtype="face" n="A"><head xml:lang="eng">Frontal Face</head>
```

```html
...
<div type="textpart" subtype="face" n="b"><head xml:lang="eng">Lateral Face</head>
```

* explicitly encoded headings will show "Frontal Face", "Lateral Face", etc.
* see Case Study 1 (A and B) in Appendix C for a similar stele where each line runs across two adjacent faces

### Example 3.4.3.D: textpart identification, set of copper plates with two inscribed seals

```html
<div type="textpart" n="A"><head xml:lang="eng">First seal</head>
```

```html
...
<div type="textpart" n="B"><head xml:lang="eng">Second seal</head>
```

```html
...
<div type="textpart" n="C"><head xml:lang="eng">Plates</head>
```

* explicitly encoded headings will show "First seal", "Second seal" and "Plates"
* see Case study 2A in Appendix C for the full markup of a set of plates with one seal

### 3.4.4. Numbered elements in textparts

- when your document is divided into textparts, you must mandatorily restart the numbering of all of the following elements in each new textpart, since there is as a rule no straightforward sequence of progression from one textpart to another

- physical lines

- stanzas

- pages<fnref n="12" />

- however, do not restart the numbering of the following elements: should they occur in more than one textpart, keep their numbers unique throughout your XML document

- pagelike milestones (§3.5.3)

- gridlike milestones (§3.6)

<footnote n="12">¹² Pages may occur in more than one textpart in copperplate sets divided into textparts because of an unknown number of lost medial plates (§5.4.8). Another theoretically possible scenario might be two sets of copper plates bound with a single ring and edited as a single text.</footnote>
### 3.4.5. Full markup example for boxlike partitions

<figure><img src="image_14.png" /><figcaption>Example 3.4.5.A: textparts for non-contiguous fragments</figcaption></figure>

* here we have two fragments of a slab, which are clearly from the top and bottom of a single inscription, but there is no way to know how much text is lost between the two

* therefore the fragments must be encoded as boxlike partitions, with the lost text handled as per §5.4.7

```html
class="fragment">
  <div type="textpart" subtype="fragment" n="A">
    <p part="I"> <!-- Paragraph interrupted by the Lacuna marked up as an initial part. -->
      <lb n="1"/>In a hole in the ground there lived a hobbit. Not a
      <lb n="2"/>nasty, dirty, wet hole, filled with the ends of worms
      <lb n="3"/>and an oozy smell, nor yet a dry, bare, sandy <unclear>hole</unclear>
      <lb n="4"/>with nothing in it to <supplied
        reason="lost" s</supplied>
        <unclear>i</unclear>
        <supplied reason="lost">t</supplied>
      </lb>
      down on or to eat: it <unclear>w</unclear>
      <supplied reason="lost" as a</supplied>
      <lb n="5"/>hobbit-hol
      <supplied reason="lost">e</supplied>
      <gap reason="lost" quantity="18"
        unit="character" precision="low"/>
      <unclear>f</unclear>
      <unclear>o</unclear>
      <gap reason="lost" quantity="12"
        unit="character" precision="low"/>
      </p>
    </div>
  </class>

  <!-- Lost Lines are not encoded in either fragment, because the presence of textparts implies them
       §5.4.7. -->
  <div type="textpart" subtype="fragment" n="B">
    <!-- Line numbering is reset to 1 in the second textpart §3.4.4. -->
    <p part="F"> <!-- Paragraph interrupted by the Lacuna marked up as a final part. -->
      <lb n="1"/> <gap reason="lost" quantity="12" unit="character"
        precision="low"/><unclear>w</unclear>as a very well-to-do hobbit, and his
      <lb n="2"/><gap reason="lost" quantity="5" unit="character"
        precision="low"/><unclear>w</unclear>as Baggins. The Bagginses had lived in the
      <lb n="3"/><unclear>ne</unclear>ighbourhood of The Hill for time out of mind, and
      <lb n="4"/>people considered them very respectable
      </p>
    </div>
```

## 3.5. Pagelike Partitions: Text Flows through Successive Zones

### 3.5.1. Overview

- if your text flows on from one zone to the next (as in the abstract scheme on the right), you have a pagelike partition

- here the text, having filled one zone completely (normally from top to bottom), continues seamlessly at the beginning (normally the top) of the next zone, so that the spatial zones do not correspond to units of the text's intrinsic structure

<figure><img src="image_15.png" /></figure>
- a single virtual text field is thus created from a string of successive zones which may appear in any spatial arrangement

- spatial partitions which are disregarded by the intrinsic structure of the text are called pagelike here, since they functionally behave like the pages of a book containing a single continuous text

- in pagelike partitions, units pertaining to the intrinsic structure of a text (such as verse stanzas and prose paragraphs) may begin in one zone and end in the next

- this, however, is not a criterion: a pagelike partition may also be coterminous with units of intrinsic structure

- to avoid the problem of overlapping hierarchies (§1.3.3), such partitions are handled in a manner similar to physical lines (§3.2): instead of wrapping each zone in tags, empty elements are employed to mark the spot where each zone begins

- these elements may be page beginnings or pagelike milestones as explained in the following subsections

- epigraphic examples of pagelike partitions include

- text laid out in consecutively readable zones laid out in any arrangement on a single surface

- text laid out in consecutively readable zones on multiple faces of a three-dimensional object (e.g. stele or pillar)

- text laid out in consecutively readable zones on multiple linked objects (e.g. copperplate sets; two jambs of a doorway)

### 3.5.2. Genuine pages

- to encode **genuine pages**, as in copper plates (and manuscript folios), use the empty element `<pb/>`

- this element signifies a page beginning (and not a page break, though the two are in many cases synonymous)

- as with line beginnings, `<pb/>` elements must be used to mark the beginning of every page including the first

- **every copperplate page**<fnref n="13" /> in your edition **must have a number** encoded in the `@n` attribute of the corresponding `<pb/>` element

- the **recommended values** are 1r, 1v, 2r, 2v etc., referring to the recto (front) and verso (back) face of plates identified with Arabic numerals, e.g. `<pb n="1r"/>`

- should pages occur in more than one textpart of a complex inscription, page numbers must be reset in each textpart

- page numbers will be utilised for display and may in the future be utilised for machine-readable referencing

- if you have a good reason to do so, you may opt to use a different numbering scheme for pages with the following constraints:

- the value of `@n` must not contain a space (use an underscore `_` instead if a space is essential)

- each page must have a unique number within your edition (or, if applicable, within a textpart division)

- see §3.3.5 about encoding any original pagination or foliation

- plates must always be treated as having two pages per folio, even if one of these pages is blank; this will facilitate the eventual linking of images (including images of blank faces) to individual pages of the digital edition

- blank faces shall be encoded as the corresponding `<pb/>` element<fnref n="14" />

<footnote n="13">¹³ In this section and elsewhere when discussing copper plates, “plate” is used in reference to one discrete physical item; “face” for one side of a plate as a physical surface; “page” as a unit of text that is inscribed on one face of a plate; and “folio” as an abstract unit of text comprised of two pages that belong to a single plate. Of these terms, only “page” has an exact markup equivalent.</footnote>

<footnote n="14">¹⁴ For a single copper plate inscribed on one face only, designate the inscribed face as the recto, and the blank face as the verso. For sets of copper plates where the first and/or last plate is only inscribed on one face, designate the blank faces to be the outer faces of the set, i.e. the recto of the first plate and the verso of the last plate.</footnote>
- the `<pb/>` elements for first/last blank pages should be placed just inside the start/end tag of the enclosing division (i.e. the edition division or a textpart division)

- thus, these `<pb/>` elements will be outside block-level containers in spite of the general rule (§8.2.3) that such empty elements must be inside block-level containers

- see Case study 2 (A, B and C) in Appendix C for an illustration of pages in an EpiDoc document

### 3.5.3. Other pagelike zones

- to encode physically separate **inscribed zones where text flows on** from the bottom of one to the top of the next, use the empty element `<milestone type="pagelike"/>`

- a "milestone" is a generic element of which `<lb/>` and `<pb/>` (and a few others permitted by TEI but not used in our project) are special cases

- the specialised milestones `<lb/>` and `<pb/>` implicitly specify the nature of the transition (viz. line and page) they represent

- the generic `<milestone/>`, on the other hand, must carry the attribute `@unit` to encode the nature of the transition explicitly; see §3.5.4 below for values recommended in pagelike partitions

- the mandatory attribute `@type` with the value `"pagelike"` serves in our corpus to explicitly distinguish these elements from other milestones used in an edition (§3.6)

- zones may be arranged in any pattern on a single surface, or on several faces of a three-dimensional object

- as with line beginnings, milestones must be used to mark the beginning of every zone including the first

- see Example 3.5.7.A for a full illustration of columnlike zones in an EpiDoc document, and Case study 1 (A and B) in Appendix C for a more complex scenario

### 3.5.4. Zone identification: unit, number and label

- every zone encoded with a `<milestone/>` element must **mandatorily** carry the **attributes** `@n` and `@unit`

- both of these attributes will be used to generate a title for partitions when your digital edition is displayed (see Example 3.5.4.A below), and may also be utilised for internal references that can be processed by a computer

- this title will probably be displayed as a heading in diplomatic editions, but as an inline label (so as not to break the flow of text) in logical editions

- the `@unit` of a milestone encoding a pagelike partition shall be a single word describing the nature of the transition in the same way as the `@subtype` of textpart divisions (§3.5.4)

- we recommend using values that describe the general nature of a unit rather than its function or appearance; preferably, use one of the following:

- "face" for the surfaces of an object with no more than 4 sides

- "facet" for the surfaces of an object with a polygonal cross-section

- "faces" and "facets" in texts where each line of a pagelike zone runs across two or more surfaces such as the frontal and lateral face of a four-sided stele

- gridlike partitions (§3.6) may be optionally used to encode the boundary of each face constituting a pagelike zone of this kind

- "zone" for visually distinct zones on a single two-dimensional surface

- "column" for zones placed side by side and generally taller than they are wide (as in newspaper columns)

- "item" for physically distinct objects such as architectural elements, e.g. when an inscription is engraved on two pillars or doorjams

- if you are certain none of the above are satisfactory, you may use other values with the following constraints:

- the value should be in lowercase throughout to avoid inconsistencies; display can easily be rendered with a capital initial

- the value should not include spaces; if you absolutely need a multi-word value, use an underscore (_) instead of a space, which can be rendered as a space in display
- having introduced a custom value, try to use it consistently and send us the value and a short definition/description of the case where you have used it, so it can be included in later versions of this guide

- every pagelike milestone element in an edition must have a unique identifier encoded in its **attribute @n**

- uppercase Latin letters are generally recommended for identification, but any scheme may be used depending on your preference and the conventions of your specific field

- in particular, feel free to use

- the uppercase letters N, S, E, W to indicate cardinal directions

- lowercase letters alternating with uppercase ones to denote major/frontal and minor/lateral faces of a three-dimensional object such as a Southeast Asian stele, e.g. A, b, C and d (for faces inscribed as separate zones); or Ab and Cd (where pairs of faces constitute single virtual zones)

- in addition to the generation of titles, this attribute will be utilised for internal references that can be processed by a computer

- should you need to encode pagelike milestones with two or more different units (e.g. columns and faces) within a single document, use a different numeration scheme for the two in order to keep their @n attributes unique

- to add further flexibility to the titles displayed for zones, you may also add the **optional element <label xml:lang="eng">** immediately after the <milestone/> element

- such elements in our editions will by default be regarded as editorial and therefore need not be marked up explicitly as such; the mandatory language attribute makes it sufficiently clear that their content is not part of the original text

- only add labels to zones if you find that the combination of @unit and @n cannot produce a sufficiently meaningful title; complex details such as the size and relative position of zones should be described in the metadata, not encoded within the edition

- for the sake of consistency it is recommended that you stick to concise labels in English

- the content of editorial labels will replace the title auto-generated from @unit and @n in display (see Example 3.5.4.B below)

- however, the use of the attributes @unit and @n on the <milestone/> element remains mandatory even if a <label> is present

- the contents of the label will not be altered in display, so

- please use a capital initial and feel free to include spaces, additional capitals and punctuation as necessary

- however, to avoid complications, do not use any further markup within this element, except the element <foreign> (§10.3.3), which you may employ if you deem necessary

**Example 3.5.4.A: zone identification, two faces of an object**

```xml
<milestone type="pagelike" unit="face" n="A"/>
...
<milestone type="pagelike" unit="face" n="B"/>
...
```

➤ auto-generated headings will show "Face A", "Face B", etc.

**Example 3.5.4.B: zone identification, two doorjams**

```xml
<milestone type="pagelike" unit="item" n="N"/><label xml:lang="eng">Northern Doorjamb</label>
...
<milestone type="pagelike" unit="item" n="S"/><label xml:lang="eng">Southern Doorjamb</label>
...
```

➤ explicitly encoded headings will show "Northern Doorjamb", "Southern Doorjamb", etc.

### 3.5.5. Placement of page and zone beginnings

- keep in mind that the elements <pb/> and <milestone/> do not replace line beginnings, which must always be encoded as per §3.2, immediately after the page or column beginning
- except that in rare cases it is possible for a page or zone beginning not to be followed by a line beginning (e.g. when a medial plate of a set is lost, but the page structure is reconstructed for it)

- the elements `<pb/>` and `<milestone/>` must always be on the same level as the text (see also §8.2.3), i.e. *inside* rather than outside block-level elements representing intrinsic structure; thus,

- the first such element must be encoded after all required block-level elements have been opened

- e.g. `<lg n="1" met="anușțubh"><l n="a"><pb n="1r"/><lb n="1"/>Āsīt...`

- if the end of a block-level element coincides with the end of a pagelike partition, the next line beginning element must come at the beginning of the next structural unit, not between the two

- e.g. ...śāntiM</l></lg><lg n="2" met="upajāti"><l n="a"><pb n="1v"/><lb n="2"/>guptānvaya...

- the only exception to this rule is the case of lost medial plates (§5.4.8), where reconstructed page beginnings may be encoded outside block-level containers

- never add a space in your XML document after a page or zone break; see §8.1.2 for further details

- adding a space or starting a new line before such a break is permitted (but not required), provided that it coincides with a word break

- when a new page or zone begins inside a word, this must be explicitly encoded in the `<pb/>` or `<milestone/>` element in the same way as (and in addition to) the `<lb/>` element marking the start of the first line of the new unit, i.e. using the attribute `@break` with the value `"no"`

- e.g. `tomara<pb n="2" break="no"/><lb break="no" n="18"/>bhindipālanārāca`

- your XML file must never contain a space or a new line before a pagelike partition that interrupts a word

- see §3.2.4 for further details of what qualifies as an interrupted word

- if you use editorial hyphens for the segmentation of compounds (see TG §2.6.2), you must remember to put the editorial hyphen at the start of the new line in the new page/column/zone

- e.g. `tomara<pb n="2" break="no"/><lb break="no" n="18"/>-bhindipāla-nārāca`

### 3.5.6. Numbered elements in pagelike partitions

- as set out under §3.2.2, **physical line** numbering may be either

- consecutive throughout successive pagelike partitions, or

- restarted in each pagelike partition, provided that complex line numbers are used, which incorporate the number of the page or zone

- stanzas should be generally numbered throughout a text with pagelike partitions, but, as permitted under §2.3.3, you may optionally reset stanza numbering in each new partition in order to follow the numbering scheme of a previous edition or the conventions of your specific field
<figure><img src="image_16.png" /><figcaption>Example 3.5.7.A: text in two columns</figcaption></figure>

```html
<p>
  <milestone type="pagelike" unit="column" n="A"/>
  <lb n="1"/>In a hole in the ground
  <lb n="2"/>there lived a hobbit. Not a
  <lb n="3"/>nasty, dirty, wet hole, filled
  <lb n="4"/>with the ends of worms
  <lb n="5"/>and an oozy smell, nor yet
  <lb n="6"/>a dry, bare, sandy hole
  <lb n="7"/>with nothing in it to sit
  <lb n="8"/>down on or to eat: it was a
  <lb n="9"/>hobbit-hole, and that
  <milestone type="pagelike" unit="column" n="B"/><!-- Line numbers continue in the second column. Alternatively, the lines numbered 1 to 9 here could be A1 to A9, and those numbered 10 to 18 here could be B1 to B9. See §3.2.2 and §3.5.6 for guidance, and Case study 1 in Appendix C for an illustration of such numbering. -->
  <lb n="10"/>means comfort. It had a
  <lb n="11"/>perfectly round door like a
  <lb n="12"/>porthole, painted green,
  <lb n="13"/>with a shiny yellow brass
  <lb n="14"/>knob in the exact middle.
  <lb n="15"/>The door opened on to a
  <lb n="16"/>tube-shaped hall like a
  <lb n="17"/>tunnel: a very comfortable
  <lb n="18"/>tunnel without smoke.
</p>
```

* in the illustration above, the partition occurs within a sentence, and it is therefore technically impossible to encode it as a boxlike partition (§3.4)

* a partition may, however, coincide with a semantic boundary as in the slightly altered illustration here

* while it is technically possible to encode a boxlike partition in this latter case, our practice shall be always to encode pagelike partitions except in the cases explicitly set out under §3.4.1 above

* therefore, the illustration on the right must also be encoded as a pagelike partition

In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort.

It had a perfectly round door like a porthole, painted green, with a shiny yellow brass knob in the exact middle. The door opened on to a tube-shaped hall like a tunnel: a very comfortable tunnel without smoke.
## 3.6. Gridlike Partitions: Text Runs Across Contiguous Zones

### 3.6.1. Overview

- **if your text runs across zone boundaries** (as in the abstract scheme on the right), you have a **gridlike partition**

- here each line of text, having reached the edge (normally the right margin) of a zone, continues at the edge (normally the left margin) of the next zone; the next line in turn begins in the first zone

- a single virtual text field is here created from a patchwork of zones which share a vertical boundary

- spatial partitions that cut across the lines of an inscription are called gridlike here because the spatial structure behaves like a grid projected onto the inscription's own layout

- as with pagelike partitions, units pertaining to the intrinsic structure of a text (such as verse stanzas and prose paragraphs) may begin in one zone and end in another

- to avoid overlapping hierarchies (§1.3.3), such partitions are also encoded with the aid of empty elements employed to mark the spot where each patch begins

- but unlike the case of pagelike partitions, the empty elements employed for this purpose must be reiterated within each affected epigraphic line

- epigraphic examples of gridlike partitions include text engraved on

- a simplex (flat or curved) surface vertically segmented into units where each line runs across two or more such quasi-columns (which often correspond to metrical units such as verse lines), as illustrated in Example 3.6.6.A

- a complex surface (such as that constituted of several facets of a polygonal pillar) with each line running across two or more subsurfaces

- a composite surface (such as several architectural blocks) with each line running across several blocks, as illustrated in Example 3.6.6.B

- a broken support where a fracture cuts across some or all lines, as illustrated in Example 3.6.6.C

<figure><img src="image_17.png" /></figure>

### 3.6.2. Encoding gridlike partitions

- gridlike partitions may be encoded with the element `<milestone/>` introduced under §3.5 above, but with the following differences

- gridlike milestones shall not carry the attribute `@type`

- the `<label>` element is not permitted in conjunction with these milestones

- such milestones will typically be iterated many times in a single document, whereas a milestone representing a particular pagelike transition point will always appear only once

### 3.6.3. Gridlike milestone identification: unit and number

- as in pagelike partitions, every gridlike area encoded with a `<milestone/>` element must **mandatorily** carry the **attributes** `@n` and `@unit`

- both of these attributes will be used in the generation of a title when your digital edition is displayed, which will always be shown as an inline label so as not to break the flow of the text

- the `@unit` of a milestone encoding a gridlike partition shall be a single word describing the nature of the transition in a way similar to that of pagelike partitions (§3.5)

- we recommend using values that describe the general nature of a unit rather than its function or appearance; preferably, use one of the following:

- "fragment" for objects with two or more extant inscribed fragments

- "block" for inscriptions on physically separate architectural blocks

- "face" for the sides of an object with no more than 4 sides

- "facet" for the sides of an object with a polygonal cross-section

- "area" for patches of text demarcated by some physical feature
- "column" for zones placed side by side and generally taller than they are wide (as in newspaper columns)

- if you are certain none of the above are satisfactory, you may use other values with the following constraints:

- the value should be in lowercase throughout to avoid inconsistencies; display can easily be rendered with a capital initial

- the value should not include spaces; if you absolutely need a multi-word value, use an underscore (_) instead of a space, which can be rendered as a space in display

- having introduced a custom value, try to use it consistently and send us the value and a short definition/description of the case where you have used it, so it can be included in later versions of this guide

- every gridlike milestone element in an edition must have a number encoded in its **attribute @n**

- the number referring to every zone of text should be unique, but, as noted above, gridlike milestones with a given combination of @unit and @n will normally be iterated several times in a document, namely once in every line that touches the zone to which that combination pertains

- lowercase Latin letters are generally recommended for numeration, but any scheme may be used depending on your preference and the conventions of your specific field

- in particular, feel free to use lowercase letters alternating with uppercase ones to denote major/frontal and minor/lateral faces of a three-dimensional object such as a Southeast Asian stele, e.g. A, b, C and d

- in addition to the generation of titles, this attribute may be utilised for internal references that can be processed by a computer

- should you need to encode gridlike milestones with two or more different units within a single document (e.g. "column" alternating with "fragment" to encode an inscription on whose original gridlike layout a secondary gridlike layout was superimposed by fragmentation), use a different numeration scheme for the two in order to keep the @n attributes of each patch of text unique

### 3.6.4. Gridlike partitions interrupting words

- just as line, page and zone beginnings, gridlike milestones must take the attribute @break="no" if the transition interrupts a word

- this applies even if the milestone is right next to another interruption (such as a line beginning) that already has @break="no"

- if you use editorial hyphens for the segmentation of compounds (see TG §2.6.2), the editorial hyphen shall be placed after the milestone, at the beginning of the text that follows it

- your XML file must never contain a space or a new line before a milestone that interrupts a word; see §8.1.2 for more details

### 3.6.5. When to encode gridlike partitions

- encoding gridlike partitions with milestones is **not mandatory** and should be applied on a case-by-case basis, judging the feasibility of encoding versus the anticipated usefulness of having such partitions represented in the edition

- such representation is particularly useful if some elements of description apply only to certain partitions (e.g. certain fragments are kept in a different place; or certain facets of the support are in a different state of preservation)

- this encoding is **strongly recommended for composite (physically disjoined) surfaces** such as

- **fragments**, especially if they have not been reconstituted

- but only if it is possible to tell which segments of text belong to which fragments

- and only if the number of fragments involved is not inordinately large

- **building blocks**, especially if they are not currently assembled

- this encoding is **recommended for visually demarcated areas** on a simplex surface, such as

- quasi-columns consisting of a metrical unit (e.g. verse line)

- this encoding is **recommended only if deemed useful for complex surfaces** such as
- two or more adjacent faces of a stele or pillar with a rectangular or polygonal cross-section

- if you opt not to encode milestones in any of the above cases, simply encode the text as if it occupied a simple surface, and describe the layout in as much detail as you wish in your metadata

### 3.6.6. Full markup examples for gridlike partitions

<caption>Example 3.6.6.A: gridlike partitions for verse inscribed in quasi-columns</caption>

> In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort.

* for the sake of the illustration assume that the sample text is verse, with one stanza (of two lines) occupying one epigraphic line

* attributes for `<lg>` and `<l>` are omitted in this illustration to reduce clutter

```html
<lg>
  <lb n="1"/><milestone unit="zone" n="a"/><In a hole in the ground</lb>
  <lb n="b"/><there lived a hobbit. Not a</lb>
</lg>

<lg>
  <lb n="2"/><milestone unit="zone" n="a"/><nasty, dirty, wet hole, filled</lb>
  <lb n="b"/><with the ends of worms</lb>
</lg>

<lg>
  <lb n="3"/><milestone unit="zone" n="a"/><and an oozy smell, nor yet</lb>
  <lb n="b"/><a dry, bare, sandy hole</lb>
</lg>

<lg>
  <lb n="4"/><milestone unit="zone" n="a"/><with nothing in it to sit</lb>
  <lb n="b"/><down on or to eat: it was a</lb>
</lg>

<lg>
  <lb n="5"/><milestone unit="zone" n="a"/><hobbit-hole, and that</lb>
  <lb n="b"/><means comfort.</lb>
</lg>
```
<figure><img src="image_18.png" /><figcaption>Example 3.6.6.B: gridlike partitions for text inscribed across architectural blocks</figcaption></figure>

<p>
  <lb n="1"/><milestone unit="block" n="a"/>In a hole in the <milestone unit="block" n="b"/> ground there lived <milestone unit="block" n="c"/> a hobbit. Not a <lb n="2"/><milestone unit="block" n="a"/>nasty, dirty, wet <milestone unit="block" n="b"/> hole, filled with the <milestone unit="block" n="c"/> ends of worms <lb n="3"/><milestone unit="block" n="a"/>and an oozy sm <milestone unit="block" n="b" break="no"/>ell, nor yet a dry, b <milestone unit="block" n="c" break="no"/>are, sandy hole <!--Notice the use of @break="no" for two milestones in Line 3. --> <lb n="4"/><milestone unit="block" n="a"/>with nothing in <milestone unit="block" n="b"/> it to sit down on or <milestone unit="block" n="c"/> to eat: it was a <lb n="5"/><milestone unit="block" n="a"/>hobbit-hole, and <milestone unit="block" n="b"/> that means comfort.
</p>
<figure><img src="image_19.png" /><figcaption>Example 3.6.6.C: gridlike partitions for contiguous fragments</figcaption></figure>

* here, two extant fragments of a slab can be joined because they share some lines, though a smaller missing fragment gives rise to gaps in other lines

* the fragments are optionally encoded as gridlike milestones

* the lacunae in the first five lines are arbitrarily allocated to one of the encoded fragments (fragment a, in the code below)

* but restorations of partially lost words are always allocated to the fragment bearing their extant segments (thus, to fragment b in lines 1 and 2)

```p
<p>
  <lb n="1"/><milestone unit="fragment" n="a"/><In a hole in
    <gap reason="lost" quantity="17" unit="character" precision="low"/><milestone unit="fragment" n="b"/><supplied
    reason="lost" li/><supplied>ved a hobbit. Not a
  </gap>
  <lb n="2"/><milestone unit="fragment" n="a"/><nasty, dirty, we
    <gap reason="lost" quantity="14" unit="character" precision="low"/><milestone unit="fragment" n="b"/><supplied
    reason="lost" w/><supplied><unclear>i</unclear>th the ends of worms
  </gap>
  <lb n="3"/><milestone unit="fragment" n="a"/><and an oozy sme
    <gap reason="lost" quantity="10" unit="character" precision="low"/><milestone unit="fragment"
    n="b"/><a dry, bare, sandy hole
  </gap>
  <lb n="4"/><milestone unit="fragment" n="a"/><with nothing in it
    <gap reason="lost" quantity="6" unit="character" precision="low"/><milestone unit="fragment"
    n="b"/><down on or to eat: it was a
  </gap>
  <lb n="5"/><milestone unit="fragment" n="a"/><hobbit-hole, and th
    <gap reason="lost" quantity="6" unit="character" precision="low"/><milestone unit="fragment"
    cert="low" at/><supplied> <milestone unit="fragment" n="b"/>means comfort. It had a
  </gap>
  <lb n="6"/><milestone unit="fragment" n="a"/><perfectly round
    <gap reason="lost" d/><supplied> <milestone unit="fragment" n="b"/><supplied>oor like a porthole, painted green,
  </gap>
  <lb n="7"/><milestone unit="fragment" n="a"/><with a shiny <milestone
    <gap reason="lost" d/><supplied> <milestone unit="fragment" n="b"/><yellow brass knob in the exact middle.
  </gap>
  <lb n="8"/><milestone unit="fragment" n="a"/><The doo
    <gap reason="lost" cert="low">:/><supplied> <milestone unit="fragment" n="b"/><a very comfortable tunnel without smoke.
  </gap>
</p>
```
# 4. Encoding the Originally Inscribed Text

## 4.1. Alphabetic Characters

- alphabetic characters do not, as a rule, need markup on their own

- they, including several special character forms, are handled through transliteration alone; see TG §3

### 4.1.1. Tagging transliterated characters as one akṣara

- in certain cases you may need to identify strings of transliterated text as belonging to a single akṣara of the original, in order to eliminate ambiguity

- the transliteration shorthand involving the = (equals) sign, described in TG §3.3.5 and §3.3.8, is recommended for such cases<fnref n="15" />

- should you prefer to use only XML markup, omit the = sign from your transliteration and wrap all transliterated characters that constitute a single original akṣara in the element `<seg type="aksara" >`, e.g.

- `<seg type="aksara">kka</seg>` to encode the Tamil ligature k=ka as distinct from both kka (with an implicit vowel killer) and k·ka (with an explicit vowel killer)

<table><caption>Example 4.1.1.A: character with two vowel marks tagged as a single akṣara</caption><tr><td>&lt;seg type="aksara"&gt;duā&lt;/seg&gt;</td><td><img src="image_0_0.png" alt="A Tamil ligature with a double vowel mark."></td></tr><tr><td>➤ this character is probably an engraving mistake for ddhā</td><td></td></tr><tr><td>➤ the encoding corresponds to the shorthand markup du=ā</td><td></td></tr></table>

- editorial spaces and hyphens may freely appear between the characters thus enclosed, wherever necessary

- thus, if a word or compound boundary occurs within such an akṣara, encode respectively:

- `<seg type="aksara">k ka</seg>` instead of k=ka

- `<seg type="aksara">k-ka</seg>` instead of k=-ka

### 4.1.2. Tagging parts of alphabetic characters

- when you need to single out transliterated characters as representing specific parts of an original complex character, you can optionally use the following markup method

- this method, which we shall call sub-akṣara markup, has been devised to facilitate the encoding of component-level lacunae (§5.4.5), and is offered as an optional encoding method for unusually arranged complex characters (§4.1.3), but we suggest that you avoid it in all other situations

- see §4.1.4 about handling character components separated from others by an intervening physical feature, a situation for which sub-akṣara markup is not applicable

- see §5.3.4 about handling reading difficulties concerning character components, a situation for which sub-akṣara markup is not normally warranted

- if you choose to tag a specific sub-akṣara component, wrap it in `<seg type="component" >` and add a `@subtype` attribute with one of the following values:

- `"body"` for the principal component of a complex character, which may be a single consonant or a conjunct

- `"superscript"` for any components above the body, such as a superscript r or a superscript vowel marker

- `"subscript"` for any components below the body, such as the subscript consonant of a conjunct or a subscript vowel marker

<footnote n="15">¹⁵ The markup alternative described here is not expressly limited to the cases discussed in the TG, but is redundant in normal circumstances. If you encounter any other situations where you think its use is warranted, feel free to employ it, but please inform the authors of this Guide and the XML-TEI Data Manager about the details.</footnote>
- "prescript" for any components to the left of the body, generally a vowel marker but also applicable to part of a horizontally composed ligature

- "postscript" for any components to the right of the body, generally a vowel marker but also applicable to part of a horizontally composed ligature

- "consonant" for exactly one consonant component whose graphic location cannot be determined or is irrelevant

- "conjunct" for two or more consonant components belonging to a single *akṣara*, when their locations cannot be determined or is irrelevant

- "vowel" for the vocalisation of an *akṣara*, when the location of the vowel marker cannot be determined or is irrelevant

### 4.1.3. Unusual spatial arrangement in conjuncts

- as our primary objective is to encode texts, the place to record information about unusual character composition is in the commentary to your edition

- however, in order to facilitate future palaeographic research, you may optionally use the above markup for tagging parts of alphabetic characters to specify what part of a complex original character corresponds to any given transliterated character

- when doing so, aim to minimise the complexity of your markup and add tags only to the components that most conspicuously deviate from the expected composition

- however, if you deem that there is any ambiguity regarding *akṣara* boundaries, feel free to wrap transliterated characters and lacunae belonging to a single original character in the element `<seg type="aksara">` as per §4.1.1

**Example 4.1.3.A: conjunct with regular *r* instead of superscript**

`<seg type="component" subtype="body">r</seg>ya`

* *rya* is here written with a regular *r* and a subscript *y* instead of a superscript *r* and a regular *y*

* the fact that the *r* is tagged as a body component dispenses with the need to explicitly tag the *y* as a subscript component

<figure><img src="image_20.png" /></figure>

**Example 4.1.3.B: conjunct composed horizontally instead of vertically**

`r<seg type="component" subtype="prescript">g</seg><seg type="component" subtype="body">gh</seg>a`

* *rggha* is here written in a horizontal composition, with *g* to the left of a regularly positioned *gh*

* in this example the second and third consonant components have both been tagged explicitly for their position, though it may arguably be sufficient to tag the prescript *g* in this way

<figure><img src="image_21.png" /></figure>

### 4.1.4. Complex characters split by an intervening feature

- prescript and postscript vowel markers split off from their consonant bodies by an intervening feature shall be handled in transliteration by means of the placeholder characters 「(left ceiling, U+2308) and 」(right ceiling, U+2309), as per TG §3.3.10

- the intervening features may be line beginnings (§3.2) or space imposed by physical features (§4.3.5) and must be encoded as applicable

- all the transliterated characters pertaining to an original *akṣara* must be placed on that side of the interruption where the consonant body is located, while the applicable placeholder character must be placed on the other side of the interruption

- the placeholder characters comprise part of the transliterated text and do not have markup equivalents (in other words, they are not shorthand notation to be replaced by markup)

- split *akṣaras* in themselves need no markup other than the above placeholder characters, but they may be further complicated by the presence of additional markup of the following kinds

- in all examples here, `<>` represents an interrupting element of any nature

- if some of the components involved are **unclear** (§5.3.1)

- apply this tag to whichever transliterated characters are affected, but not to unaffected ones
- separately apply the tag to the placeholder only if the split-off component is itself affected

- do not include the interruption itself in the markup

- for example:

– கை<sup>0</sup> டீ with grey text signifying unclear) would be encoded as k<unclear>o</unclear><><unclear>|</unclear>

– கை<sup>1</sup> டீ would be encoded as <unclear>ko</unclear><><>

– கை<sup>2</sup> டீ<sup>1</sup> would be encoded as <unclear><</unclear><><k<unclear>o</unclear>

- if the reading of some components is **ambiguous** (§5.3.3), in the interest of minimising complexity consider whether encoding the *akṣara* as unclear would be sufficient for a reader familiar with the script to deduce the possible alternatives

- if you deem that encoding an ambiguity is essential

- do so for the transliterated characters concerned

- add an unclear(!) tag to the placeholder if the split-off component is affected

- do not include the placeholder in the markup for the ambiguity, and do not include the interruption itself in any markup

- for example:

– கை<sup>3</sup> டீ where the unclear strokes after the interruption may be the character ங ra instead of the vowel marker டீ (called *kāl*) may be encoded as k<choice><unclear>o</unclear><unclear>era</unclear></choice><><unclear>|</unclear>

- note that in this case the second option of the <choice> element produces the text “kera<sup>1</sup>”, where the placeholder sign must be understood to mean that the entire preceding *akṣara* (i.e. *ra*), rather than just one component of it, is located after the interruption<fnref n="16" />

- if an adjacent **lacuna** has obliterated a split-off component which you **supply** (§5.5)

- mark up the affected vowel

- as supplied if it consists only of the supplied split-off component

- as unclear if it consists of an extant component *and* a supplied split-off component

- mark up the placeholder as supplied

- do not include the interruption itself in any markup

- for example

– கை<sup>4</sup> டீ (with grey text for the restored lacuna) would be encoded as k<unclear>o</unclear><><<supplied reason="lost">>|</supplied>

– கை<sup>5</sup> டீ would be encoded as <supplied reason="lost">>|</supplied><><k<supplied reason="lost">>e</supplied>

- if an adjacent **lacuna** may have obliterated a split-off component but you **do not supply** this even tentatively

- simply mark up the *extant* vowel component as unclear and leave it to the proficient reader to deduce the fact that an additional component may have been destroyed in the lacuna

## 4.2. Non-alphabetic Characters

### 4.2.1. Overview

- we will use the element <g> (for “glyph” or “gaiji”<fnref n="17" />) in the encoding of all characters other than alphabetic ones and decimal digits

- the use of this element indicates that no perfect equivalent to the original character is available in our transliteration system

<footnote n="16">16 We must resort to this compromise because the internal logic of EpiDoc does not permit <space> or <lb> elements inside <unclear>, so it is not possible to encode alternative readings which include an interruption, even if the location of that interruption with respect to the text is different in the alternatives.</footnote>

<footnote n="17">17 https://en.wiktionary.org/wiki/gaiji</footnote>
- the characters prescribed in our Transliteration Guide are deemed to be perfect equivalents to original alphabetic characters and decimal digits and therefore require no encoding as glyphs

- the element `<g>` shall be used in two different ways:

- as a text-containing element `<g>text</g>` to **wrap** one or more transliteration characters that convey information about the function of the glyph, namely (1) **numerals** and the dedicated characters for (2) **space fillers** and (3) **punctuation marks**

- as an empty element `<g/>` to **represent** a glyph about whose function our encoding makes no assertions, i.e. all glyphs not covered by these three specific cases, such as auspicious symbols at the beginning or end of an inscription

- in addition to serving as an indication of a character for which no exact transliteration equivalent exists, `<g>` shall always carry the attribute `@type` to encode further details of the original glyph, as discussed in the subsections below

- this twofold encoding (involving a `<g>` element in all cases and text enclosed within that element in specific cases) serves to represent the fact that a glyph of a particular shape may be used in more than one function across the corpus, a subcorpus, or even within a single inscription, so that

- glyphs that are definitely numeral characters (other than decimal digits) are transliterated into Arabic numerals wrapped in `<g type="numeral">` as described in §4.2.2

- glyphs that are definitely punctuation marks (§4.2.4) are transliterated as the abstract punctuation character . and wrapped in `<g>` with an appropriate `@type`

- glyphs that are definitely space fillers (§4.2.5) are transliterated as the dedicated transliteration character § and wrapped in `<g>` with an appropriate `@type`

- non-alphabetic glyphs that do not clearly fall into any of the above categories (§4.2.6) are not transliterated with any character, but represented by the empty element `<g/>` with an appropriate `@type`

### 4.2.2. Numeral symbols other than decimal digits

- keep in mind that all numbers originally recorded in numeral symbols (including those in decimal digits) must also be encoded for their value as described under §7.1

- the encoding introduced here pertains to specific numeral characters used in the original script, that have no exact equivalent in our transliteration system, while the encoding of value introduced in §7.1 applies to all numbers written in numeral signs and adds semantic information to our encoding scheme

- TG §4.1 and its subsections provide a shorthand notation to distinguish numeral signs transliterated in any way other than by a single Western numeral or vulgar fraction sign

- namely

- two or more Arabic digits transliterating a single glyph in the original (e.g. “10+” for the Brahmi glyph $\alpha$ meaning “10”)

- one or more iterations of a Latin uppercase I transliterating Cambodian numeral notation involving vertical bars (e.g. “III+” for a triple vertical bar meaning “3”)

- fractions other than halves, thirds and fourths (e.g. “1/8+” for an original character denoting “one eighth”)

- this shorthand notation will be automatically converted to the XML markup presented below

- however, it is recommended that you use only the XML markup when encoding a new edition in XML, as the shorthand is mainly intended to facilitate the conversion of e-texts prepared earlier into DHARMA-compliant XML encoding

- never combine the shorthand markup involving a + sign with XML markup for the same purpose

- the transliteration string corresponding to a single original numeral must be

- wrapped in the XML element `<g type="numeral">`, e.g.

- `<g type="numeral">200</g>` corresponds to the shorthand 200+

- `<g type="numeral">100</g> <g type="numeral">20</g> 3` corresponds to the shorthand 100+20+3

- note that the transliterated 3 is not wrapped in `<g>`, because it is a single Arabic digit
- `<g type="numeral">1000</g> 8 <g type="numeral">100</g> 3 <g type="numeral">10</g>` corresponds to the shorthand 1000+ 8 100+ 3 10+

- 8 and 3 are not wrapped in `<g>`, because they are single Arabic digits

- `<g type="numeral">I</g>` corresponds to the shorthand I+ (for a vertical bar denoting “1” in a Cambodian inscription)

- note that even though “I” in transliteration is a single character, the `<g>` tag is necessary in this case to mark up this character as non-alphabetic<fnref n="18" />

- `<g type="numeral">1/8</g>` corresponds to the shorthand 1/8+ (for “one eighth” written as a single original character)

### 4.2.3. Symbol tokens

- as indicated in §4.2.1 above, non-numeric symbols encoded with a `<g>` element (i.e. punctuation marks, space fillers and miscellaneous symbols, covered separately in the following subsections) must be encoded with a variety of values for `@type`

- the value of used in each case shall be a simple description of the symbol's visual appearance (or in a limited number of cases its traditional name), hereafter referred to as a *token*

- the token must contain no spaces, but it may contain any combination of letters and numbers

- at this stage of our project there is no constraint on the permitted symbol tokens

- at a later stage, we intend to harvest tokens that have been used and utilise them as a starting point for a controlled vocabulary for symbol description, involving a limited number of `@type` values and a larger number of permitted `@subtype` values for each `@type`

- however, for the sake of making that future work easier, and to facilitate the development of display solutions for symbols, it is strongly recommended that you follow certain basic constraints in naming your symbols:

- use a **simple character set** consisting only of the letters of the English alphabet and numerals, i.e. avoid symbol characters and letters with diacritic marks

- use a **hierarchical approach**, in which tokens may be

- simple, consisting of a single term that identifies a broad category of shapes (“genus”), e.g.

- "circle", "dash", "flower", etc.

- complex, beginning with a term for a species as above, and followed by one or more qualifications of a subcategory (“genus”), using camelCase (i.e. starting each subsequent word with an uppercase initial) for segmentation, e.g.

- "circleSmall", "circleCross", "circleSmallHigh", etc.

- "dashHook", "dashConcave", "dashHookHigh", etc.

- it is, however, recommended that you resist the temptation of creating highly elaborate complex tokens, since our ultimate aim is to devise a versatile but limited vocabulary for symbol classification

- keep in mind that symbols can be described in detail in the Hand Description (§11.2.1), and doing so is strongly recommended for all symbols whose shape will not be self-evident to a reader familiar with the subcorpus

- while there is no such thing as an incorrect symbol token, all of us should from this early stage onward try to **avoid excessive diversity** in the naming of symbol shapes

- for this purpose, we have created an online Supplement to the EGD on Symbol Taxonomy<fnref n="19" /> in which we have entered some of the symbols we have encountered in our work so far, with the recommended tokens for each

- all encoders are requested to refer to that list before creating a token for a symbol

- all encoders are encouraged to contribute to that document by

- inserting clippings of symbols they have encoded with a token already featured in the list

<footnote n="18">¹⁸ Notwithstanding the fact that for a so-called 'independent vowel' *i* you would normally use *qi* rather than *I* in Cambodian inscriptions (TG §3.3.4), the use of *I* for numerals without this explicit markup would create an inconsistency in the corpus as a whole.</footnote>

<footnote n="19">¹⁹ https://docs.google.com/document/d/1glfyQnFqPrbVOYzegfjKIOVrc-vMgznEQ1iNsFf7DE8/edit?usp=sharing</footnote>
- inserting new rows in the list with clippings of new symbols and the tokens they have come up with for those symbols

### 4.2.4. Punctuation marks

- as stated in TG §4.2.1, the term “punctuation mark” is used within this Guide in a sense restricted to symbols

- which are (or are derivations of) simple non-figural shapes

- and which are employed in the original for syntactic or metrical segmentation into relatively small units, similar in function to a modern comma, full stop, question mark, exclamation mark, colon or semicolon

- generally excluding figural and ornamental signs as well as signs used to mark the end or beginning of an entire text or a major section of text

- this subsection concerns the encoding of punctuation marks as described above; for symbols that do not qualify as punctuation marks, use the encoding described in §4.2.6 below

- we feel that this distinction in encoding is useful in many cases for distinguishing symbols definitely used for the purpose of punctuation from symbols used for a different or a less straightforward purpose

- however, the above definition is not and cannot be entirely objective, and in some cases it will not be possible to decide whether a symbol is a “punctuation mark” in this sense, or a “miscellaneous symbol”

- we recommend that you choose the encoding for miscellaneous symbols whenever in doubt

- also keep in mind that encoding a miscellaneous symbol instead of a punctuation mark or vice versa is not an error and will have little ultimate impact on the quality of our corpus

- as also explained in TG §4.2.1, punctuation marks are to be transliterated as the abstract punctuation character. (full stop, period), and their shape must normally be encoded in the `<g>` wrapper of this character

- this `<g>` element must mandatorily take the attribute `@type`, with a value as described under §4.2.3 above

- since punctuation marks, despite their diversity across the entirety of our corpus, are generally variations on a small number of basic shapes, it is strongly recommended that your tokens (or the first component of your complex tokens) chosen for describing punctuation marks follow the nomenclature suggested in the Symbol Taxonomy<fnref n="20" />

- thus, for the purposes of our encoding, the only difference between the encoding of a miscellaneous symbol and that of a punctuation mark is that while a miscellaneous symbol is encoded as an empty `<g/>` element representing the symbol, a punctuation mark is encoded as a `<g>` element wrapping a character which serves in our system as an abstract punctuation character (i.e., it implies nothing about the shape of the punctuation mark in your document)

- the primary purpose of adding . within `<g>` for punctuation marks is to make it explicit on the lowest level (that of the text itself) that we consider certain characters to be punctuation marks<fnref n="21" />

- in addition, the use of the dedicated transliteration character for abstract punctuation marks permits us, when necessary, to use this character without a `<g>` wrapper, for representing a punctuation mark without any assertion as to its shape, exclusively in the following situations:

- when supplying punctuation for the purpose of semantic segmentation

- in this case, use a . character marked up as omitted in the original

- see §6.3.6 for further details

- when encoding a text from a previous edition, without access to the original or a surrogate, if that edition does not describe the appearance of original punctuation marks

<footnote n="20">²⁰ https://docs.google.com/document/d/1glfyQnFqPrbVOYzegfjKIOVrc-vMgznEQ1iNsFf7DE8/edit?usp=sharing</footnote>

<footnote n="21">²¹ TEI allows the semantic tagging of characters as punctuation marks. We may at a later stage decide to add such tags automatically, but at present we see no advantage to doing so.</footnote>
- in this case, use a single `.` to represent a lower-level or generic punctuation mark (e.g. a full stop or *daṇḍa*) used in the previous edition,

- or a double `..` to represent a higher-level punctuation mark (e.g. a double *daṇḍa*) used in the previous edition, if that edition employs two levels of punctuation

### 4.2.5. Space filler signs

- symbols whose function is clearly and unambiguously to fill up space in a line to the binding-hole or margin are, as per TG §4.2.2, transliterated using the § sign

- in your XML markup, § characters must be wrapped in a `<g>` element with the mandatory attribute `@type`, with a value as described under §4.2.3 above

- thus, a symbol used as a space filler is distinguished from an identical-looking symbol used in a different (or unidentified) function by the presence of the § character within `<g>`

- multiple iterations of an identical space filler shall be wrapped in a single `<g>` tag, so that the number of § characters within that tag corresponds to the number of symbols in the original

<figure><img src="image_22.png" /><figcaption>Example 4.2.5.A: space fillers from South India</figcaption></figure>

kṛtvān imām. <g type="gomutraFinal">§§§§§</g>

<figure><img src="image_23.png" /><figcaption>Example 4.2.5.B: space filler from Southeast Asia</figcaption></figure>

karuhun di:rghāyūrāro<g type="squiggleVertical">§</g>

### 4.2.6. Miscellaneous symbols

- this subsection applies to non-alphanumeric symbols which do not clearly fall into any of the following categories:

- premodern editorial marks, which are not encoded as textual content, but as per §4.5

- punctuation marks as defined in §4.2.4

- space fillers as defined in §4.2.5

- in our XML files, miscellaneous symbols must be represented by the empty element `<g/>` with the mandatory attribute `@type`, with a value as described under §4.2.3 above

### 4.2.7. Alphanumeric characters used for a different function

- it occasionally happens that alphabetic or numeric characters are used in a function other than their regular value

- when an **alphabetic character** functions as a symbol (such as the character *cha* or *chah* used in some regions and periods as a closing symbol)

- do not use any markup to encode its function, but simply transliterate the character normally, separated by a space from any adjacent text

- when a **numeral sign** functions as a symbol (such as the glyph normally meaning 1, occasionally used as an auspicious opening mark)

- do not use any markup to encode its function, but also do not apply the semantic markup for numerals described in §7.1

- when a **numeral sign** functions as an alphabetic character (such as the numeral 2 used in Old Sundanese to represent the phonemes /ro/)

- do transliterate the character as the numeral, but do not apply the semantic markup for numerals described in §7.1
## 4.3. Space

### 4.3.1. Generic markup for original space

- if an inscription contains blank **space**, this should generally be encoded using the empty element `<space/>`, which can take the attributes `@unit` and `@quantity` to describe the size of the space, and `@type` for classification

- the following subsections describe when to use which attribute, and with what values

- the encoded size of spaces is by default always understood to be approximate

- the element `<space/>` should normally be separated from surrounding text by editorial spaces in your file, but if a `<space/>` occurs within a word of the text, no spaces should be added around the element

- see §8.1.2 for more details

### 4.3.2. Space for semantic segmentation

- this subsection is about spaces employed within lines by the creator of an inscription, with the presumed purpose of highlighting some aspect of semantic structure, such as spacing

- between words

- after stanzas or lines

- at a transition from verse to prose or vice versa

- at points where the topic changes markedly, for instance

- after an initial salutation or auspicious phrase

- before a colophon

- regular TEI practice<fnref n="22" /> is not to use `<space/>` for such spaces, but since our texts do not normally space words, we consider these to be “significant spaces” when they do occur and encode them as follows

- **small spaces** (from barely noticeable to less than two average character widths in extent) may be encoded using the `<space/>` element without any attributes

- as per TG 4.3, you can use the `_` character as shorthand for `<space/>` without any attributes; this will be automatically converted to markup

- the encoding of small spaces is optional and should be decided on a case by case basis, with considerations such as the following:

- no space should be encoded for widely spaced characters within a word, or between words if spaces of similar size also occur within a word

- however, segments of text written in conspicuously widely spaced characters may be marked up as per §7.5.5

- interword spacing used with fair consistency throughout an inscription may be mentioned in the metadata or commentary rather than being encoded at every instance

- small spaces used before and/or after punctuation marks, numerals and other symbols do not normally need to be encoded

- spaces used in lieu of punctuation (e.g. at the end of stanzas, verse lines or semantic units) should generally be encoded even if small

- **large spaces** (two or more characters wide) must always be encoded, using the element `<space/>` with the following mandatory attributes

- `@quantity`, whose value shall be the width of the space given as the number of characters that could fit into it (i.e., the number of widths of an average *akşara*)

- `@unit`, with the value `"character"`

- if an encoded semantic space is at a boundary between XML elements (e.g. between stanzas, semantic paragraphs, etc.), place the `<space/>` element within the structural container to which it can be allocated more logically

- space used instead of punctuation should generally be encoded at the end of the container which it separates from the next

<footnote n="22">²² https://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHSP</footnote>
### 4.3.3. Space left blank for subsequent filling

- this section is about areas that were left blank when the rest of the inscription was engraved, with the intent to be filled later on, e.g. with a name or a date

- for such spaces, called *vacat* in the western scholarly tradition, add the attribute `@type` with the value `"vacat"` to the element

- always record the size of such spaces as described for large spaces above, even if they are smaller than two character widths

- e.g. `<space type="vacat" quantity="3" unit="character"/>`

- for areas first left blank and subsequently partially filled (with some blank space remaining),

- if there is any uncertainty about the presence of an addition or its exact extent, mark up only the remaining blank space in this way

- if you are certain about both the existence and the size of the text filled in later, mark up a *vacat* for the entire length of the original space, and mark up the added text as a premodern inline addition (§4.5.2) either after or before the space

### 4.3.4. Space for visual layout

- space left blank in a text for the sake of visual appearance should not, as a rule, be marked up as space

- instead, the following options are available

- for inline layout spaces:

- optionally encode specially aligned lines (as per §7.5.2) when spaces appear

- at the end of a line that begins flush with the left margin

- at the beginning of a line that ends flush with the right margin

- at the beginning and end of a line that is centred between the two margins

- between all or most words or characters in a line that is justified to both margins

- optionally encode gridlike partitions (as per §3.6) when spaces appear between segments of each line (such as stanza quarters) to divide the text into quasi-columns where each line is intended to be read across several of these

- for blank space between lines:

- encode nothing, i.e. create no `<lb/>` elements for empty lines and insert no `<space/>` elements to represent them

- the regular line spacing and any deviations from it should be described for human readers in the layout description

- for blank pages in copper plates:

- encode `<pb/>` elements for the blank pages as per §3.5.2, but insert no `<space/>` elements to represent their content

### 4.3.5. Spaces imposed by physical necessity

- this subsection is in general about cases where the engraver was prevented from writing on a certain area of the support

- specific features causing such prevention are discussed in the following subsections

- encoding such interruptions as “significant space” is helpful because their presence may be the cause of non-standard sandhi and scribal errors

- the encoding of such spaces is optional, especially when encoding a printed edition without access to the original or a surrogate

- however, if you do choose to encode any such space in an edition, then do so consistently throughout the edition, i.e.

- encode all spaces of the same type (as per the subsections below)

- while remaining free to ignore imposed spaces of a different type in the same edition, and to ignore imposed spaces of any type in other editions even within the same subcorpus

- when encoding spaces imposed by physical necessity, distinguish these from functional spaces by adding the attribute `@type` to `<space/>`, with a value according to one of the following subsections
- should you encounter a space that you feel was imposed on the engraver by a physical feature, yet none of the types listed below classify it correctly, choose another word for the type and contact the authors and the XML-TEI Data Manager to discuss adding it to the Guide

- note that unlike other encoded spaces, this kind of space will frequently occur within a word

- in this case, do not add space characters around the `<space/>` element

- see §8.1.2 for further details

- whether or not you encode them as spaces, conspicuous features of the support may be mentioned in your layout description (global aspects) or your commentary (individual instances)

### 4.3.6. Binding holes in copper plates

- when the binding hole in a copper plate affects the text of a line, this may be encoded as `<space type="binding-hole"/>` at the locus of the hole

- use the above encoding regardless of the size of the space caused by the hole, i.e. never use `@quantity` and `@unit`

- keep in mind that it is not the presence of a binding hole that we encode here, but the fact that such a hole has obliged the engraver to skip horizontally, therefore

- **do not** encode a space for a hole that is fully outside a margin line (in the area surrounding the text field), as in Example 4.3.6.A/1

- **do not** encode a space for a hole that lies within the text field, but between lines (even if lines above/below the hole bend, or if characters in those lines are distorted in order to accommodate the hole), as in Example 4.3.6.A/2

- **optionally** encode a space for a hole that is on or within the margin line, causing one or more text line to begin with an indent, as in Example 4.3.6.A/3

- **preferably** encode a space for a hole that is fully within the text field, interrupting one or more text lines, as in Example 4.3.6.A/4

- keep in mind that binding holes, whether encoded individually or not, must be described in your layout description

<figure><img src="image_24.png" /><figcaption>Example 4.3.6.A: positions of a binding hole relative to text</figcaption></figure>

- when a binding hole affects more than one line in this way, encode such a space for every affected line

- there is no need to explicitly encode the fact that a single hole interrupts more than one line

### 4.3.7. Surface defects

- when a **surface defect in the support** has prevented the engraver from writing on a certain area, you may use `@type` with the value `"defect"`

- without further attributes if they are less than two average character widths in breadth, e.g. `<space type="defect"/>`

- or with `@quantity` and `@unit` (as described under §4.3.2 above) when they are two or more characters wide, e.g. `<space type="defect" quantity="3" unit="character"/>`

- the significance of any such spaces as relevant to the understanding of the text and its creation may be discussed in an apparatus note

- when a defect affects more than one line in this way, encode such a space for every affected line

- there is no need to explicitly encode the fact that a single defect interrupts more than one line
### 4.3.8. Spaces imposed by other glyphs

- if a space was left blank in a line because (part of) another (pre-existing or pre-conceived) character, belonging to another line, was already occupying that space, then you may use `@type` with one of the following values

- `descender` where a large **character hanging down** from the previous line encroaches on the current line

- `ascender` where a large **character popping up** from the following line encroaches on the current line

- spaces for ascenders and descenders should be encoded without any attributes other than `@type`, i.e. their extent should not be explicitly encoded

- e.g. `<space type="ascender"/>`

- the significance of any such spaces as relevant to the understanding of the text and its creation may be discussed in an apparatus note

## 4.4. Scribal Hands

- in epigraphic parlance, a "hand" means a particular combination of writing features, often indicative of one scribe taking over the work of another

- **if your inscription is written in several, clearly distinguishable hands** (as opposed to different scripts or styles, covered in §7.5.4 and §7.5.5), first of all you need to create short descriptions of each hand in the `<handDesc>` element of the TEI header (§11.2.1)

- within your edition, create the empty element `<handShift/>` at each point where the hand changes, including the beginning of the inscription where the first hand appears

- in this element, include the mandatory attribute `@new`,<fnref n="23" /> whose value shall be the XML identifier associated in the header with the hand in question, prefixed with a # mark

- e.g. `<handShift new="#Pallava00001_hand1"/>`

## 4.5. Premodern Editorial Intervention

- this section covers deliberate alteration of the inscribed text carried out in premodern times, and thus does not apply to

- purposeful or accidental effacement of the entire text or random parts of it

- the engraving of a palimpsest over a pre-existing inscription

- most premodern editorial corrections presumably took place shortly after the full text was first engraved, though some may have happened at a later time

- the precise deletion of clearly circumscribed sections of an inscription (e.g. of names) is included in the scope of this section

### 4.5.1. Premodern deletion

- text deleted (without adding a corresponding correction) in ancient or medieval time, e.g. by chiselling a stone surface, hammering the copper flat, or marking text for deletion by dotting or other conventional signs, should be wrapped in the element `<del>`

- the contents of this element may include additional markup, e.g. for reading difficulties (§5.3)

- `<del>` should be used only if you are certain that you are facing purposeful deletion, not damage to the support

- in our project, this element will by default be understood to represent text rendered illegible through **erasure** by means of chiselling, rubbing or hammering

- for **cancellation indicated by marks** (even if accompanied by partial erasure), add the attribute `@rend` to classify the method of deletion, with one of the following values

- `strikeout` for text struck through or slashed

<footnote n="23">²³ The reason why the attribute is named "new" is presumably the fact that it identifies the new hand, i.e. the one taking over at the shift. TEI guidelines note that this attribute may be renamed in a subsequent major release.</footnote>
- "ui" for the combined application of vowel markers *u* and *i* to characters to be deleted

- "other" for any deletion marker other than those listed above

- further details about the form and placement of deletion marks used in your inscription may be described in your metadata

- keep in mind that the cancellation of a previously inscribed explicit vowel mark restores the inherent *a* of a consonant *akṣara* in the scripts we work with, so such deletion must be encoded as a correction (§4.5.3) of the explicit vowel into *a*

### 4.5.2. Premodern insertion

- for characters inserted into an inscription in premodern time, create the added text at the text location where it was meant to be read (regardless of its actual location in the inscription), and wrap it in the element `<add>` with the following attributes:

- mandatorily, @place, with one of the following values:

- "inline" when inscribed within the same line in the immediate vicinity of the locus

- e.g. a character inserted between two pre-engraved characters or text engraved over a space previously left blank (see also §4.3.3)

- "below" for an interlinear addition below the locus

- "above" for an interlinear addition above the locus

- "top" for an addition in the top margin

- "bottom" for an addition in the bottom margin

- "left" for an addition in the left margin

- "right" for an addition in the right margin

- when applicable, @rend with the value "mark" to encode the involvement of a premodern editorial mark (Sanskrit *kākapada*), as illustrated in Example 4.5.2.B

- this encoding method shall apply regardless of where such an editorial mark appears (at the locus of insertion, next to the inserted text, or at both places)

- the shape and placement of the marks shall be described in an apparatus note

- the inserted text may include additional markup

- it may sometimes be impossible to determine the intended locus of a piece of interpolated or marginal text; in this case

- encode the addition at a likely place or, if one cannot be found, at any locus of your choice such as the beginning or end of a line, page or the entire inscription

- and describe the situation in your commentary

- alternatively, you may opt to encode the added text as an additional line of the principal text (§3.3.4)

**Example 4.5.2.A: premodern interlinear insertion**

<figure><img src="image_25.png" /></figure>

> an originally inscribed word *dīnāram* was corrected to *dīnāra-dvayam* by adding *dvaya* between lines below this word

dīnāra<add place="below">-dvaya</add>m

**Example 4.5.2.B: premodern insertion with an editorial mark**

<figure><img src="image_26.png" /></figure>

> an originally inscribed *maphalā* was corrected into *makaphalā* by adding *ka* between lines below this word (see the illustration)

<figure><img src="image_27.png" /></figure>

> the scribal marks on the left and right of the added *ka* look like punctuation marks, but the scribe's intention was *not* to write *ma,ka,phalā* so we should not transliterate these marks as punctuation signs

ma<add place="below" rend="mark">ka</add>phalā

<figure><img src="image_28.png" /></figure>

### 4.5.3. Premodern correction

- when a correction is written over previously engraved text, which was rendered completely illegible in the process, encode the correction as an insertion with a special value of @place:

- `<add place="overstrike">abc</add>`
- when any of the pre-correction text can be read (or restored), correction must be represented as a combination of deletion and addition, wrapped in the element `<subst>` to show that one is meant to be substituted by the other

- tag the deleted text with `<del>`, using the attribute `@rend`

- with one of the values listed under premodern deletion above; or

- with the value `"corrected"`, if the text to be replaced was neither erased, nor marked for cancellation (i.e. it is either overwritten with the post-correction text or left in place without any apparent alteration)

- tag the added text with `<add>`, using the attribute `@place`

- with one of the values listed under premodern addition above; or

- with the value `"overstrike"`, if the replacement text is inscribed over the pre-correction text (rather than at some other position)

- bear in mind that the cancellation of an explicit vowel mark restores the inherent *a* of a consonant *akṣara* in the scripts we work with, so even though no act of correction separate from the act of deletion is involved, the result is in fact a correction of the reading

- therefore such deletion must be encoded as a correction of the explicit vowel into *a*, with the corrected text struck over the pre-correction text (see Example 4.5.3.C below)

### Example 4.5.3.A: premodern correction by overwriting

> an originally inscribed *droṇavāpam* was corrected to *kulyavāpam* by inscribing *kulya* over *droṇa*
> `<subst><del rend="corrected">droṇa</del><add place="overstrike">kulya</add></subst>vāpam`

### Example 4.5.3.B: premodern correction with an editorial mark

> an originally inscribed *droṇavāpam* was corrected to *kulyavāpam* by striking out *droṇa*, adding a *kākapada* at this spot, and adding *kulya* in the bottom margin
> `<subst><del rend="strikeout">droṇa</del><add place="bottom" rend="mark">kulya</add></subst>vāpam`

### Example 4.5.3.C: premodern correction by striking out a component

> an originally inscribed *prisaṅgi* was corrected to *prasaṅgi* by striking out
> the superfluous *i* marker

> the markup must include the correction encoded as `"overstrike"`
> even though no explicit *a* was engraved
> `pr<subst><del rend="corrected">i</del><add place="overstrike">a</add></subst>saṅgi`

<figure><img src="image_29.png" /></figure>

### Example 4.5.3.D: premodern correction with an editorial mark

> an originally inscribed *ri lata* was corrected to *ri tala* in a
> manuscript by adding an editorial mark

> `ri<subst><del rend="corrected">lata</del><add place="overstrike" rend="mark">tala</add></subst>`

<figure><img src="image_30.png" /></figure>

> although the intended correction is not explicitly written anywhere, the intent is clear to a competent editor, so
> we encode the facts that can be encoded in the above scheme:

> that the pre-correction text is not explicitly deleted, but overruled by the correction (`@rend="corrected"` on `<del>`)

> that the post-correction text is right there and not somewhere else on the support (`@place="overstrike"` on `<add>`)

> that an editorial mark is present (`@rend="mark"` on `<add>`)
# 5. Physical Condition and Legibility

## 5.1. Overview

The criteria for determining the markup appropriate for specific problems may not be straightforward, so please read through this entire section to familiarise yourself with the options, then, whenever in doubt, return to this introduction for a guided decision. The factors to consider are as follows:

1. What is the condition of the support at that particular spot?

a. wholly lost; or extant, but so damaged that all vestiges of writing are obliterated: `<gap reason="lost"`, see §5.4.2

b. extant, with damage ranging from minor to extensive: go to point 2

c. extant and undamaged: go to point 3

2. To what extent does the damage hinder the reading of the text?

a. Though vestiges of text are discernible, they are too scant to favour one contextually possible restoration over another: `<gap reason="illegible"`, see §5.4.2

b. Due to damage, characters cannot be identified with certainty without relying on their context, but given the context and your expertise, you can at least make an educated guess about them: `<unclear>`, go to point 4 for further details

c. Despite some damage, all characters can be identified with certainty even if their context is disregarded: no markup (or optional `<damage>`, see §5.2)

3. Does an unusual, awkward or incompetent execution of the glyphs hinder the reading?

a. Due to their form, characters cannot be identified with certainty without relying on their context: `<unclear reason="eccentric_ductus"`, go to point 4 for further details

b. All characters can be identified with certainty even if their context is disregarded (though some irregularity of execution may be present): no markup

4. Informed by the context and your expertise, how confidently can you read/restore the affected characters?

a. With complete confidence and a conviction that even if something other than your reading was intended, the difference is trivial: omit markup at your own discretion and simply treat the text as clearly legible.

b. Quite confidently, but admitting for honesty's sake that there is a small chance of a non-trivial alternative reading being possible: `<unclear>`, see §5.3.1

c. You recognise a small number of alternatives as being possible with fairly equal chance: ambiguity marked up as `<choice>` with `<unclear>`, see §5.3.3

d. Tentatively, admitting a fair chance that a non-trivial alternative reading is possible `<unclear cert="low"`, see §5.3.2
Another way to look at the options is summarised by the following table:<fnref n="24" />

<table><caption>Table 1. Overview of legibility issues</caption><thead><tr><th rowspan="2">Confidence in reading/restoration</th><th colspan="3">Status of text</th></tr><tr><th>lost</th><th>illegible</th><th>doubtful</th></tr></thead><tbody><tr><td>absolute</td><td>&lt;supplied reason="lost"&gt;</td><td>&lt;unclear&gt;</td><td>no markup</td></tr><tr><td>reasonable</td><td></td><td></td><td>&lt;unclear&gt;</td></tr><tr><td>tentative</td><td>&lt;supplied reason="lost" cert="low"&gt;</td><td>&lt;unclear cert="low"&gt;</td><td>&lt;unclear cert="low"&gt;</td></tr><tr><td>nil</td><td>&lt;gap reason="lost"&gt;</td><td>&lt;gap reason="illegible"&gt;</td><td>NA</td></tr></tbody></table>

- status:

- lost = the support is gone or at least its surface layer is completely destroyed

- illegible = the support is extant and there are vestiges of writing on its surface, but they cannot be read with any degree of confidence

- doubtful = writing is extant and at least tentatively legible, but if the character(s) were taken out of their context, their reading would be equivocal (either because they are damaged or because they are unusually formed)

- confidence: as per 4a,b,c,d above, plus

- nil = the text cannot be read or restored with any confidence

## 5.2. Damage Not Affecting Legibility

- when the physical features of the support or damage to its surface do not affect the reading of the inscription, such features **need not be marked up**

- extensive patches of weathering or loss (which may include lacunae and reading difficulties intermingled with clearly legible text) may be described for human readers in your metadata

- spaces left blank in an inscription because of pre-existing defects or features of the surface shall be encoded as per §4.3.5

- however, should you deem it essential to explicitly encode a stretch of text as damaged, wrap the affected stretch in the element `<damage>`

- the contents of this element may include markup for lacunae and reading difficulties intermingled with clearly legible text, paying attention to the following:

- avoid overlapping with other tags by splitting `<damage>` into several segments as necessary

- regardless of the `<damage>` tag, any reading difficulties and lacunae within a spot of damage must always be marked up as described below

<footnote n="24">²⁴ As the table makes clear, EpiDoc does not allow the use of `<supplied reason="illegible"/>`, which would be expected in the middle column. The rationale behind this is that if any vestiges remain, and these can be reconstructed on the basis of context, then they meet the definition of `<unclear>` (see §5.3.1) and ought to be marked up as such. While one could argue for a distinction between “conjecturally restored text not explicitly ruled out by vestiges” and “text restored on the basis of vestiges,” our encoding practice shall follow established EpiDoc convention. Note also that the tradition of epigraphic editions in India is actually quite in line with the EpiDoc approach. Even in the *Corpus inscriptionum indicarum*, Fleet (1888,194) uses the same editorial markup for “letters which are much damaged and nearly illegible in the original, or which, being wholly illegible, can be supplied with certainty.”</footnote>
## 5.3. Doubtful Readings

### 5.3.1. The EpiDoc element <unclear>

- the term “unclear”, represented by the XML element `<unclear>`, stands in EpiDoc for any character “of which at least traces survive, but not adequately to identify the letter unambiguously outside of its context”,<fnref n="25" /> and therefore includes not only situations where a reading is tentative, but also

- where the text is read in context with absolute confidence and would only be doubtful in isolation

- where the vestiges are entirely illegible, but can be restored from the context

- while many of us tend to use editorial markup (such as brackets) only to indicate “I’m not sure this is really what the inscription said”, `<unclear>` in EpiDoc, as per the definition quoted above, means “this bit of text could conceivably be something else if the context was not there to help”

- `<unclear>` would, by that logic, be used more extensively than indications of editorial uncertainty in most of our editions

- given, however, that many of the inscriptions we work with are considerably damaged, it is desirable to avoid cluttering the edition with `<unclear>` markup and thereby distracting attention from spots where damage (or form) casts genuine doubt on a reading

- therefore, at your own discretion, **ignore trivial doubts** if the text can be read in its given context with such confidence that there is no need to leave open the possibility of any alternative

- when marking up text as unclear, you must keep in mind that the EpiDoc schema permits only text and the XML element `<g>` within `<unclear>`

- therefore, if a stretch of text you wish to mark up as unclear incorporates or overlaps with another stretch that needs different markup, you will need to split the tagged stretches of text accordingly

- see §8.2.5 for details and examples

- to mark up **damaged text legible in context with reasonable confidence**, while allowing a slight chance that a different reading might be possible

- use the element `<unclear>` without any attributes

- when the confidence of a reading is affected not by damage, but by the **unusual, awkward or incomplete execution of a glyph** by its original engraver

- add the attribute `@reason` with the value `"eccentric_ductus"`, e.g. e.g. `<unclear reason="eccentric_ductus">jñ</unclear>āna`

- when damage and eccentric ductus are (or may be) simultaneously present, use `<unclear>` with or without this attribute depending on what you consider to be the primary reason for the lack of clarity

- when in doubt, prefer `<unclear>` without this attribute

### 5.3.2. Tentative readings

- if some of the text is only **tentatively legible** even in its context, add the attribute `@cert` with the value `"low"` to the element `<unclear>`

- e.g. `mahā<unclear cert="low">puruṣa</unclear>`

- this attribute may be used in conjunction with `@reason` when needed

- no additional degrees of confidence shall be represented in markup, so `"low"` here may stand for anything between “not quite fully confident” to “desperate conjecture”

- however, it is preferable to save desperate conjectures for your commentary or apparatus, and within the edition, only encode readings in which you have some confidence

- note that while a low certainty expressed by this attribute is often a consequence of extensive damage, the **degree of legibility** is not in direct correlation to the necessity of adding this attribute, thus:

- even very badly damaged characters may be marked up with plain `<unclear>` if they can be confidently supplied in the context; whereas

<footnote n="25">²⁵ http://www.stoa.org/epidoc/gl/latest/trans-ambiguous.html.</footnote>