Behind every claim about "N inscriptions show…" stands a database, an encoding, a license, a scope

每一句"N 件铭文显示……"的背后，都站着一个数据库、一种编码、一份授权、一块范围

When you read a sentence like "of 12,000 surviving inscriptions from Roman North Africa, 38% mention an emperor", the number 12,000 is the residue of a chain of choices — which database the author queried, which fields they filtered, which encoding the editors used to mark "imperial reference," what license allowed bulk download, and which inscriptions fell outside the chosen scope.

当你读到一句话："罗马北非现存的一万两千件铭文中，有 38% 提及元首"，这个一万二的数字背后，是一条选择链：作者查的是哪个数据库？过滤了哪些字段？编辑用什么编码标记"元首指称"？什么授权允许了批量下载？哪些铭文落在了所选范围之外？

This atlas covers the major projects that the SDAM ETL pipelines (and most digital epigraphy work) draw on. It does not claim completeness — there are smaller and newer projects — but the families it identifies are stable.

本图覆盖 SDAM ETL 管道（以及大多数数字铭文学工作）所依赖的主要项目。它不声称完备，还有更小、更新的项目，但所标识的"家族"分类是稳定的。

Disciplinary lineage (skim before reading the families): the print authority chain from CIL (Mommsen 1853–) and IG (Boeckh 1828–) → PHI CD-ROMs (1985) → web databases (EDH, EDCS, 1995–) → TEI EpiDoc + IIIF (2005–) → open-data + reproducibility (FAIR, 2015–). → Full lineage walk-through in Paper § 1.5学科谱系（在读各家族前略览）：印本权威链 CIL（Mommsen 1853–）与 IG（Boeckh 1828–）→ PHI 光盘（1985）→ Web 数据库（EDH、EDCS，1995–）→ TEI EpiDoc + IIIF（2005–）→ 开放数据 + 可复现（FAIR，2015–）。→ 完整谱系见论文版 § 1.5

What is XML?

什么是 XML？

XML (eXtensible Markup Language) is a way of writing structured data so that both humans and computers can read it. Every piece of content sits inside a labelled box — a tag — and tags can contain other tags, like Russian dolls. The labels carry meaning: a computer reading <date>1883</date> knows the number is a date, not just a string.

XML（可扩展标记语言）是一种把结构化数据写成人与计算机都能读懂的格式。每段内容都装进一个有"标签"的盒子里，盒子可以套盒子，像俄罗斯套娃。标签本身携带语义：计算机读到 <date>1883</date>，就知道里头的数字是"年份"，而不仅仅是一串字符。

<inscription>
  <title>Stonecutter's sign</title>
  <date>1st century CE</date>
  <text language="latin">
    Tituli heic ordinantur
  </text>
  <text language="greek">
    στῆλαι ἐνθάδε τυποῦνται
  </text>
</inscription>

Why epigraphy uses XML: editorial markup needs more than plain text. You need to mark "this letter was supplied by the editor" or "the date is between 117 and 138 CE with low confidence." Plain text cannot do this; XML can.

铭文学为何选 XML：编辑标记需要的不只是纯文本。你需要标"这一字母为编辑所补"，或"年代为公元 117–138 年，低置信度"。纯文本做不到，XML 可以。

Note for low-coding-literacy readers: XML files are just text files. You can open them in any text editor (Notepad, TextEdit, VS Code). The angle brackets are not magic — they are just a convention so a computer can find where one piece of information ends and the next begins.

给非程序员的提示：XML 文件就是纯文本文件，任何文本编辑器（记事本、TextEdit、VS Code）都能打开。尖括号没有魔法，只是一种约定，让计算机知道一段信息从哪开始、到哪结束。

What are JSON, CSV, and tabular data?

什么是 JSON、CSV 与表格型数据？

id,province,date_from,date_to
EDCS-22000882,Sicilia,-100,100
EDCS-22000883,Africa,150,200

{
  "id": "EDCS-22000882",
  "province": "Sicilia",
  "date": {"from": -100, "to": 100},
  "text": ["Tituli heic", "στῆλαι ἐνθάδε"]
}

import pandas as pd
df = pd.read_parquet(
   'LIST_v0-3.parquet'
)
df.shape
# (~600000, 50)

Real-world example: the SDAM ETL pipeline takes EDCS's web records, parses them, runs regex cleaning, and outputs EDCS_merged_cleaned_attrs_2022-09-12.json (537,262 records, 50 fields). That JSON dump is what every downstream analysis loads. The TEI XML remains in I.Sicily / IRT / IRCyr GitHub repos for any reader who wants to verify the pipeline's choices.

真实例子：SDAM ETL 管道抓取 EDCS 网页记录、解析、跑正则清洗，输出 EDCS_merged_cleaned_attrs_2022-09-12.json（53.7 万条、50 字段）。下游所有分析都是基于这份 JSON。TEI XML 原件保留在 I.Sicily / IRT / IRCyr 的 GitHub 仓库中，供想核查管道决策的读者使用。

What is a schema? — RNG, DTD, Schematron

什么是 schema？RNG、DTD、Schematron

A schema is a contract that says: "an XML document is valid if and only if it follows these rules." It defines which elements may appear, in what order, with which attributes, and with which content. Without a schema, two editors will quietly use different conventions and the data will not be queryable.

schema（模式）是一份契约："此 XML 文档若且仅若遵守这些规则才算有效"。它规定：哪些元素可以出现、以什么顺序、带哪些属性、内容是什么。没有 schema，两位编辑会暗中采用不同惯例，整套数据就无法查询。

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://www.stoa.org/epidoc/schema/dev/tei-epidoc.rng"
             schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://www.stoa.org/epidoc/schema/dev/ircyr-checking.sch"
             schematypens="http://purl.oclc.org/dsdl/schematron"?>

Reading this: the file declares two schemas. The first (RNG) says "this file follows the EpiDoc structure." The second (Schematron) says "this file additionally follows the IRCyr project's checking rules." A validator runs both — RNG catches structural errors; Schematron catches "you used a Cyrene placeRef but the geographic region must then be Cyrenaica."

读法：文件声明了两份 schema。第一份（RNG）说"本文件遵循 EpiDoc 结构"；第二份（Schematron）说"本文件额外遵循 IRCyr 项目的检查规则"。校验器会同时跑两者，RNG 抓结构错误；Schematron 抓"你用了 Cyrene 的 placeRef，那么地理区域必须是 Cyrenaica"这类业务规则。

Why this matters: EpiDoc XML across different projects (I.Sicily, IRT, IRCyr) is interoperable because they all share the same RNG schema. Project-specific Schematron rules add local discipline without breaking that interoperability.

这为何要紧：不同项目（I.Sicily、IRT、IRCyr）的 EpiDoc XML 之所以可互操作，是因为它们共用同一份 RNG schema。项目自有的 Schematron 规则在不破坏互操作性的前提下，叠加了"本地纪律"。

URI, URL, handle, DOI, ARK — names that should not break

URI、URL、handle、DOI、ARK，不该断的名字

A digital scholarly resource is only as durable as the name you cite it by. Different naming systems trade off readability, persistence, and institutional commitment.

数字学术资源的可持续性，取决于你引用它时所用的名字。不同的命名系统在"可读性""持久性""机构承诺"之间各有取舍。

The honest reality: a 2018 study found that ~10–15% of cited URLs in classical-studies articles are dead within 5 years. Schemes like DOI and handle exist to push that rate down — but they cost money and require institutional maintenance.

诚实的现实：2018 年一项研究发现，古典学论文中所引 URL 在 5 年内"失效"的比例约为 10–15%。DOI、handle 等方案就是为压低这个比例而存在，但需要持续的资金与机构维护。

What is an API? — REST, OAI-PMH, SPARQL

什么是 API？REST、OAI-PMH、SPARQL

An API (Application Programming Interface) is a way for one program to ask another for data, structured so the answer comes back in a predictable format. Most epigraphy databases offer one or more APIs alongside their human-readable web pages.

API（应用程序接口）是一个程序向另一个程序请求数据的方式，请求与响应都按可预测的格式来。大多数铭文数据库都在面向人类的网页之外提供一个或多个 API。

GET https://kb.osu.edu/server/api/core
    /items/88887477-ad90-4c87-b9dd-…

→ {"name": "CIL 10.7296/IG 14.297…",
   "metadata": {…},
   "_links": {…}}

GET …/oai-pmh?verb=ListRecords
&metadataPrefix=oai_dc

→ <ListRecords>
    <record>…</record>
    <record>…</record>
  </ListRecords>

SELECT ?place ?name WHERE {
  ?place rdfs:label ?name .
  ?place pleiades:type "settlement" .
  ?place geo:in_region pleiades:Sicily .
}

git clone https://github.com/
       ISicily/ISicily

# → 3,500 TEI XML files,
#   one per inscription

For SDAM and similar projects: the ETL pipelines combine all of these. They scrape HTML where there's no API, hit REST endpoints where one exists, harvest OAI-PMH from DSpace, and pull GitHub bulk dumps where projects publish them. No single API handles the field; ETL stitches the methods.

对 SDAM 等项目而言：ETL 管道把以上方法结合使用。无 API 处抓取 HTML，有 REST 处调 REST，DSpace 处用 OAI-PMH 收割，凡 GitHub 公开批量数据处直接拉取。没有任何一种单一 API 能覆盖整个领域；ETL 才是把它们缝合起来的工艺。

What is a controlled vocabulary?

什么是 受控词表？

A controlled vocabulary is a fixed list of allowed values for a field. Instead of letting an editor type "limestone" or "Limestone" or "Lst." or "lapis", you say: "the allowed values for material are this list of 14 lithic types." Queries become reliable; spelling variants stop polluting counts.

受控词表是某字段允许取值的固定列表。与其让编辑随手写 "limestone"、"Limestone"、"Lst." 或 "lapis"，不如规定："字段 material 的允许取值是 下列 14 种岩性。"于是查询变得可靠，拼写变体不再污染计数。

<classDecl><taxonomy>
  <category xml:id="photograph">
    <catDesc>Digital or digitized
            photographs</catDesc>
  </category>
  <category xml:id="representation">
    <catDesc>Digitized other
            representations</catDesc>
  </category>
</taxonomy></classDecl>

For users of the data: when joining records across databases, the join is most reliable on controlled-vocabulary fields. EAGLE's vocabularies are why an EDR record can be lined up with an EDB record. Free-text fields ("commentary," "notes") cannot be joined that way.

对数据使用者：跨数据库联接时，受控词表字段最可靠。EAGLE 词表正是 EDR 记录能与 EDB 记录对齐的原因。自由文本字段（"commentary"、"notes"）则无法这样联接。

Six families — read this, then the rest of the atlas tiles in

六大家族，读完这页，全图就立起来了

Click any tile to jump to that family's detailed slide.

点击任一卡片，跳到该家族的详细幻灯。

How they relate: Family 2 produces the deepest records; Family 1 swallows them and re-publishes with shallow joins; Family 3 ingests text only; Family 4 mirrors Family 1 in Italian; Family 5 is a parallel TEI EpiDoc world for papyri; Family 6 distills text for ML training.

彼此关系：家族二产出最深的记录；家族一吞下后浅联接重发；家族三只取文本；家族四是家族一的意大利语镜像；家族五是莎草纸学的 TEI EpiDoc 平行宇宙；家族六把文本蒸馏为 ML 训练数据。

The wide-coverage databases

广覆盖数据库

What aggregators are good at: "find me all Latin inscriptions that mention X" — recall-first, breadth-first. What they are not: a faithful witness to any one stone. The deeper you go on a single record, the more you should be reading the original publication, not the aggregator's row.

聚合器擅长的："给我所有提到 X 的拉丁铭文"，召回率优先、广度优先。它们不擅长的：对任何单一石头的忠实见证。越深入单条记录，就越应该回到原始出版物，而不是聚合器的那一行。

The deep, narrow corpora

深而窄的语料库

Each project covers one region or one corpus, in TEI EpiDoc XML, with rich editorial metadata. Most are in the King's College London family (or its diaspora) and share a common structural vocabulary.

每个项目覆盖一个地区或一种语料，以 TEI EpiDoc XML 编码，附丰厚的编辑元数据。多数项目出自伦敦国王学院家族（及其海外分支），共享一套结构化词表。

The <msDesc> block — how the stone is described

<msDesc> 区块，石头是如何被描述的

msDesc ("manuscript description," but used for inscribed objects too) is the spine of every EpiDoc record. It nests four blocks:

msDesc（"manuscript description"，写本描述，但也用于铭文对象）是每条 EpiDoc 记录的主干。它嵌套四个区块：

<msDesc>
  <msIdentifier>       ← where the object lives now (museum, collection, inv. number)
    <repository ref="institution.xml#db932">Apollonia Museum</repository>
  </msIdentifier>
  <msContents>          ← what kind of text is on it (a one-line summary)
    <summary><seg>Dedication.</seg></summary>
  </msContents>
  <physDesc>            ← physical: material, dimensions, layout, lettering
    <objectDesc> ... </objectDesc>
    <handDesc> ... </handDesc>
  </physDesc>
  <history>             ← origin (when/where made), provenance (when/where seen)
    <origin> ... </origin>
    <provenance type="found"> ... </provenance>
    <provenance type="observed"> ... </provenance>
  </history>
</msDesc>

What you can ask, given this structure: "show me all inscriptions on limestone, found at Cyrene, between 100–300 CE, currently held at the Apollonia Museum." Each clause maps to one nested element. Without msDesc, this query would be impossible without the editor doing manual filtering.

有了这套结构，你能问："列出所有材质为石灰岩、出土于昔兰尼、年代在 100–300 CE 之间、当前藏于 Apollonia 博物馆的铭文。"每一个子句都映射到一个嵌套元素。没有 msDesc，这种查询离不开编辑的人工筛选。

<physDesc> — material, dimensions, lettering

<physDesc>，材质、尺寸、字形

A real physDesc from IRCyr's record C24400 (a fragmentary building inscription from the temple of Artemis at Cyrene):

来自 IRCyr 记录 C24400（昔兰尼阿尔忒弥斯神庙的一段残断建筑铭文）的真实 physDesc：

<physDesc>
  <objectDesc>
    <supportDesc>
      <support>
        <p><material>Limestone</material> block with moulding above,
           from a Doric <objectType>entablature</objectType>,
           broken in two and damaged at the lower right corner
           (<dimensions>
             <width>1.03</width>
             <height>0.59</height>
             <depth precision="low">0.44</depth>
           </dimensions>).</p>
      </support>
    </supportDesc>
    <layoutDesc>
      <layout><rs type="execution" key="scalpro">Inscribed</rs> on one face.</layout>
    </layoutDesc>
  </objectDesc>
  <handDesc>
    <handNote>Second century: <height>0.07</height>; ligature in line 2</handNote>
  </handDesc>
</physDesc>

What this records:

记录了什么：

• material = Limestone (could be controlled vocab)
• material = 石灰岩（可由受控词表）
• objectType = entablature, with prose context "from a Doric…"
• objectType = 檐部，附上下文"从一座多立克式…"
• dimensions = 1.03m × 0.59m × 0.44m. The depth has precision="low" — the editor was uncertain.
• dimensions = 1.03m × 0.59m × 0.44m。深度带 precision="low"，编辑者不太确定。
• execution with key="scalpro" — a controlled-vocab term (sculpted/incised). External taxonomy.
• execution 带 key="scalpro"，受控词表中的"刻凿"项。外置词表。
• letter height = 0.07m, plus a free-text note about ligatures.
• 字母 height = 0.07m，加自由文本备注（连字）。

Compare to EDCS for the same kind of object: EDCS would record material as a single string like "lapis", dimensions are absent entirely, and lettering height is absent. The depth + breadth trade-off again — IRCyr knows much more per record but is much smaller.

与 EDCS 对照：EDCS 会把材质记成一串 "lapis"；尺寸字段完全没有；字母高度也无。深 vs 广的取舍再次显形，IRCyr 单条记录懂得多得多，但总条数小得多。

<layoutDesc> — where the letters sit on the surface

<layoutDesc>，字母在表面的位置

"Layout" in epigraphy means: how is the inscribed text spatially arranged on the object? Is it in one block or several? Is there an iconographic field next to it? Are there frames, dividers, vacant spaces? IRCyr's record A00300 (a Christian mosaic caption for an image of Noah) shows what this looks like:

铭文学中的"layout"指：刻文如何在对象表面空间分布？是一段还是数段？旁边有无图像区？是否有边框、分隔、空白？IRCyr 记录 A00300（"诺亚释鸽"马赛克的希腊文 caption）展示了这是什么样：

<layoutDesc>
  <layout>
    <rs type="execution" key="tessellis">Mosaic</rs> lettering, in a panel
    representing <rs type="iconography">Noah</rs> as he releases the
    <rs type="iconography">dove</rs> from the <rs type="iconography">Ark</rs>.
  </layout>
</layoutDesc>

The layered information: execution="tessellis" = "made of mosaic tesserae" (controlled vocabulary). Three iconographic fields tagged: Noah, dove, Ark. Each iconography tag is a hook for cross-image searches: "show me all Christian mosaics in IRCyr that depict the dove."

分层信息：execution="tessellis" = "由马赛克小方砖拼成"（受控词表）。三个图像学标签被打上：诺亚、鸽子、方舟。每个 iconography 标签都是一条跨图像检索的"钩子"：可问"列出 IRCyr 中所有描绘鸽子的基督教马赛克"。

<history> — when made, when found, where now

<history>，何时所作、何时被发现、现存何处

Inscriptions have biographies. They are made at one time and place; they are found later, sometimes much later; they are then moved (often more than once) and may be on display, in storage, or lost. EpiDoc records this with three sub-elements inside <history>:

铭文有自己的"传记"。它在某一时间地点被造出，后来被发现（往往晚得多），又被搬动（不止一次），如今可能在展厅、库房，或失踪。EpiDoc 在 <history> 中以三个子元素记录这一切：

<history>
  <origin>             ← when and where made
    <origPlace ref="...">Findspot.</origPlace>
    <origDate notBefore="0117" notAfter="0138"
              precision="low" evidence="reign">C.E. 117-138</origDate>
  </origin>
  <provenance type="found">     ← when and where excavated/observed
    <p><placeName type="ancientFindspot"
        ref="https://www.slsgazetteer.org/909">Cyrene</placeName>:
       <placeName type="monuList"
        ref="https://www.slsgazetteer.org/1051">Temple of Artemis</placeName>;
       recorded in <date type="found">1861</date>.</p>
  </provenance>
  <provenance type="observed">   ← currently visible at this location
    <p>Temple of Artemis: standing on the wall to the right of the entrance.</p>
  </provenance>
</history>

What this lets you ask: "show me all inscriptions found at Cyrene before 1900, currently lost." (You filter provenance/@type="found" with date < 1900, but find no provenance/@type="observed".) Or: "match origDate to provenance: how many years between an inscription's making and its rediscovery?" Possible because origin and provenance are encoded as separate, structured elements.

能问的问题："列出昔兰尼出土、年代在 1900 年以前、现已失踪的铭文。"（筛 provenance/@type="found" 且日期 < 1900 而无 provenance/@type="observed"。）或："把 origDate 对照 provenance：刻成与重见天日之间相隔多少年？"之所以能问，是因为 origin 与 provenance 各自是独立的结构化元素。

Aggregator equivalent: EDCS has a single place field that conflates origin and findspot. EDH separates them better. Only TEI EpiDoc keeps the full biography.

聚合器对应：EDCS 用一个 place 字段，把"刻作处"与"出土处"混在一起。EDH 分得稍好。只有 TEI EpiDoc 保留了完整的传记。

Certainty markers — honest about what we don't know

置信度标记，对未知保持诚实

EpiDoc treats uncertainty as a first-class citizen. Almost every dating, attribution, and reading attribute can carry confidence markers, so a downstream analysis can either filter on them or propagate them.

EpiDoc 把"不确定性"作为一等公民对待。几乎每一个定年、归属、释读属性都可携带置信度标记，下游分析可据此过滤或传播。

Why this drives method: the JDH 2021 paper's tempun toolkit propagates date uncertainty by Monte-Carlo-sampling each inscription's date range many times — only possible because notBefore and notAfter are separately encoded. If you collapse the date to a single number, you lose the basis for honest uncertainty propagation.

这如何驱动方法：JDH 2021 中的 tempun 工具包通过对每条铭文的年代区间做蒙特卡洛抽样来传播不确定性，这件事之所以可能，是因为 notBefore 与 notAfter 各自被独立编码。若把日期塌成一个数，就失去了"诚实地传播不确定性"的基础。

Named entities — people, places, gods

命名实体，人、地、神

EpiDoc tags every proper name in the transcription, classifying them and linking to authority files. This makes "all inscriptions mentioning emperor Hadrian" a structured query rather than a string-search.

EpiDoc 把转写中的每一个专名都打上标签、分类、并链到权威文件。这让"所有提到哈德良元首的铭文"成为一项结构化查询，而非字符串搜索。

A real example from IAph 010001 (a Greek inscription mentioning the Roman dictator Caesar and the goddess Aphrodite):

真实示例（IAph 010001，一段希腊铭文，提到罗马独裁者凯撒与阿芙罗狄忒女神）：

<persName type="emperor">
  <name reg="Καῖσαρ"><supplied reason="lost" cert="low">Καῖσαρ</supplied></name>
</persName>
...
<persName type="aphrodisian">
  <name reg="Γάϊος"><supplied reason="lost">Γάϊος</supplied></name>
  <name reg="Ἰούλιος"><supplied reason="lost">Ἰούλιος</supplied></name>
  <name reg="Ζωΐλος"><supplied reason="lost">Ζωΐλος</supplied></name>
</persName>
...
<persName type="divine">
  <name reg="Ἀφροδίτη"><supplied reason="lost">Ἀφροδείτης</supplied></name>
</persName>

The reg attribute normalises the surface form to a "regularised" form for searching. So reg="Ἀφροδίτη" on a stone that actually has Ἀφροδείτης means "this is the goddess Aphrodite, normalised." Now you can ask "all inscriptions mentioning Aphrodite" and get hits even where the spelling varies.

reg 属性把表面形归一化为标准形以便检索。如石面写 Ἀφροδείτης，但 reg="Ἀφροδίτη" 表示"这是阿芙罗狄忒女神的归一形"。于是可问"所有提到阿芙罗狄忒的铭文"，即使拼法不同也能命中。

The apparatus criticus — recording editorial disagreements

异文校勘记，记录编辑间的分歧

An ancient inscription is rarely transcribed identically by every editor who has read it. The apparatus criticus is the place where competing readings are recorded — Editor A reads x, Editor B reads y, the present editor follows A. EpiDoc represents this as a special <div type="apparatus"> block.

同一块铭文很少能让所有读过它的编辑给出完全一致的转写。"异文校勘记"就是用来记录互相竞争的释读，编辑 A 读 x，编辑 B 读 y，本版从 A。EpiDoc 用一个特殊的 <div type="apparatus"> 区块来呈现。

<div type="apparatus">
  <p>Line 2: <app>
    <lem resp="#jmr">Apolli<supplied reason="lost">naris</supplied></lem>
    <rdg resp="#jbwp">Apolli<supplied reason="lost">nius</supplied></rdg>
  </app>.</p>
  <p>For the supplements, compare the partner inscription
     <ref type="inscription" n="1581" href="010038">1.38</ref>.</p>
</div>

Reading this: in line 2, the present editor (Joyce M. Reynolds) reads "Apollinaris"; an alternative editor (J. B. Ward-Perkins) read "Apollinius." The <app> tag wraps the disputed passage; <lem> ("lemma") is the chosen reading; <rdg> ("reading") is each alternative. Each carries resp="…" linking to an editor's xml:id.

读法：第 2 行中，本版编辑（Joyce M. Reynolds）读为 "Apollinaris"；另一编辑（J. B. Ward-Perkins）读为 "Apollinius"。<app> 标签包住有争议段落；<lem>（lemma 当选释读）；<rdg>（reading 备选释读）。每一个都带 resp="…"，链到某编辑的 xml:id。

<revisionDesc> — the digital record's biography

<revisionDesc>，数字记录自身的传记

Just as the stone has a history, the digital record about it has one too. Every meaningful change to a TEI file is logged with date, editor, and a short note. This is editorial transparency at its most basic: any reader can see who decided what, when.

石头有历史，关于它的数字记录也有。TEI 文件每一次有意义的修改，都附日期、编辑者、简短说明。这是最基本的编辑透明：任何读者都能看清"谁、何时、做了什么决定"。

<revisionDesc>
  <change when="2021-02-20" who="CMR">adapted</change>
  <change when="2013-08-22" who="TW">tagged words, names and placenames</change>
  <change when="2012-11-05" who="GB">moved text-constituted-from to profileDesc/creation</change>
  <change when="2012-10-16" who="GB">broke provenance events into multiple provenance elements</change>
  <change when="2010-08-18" who="GB">Converted from TEI P4 (EpiDoc DTD v. 6) to P5 (EpiDoc RNG schema v. 8)</change>
  <change when="2009-08-24" who="RV">Added Figures</change>
  <change when="2008-09-09" who="ZA">converted using CHET-C</change>
</revisionDesc>

What you can read out of this: the IRT0001 record was originally created in TEI P4 (older), converted to P5 in 2010, had figures added in 2009, broke its provenance into separate elements in 2012, gained word/name/place tagging in 2013, and was last adapted in 2021. The digital record's history is itself a research object — encoding fashions changed; this file evolved with them.

能读出的信息：IRT0001 记录最初以 TEI P4（旧版）创建，2010 年转为 P5；2009 年增图；2012 年把 provenance 拆为独立元素；2013 年加上词/人名/地名标注；2021 年最后一次调整。数字记录自身的历史本身就是一项研究对象，编码风潮变迁，本文件随之演进。

For citation: when citing a TEI EpiDoc record, modern practice is to include the last revision date alongside the URI. The data may have changed since you first read it; the revision-history makes that explicit.

引用时：引用一份 TEI EpiDoc 记录，现代规范是把 最近修订日期 与 URI 一并列出。读到之后数据可能已变；revision-history 把这件事写明。

A regional EpiDoc record up close — IRT0001

看一份区域 EpiDoc 记录，IRT0001

The Inscriptions of Roman Tripolitania (IRT) project: 1,618 records from Roman-period Libya. Each is a TEI XML file with this structure:

罗马时期 Tripolitania 铭文项目（IRT）：1,618 条来自利比亚罗马时期的铭文。每条是一份 TEI XML，结构如下：

<TEI xml:id="IRT0001" xml:lang="en">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>Reference to Apollo (?)</title>
        <editor xml:id="jmr">J. M. Reynolds</editor>
      </titleStmt>
      <publicationStmt>
        <publisher>Society for Libyan Studies</publisher>
        <idno type="filename">IRT0001</idno>
        <availability><p>CC BY 2.0 UK</p></availability>
      </publicationStmt>
      <sourceDesc><msDesc>
        <msIdentifier><repository>Findspot</repository></msIdentifier>
        ...physical description, layout, dimensions, dating...
      </msDesc></sourceDesc>
    </fileDesc>
  </teiHeader>
  <text><body>
    <div type="edition" xml:lang="la">...transcription with line numbers, brackets, certainty markers...</div>
    <div type="translation">...</div>
    <div type="commentary">...</div>
    <div type="bibliography">...</div>
  </body></text>
</TEI>

Notice the four <div type=…> blocks: edition (transcription), translation, commentary, bibliography. This is the EpiDoc convention. Every regional project follows it. An aggregator like EDCS, by contrast, flattens these into separate columns, often losing the editorial-certainty markup.

注意四个 <div type=…> 区块：edition（转写）、translation（译文）、commentary（评注）、bibliography（参考文献）。这是 EpiDoc 的惯例。每个区域项目都遵循它。聚合器（如 EDCS）则把这些字段铺平为独立列，常常在过程中丢失"编辑确定性"标记。

The deep encoding extreme — word-by-word lemmatization in IAph

深度编码的极致，IAph 中逐词的 lemma 标注

The Aphrodisias Inscriptions project (IAph 2007 — Joyce M. Reynolds, KCL) goes one step further than most regional projects: every word in every Greek transcription carries a <w lemma="…"> wrapper that identifies its dictionary form. This makes morphological queries possible at scale — without re-parsing the text.

阿芙罗狄西亚铭文项目（IAph 2007，KCL，Joyce M. Reynolds 主编）比大多数区域项目更进一步：每个希腊文转写中的每个词都包在 <w lemma="…"> 元素里，标注其辞典形（lemma）。这使得"按词形查询"可以批量进行，不需要重新分词。

<ab><lb n="1"/>
<w lemma="οὗτος"><supplied reason="lost">οὗτος</supplied></w>
<w lemma="ὁ"><supplied reason="lost">ὁ</supplied></w>
<w lemma="τόπος"><supplied reason="lost">τόπο</supplied><unclear reason="damage">ς</unclear></w>
<w lemma="ἱερός">ἱερὸς</w>
...

Reading this: "οὗτος" is reconstructed (lost on the stone, supplied by the editor); "τόπος" is partly lost and partly damaged; "ἱερός" is intact. The lemma values let you ask "how often does ἱερός occur in IAph?" without re-tokenizing.

读法："οὗτος" 是补足（石上已失，由编辑补；"τόπος" 部分缺失、部分残损；"ἱερός" 完整保留。lemma 标注让你能够直接问："ἱερός 在 IAph 中出现多少次？"，而不需要重新切词。

Trade-off: This depth costs editorial labour. IAph 2007 has 1,489 records — a large team's lifetime work. EDCS has 537,000 records, but no lemma tagging at all. Depth and breadth are inversely correlated.

取舍：这种深度需要编辑投入大量人工。IAph 2007 收 1,489 条，一支团队几代人的工作。EDCS 收 53.7 万条，但完全没有 lemma 标注。深度与广度成反比。

A Christian mosaic caption — "Noah and the Dove" at Apollonia

基督教马赛克 caption，阿波罗尼亚的"诺亚与鸽"

From the East Church at Apollonia (Cyrenaica), 6th century CE: a mosaic floor depicting Noah releasing the dove from the Ark, with a Greek caption. Read this record as one example of how EpiDoc captures genre + visual programme + Christian context.

来自昔兰尼加阿波罗尼亚的东教堂，公元 6 世纪：一幅马赛克地板，描绘诺亚从方舟中释放鸽子，旁附希腊文 caption。把这条记录当作一个范例：EpiDoc 如何同时记录"体裁 + 视觉方案 + 基督教语境"。

<idno type="filename">A.1</idno>
<idno type="ircyr2012">A00300</idno>

<title>
  <rs type="textType">Caption</rs>
  for image of Noah
</title>

<layout>
  <rs type="execution" key="tessellis">Mosaic</rs> lettering, in a panel
  representing <rs type="iconography">Noah</rs> as he releases the
  <rs type="iconography">dove</rs> from the <rs type="iconography">Ark</rs>.
</layout>

<origDate notBefore="0501" notAfter="0600"
          precision="low" evidence="mosaic">Sixth century CE</origDate>

<keywords scheme="IRCyr">
  <term><geogName type="ancientRegion" key="Cyrene">Cyrenaica</geogName></term>
  <term><geogName type="modernCountry" key="LY">Libya</geogName></term>
  <term><placeName type="modernFindspot"
                ref="http://sws.geonames.org/81584">Marsa Suza</placeName></term>
  <term>Christian</term>
</keywords>

The full record exists in your local ~/Documents/epidoc/cyrenaica/A.1.xml. Across all of IRCyr's 2,360 records, this same structural vocabulary applies — which makes corpus-level questions ("how many Christian inscriptions in 6th-century Cyrenaica are mosaic captions?") into single XPath queries.

完整记录就放在你本地的 ~/Documents/epidoc/cyrenaica/A.1.xml。IRCyr 全部 2,360 条记录都遵循同一套结构化词汇，因此"6 世纪昔兰尼加有多少基督教马赛克 caption"这种语料级问题，化作一行 XPath 查询。

An archaic graffito — a kothon scratched ca. 500 BCE

一段古风涂刻，约公元前 500 年的 kothon 刻文

A different genre: a Greek dedication scratched onto a Corinthian-ware kothon (a small ritual jug), found at Taucheira (Cyrenaica) in 1963–65. The IGCyr record (002200) is shorter than the Roman entablature in the previous case study — but the same structural skeleton is there.

另一个体裁：一段希腊文奉献铭文，刻于一只科林斯式 kothon（小祭祀壶）的器壁上，1963–65 年间在塔乌克拉（昔兰尼加）出土。IGCyr 记录（002200）比上一案例的罗马檐部短得多，但同一套结构骨架仍然在场。

<support><p>Two adjacent fragments of a
  <objectType>kothon</objectType>,
  <material>Corinthian ware</material>
  (<dimensions>
    <width atLeast="0.074">0.074-</width>
    <height/><depth/>
  </dimensions>).</p></support>

<handNote>
  <height atLeast="0.003" atMost="0.006">
    0.003-0.006</height>;
  epsilon with three equal bars,
  straight iota,
  rho without tail.
</handNote>

<layout>
  <rs type="execution" key="graffito">Scratched</rs> on wall, below frieze.
</layout>

<provenance type="found" notBefore="1963" notAfter="1965">
  Found between 1963 and 1965 at Taucheira: archaic votive deposit.
</provenance>
<provenance type="observed" when="1965" resp="Boardman">
  Seen in 1965 by J. Boardman.
</provenance>
<provenance type="not-observed">
  Not seen by IGCyr team.
</provenance>

The whole IGCyr corpus is licensed CC BY-NC 4.0; bulk download via Bologna's repository at doi.org/10.6092/UNIBO/IGCYRGVCYR.

整个 IGCyr 语料库采用 CC BY-NC 4.0；批量下载经博洛尼亚机构知识库 doi.org/10.6092/UNIBO/IGCYRGVCYR。

A bilingual EpiDoc — IOSPE publishes everything in Russian + English

一个双语 EpiDoc，IOSPE 把一切都同时用俄语与英语发表

The Inscriptions of the Northern Black Sea Coast (IOSPE) project is a methodologically distinctive case: every editorial field in the TEI is repeated in both Russian and English (with xml:lang="ru" and xml:lang="en"). The project's intended user-base spans two scholarly communities with little overlap; the database serves both natively.

"北黑海沿岸铭文"项目（IOSPE）是方法论上的独特案例：TEI 中的每一个编辑字段都用俄语与英语并列两版（分别带 xml:lang="ru" 与 xml:lang="en"）。项目预设的使用者跨越两个几乎不重叠的学术圈，数据库为二者同时原生服务。

<origDate notBefore="1451" notAfter="1452"
            evidence="эпиграфический_контекст" cert="low">
  <seg xml:lang="ru">1451–1452 гг.</seg>
  <seg xml:lang="en">1451–1452 C.E.</seg>
</origDate>
<provenance type="observed" subtype="autopsy">
  <seg xml:lang="ru">Non vidi.</seg>
  <seg xml:lang="en">Non vidi.</seg>
</provenance>

What this lets you do: read the same record in either language, do bilingual NLP work, search Russian terminology against English equivalents. What it costs: editorial labour roughly doubled. Who benefits: Black-Sea archaeology, where Russian-language scholarship is the largest body.

由此能做什么：同一记录可任选语言阅读；可做双语 NLP；可把俄语术语与其英语对应版互查。代价：编辑工作量约翻倍。受益者：黑海考古学界，俄语文献是该领域最大的存量。

PHI and the find-the-string family

PHI 与"找字串"家族

The EAGLE federation — Italian-language partners

EAGLE 联盟，意大利语合作伙伴

EAGLE (Europeana network of Ancient Greek and Latin Epigraphy) was an EU-funded effort to harmonise Italian regional databases under a shared identifier scheme. The data infrastructure outlived the project; the federation today is a loose alliance.

EAGLE（"欧洲古希腊语与拉丁语铭文网"）是欧盟资助、试图把意大利各区域数据库纳入一套共享标识符方案下的努力。项目结束后，数据基础设施仍在运转；今天它是一个松散联盟。

The EAGLE promise: a single resolver that, given any partner's ID, would return the records held in all the others. The reality: partial. Some pairs of partners cross-reference reliably, others don't — so any "EAGLE-aware" query has to be coded defensively.

EAGLE 的承诺：建一个解析器，给定任一合作方的 ID，即可返回其他成员所持有的对应记录。现实：部分实现。某些合作方间交叉引用稳定，另一些则不稳定，因此任何"EAGLE 感知"的查询都必须做防御性编码。

A parallel TEI EpiDoc world — papyrology

TEI EpiDoc 的平行宇宙，莎草纸学

Papyrology and epigraphy are technically distinct (papyrus vs stone) but share the same TEI EpiDoc tooling, the same Leiden conventions, and a sharper identifier ecosystem. Their backbone is papyri.info, a single portal that aggregates DDbDP texts + HGV metadata + APIS images.

莎草纸学与铭文学技术上有别（介质是莎草纸而非石头），但共用 TEI EpiDoc 工具链、共用 Leiden 惯例，且 ID 生态更清晰。它们的中枢是 papyri.info，单一门户，聚合 DDbDP 文本、HGV 元数据、APIS 图像。

The lesson for inscriptions: papyrology has solved the federation problem the inscription world is still working on. A papyrus has one TM-ID; that one number resolves to text (DDbDP), metadata (HGV), and images (APIS), each maintained by a different institution. Inscription databases — even within EAGLE — don't have an equivalent universal resolver yet.

对铭文界的启示：莎草纸学已解决了铭文界仍在挣扎的"联邦化"问题。一份莎草纸只有 一个 TM-ID；这一个号码解析为文本（DDbDP）、元数据（HGV）、图像（APIS），各由不同机构维护。铭文数据库，即使在 EAGLE 内部，至今没有等同的"通用解析器"。

A papyrus record — cde.85.247 with HGV + TM

一份莎草纸记录，cde.85.247 附 HGV + TM

<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
  <teiHeader><fileDesc>
    <titleStmt><title>cde.85.247</title></titleStmt>
    <publicationStmt>
      <authority>Duke Collaboratory for Classics Computing (DC3)</authority>
      <idno type="filename">cde.85.247</idno>
      <idno type="ddb-hybrid">cde;85;247</idno>
      <idno type="HGV">140713</idno>
      <idno type="TM">140713</idno>
      <availability>CC BY 3.0</availability>
    </publicationStmt>
  </fileDesc></teiHeader>
  <text><body>...transcription...</body></text>
</TEI>

Notice the four identifiers in one block: filename, ddb-hybrid, HGV, and TM. Each is the join key into a different system. Most papyri carry all four. Most stone inscriptions, by contrast, carry only one (the project-local one).

注意一段里 四个 标识符：filename、ddb-hybrid、HGV、TM。每一个都是通往另一个系统的"联接键"。绝大多数莎草纸都同时带全部四个。相比之下，绝大多数石质铭文只带一个（项目自定的那个）。

Practical implication: if you build an analysis pipeline that joins inscription text to geography, dating, or images, you will spend most of your engineering time figuring out which records correspond. With papyri, this is a JOIN ON tm. With inscriptions, it is custom code per database.

实际意味：若你写一个把"铭文文本 → 地理 → 定年 → 图像"联起来的分析管道，绝大多数工程时间会耗在搞清楚"哪条记录对应哪条"。莎草纸只需 JOIN ON tm。铭文则要为每个数据库写一段自定义代码。

iPHI / Ithaca — when an epigraphic database becomes a training corpus

iPHI / Ithaca，当铭文数据库变成模型训练语料

DeepMind's Ithaca (Assael et al., Nature 2022) is a transformer-based model that proposes restorations, geographical attributions, and dates for damaged Greek inscriptions. Its training data — iPHI — is PHI's text dump, deduplicated and re-formatted into train/val/test splits.

DeepMind 的 Ithaca（Assael 等，Nature 2022）是一个基于 transformer 的模型，可为损坏的希腊文铭文给出修复、地理归属、定年的建议。它的训练数据，iPHI：是 PHI 文本导出版，经去重并重新切分为 训练 / 验证 / 测试 集。

Other ML datasets in the family: PHI-Latin (Latin-side mirror, in development), Latin BERT (trained on classical Latin corpora — not just inscriptions), and various single-task fine-tunings released as Hugging Face checkpoints.

家族内其他 ML 数据集：PHI-Latin（拉丁面镜像，开发中）、Latin BERT（在古典拉丁语料上训练，不限铭文）、以及若干以 Hugging Face checkpoint 形式发布的单任务微调模型。

A literary text in TEI — Galen on the Natural Faculties

TEI 中的文学作品，盖伦《论自然机能》

If you work with inscriptions and you also use literary texts, you'll meet TEI in this other shape. The canonical-greekLit repository (Open Greek and Latin / Perseus) holds works of ancient Greek authors, each one a TEI XML file inside a folder structure that is itself a citation system.

若你做铭文研究、又用古典文学文本，会遇到 TEI 的另一形态。canonical-greekLit 仓库（Open Greek and Latin / Perseus 项目）收录古希腊作家作品，每一篇都是一份 TEI XML 文件，所在文件夹结构本身就是一套引用系统。

data/
  tlg0057/                                     ← Galen (TLG author #57)
    __cts__.xml                                ← textgroup metadata
    tlg010/                                    ← work #10 (On the Natural Faculties)
      __cts__.xml                              ← work-level metadata
      tlg0057.tlg010.perseus-grc2.xml          ← Greek text edition
      tlg0057.tlg010.perseus-eng2.xml          ← English translation

urn:cts:greekLit:tlg0057.tlg010.perseus-grc2:1.5.3
              ↑          ↑     ↑          ↑     ↑
              namespace  author work  edition   passage

Why this matters for inscription work: inscriptions sometimes quote, paraphrase, or refer to literary texts. With both sides in TEI + URNs, you can join "Pindar Ol. 13.5" mentioned in IRCyr to the actual passage in Pindar's TEI file. Without that infrastructure, you'd be doing it by hand.

这对铭文研究为何要紧：铭文有时引用、化用、提及文学文本。两端都在 TEI + URN 体系下，你可以把 IRCyr 中提到的 "Pindar Ol. 13.5" 联接到 Pindar TEI 文件中的实际段落。没有这套基础设施，就只能逐一人工处理。

From CIL X 7296 to a parquet row — the seven-step journey

从 CIL X 7296 到一行 parquet，七步旅程

A concrete walk-through of how one inscription becomes a row in the SDAM analysis-ready dataset, naming the database family at each step:

具体走一遍：一块铭文如何变成 SDAM 分析就绪数据集中的一行，每一步命名所属"家族"：

For full mechanics, see Reference Edition § 4.5 (the actual code) or the Visual edition (the same chain visually).

完整机制参见 参考版 § 4.5（实际代码）或 视觉版（同一条链的视觉版本）。

The shared spine — TEI EpiDoc

共同的主干，TEI EpiDoc

TEI (Text Encoding Initiative) is the XML standard for textual scholarship in the humanities. EpiDoc is its epigraphy customisation — a smaller, sharper vocabulary for writing inscriptions that preserves editorial judgement as structured tags. Most regional EpiDoc projects, papyrology databases, and even some aggregator backends speak this language.

TEI（文本编码倡议）是人文学科文本研究的 XML 标准。EpiDoc 是其铭文学版本，一套更小、更锐利的词表，用以书写铭文，并把编辑判断保留为结构化标签。绝大多数区域 EpiDoc 项目、莎草纸数据库、甚至部分聚合器后台都说这门语言。

Why this matters: EpiDoc adds three things that Leiden conventions alone cannot — queryable certainty (you can filter for "high-confidence readings only"), queryable lemmas (you can search by lexical form, not by surface string), and queryable named entities (you can ask "how often does Diocletian appear in IRT?").

为何要紧：EpiDoc 在 Leiden 惯例 之外多了三样东西，可查询的确定性（可只筛"高置信度的释读"）、可查询的词形（按辞典形而非表面拼写搜索）、以及 可查询的命名实体（可问"Diocletian 在 IRT 中出现多少次？"）。

The older convention — Leiden brackets

更早的惯例，Leiden 括号

Before computers, epigraphers signalled editorial judgement with a system of brackets and dots, agreed at the 1931 Leiden conference. Almost every printed transcription you read still uses them. PHI inherits them as plain-text glyphs; EpiDoc translates them into XML tags.

计算机出现前，铭文学者用 1931 年 Leiden 会议确立的一套括号与符号系统传达编辑判断。几乎你读到的每一份印本转写都还在用它。PHI 把它们当作纯文本字符继承下来；EpiDoc 则把它们翻译成 XML 标签。

[abc]      → <supplied reason="lost">abc</supplied>
⟨abc⟩      → <supplied reason="omitted">abc</supplied>
{abc}      → <surplus>abc</surplus>
⟦abc⟧      → <del rend="erasure">abc</del>
ạḅc        → <unclear>abc</unclear>
[- - -]    → <gap reason="lost" extent="3"
                 unit="character"/>
(abc)      → <expan><abbr/><ex>abc</ex></expan>
vac.       → <space unit="character"
                  extent="…"/>

A printed CIL volume page will read like a thicket of brackets. EpiDoc XML reads like a thicket of tags. The two convey the same editorial information; the second is queryable, the first is not.

一页印本 CIL 是一片"括号丛林"。一份 EpiDoc XML 是一片"标签丛林"。二者传达同样的编辑信息；后者可查询，前者不可。

The flatter alternatives — Dublin Core, plain CSV, JSON-LD

更扁平的替代，Dublin Core、CSV、JSON-LD

RDF, JSON-LD, SPARQL — turning fields into a graph

RDF、JSON-LD、SPARQL，把字段变成一张图谱

Linked data treats every fact as a triple: subject — predicate — object. Instead of "the inscription EDCS-22000882 was found in Palermo," you write three things:

关联数据把每一条事实视为一个三元组：主语 — 谓语 — 宾语。"铭文 EDCS-22000882 出土于巴勒莫"被写成三件事：

<edcs:22000882> <dcterms:isFoundAt> <pleiades:462492> .   ← findspot triple
<pleiades:462492> <rdfs:label> "Panhormus" .                ← human-readable label
<pleiades:462492> <geo:lat> "38.111" .                       ← geo coordinate

Each subject and predicate is itself a URI. Anyone can add a triple about edcs:22000882 from a different system, and a query engine can join across all of them.

每个主语与谓语本身都是一个 URI。任何人可在另一系统中为 edcs:22000882 添加一条三元组；查询引擎可跨系统联接。

{"@context": {"foaf": "http://…"},
 "@id": "edcs:22000882",
 "foaf:depicts": {"@id":"pleiades:462492"}
}

SELECT ?inscription ?place WHERE {
  ?inscription foaf:depicts ?place .
  ?place geo:in_region pleiades:Sicilia .
  ?inscription rdf:type epidoc:Bilingual .
}

IIIF in detail — two APIs, four institutions, one viewer

IIIF 细解，两套 API、四家机构、一个查看器

IIIF (International Image Interoperability Framework) is the standard most well-funded epigraphy projects use to publish images. It defines two APIs:

IIIF（国际图像互操作框架）是经费充足的铭文项目发布图像所用的标准。它定义两套 API：

.../iiif/2/ISic000470/
   full/full/0/default.jpg
.../iiif/2/ISic000470/
   2000,1500,400,400/full/0/default.jpg

{
  "@context": "http://iiif.io/...",
  "type": "Manifest",
  "items": [{ "type": "Canvas", ... }]
}

Who currently uses it: I.Sicily (full IIIF), AshLI, partial IRT, Vindolanda Tablets Online (multispectral). Who does not (yet): EDCS, EDH, PHI — these still serve plain JPGs at fixed URLs.

目前使用 IIIF 的：I.Sicily（完全 IIIF）、AshLI、部分 IRT、Vindolanda 多光谱版。尚未使用的：EDCS、EDH、PHI，仍以固定 URL 提供普通 JPG。

How to cite a digital inscription record — a working template

如何引用一份数字铭文记录，可用模板

In a paper, you cite an inscription by stacking three layers: the print authority, the digital project, and the access metadata. Here is a working template plus a real example:

论文中引用铭文，叠加三层：印本权威、数字项目、访问元数据。下面是模板与真实示例：

[Print citation: corpus, volume, number]
  = [Digital project name] [project ID]
    ([URL], accessed [date], rev. [last revision date]).

CIL X 7296 = IG XIV 297
  = I.Sicily ISic000470
    (http://sicily.classics.ox.ac.uk/inscription/ISic000470,
     accessed 2025-04-15, rev. 2024-06-12)
  = EDCS-22000882
    (https://edcs.hist.uzh.ch/?edcs-id=22000882, accessed 2025-04-15)
  = EDR140617
    (http://www.edr-edr.it/edr_programmi/res_complex_comune.php?do=book&id_nr=edr140617).

Why all three layers: the print citation is permanent (the book exists in libraries); the digital project ID lets a reader find your exact record; the access date + revision date pin which state of the data you saw. If the digital record changes, your citation still resolves to "the version I saw."

为何要三层：印本引用是永久的（图书馆里有书）；数字项目 ID 让读者能找到你看的那条记录；访问日期 + 最近修订日期固定了你所看到的数据状态。即使日后数字记录有变，你的引用仍能解析到"我当时看到的那一版"。

The names by which a stone is known to a database

数据库给一块石头起的名字

Each project assigns its own ID. Some try to be a universal join key (TM, Pleiades for places); others are project-local (ISic, IRT, edcs-id). To find one stone in two databases you usually need a hand-curated cross-reference.

每个项目都自定义 ID。有些试图扮演通用联接键（TM；Pleiades 之于地名）；另一些是项目内部用（ISic、IRT、edcs-id）。要在两个数据库中找到同一块石头，通常需要人工维护的交叉引用。

Where a database carries pictures — and where it doesn't

哪些库带图，哪些不带

What this means in practice: if your research question depends on visual evidence (lettering style, layout, paint traces), you need to identify which databases hold the image for any given inscription — and accept that for many inscriptions, no public image exists at all. Image presence is itself a piece of metadata most aggregator dumps do not preserve.

实际意味：若你的研究问题依赖视觉证据（字体、版面、留色），你需要先确认哪些数据库拥有特定铭文的图像，并接受一个事实：很多铭文根本没有公开图像。"是否有图"本身就是一种元数据，而绝大多数聚合器导出版并不保留它。

What you may legally do with the data — a brief survey

合法可做的事，一份简表

The 19th-century print authorities every database descends from

每个数据库都源自的 19 世纪印本权威

Almost every digital inscription database — even the newest ML dataset — ultimately descends from 19th-century printed editions. Knowing the print line helps you read the digital fields back to the editor who first transcribed the stone.

几乎每一个数字铭文数据库，包括最新的 ML 数据集，都最终源自 19 世纪的印本。了解印本谱系，能让你把数字字段读回到当年第一位转写这块石头的编辑。

Relevant when reading any database: the publication or idno fields you find on a digital record will almost always include a CIL / IG / AE / SEG number. That is the digital project saying: "for the authoritative print transcription, see here." Any ambiguity in the digital text usually traces back to a disagreement among these printed authorities.

读任何数据库时都要记住：数字记录的 publication 或 idno 字段几乎总会包含一个 CIL / IG / AE / SEG 号码。这是数字项目在说："关于这块石头的权威印本转写，见此。"数字文本中的任何模糊往往可追溯到这些印本权威之间的分歧。

An actual page from each pole两极各一页

Both are the same physical stone — CIL X 7296 = IG XIV 297. Same object, two corpora, two editorial styles, ~7 years apart in publication. → Full retention/loss analysis in the Case Study

两者是同一块石头，CIL X 7296 = IG XIV 297。同一对象，两套集成，两种编辑风格，相隔约 7 年出版。→ 完整保留／丢失分析在案例版

A papyrus body close-read — a tax receipt from 144 CE

一份莎草纸本文细读，公元 144 年的税收回执

A real DDbDP record (cde.85.247 / TM 140713) — a tax receipt from the Fayum, dated by the regnal year of Antoninus Pius. Its body shows a different style of EpiDoc: dense Leiden mark-up, expansion tags, certainty markers, all packed into eight lines.

真实 DDbDP 记录（cde.85.247 / TM 140713）—— 来自法雍的一份税收回执，以安东尼努斯・庇乌斯在位年份定年。其本文展示了 EpiDoc 的另一风格：密集的 Leiden 标记、缩略展开、置信度标记，挤在八行之内。

<ab>
<lb n="1"/>ἔτους ἐβδ<supplied reason="lost">ό</supplied>μου
       <unclear>Ἀ</unclear><supplied reason="lost">ν</supplied>
       <unclear>τω</unclear>νείνου

<lb n="2"/><choice><reg>Καίσαρος</reg><orig>Καίσαξος</orig></choice>
       τοῦ κυρίου Μεχεὶρ <num value="23"><hi rend="supraline">κγ</hi></num>

<lb n="3"/><expan>διέγρ<ex>αψε</ex></expan> Ἀρείῳ
       <expan>ἐγλ<unclear>ή</unclear>μπ<ex>τορι</ex></expan>
       <choice><reg><expan>χειρωναξίο<ex>υ</ex></expan></reg>
                <orig><expan>χειροναξίο<ex>υ</ex></expan></orig></choice>
</ab>

What's happening line-by-line:

逐行解读：

• <lb n="1"/> — line break, this is line 1.
• <lb n="1"/>，换行，本行为第 1 行。
• <supplied reason="lost">ό</supplied> — the editor inserts the omicron because the papyrus is broken there.
• <supplied reason="lost">ό</supplied>，编辑补 ό，因为这里莎草纸已残。
• <unclear>Ἀ</unclear> — the alpha is on the papyrus but only partially legible.
• <unclear>Ἀ</unclear>，α 在纸上但仅部分可读。
• <choice><reg>Καίσαρος</reg><orig>Καίσαξος</orig></choice> — the scribe wrote "Καίσαξος" (a slip), the editor regularises to "Καίσαρος."
• <choice><reg>Καίσαρος</reg><orig>Καίσαξος</orig></choice>，抄手误写为 "Καίσαξος"，编辑规范为 "Καίσαρος"。
• <num value="23"><hi rend="supraline">κγ</hi></num> — Greek numeral κγ (= 23) with an overline (the diagnostic mark for "this is a number, not a word").
• <num value="23"><hi rend="supraline">κγ</hi></num>，希腊数字 κγ（= 23），上有横线（"这是数字而非单词"的标记）。
• <expan>διέγρ<ex>αψε</ex></expan> — abbreviated as "διέγρ" on the papyrus; editor expands to "διέγραψε" (he/she paid).
• <expan>διέγρ<ex>αψε</ex></expan>，纸上缩写为 "διέγρ"；编辑展开为 "διέγραψε"（"已支付"）。

Three layered information types in eight lines: the surface text (what the scribe wrote), the editor's reading (what they think the scribe meant), and the editorial certainty per character (lost / unclear / present). Translate this to flat text and you collapse all three. This is exactly what an aggregator like EDCS does to its records.

八行内三层信息：表面字（抄手所写）、编辑的释读（认为抄手"应该"写的）、按字符的编辑置信度（缺/不清/在）。把它转换成纯文本就把三层都塌成一层。这正是 EDCS 等聚合器对其记录所做的。

Five inscription genres — how databases tag them

五种铭文体裁，数据库如何标注

Different inscription genres demand different fields. EpiDoc encodes "what kind of text" via <rs type="textType"> in the title and <keywords> in the textClass. Here are the five most common in Mediterranean epigraphy:

不同体裁的铭文需要不同字段。EpiDoc 通过标题中的 <rs type="textType"> 与 textClass 中的 <keywords> 来编码"是什么类型的文本"。地中海铭文学中最常见的五类：

What this changes about the database choice: if you ask a question by genre, choose a database that tags genre. EDH has a strong genre vocabulary; EDCS has weaker but still has inscr_type; PHI has none — you'd have to infer genre from the text itself. Genre questions are also where TEI EpiDoc projects' textType + iconography combination really shines.

这如何影响"该用哪个库"：若问题以体裁为单位，应选体裁标签强的库。EDH 体裁词表较强；EDCS 较弱但仍有 inscr_type；PHI 无，只能从文本推断。体裁类问题也最能展现 TEI EpiDoc 项目 textType + iconography 标签组合的价值。

Bilingual inscriptions — how databases handle two languages on one stone

双语铭文，数据库如何处理一石两语

Bilingual inscriptions are common around the Mediterranean: Greek + Latin, Punic + Latin, Hebrew + Greek. EpiDoc handles them with parallel <div type="edition" xml:lang="…"> blocks, one per language. Aggregators handle them less gracefully.

地中海地区双语铭文很常见：希腊文＋拉丁文、布匿文＋拉丁文、希伯来文＋希腊文。EpiDoc 用并列的 <div type="edition" xml:lang="…"> 区块（每种语言一份）来处理。聚合器处理得不那么优雅。

Practical implication: if you query "how many bilingual inscriptions in EDCS?" you have to write a regex that detects the // separator. If you query "how many bilingual in PHI?" you can't — PHI's records are language-specific, so the two halves of one stone count as two separate records.

实际意味：若问"EDCS 中有多少双语铭文"，得写正则识别 // 分隔符。若问"PHI 中有多少双语"，则无法，PHI 记录按语种切分，同一块石头的两半被计为两条独立记录。

The wider TEI EpiDoc world — things you'll meet next door

更广的 TEI EpiDoc 世界，隔壁就会遇到的项目

If you work with inscriptions, you will sooner or later run into these adjacent projects. They share the same XML schema and bracket conventions; the data flows between them with surprisingly little glue.

做铭文研究迟早会撞上这些邻居项目。它们共享同一套 XML 模式与括号惯例；数据在它们之间几乎不需要"胶水"就能流动。

Inside papyri.info — how a federated portal actually works

papyri.info 内部，一个联邦门户的实际工作机制

A look at how the papyri.info portal stitches together DDbDP texts, HGV metadata, and APIS images. The same architectural pattern is what inscription federation projects (EAGLE) aspire to.

看 papyri.info 如何把 DDbDP 文本、HGV 元数据、APIS 图像缝合在一起。这正是铭文联邦项目（EAGLE）所向往的架构。

          USER                        PAPYRI.INFO BACKEND
          ──────                       ──────────────────
                                       ┌────────────────────┐
   ┌────────────┐    HTTP GET          │    Solr index      │
   │  Browser   │ ───────────────────▶ │  (full-text + IDs) │
   └────────────┘                      └─────────┬──────────┘
                                                 │
                                       resolves TM-ID against:
                                                 │
                          ┌──────────────────────┼─────────────────────┐
                          ▼                      ▼                     ▼
                 ┌──────────────┐       ┌──────────────┐       ┌──────────────┐
                 │  DDbDP repo  │       │   HGV repo   │       │   APIS repo  │
                 │  TEI XML     │       │  TEI XML     │       │  IIIF + DC   │
                 │  (text)      │       │  (metadata)  │       │  (images)    │
                 └──────────────┘       └──────────────┘       └──────────────┘
                  Github / Duke         Heidelberg            many universities

What this required: (1) every record must have a TM-ID; (2) all three repositories must use the same identifier scheme; (3) the index must be rebuilt when source files change; (4) one institution must own the portal's uptime. Inscriptions don't have all four yet. EAGLE has aspired to (1) and (2); (3) and (4) are still in negotiation.

这要求：(1) 每条记录必须有 TM-ID；(2) 三个仓库必须共用同一标识符方案；(3) 源文件变动时索引必须重建；(4) 必须有一家机构对门户在线率负责。铭文界尚未同时具备这四点。EAGLE 已争取 (1)(2)；(3)(4) 还在谈。

Encoding versions move — P4, P5, EpiDoc 8, EpiDoc 9

编码版本会变，P4、P5、EpiDoc 8、EpiDoc 9

A real concern when working across projects: not all TEI is the same TEI, and not all EpiDoc is the same EpiDoc. The schema has gone through several major revisions. A query that works on one project's records may fail on another.

跨项目工作时的真实问题：不是所有 TEI 都是同一种 TEI，也不是所有 EpiDoc 都是同一种 EpiDoc。schema 已历经数次大修。在某项目记录上能用的查询，到另一项目可能失败。

The toolkit that makes it readable — EFES, Mirador, ITHACA, Latin BERT

让它们可读的工具集，EFES、Mirador、ITHACA、Latin BERT

A TEI XML file is hard to read directly. The ecosystem of tools that turn EpiDoc XML into HTML, into a reading interface, into a IIIF viewer, into a search index, into model training data — is what makes the data usable.

直接读 TEI XML 并不容易。把 EpiDoc XML 变成 HTML、阅读界面、IIIF 查看器、搜索索引、模型训练数据，这一整套工具生态，才让数据真正可用。

Which database for which question — a small decision tree

什么问题用哪个库，一棵小决策树

Honest practice: for non-trivial questions, you will end up using two or three databases together. Plan the join before you plan the analysis.

诚实的做法：遇到非平凡的问题，你最终会同时用两到三个数据库。先把联接规划好，再去做分析。

~30 databases — at a glance

约 30 个数据库，一图概览

Counts are approximate (most rows update over time). The "Family" column lets you read this table as a folded version of the previous slides.

条数为近似值（多数随时间更新）。"家族"一列让你能把此表读作前几张幻灯的折叠版。

Three things to keep when you close this atlas

合上这本图册时请带走的三件事

1. Inscription databases are families, not a monolith. The six families have different goals, different encodings, different identifier systems, and different licences.
2. 铭文数据库是若干 家族，不是一块铁板。六大家族目标、编码、标识符、授权各异。
3. The TEI EpiDoc spine connects regional projects, papyri databases, and Greek/Latin literary corpora. If you learn to read it, you can read across the field.
4. TEI EpiDoc 是连接区域项目、莎草纸库、希腊／拉丁文学语料的共同主干。学会读它，就能横读整个学科。
5. For non-trivial questions, plan the join before you plan the analysis. Which databases? Which join key? Where will the join fail, and how will you know?
6. 遇到非平凡问题，先规划 联接，再规划分析。用哪些库？以哪个 ID 联？联在哪里会断？怎么知道断了？

Project URLs & key sources

项目网址与重要来源

Encoding & tooling

编码与工具

• EpiDoc Guidelines ↗ · TEI XML for inscriptions
• Leiden conventions ↗ · the printed bracket system
• Pleiades ↗ · place identifiers
• Scaife Viewer ↗ · canonical Greek + Latin reading interface
• github.com/sdam-au ↗ · the SDAM ETL pipelines (37 repos)

Format observations on this atlas were drawn directly from sample TEI XML files in the local epidoc folder (Aphrodisias, IRT, IRCyr, IGCyr, IOSPE, DDbDP) and from the SDAM ETL bulk dumps for EDH and EDCS.

本图中的格式观察直接取自本地 epidoc 文件夹中的 TEI XML 样本（Aphrodisias、IRT、IRCyr、IGCyr、IOSPE、DDbDP），以及 SDAM ETL 中 EDH 与 EDCS 的批量导出。