Human Disease Ontology — 人类疾病的统一命名世界语

INFOBOX — Human Disease Ontology 一屏速览

维度	内容
本质	OBO Foundry 开源疾病本体：机器可读的疾病概念词典 + 单根层级树 + 跨库标识映射（知识资源，非患者数据集）
团队	University of Maryland Institute for Genome Sciences，PI Lynn Marie Schriml（ORCiD 0000-0001-8910-9851）；NHGRI 资助；2022 更新论文 15 位作者
论文	NAR Database 专辑四连发：2012（PMID 22080554）→ 2015（PMID 25348409）→ 2018（PMID 30407550）→ 2022（doi:10.1093/nar/gkab1063，PMID 34755882）
规模	11,953 疾病类 / 9,656 带定义（80.8%）/ 35,984 cross refs / 22,137 SubClassOf（v2025-09-30，DOI 10.5281/zenodo.17238005）
成长线	8,043（2012 创刊）→ 10,862（v2021-08-17，第 100 个 Release）→ 11,612（v2024-07-31）→ 11,953（v2025-09-30）
ID 体系	DOID 数字编号（如 DOID:3093 Crohn disease），PURL 永久解析
上游融合	OMIM（>1,000 亚型条目）、UMLS CUIs、ICD 映射；15 个上游本体 imports
下游影响	>50 个应用本体引用；>150 万条标注元素挂接；AGR、MGI、IEDB 等数据库采用
特殊分支	SARS-CoV-2 疾病分支（COVID-19 期间快速扩展的新发传染病节点）
许可	CC0-1.0（GitHub / OBO Foundry / Zenodo 三证一致，公有领域贡献）
获取	PURL + GitHub Releases + Zenodo（仓库级 DOI 10.5281/zenodo.10030383）+ 官网 SPARQL/API 入口
库内互链	ncbi-disease(425)、global-burden-of-disease(97)、chronic-kidney-disease-uci(726)、iqvia-disease-analyzer(510)、mondo(748)、hpo(747)、bc5cdr(415)、medmentions(390) 等

Human Disease Ontology（人类疾病本体，简称 DO，概念标识前缀 DOID）是一棵给「人类疾病」这个词下的每一个说法都发一个身份证的树。它不收集病例、不采集影像，只做一件事：把医学文献、基因数据库、电子病历里五花八门的疾病叫法——同一个病可能同时叫溃疡性结肠炎、UC、ICD-10 里的 K51、OMIM 里的 191340——整理成一棵机器可读的层级树，每个节点一个 DOID 编号、一组同义词、一条结构化定义，再用 cross references 把节点挂回 OMIM、UMLS、ICD 等外部词表。十五年过去，这棵树从 8,043 个节点长到 11,953 个，以 CC0 许可完全开放，成了生物医学领域疾病命名实体识别（NER）、富集分析和临床数据归一化的默认共享骨架。

导语读法三则：

1. 只想拿数据：直奔 §6 获取与许可——先分清五件套文件族该下哪一个，再确认引用的是版本级 DOI 而不是仓库级概念 DOI。
2. 关心 NLP 用法：直奔 §5 任务与标注——疾病 NER 语料族（bc5cdr、medmentions 等）的标签空间与 DO 同族，§9 给出库内可互链的具体条目。
3. 做数据治理：直奔 §10 避坑清单——八条实战坑，第一条就是「规模数字随版本漂移」，引用不带版本日期等于引用了一个不存在的口径。

§0 导读：这个数据集解决什么问题

疾病命名的碎片化是生物医学数据整合的第一堵墙。同一个疾病在不同语境下有不同名字：研究文献用学名和缩写，基因数据库沿用 OMIM 的条目名，医院系统挂 ICD 编码，商业词表用自己的分类学。这些叫法之间没有天然的机器可读对应关系——一段文本里出现「Crohn disease」，另一段出现「克罗恩病」，第三段出现「regional enteritis」，人类读者知道是同一个病，模型不知道。没有统一骨架，疾病层面的文献挖掘、队列对接、跨库统计就只能逐项目手工对表。

Human Disease Ontology 的回答分三层。第一层是概念：把疾病建成一个有向无环的分类树——每个节点是一个疾病概念，携带 DOID 永久编号、首选标签、同义词组、结构化定义（v2025-09-30 版 9,656 个类有定义，占 80.8%），节点间以 SubClassOf 关系构成从根部 disease 逐层下分的层级。第二层是链接：35,984 条 cross references 把 DO 节点挂到 OMIM、UMLS CUI、ICD 等外部词表，使 DO 成为不同疾病词表之间的「翻译中枢」——不必两两互译，各自对齐 DO 即可互通。第三层是生态：以 CC0 许可发布，允许任何人零门槛使用、修改、再分发；超过 50 个应用本体直接引用 DO 作为上游，AGR、MGI、IEDB 等主流数据库把基因-疾病标注挂在 DO 节点上，全生态挂接的标注元素超过 150 万条。

§0 读法三则：

1. 这个条目介绍的是「知识本体」而非「病例数据集」：没有患者行、没有文本语料，产出物是一个 OWL/OBO 文件族与配套查询服务——它与文本语料（库内 ncbi-disease、bc5cdr、medmentions）的关系是「标签空间与被标注对象」的关系（§5、§9）。
2. 全文统计数字均带版本日期或 DOI：DO 的规模数字随版本漂移（坑 1），本文所有硬数字锚定在 2012 创刊论文、2022 NAR 更新论文（PMID 34755882）与 v2024-07-31 / v2025-09-30 两个 Zenodo 版本存档上，口径链完整存照于 §3 与附录。
3. 检索时注意：DO 是「Human Disease Ontology」的惯用缩写，与实验设计（Design of Experiments）、从头设计蛋白等无关；另一个易混词是 DOID——它是标识前缀，不是本体名的另一译法（坑 3）。

§1 数据集速览：十问十答

Q1：DO 到底是数据库、软件还是数据集？
都不是传统意义上的那三种，它是「本体」（ontology）：一个用 OWL（主发布格式 doid.owl）与 OBO 平文本（doid.obo）双重发布的知识资源，内容是疾病概念、层级关系、同义词、定义与跨库链接。你能像下数据集一样下载它（五件套文件族，§6），也能像用数据库一样在官网用 SPARQL/API 查询它，但没有行级患者数据、没有图像、没有文本原文。

Q2：现在多大？数字会不会过时？
v2025-09-30 版：11,953 个疾病类，其中 9,656 个（80.8%）带结构化定义，35,984 条 cross references，22,137 条 SubClassOf 层级公理，12,739 条定义来源记录。这个数字一定会过时——DO 每个 Release 都在增长，上一轮（v2025-09-30 相对 v2024-07-31）就净增了 1,793 个新术语。所以引用任何计数必须同时给出版本日期或版本 DOI（坑 1）；本文把 2012 到 2025 的完整口径链列在 §3。

Q3：DOID 编号是什么？怎么永久引用一个疾病概念？
每个疾病类有一个 DOID 数字编号，如 DOID:3093 指克罗恩病（Crohn disease）。编号永久不变，通过 PURL 永久解析：访问 purl.obolibrary.org/obo/DOID_3093 会被重定向到当前版本的定义页或文件段。文献与本条目内文的短格式写作 doid:3093。给本体节点发永久身份证、由 PURL 层做版本解耦，这是 OBO Foundry 全家通行的约定。

Q4：内容从哪来，会不会是抄 OMIM 的？
DO 是融合再组织而非照搬：以 OMIM（超过 1,000 个亚型条目被收编进对应疾病类）、UMLS CUIs、ICD 映射等词表为素材来源，用统一的上位类结构重新组织——OMIM 是「按孟德尔遗传条目组织」的表型-基因型目录，DO 则按疾病本位（按解剖部位、病理过程）组织。2022 NAR 论文（PMID 34755882）特别强调这一版强化了整合与一致性：15 个上游本体以 imports 方式接入，定义统一记录来源（12,739 条 definition sources），证据类型标注采用 ECO 框架（本版含 11 个新增 ECO 类型）。

Q5：免费吗？商用可以吗？
完全免费且零门槛：CC0-1.0 许可（公有领域贡献声明），GitHub 仓库 LICENSE 文件、OBO Foundry 登记页与 Zenodo 存档元数据三处一致。CC0 意味着无署名要求、无相同方式共享约束、商用无限制——这在医学知识资源里是最宽松的一档（对照：部分临床词表走商业授权，库内 iqvia-disease-analyzer 条目即为一例，§9）。

Q6：怎么下载？有哪几种格式？
五个文件各有用途：doid.owl（OWL/RDF/XML，主发布，推理与图数据库用）、doid.obo（OBO 平文本，人类可读、脚本友好）、doid.json（JSON，Web 服务用）、doid-merged.obo（把 15 个 imports 合并成单文件，做完整图分析用）、HumanDO.obo（历史主文件名，老管线兼容）。三入口：PURL 直链、GitHub Releases、Zenodo 版本存档（带 DOI）。细节与取舍见 §6 与坑 2。

Q7：谁在用它？用在哪？
三类用途：其一，基因-疾病标注——AGR（含 COVID-19 专题页）、MGI 等把基因疾病关联挂在 DO 节点上，全生态标注元素超过 150 万条；其二，富集分析——FunDO、GeneAnswers 等工具以 DO 为疾病词表做基因列表的疾病富集；其三，本体工程——超过 50 个应用本体直接引用 DO 作为模块或上游。文本挖掘场景中，DO 是疾病 NER 归一化的目标词典之一（§5）。

Q8：和 MONDO、SNOMED CT、UMLS 什么关系？分工还是竞争？
同类不同路：SNOMED CT 是覆盖临床全流程的商业受控词表（许可与 DO 完全不同档，§9 有 snomed-ct 条目可对照）；UMLS 是词表的超集索引器；MONDO（库内 748 号条目）是后起的跨本体疾病合并本体，其构建过程明确以 DO 为输入之一——两者现在是「DO 提供精细层级与定义、MONDO 做跨库合并」的互补格局。DO 保留 cross refs 而不做等价合并，这正是它作为「翻译中枢」的定位（坑 5）。

Q9：COVID-19 疫情期间 DO 做了什么？
快速扩展了 SARS-CoV-2 疾病分支：把新冠相关疾病从感染、肺炎到多系统炎症综合征逐层入树，供数据库与文献挖掘直接挂接。AGR 的 COVID-19 专题着陆页即以 DOID:0080599 为锚点。这是本体响应新发传染病的一次实战演示：词表先行，下游统计与标注才能统一口径。

Q10：适合直接拿去做 NLP 吗？
适合做「归一化目标」，不适合当「训练语料」。它没有文本，但提供了疾病概念层：NER 模型抽出的疾病提及需要映射到标准概念，DO 的同义词组与层级正好承担这一步——库内 bc5cdr(415)、medmentions(390) 两个 NER 语料的标签空间与 DO/Mesh/OMIM 同族，可直接对接做疾病归一化评测（§5、§9）。注意定义覆盖率 80.8%，做细粒度归一化时需检查目标节点是否有定义。

§2 数据构成：文件族五件套与树上的每一层

DO 的产出物是一个文件族加配套服务。文件族五个成员，各司其职：

文件	格式	用途	谁该用
doid.owl	OWL / RDF/XML	主发布文件，携带完整公理与注解	推理引擎、图数据库、SPARQL 端点、Protégé
doid.obo	OBO 平文本	人类可读的传统格式，逐段 stanza	脚本处理、快速 grep、老管线
doid.json	JSON	面向 Web 服务与 JS 生态	前端展示、API 中间层
doid-merged.obo	OBO（合并版）	把 15 个上游本体 imports 合并为单文件	需要完整闭包图分析的下游（如 MONDO 类整合工程）
HumanDO.obo	OBO	历史主文件名，保留发布	旧工具链兼容（坑 2）

树上每层的内容构成（以 v2025-09-30 版为准，全部数字带版本存照）：

• 疾病类（disease classes）：11,953 个。这是本体的主资产——每个类一个 DOID 编号、一个首选标签、若干同义词。类覆盖从大类（如消化系统疾病）到具体病种（如克罗恩病）再到亚型（如 >1,000 个收编自 OMIM 的亚型条目）的完整粒度谱。
• 层级公理（SubClassOf）：22,137 条。构成从单根 disease 向下生长的分类树。层级是 DO 的核心价值之一——它使「某基因与某个 DO 节点相关」的断言可以沿树向上泛化统计。
• 跨库链接（cross references）：35,984 条。把 DO 节点挂到 OMIM、UMLS CUI、ICD 等外部词表。注意这是「链接」而非「等价断言」——映射粒度不一、非全量覆盖（坑 5）。
• 结构化定义（definitions）：9,656 个类携带定义，覆盖率 80.8%。定义是受控的正式文本，区别于标签与同义词。
• 定义来源（definition sources）：12,739 条记录。注意与上一条是两个口径——一个定义可引多个来源，来源数大于带定义的类数（坑 6）。
• 上游导入（imports）：15 个上游本体的导入声明，2022 NAR 论文（PMID 34755882）强调的「improved integration」正是把分散的外部引用收拢为标准化 imports。
• 证据类型（ECO）：11 个新增 ECO（Evidence & Conclusion Ontology）类型在本版接入，使标注与定义的证据来源可被机器区分。
• 特殊分支：SARS-CoV-2 疾病分支——COVID-19 期间逐层扩充的新发传染病子树，含 DOID:0080599（COVID-19）及其下级，AGR 等数据库以此为标注锚点。

配套服务：官网提供浏览与检索界面、SPARQL 端点与 API 入口（自官网导航进入）；PURL 服务把 DOID 编号永久解析到当前版本。第三方镜像（OLS、BioPortal、OntoBee、AberOWL）提供网页浏览与交叉检索，但其计数可能滞后（坑 8）。

本体的物理体量：v2025-09-30 版 Zenodo 存档 ZIP 为 84.0MB——一个知识本体达到几十 MB 量级，主要因为合并了 imports 与完整注解（同义词、定义、cross refs、定义来源、ECO 标记全部内联）。下载前请确认目标：只要主干用 doid.owl/doid.obo 即可，要完整图分析才需要 merged 版。

§3 论文与版本时间线：四篇 NAR 与口径链

DO 的学术档案集中在 Nucleic Acids Research Database 专辑，四篇论文构成四个阶段：

第一阶段·创刊（2012）
论文 Disease Ontology: a backbone for disease semantic integration（NAR 2012;40(D1):D940-946，doi:10.1093/nar/gkr972，PMID 22080554，PMC3245088）。提出「疾病语义整合骨干」的定位：8,043 个疾病术语，把文献、基因库、临床词表中的疾病叫法对齐为一棵语义树。这一版确立了 DOID 编号、PURL 解析与 OBO 发布的基本形态。注意：PMC3245088 在抓取时受 PMC 反爬封锁，正文细节以 NAR 官网与 PubMed 摘要为准（附录存照）。

第二阶段·扩展（2015）
论文 Disease Ontology 2015 update: an expanded and updated database of diseases and diseases vocabulary（NAR 2015;43(D1):D1073-D1078，doi:10.1093/nar/gku1011，PMID 25348409）。主要工作是把孤儿药、罕见病与更细的临床亚型纳入词表，扩大覆盖。

第三阶段·平台化（2018）
论文 Disease Ontology 2018 update（NAR 2019;47(D1):D955-D962，doi:10.1093/nar/gky1032，PMID 30407550）。期刊卷期与发表年跨 2018/2019（在线 2018、专辑归 2019 卷），引用时注意双口径。这一阶段 DO 的定位从静态词表转向持续维护的平台，标注挂接量在本阶段突破百万级（>1.5M 标注元素的说法由此确立）。

第四阶段·社区协作（2022）
论文 Disease Ontology: improved integration, consistency, and greater collaboration with the broader biomedical ontology community（NAR 2022;50(D1):D1255-D1261，doi:10.1093/nar/gkab1063，PMID 34755882，PMC8728220）。流程档案：Received 2021-09-22，Accepted 2021-10-18，在线发表 2021-11-10；正文署名 15 位作者，通讯 Lynn Marie Schriml。核心内容：imports 标准化（15 个上游本体）、定义与来源治理（12,739 条 definition sources）、ECO 证据框架接入（11 个新增类型）、与更广泛本体社区（MONDO 等工程）的协作机制。Google Scholar 记录该文引用约 363 次（2026-10 查询快照，见附录存照）。

版本口径链（规模数字的正确打开方式）

时点	疾病类数	定义覆盖	出处锚点
2012 创刊	8,043	—（早期未按现口径统计）	NAR 2012，PMID 22080554
v2021-08-17（第 100 个 Release 里程碑）	10,862	76%	NAR 2022 论文正文表
v2024-07-31	11,612	79.9%	Zenodo DOI 10.5281/zenodo.13145656
v2025-09-30（本文主口径）	11,953	9,656 个即 80.8%	Zenodo DOI 10.5281/zenodo.17238005

四行数字不是矛盾而是递进：DO 每个 Release 都在净增（v2025-09-30 相对 v2024-07-31 净增 1,793 个新术语）。引用任何一行必须同时给版本日期或 DOI——只写「DO 有约 1.2 万个疾病类」不带版本，等于引用了一个不存在的口径（坑 1）。Release 编号上，v2021-08-17 恰是第 100 个 Release，按此节奏估算年均约 4-5 个 Release、十六年累计 100+ 个版本存档，每个版本在 Zenodo 均有独立 DOI 可引。

发布管线变更存照：2025 年官方宣布发布管线切换至 ROBOT 1.9.10。需注意「宣布切换」与「已完成切换」是两回事——截至本文写作（2026-10），官方文档中该切换以已宣布口径存照，跨版本做产物 diff（尤其公理序列化细节）前应先确认所用 Release 的管线版本（坑 4）。

§4 机构与人物：一人主导十五年的本体工程

PI 与机构。DO 由 Lynn Marie Schriml（ORCiD 0000-0001-8910-9851）主导，她任职于 University of Maryland（马里兰大学）Institute for Genome Sciences（基因组科学研究所，IGS），也是 IGS 中生物医学本体方向的核心研究员。四篇 NAR 论文的通讯作者均为她——十五年四届 Database 专辑连续主导，在本体领域是罕见的长期投入。2022 更新论文署名 15 位作者，团队横跨本体编辑、软件工程与社区协调（完整名单见论文页，本条目不逐名列出以避免转抄误差）。

资助。DO 的持续维护依托美国 NHGRI（国家人类基因组研究所）资助——本体属于 NIH 数据科学基础设施资助口径，长期滚动支持，这也是 DO 能十六年免费开放且不设付费墙的物质基础。

社区协作结构。2022 论文标题里的「greater collaboration」指向 DO 的工作方式变化：其一，与 OBO Foundry 生态的规则对齐（CC0、单根、PURL、imports 规范）；其二，与 MONDO 等后起整合工程的分工协作——MONDO 把 DO 作为上游输入之一，DO 专注精细层级与定义质量；其三，领域专家社区参与入树——罕见病亚型、新发传染病的条目扩充由领域专家贡献、本体编辑团队治理入库。SARS-CoV-2 分支的快速扩充正是这套协作机制的实战检验。

OBO Foundry 身份。DO 是 OBO Foundry 登记本体（登记页 obofoundry.org/ontology/doid.html），遵守 OBO Foundry 原则：开放许可（CC0）、常用格式（OWL/OBO）、永久标识（PURL/DOID）、版本化发布、可追溯定义来源。这套原则正是本条目 §6 获取链与 §7 评估的框架来源。

§5 任务与标注：谁在用什么方式用这棵树

DO 不是标注数据集，但它支撑了大量标注任务。四类用法，按数据流排序：

用法一：疾病 NER 的归一化目标词典。命名实体识别流水线分两步：先把文本里的疾病提及抽出来（NER），再把它映射到标准概念（normalization/linking）。DO 在第二步供弹：同义词组承接各种写法，DOID 编号作为输出 ID，层级关系支撑粗细粒度切换。库内两个 NER 语料与 DO 同族——bc5cdr（415 号条目，BC5CDR-disease 子任务）与 medmentions（390 号条目，多类型 MEDMENT）的疾病标签空间均属 DO/Mesh/OMIM 词表族，用 DO 做归一化评测时标签对齐工作量可控（§9 有链接细节）。

用法二：基因-疾病关联标注。AGR（Alliance of Genome Resources，含 COVID-19 专题着陆页 DOID:0080599）、MGI（小鼠基因组信息学）等数据库把模式生物与人类基因的疾病关联挂在 DO 节点上。DO 官方口径：全生态标注元素超过 150 万条（>1.5M annotation elements，2018 论文确立的说法，2022 论文延续）。这一用法的关键是层级——挂接在某个中间节点上的标注，可沿 SubClassOf 树做上下泛化统计。

用法三：富集分析。给一个基因列表，问「哪些疾病被过度代表」——FunDO、GeneAnswers 等工具以 DO 为疾病词表执行疾病富集，逻辑与 GO 富集同构：统计基因列表在 DO 节点上的分布，对照背景分布做显著性检验。这是 DO 在湿实验合作研究中最常见的消费形态。

用法四：本体工程的上游模块。超过 50 个应用本体（application ontologies）直接引用 DO：有的整体导入（imports），有的抽取子树（如疼痛本体取神经病理性疼痛分支、传染病本体取感染分支）。MONDO 是其中体量最大的消费者之一——以 DO 为输入做跨本体合并。这一用法对 DO 的要求是格式规范与版本稳定，也正是 §3 所述 2022 版治理工作的服务对象。

标注治理细节（2022 版治理框架，直接影响下游标注质量）：

1. 定义溯源：12,739 条 definition sources 让每个定义可回溯到文献或权威词表——下游引用定义时能给出出处，而不是引用一个无主文本。
2. 证据类型：11 个新增 ECO 类型接入后，「这条断言是文献实证还是计算推断」可被机器区分——对做证据等级加权的下游（如药物重定位）是实质改进。
3. 同义词治理：同义词分精确、宽泛、相关、缩写等类型（OBO 惯例），NER 归一化时可按类型控制召回-精度取舍。
4. 入树流程：新疾病条目由领域专家提案、本体编辑团队审核入树，SARS-CoV-2 分支 2020 年的快速扩充即此流程的加速版。

§6 License 与获取：CC0 三证与五入口

许可结论：CC0-1.0，医学知识资源里最宽松的一档。三处独立证据互证：

1. GitHub 仓库 DiseaseOntology/HumanDiseaseOntology 的 LICENSE 文件：CC0-1.0 全文；
2. OBO Foundry 登记页（obofoundry.org/ontology/doid.html）：license 栏目登记为 CC0-1.0；
3. Zenodo 存档元数据：license 字段为 CC0-1.0（仓库级 DOI 10.5281/zenodo.10030383 及各版本 DOI 均继承）。

CC0 的实际含义：作者向全球公有领域贡献，任何人可自由使用、修改、再分发、商用，无署名要求（礼貌性致谢仍受欢迎但非义务）、无相同方式共享约束、无需申请。与常见医学词表对照：SNOMED CT 走各国授权（UMLS 许可证），OMIM 限制再分发与商用，DO 的 CC0 意味着可以把它直接打进商业产品的分发包——这正是它被 >50 个应用本体引用的许可前提。

获取链五入口：

1. PURL 直链（要最新版用这个）：purl.obolibrary.org/obo/doid.owl 永久解析到当前发布文件；同理可得各格式（doid.obo 等）。PURL 层把「你引用的地址」与「实际文件版本」解耦——地址永远有效，内容随版本演进。
2. GitHub Releases（要版本历史用这个）：仓库 Release 页逐版挂出发布文件与更新说明；第 100 个 Release 里程碑是 v2021-08-17。适合做版本间 diff、锁定版本的工作流。
3. Zenodo（要可引用 DOI 用这个）：两层 DOI 结构——仓库级概念 DOI 10.5281/zenodo.10030383（永远指向最新版）与逐版本 DOI（如 v2024-07-31 为 10.5281/zenodo.13145656、v2025-09-30 为 10.5281/zenodo.17238005）。论文引用一律用版本级 DOI 以保证可复现（坑 7）。
4. 官网查询服务：disease-ontology.org 提供浏览、检索界面与 SPARQL/API 入口（自官网导航进入）；适合探索性查词而非批量下载。
5. 第三方镜像：OLS（EMBL-EBI）、BioPortal、OntoBee、AberOWL 提供在线浏览与交叉检索；注意镜像计数可能滞后于官方 Release，官方口径以 GitHub/Zenodo 为准（坑 8）。

引用规范小结：引数据集本体→给版本级 Zenodo DOI；引学术工作→给 NAR 论文（2022 版 doi:10.1093/nar/gkab1063）；引单个疾病概念→给 DOID PURL（如 purl.obolibrary.org/obo/DOID_3093）。三层引用对象各对应一种 DOI/PURL，混用会让审稿人与下游工具都困惑。

§7 评估与基准：本体质量的验法

DO 没有传统意义的「测试集 leaderboard」——它是基础设施而非基准任务。但它的质量可以从四个维度验：

维度一：OBO Foundry 原则符合度。作为登记本体，DO 逐项满足 OBO Foundry 原则：开放许可（CC0）、可复用格式（OWL/OBO）、永久标识（DOID/PURL）、单根层级（2022 版治理后的疾病单根树）、定义可溯源（12,739 条 definition sources）、版本化发布（Zenodo 逐版 DOI）。这些原则本身构成一套「本体体检表」，DO 是其中高分样本。

维度二：内部一致性指标。定义覆盖率 80.8%（9,656/11,953，v2025-09-30）且逐版上升（76% @v2021-08-17 → 79.9% @v2024-07-31 → 80.8% @v2025-09-30）——三年间定义工作持续在还历史欠账。证据类型接入（11 个新增 ECO 类型）与 imports 标准化（15 个上游本体）是 2022 论文自报的两项结构改进。剩余近两成无定义节点集中在极罕见与新增条目——这是已知的、官方可见的最大质量缺口。

维度三：生态采用度。>50 个应用本体引用、>1.5M 标注元素挂接、AGR/MGI/IEDB 等数据库采用、FunDO/GeneAnswers 等工具内建——采用度是本体价值的硬通货。学术侧，2022 更新论文 Google Scholar 引用约 363 次（2026-10 快照），四篇 NAR 论文构成稳定的引用层。

维度四：下游任务表现。DO 参与的 NLP 评测通常以「疾病归一化准确率」形式出现——在 bc5cdr、medmentions 等语料的疾病链接任务中，映射到 DO/MeSH/OMIM 标签空间是主流评测设定（各模型分数见对应库内条目，本条目不重复计分）。本体侧，MONDO 的构建管线把 DO 与 OMIM、Orphanet 等并列输入，其合并质量报告间接构成对 DO 的第三方检验。

再补一句边界：DO 的层级是疾病本位（按解剖部位、病理过程组织），与 ICD 的统计本位（按死因/报表需求组织）、OMIM 的遗传条目本位不同——用 DO 层级做死因统计归类会失真，那是 ICD 的主场（§9 有 global-burden-of-disease 条目可对接）。

§8 生态与外部互链：DO 在万物图谱里的位置

上游（喂给 DO 的）：OMIM（>1,000 个亚型条目收编入树，贡献遗传病粒度）、UMLS CUIs（贡献临床词表对齐）、ICD 映射（贡献统计口径桥接）、Orphanet/罕见病资源（贡献罕见病条目）、领域文献（贡献定义与来源）。15 个上游本体以 imports 方式标准化接入（2022 版），包括 ECO（证据类型）等框架本体。

下游（消费 DO 的）：

• 数据库类：AGR（联盟基因组资源，COVID-19 专题页锚定 DOID:0080599）、MGI（小鼠基因-疾病标注）、IEDB（免疫表位数据库，疾病语境标注）；
• 工具类：FunDO、GeneAnswers（疾病富集分析），OntoBee、AberOWL（本体浏览与 SPARQL）；
• 整合工程类：MONDO（最大消费者，跨本体疾病合并）、>50 个领域应用本体（整体导入或子树抽取）；
• NLP 语料族：bc5cdr、medmentions 等疾病 NER 语料的标签空间与 DO 同族（详见 §5/§9）。

镜像与索引：OLS（EMBL-EBI）、BioPortal（Stanford）、OntoBee、AberOWL、Bioregistry（公平数据标识注册，收录 DOID 前缀）——这些索引层让 DO 的概念可以在其他系统内被直接引用。

一句话定位：在疾病知识栈里，OMIM/ICD/Orphanet 是「原始词表」，DO 是「语义整合层」，MONDO/UMLS 是「合并/索引层」——DO 的独特生态位是中间那层：比原始词表更结构化，比合并层更保留源词表细节。

§9 与库内条目的关系：互链地图

本条目在库内的互链条目分三组（rid 为库内 record_id，只读反查于 2026-10-04）：

第一组·同主题对照（疾病知识资源）：

• mondo(748)：后起跨本体疾病合并本体，构建管线以 DO 为上游输入之一；对照阅读可见「合并派」（MONDO）与「精细树派」（DO）两条路线的分工。
• hpo(747)：人类表型本体。与 DO 是「表型侧 vs 疾病侧」的姊妹本体——HPO 组织表型异常，DO 组织疾病实体，两者通过疾病-表型关联（如 OMIM 条目）间接对接。
• orphanet-ordo(812)：罕见病专用本体，与 DO 在罕见病亚型上重叠交叉，Orphanet 编号与 DOID 之间存在映射需求。
• iqvia-disease-analyzer(510)：商业疾病词汇词表。与 DO 形成「商业授权 vs CC0 开放」的许可光谱对照——做全球市场数据时用 IQVIA，做开放科学时用 DO。
• snomed-ct(557)：临床全流程受控词表（商业授权）。DO 与其定位不同：SNOMED 覆盖临床操作全栈，DO 专注疾病语义整合；两者通过 UMLS 间接对齐。
• umls(558)：词表超集索引器，DO 的 CUI 对齐经由 UMLS 完成——互为映射枢纽。

第二组·下游消费（NLP 语料与知识图谱）：

• ncbi-disease(425)：疾病 NER 经典语料（PubMed 摘要级疾病提及语料），其概念标注空间属 DO/MeSH/OMIM 词表族——DO 可直接作为其归一化目标。
• bc5cdr(415)：BioCreative V CDR 语料的疾病子任务，疾病标注同样落在 DO/MeSH/OMIM 族标签空间。
• medmentions(390)：大规模多类型实体链接语料，疾病类型实例可用 DOID 归一化。
• ctd(749)：Comparative Toxicogenomics Database 的数据条目，其疾病-基因关联采用 MeSH 疾病词表（与 DO 存在广泛交叉引用）。
• disgenet(449)：基因-疾病关联数据库，疾病概念层与 DO 的层级可直接对接做富集与网络分析。
• gene-ontology(441)：GO 与 DO 同属 OBO Foundry 家族，是「基因功能侧 vs 疾病侧」的对应物；FunDO 类富集工具正是把两者串起来的产物。

第三组·应用场景对接：

• global-burden-of-disease(97)：GBD 的疾病负担统计以自身 cause list 组织（ICD 本位）；与 DO 对接需经 ICD 映射层，适合做「语义骨架 vs 负担统计」的跨源连接案例。
• chronic-kidney-disease-uci(726)：单病种临床数据集；可用 DO 的慢性肾病节点（检索 chronic kidney disease 定位其 DOID）及其下级亚型为其提供概念锚点，是「本体给表格数据加语义」的最小示例。
• omim(159)：DO 的最大上游之一（>1,000 亚型收编）；上游词表与整合本体的对照关系在 §4/§8 已展开。

互链原则：以上 16 个条目按「同主题对照/下游消费/场景对接」三组串联，发布互链的最终取舍由主会话定夺；本条目正文已在对应章节预埋锚点（§5 用法一对应第二组、§6 许可对照对应第一组、§7 边界一句对应第三组）。

§10 避坑清单：八条实战坑

坑 1：规模数字随版本漂移，引用必须带版本日期。 8,043（2012）、10,862（v2021-08-17）、11,612（v2024-07-31）、11,953（v2025-09-30）——四个数都对，也都马上会过时。DO 的 Release 节奏使任何不带版本戳的计数都不可复现：论文里写「DO 有 11,953 个疾病类」而不给「v2025-09-30 / DOI 10.5281/zenodo.17238005」，半年后就成了查无此数的悬空引用。正确姿势：主口径带版本日期与 DOI，历史对比列表给出完整口径链（本文 §3 表即模板）。

坑 2：五件套文件族下错格式白折腾。 doid.owl（OWL/RDF/XML，推理与图库用）、doid.obo（OBO 平文本，脚本用）、doid.json（JSON，Web 用）、doid-merged.obo（合并 15 个 imports 的单文件，完整图分析用）、HumanDO.obo（历史主文件名，旧管线兼容）。常见事故：想要完整闭包图却拿了 doid.obo——imports 不在内，算出来的关系少一截；想 grep 却拿了 doid.owl——RDF/XML 没法直接逐行处理。下载前先想清楚用途再选格式。

坑 3：名称检索的三重陷阱。 第一重：Human Disease Ontology 惯用缩写 DO——在工程语境里 DO 常指实验设计（Design of Experiments）或从头设计蛋白，检索时加上 disease ontology 或 DOID 前缀。第二重：DOID 是标识前缀不是本体名的另一译法——「DOID 本体」的说法不准确，正确是「DO 的 DOID 编号体系」。第三重：Disease Ontology 不带 Human 一词时可能撞上动物疾病本体等他物，引用时优先写全称 Human Disease Ontology。

坑 4：2025 年 ROBOT 1.9.10 管线切换，跨版本 diff 先查管线版本。 官方 2025 年宣布发布管线切换至 ROBOT 1.9.10——注意「宣布」不等于「已完成」，官方文档以已宣布口径存照（本文写作时点 2026-10）。新管线产物在公理表达与序列化细节上可能与旧版不一致：做跨版本 diff 时若发现大批格式性差异，先确认两个 Release 各自的管线版本，别把管线噪音误判为内容变化。

坑 5：cross refs 是链接不是等价断言。 35,984 条 cross references 把 DO 节点挂向 OMIM、UMLS、ICD，但映射粒度不一：一条 DOID 可能对多条 OMIM 亚型、一条 UMLS CUI 可能对应粒度不同的 DOID。把 DO 当成「UMLS 的免费替代品」或把 cross refs 当成「无损翻译表」都会踩坑——正确用法是把 cross refs 当对齐线索，关键映射（尤其计费、死因编码等高风险场景）逐条人工核验。

坑 6：definitions 与 definition sources 是两个口径。 v2025-09-30 版：9,656 个类带定义（80.8%），而 definition sources 记录 12,739 条——后者大于前者，因为一条定义可引多个来源。混用两个口径会让「定义覆盖率」算错分母；同样小心「76%（v2021）→79.9%（v2024）→80.8%（v2025）」的分母各是当年类数，不是 11,953。

坑 7：Zenodo 双层 DOI，引用要用版本级。 仓库级概念 DOI 10.5281/zenodo.10030383 永远指向最新版；逐版本 DOI（如 10.5281/zenodo.17238005 对应 v2025-09-30）锁定具体内容。论文与可复现工作流引用版本级 DOI；概念级 DOI 只适合「泛指 DO 全部版本」的场合。反过来，想看最新版却把版本级 DOI 当概念级用，会拿到过时文件。

坑 8：别把第三方镜像计数当官方口径。 OLS、BioPortal、OntoBee、AberOWL 等镜像同步有延迟，显示的类数、关系数可能落后于最新 Release；官网检索界面与镜像间的计数差异同样存在。需要权威计数时以 GitHub Release 说明与 Zenodo 版本存档为准；镜像适合浏览与探索，不适合出数字。

§11 总结：一棵树如何长成行业标准

Human Disease Ontology 的十五年给出了一条「知识基础设施」的标准成长路径：2012 年以 8,043 个术语立起「疾病语义整合骨干」的定位（NAR 2012）；2015 扩罕见病与亚型；2018 转向平台化维护、标注挂接破百万；2022 完成 imports 标准化与定义治理、强化社区协作（NAR 2022，15 作者，Google Scholar 约 363 引）；到 v2025-09-30，11,953 个疾病类、80.8% 定义覆盖、35,984 条跨库链接、>50 个应用本体引用、>150 万条标注元素——一棵树长成了一个行业标准。

它对 AI-Ready 数据集库的价值有三层：对做疾病 NER 的团队，它是归一化目标词表（与库内 ncbi-disease(425)、bc5cdr(415)、medmentions(390) 无缝对接）；对做知识图谱与富集分析的团队，它是疾病侧的语义骨架（与 gene-ontology(441)、disgenet(449)、ctd(749) 对接）；对做数据治理的团队，它是「CC0 许可 + 永久标识 + 版本化发布」三件套的教科书样本（与 mondo(748)、hpo(747)、snomed-ct(557) 等对照可覆盖整个疾病知识栈的许可与定位光谱）。

记住三件事：引用带版本日期（坑 1）；下载先选对格式（坑 2）；cross refs 当线索不当等价（坑 5）。这三条守住，DO 就是最好用的疾病词表；守不住，它就是最容易用错的知识资源。

FAQ 常见问题三十二问

FAQ 组 A·身份与规模

Q1：DO 是数据库还是数据集？
是本体（ontology）——介于两者之间的知识资源：像数据集一样有文件可下载（五件套，§2），像数据库一样有查询服务（官网 SPARQL/API），内容是概念与关系而非记录行。

Q2：DO 和 DOID 是什么关系？
DO 是本体名（Human Disease Ontology 缩写），DOID 是其标识前缀（如 DOID:3093）。说「DOID 编号 3093」对，说「DOID 本体」不准确。

Q3：现在有多少个疾病类？
v2025-09-30 版 11,953 个（DOI 10.5281/zenodo.17238005）。这个数字随 Release 增长，引用必须带版本日期（坑 1）。

Q4：增长速度如何？
v2024-07-31（11,612）到 v2025-09-30（11,953）净增 1,793 个新术语；2012 创刊时 8,043 个，十三年增长约 48.6%。

Q5：有多少定义？
9,656 个类带结构化定义（80.8%），另有 12,739 条定义来源记录——两个口径不要混（坑 6）。

Q6：跨库链接有多少？
35,984 条 cross references（v2025-09-30），指向 OMIM、UMLS CUI、ICD 等外部词表；这些是链接不是等价断言（坑 5）。

FAQ 组 B·获取与许可

Q7：哪里下载最新版？
三个正门：PURL 直链 purl.obolibrary.org/obo/doid.owl（要最新）、GitHub Releases（要历史）、Zenodo（要 DOI 引用）。三入口同步同一套文件（§6）。

Q8：可以商用吗？
可以。CC0-1.0 是公有领域贡献声明：无署名要求、无相同方式共享约束、无商用限制（三证见 §6）。

Q9：需要注册或申请吗？
不需要。全部入口零注册直下——这是它与「请求制」「会员制」数据集的根本区别。

Q10：怎么引用单个疾病概念？
用 DOID PURL，如 purl.obolibrary.org/obo/DOID_3093（克罗恩病）；PURL 永久解析，版本由 PURL 层解耦。

Q11：怎么引用整个数据集？
论文场景引版本级 Zenodo DOI（如 v2025-09-30 为 10.5281/zenodo.17238005）加 NAR 2022 论文（doi:10.1093/nar/gkab1063）；泛指全库才用仓库级概念 DOI 10.5281/zenodo.10030383（坑 7）。

Q12：文件多大？
v2025-09-30 版 Zenodo 存档 ZIP 84.0MB（含 imports 与完整注解）；单拿 doid.owl/doid.obo 主干文件体积小得多。

FAQ 组 C·内容与结构

Q13：本体是单根树吗？
是——从根部 disease 节点经 SubClassOf 逐层下分的层级树（22,137 条层级公理），按解剖部位与病理过程组织。

Q14：内容从哪来？
融合再组织：OMIM（>1,000 亚型收编）、UMLS CUIs、ICD 映射、领域文献；15 个上游本体以 imports 接入（§4/§8）。

Q15：同义词怎么组织？
每类携带同义词组并分类型（精确、宽泛、相关、缩写，OBO 惯例），NER 归一化时可按类型调召回-精度（§5）。

Q16：定义有来源吗？
有——12,739 条 definition sources 让定义可回溯文献或权威词表（2022 版治理重点，§5）。

Q17：证据类型怎么标？
用 ECO 框架，本版接入 11 个新增 ECO 类型，可机器区分文献实证与计算推断。

Q18：罕见病覆盖如何？
覆盖持续扩充：OMIM 亚型大量收编，Orphanet 资源对接；无定义节点集中在极罕见与新增条目（§7 维度二）。

Q19：SARS-CoV-2 分支是什么？
COVID-19 期间快速扩充的新发传染病子树，DOID:0080599（COVID-19）为锚点，AGR 等数据库以此为标注挂点（§2/§8）。

FAQ 组 D·NLP 与数据治理用法

Q20：能直接当 NER 训练语料吗？
不能——它没有文本。它的角色是归一化目标词典：NER 抽出提及后映射到 DOID（§5 用法一）。

Q21：哪些库内语料能和它对接？
ncbi-disease(425)、bc5cdr(415)、medmentions(390) 的疾病标签空间与 DO/MeSH/OMIM 族同源，归一化评测可直接对接（§9）。

Q22：怎么用层级做统计？
挂在中间节点的标注可沿 SubClassOf 向上泛化、向下细化——这是树形本体对平面词表的核心优势（§5 用法二）。

Q23：做疾病富集分析用什么工具？
FunDO、GeneAnswers 等以内建 DO 词表执行基因列表的疾病富集，逻辑与 GO 富集同构（§5 用法三）。

Q24：能拿来做死因统计吗？
不建议——死因统计是 ICD 的统计本位主场；DO 是疾病本位，两者经映射层桥接（§7 边界与 §9 GBD 条目）。

Q25：数据治理上最值得学的是什么？
三件套组合：CC0 许可（零门槛采用）+ 永久标识（PURL/DOID）+ 版本化发布（逐版 DOI）——三者齐备的知识资源极少（§6）。

Q26：跨版本 diff 要注意什么？
2025 年起管线切换 ROBOT 1.9.10（已宣布口径），跨版本差异先排除管线噪音再谈内容变化（坑 4）。

FAQ 组 E·生态与替代品

Q27：DO 和 MONDO 选哪个？
要保留源词表细节与精细层级用 DO；要跨本体合并后的最大覆盖用 MONDO(748)——两者是互补而非互斥（§9）。

Q28：DO 和 SNOMED CT 选哪个？
开放科学、出版、商用分发选 DO（CC0）；临床系统落地（尤其收费/电子病历场景）用 SNOMED CT(557)（商业授权，各国许可）。

Q29：DO 和 HPO 什么关系？
HPO(747) 管表型异常、DO 管疾病实体——「症状侧 vs 病名侧」的姊妹本体，经 OMIM 类疾病-表型关联间接对接。

Q30：UMLS 里已经有疾病概念了，为什么还要 DO？
UMLS(558) 是索引器与许可受限的超集；DO 提供免费、单根、可整体再分发的疾病层级——UMLS CUI 与 DOID 经 cross refs 互通而非互斥。

Q31：OMIM 为什么不自己干这件事？
OMIM(159) 按孟德尔遗传条目组织（表型-基因型目录本位），DO 按疾病本位重组并开放许可——分工不同，OMIM 反而是 DO 的最大上游（§4）。

Q32：这个本体过时了吗？
没有——v2025-09-30 仍在稳定发布，2022 后工作重心转向社区协作与质量治理；关注 GitHub Release 动态即可跟踪最新（§3）。

深度专题 A·走一遍这棵树：层级怎么用

对没用过本体的人，「疾病分类树」是抽象的。这一讲带读者从根走到叶，走通一条真实路径——走通一次，层级的价值就不用再解释了。

第一站：根。整棵树的根部是一个类：disease（疾病）。所有 11,953 个疾病类都是它的后代（22,137 条 SubClassOf 公理保证连通）。单根设计（坑外知识点：DO 历史上曾有多根结构，2022 版治理强化单根一致性）意味着任何一个疾病类的最泛化归口都是 disease——统计「疾病总量」时不会漏分支。

第二站：顶层大类。从根向下第一层，DO 按疾病的本源特征划出若干顶层分支：按解剖部位定位的（如解剖部位疾病）、按病因定位的（如感染性疾病）、按机制定位的（如细胞增殖异常）、按临床形态定位的（如综合征）等（确切顶层类目以官方浏览器实时展示为准——顶层结构随版本演进微调，本文不固化类名清单以避免漂移）。这一站的设计哲学：一个疾病可以从多个维度归类，DO 选一个主维度入树，其余维度靠分支交叉与外部映射补足——这与 ICD 按报表需求、OMIM 按遗传条目组织形成方法论对照。

第三站：系统级分支。继续向下，进入「消化系统疾病」这类解剖系统分支。从这里开始，类目与临床科室的直觉开始对齐——消化科、心内科、呼吸科各自能在树上找到自己的领地。系统分支是富集分析最常见的解释层：基因列表富集到「消化系统疾病」比富集到具体病名更能给湿实验同事传达全景。

第四站：病种。再下一层是病种节点——克罗恩病（DOID:3093）就住在这里。每个病种节点携带：首选标签（Crohn disease）、同义词组（含「克罗恩病」「regional enteritis」等历史叫法与译名）、定义（带 definition source）、cross references（挂向 OMIM 条目与 UMLS CUI 等）。NER 归一化的终点通常就是这一层：文本里的「克罗恩病」「CD」「末端回肠炎」三种写法最终都映射到 DOID:3093。

第五站：亚型。病种之下还有亚型层——克罗恩病下可再分部位亚型；OMIM 收编的 >1,000 个遗传亚型条目多在这一层。亚型层是 DO 粒度优势所在：平面词表到病种就停了，树还能继续向下——但注意越往下定义覆盖率越低（近两成无定义节点集中在深层的极罕见与新增条目，§7 维度二）。

层级的三种用法（都在这趟旅程里）：

1. 向上泛化：挂在 DOID:3093 上的标注，沿 SubClassOf 上溯可计入「炎症性肠病」「消化系统疾病」的统计——一次挂接，全链可用。
2. 向下细化：富集分析发现「消化系统疾病」信号后，沿树下钻找具体病种，定位候选机制。
3. 兄弟比较：同一父节点的子类天然可比——「克罗恩病 vs 溃疡性结肠炎」的文献量对比、基因集对比，共享同一个比较基准。

深度专题 B·三向映射实战：DOID 与 OMIM/ICD/UMLS 的对齐工作流

cross references（35,984 条）是 DO 的「翻译中枢」功能载体。这一讲拆解三个方向的映射各难在哪、怎么干。

方向一：DOID → OMIM（基因研究场景）。典型需求：拿到一列 DOID 疾病，找对应的 OMIM 条目去查基因。DO 的做法是把 OMIM 亚型直接收编进树（>1,000 个亚型条目），因此很多 OMIM 对应关系内联在树上——病种节点直接带亚型子节点，各亚型节点带 OMIM cross ref。工作流：病种节点 → 遍历子树亚型 → 逐亚型读 OMIM cross ref → 汇总 OMIM ID 列表。粒度坑：一个 OMIM 条目可能同时描述「病种 + 亚型」（如同一编号下既有表型描述又有亚型细分），映射时以 DO 节点的粒度为准，不要假设一一对应（坑 5 的展开）。

方向二：DOID → ICD（临床统计场景）。典型需求：把研究用的 DOID 口径落到 ICD 编码做院内统计。DO 与 ICD 的映射经过 UMLS 中转更稳（UMLS 统一维护 CUI 对齐），直接 cross ref 的 ICD 链接存在但覆盖不全。粒度坑最大：ICD 的类目按统计本位切分（§7 边界），一个 DOID 节点可能对应多个 ICD 码、一个 ICD 码也可能被多个 DOID 共享。高风险场景（计费、死因上报）必须逐条人工核验，不可自动批量翻译。

方向三：DOID ↔ UMLS（数据整合场景）。典型需求：两个不同来源的数据集各用一套疾病词表，要合并。UMLS CUI 是现成的公共枢纽：两边的疾病概念各自对齐到 CUI，再经 DO 的 CUI cross ref 归到 DOID——「各自对齐 DO 即可互通」的翻译中枢逻辑就在这里跑通。注意 UMLS 本身许可受限（库内 umls(558) 条目有详情），商业场景要先过 UMLS 的许可关，这是 DO 的 CC0 救不了的一环。

映射质量的自检三问：这条 cross ref 的粒度对吗（病种对亚型？）；它是最新的吗（DO 与外部词表都在演进）；它的方向语义对吗（「 narrower/broader/related」在 OBO 语境下有类型区分，不是全部等价于「same as」）。三问过不了，就回到人工核验。

深度专题 C·疾病 NER 归一化工作流：从文本到 DOID 的五步

这一讲给 NLP 工程师一条可落地的流水线，从 bc5cdr(415)/medmentions(390) 这类语料的对接视角写。

第一步：构建词典。从 doid.obo 提取（类，同义词组）对：每个疾病类的首选标签与全部同义词（含缩写、历史叫法）各成一个词条，词条指向 DOID。OBO 平文本格式让这一步可以用脚本直接跑（坑 2 提示：别拿 doid.owl 干这个）。同义词类型（精确/宽泛/相关/缩写）要保留——归一化阶段按类型加权。

第二步：候选召回。文本提及（NER 已抽出 span）在词典上查候选：精确匹配、缩写匹配、模糊匹配各给一路召回。DO 同义词组的「精确/缩写」两路通常覆盖绝大多数命中；「相关」型同义词召回进来但降权。

第三步：消歧。同一提法可能命中多个 DOID 候选（缩写歧义尤其多）。消歧信号按优先级：上下文层级信号（附近文本的解剖/病因提示）、提及频次先验（文献中高频病种优先）、层级约束（已知上游疾病类时限定子树内消歧）。

第四步：层级校验。归一化结果做层级合理性检查：结果节点是否有定义（80.8% 有，没有的检查是否深层亚型）；结果节点与语料标签空间的粒度约定是否一致——bc5cdr 的疾病标注粒度与 DO 病种层对齐良好，medmentions 的疾病类型实例粒度更碎，两者归一化策略应分别设定（§9）。

第五步：版本锁定与报告。输出 DOID 列表时锁定版本（v2025-09-30 / DOI 10.5281/zenodo.17238005）——不然三个月后复现实验时词典变了，结果不可比（坑 1 的 NLP 版本）。评测报告里同时给「未归一化率」与「多候选率」，两个指标比单一准确率更能暴露词典覆盖问题。

与库内语料的对接提示：ncbi-disease(425) 的概念标注层历史上以 MedGen/OMIM/Mesh 口径给出，经 UMLS CUI 可桥接到 DOID；bc5cdr(415) 与 medmentions(390) 的标签空间属 DO/Mesh/OMIM 族。三套语料 + DO 词典可以搭出「同词表族内」的归一化评测台——标签对齐工作量可控，这是选 DO 族而不是另起炉灶的核心理由。

深度专题 D·富集分析工作流：基因列表问「得了什么病」

湿实验合作者最常遇到的请求：测完一组基因，问「这堆基因和什么病有关」。DO 是标准答案之一。

原理：与 GO 富集同构——把基因列表映射到疾病关联（经 AGR、MGI 等数据库的基因-疾病标注，挂在 DO 节点上），统计目标列表在 DO 节点上的分布与背景分布的偏离，超几何/Fisher 检验给出显著性，多重检验校正出排名。

操作流：基因列表（ID 先统一）→ 经标注数据库映射到 DO 节点 → 沿 SubClassOf 把每个节点的信号向上聚合（层级聚合是 DO 富集区别于平面词表的核心优势：深层零散信号在中间层聚合成可读结论）→ 显著性检验与校正 → 输出带层级的疾病排名。

工具：FunDO（网页式，适合快速看一眼）、GeneAnswers（R/Bioconductor，适合批量与自定义背景）。两工具均以内建 DO 词表运行（事实清单第 32 条）。

解读三条：富集结果的解释层级选中间层（顶层太泛、亚型太碎）；跨分支的信号要分开报告（同时富集到感染性疾病与细胞增殖异常通常意味着两回事）；所有结论挂版本号——DO 词典与标注库都在演进（坑 1 通用条款）。

深度专题 E·数据治理三件套拆解：DO 作为 CC0 教科书

对做数据治理的团队，DO 的价值不止是词表本身，更是一套可复制的「知识资源运营范式」。三件套拆解：

件一：许可（CC0）。为什么 CC0 而不是 CC BY？对知识基础设施而言，CC0 把「署名义务」从法律要求降为社区礼仪——下游不必维护出处链条即可合法再分发，这对编译型产品（聚合器、词典合并、模型词表内嵌）是决定性的便利。代价是本体方放弃追索能力，靠的是 NHGRI 资助这类制度性供养而非许可回报——这是公共资金的正确用法之一。对照：库内 iqvia-disease-analyzer(510) 的商业词表走的是另一条路（许可收入供养维护），两条路各有适用场景（§9 第一组）。

件二：标识（DOID + PURL）。永久标识的要害不是「编号唯一」（谁都做得到）而是「解析永续」——PURL 服务保证十年前的文献里写的 purl.obolibrary.org/obo/DOID_3093 今天依然能解析到正确概念，即便本体搬了家、换了托管。数字编号（DOID:数字）比语义字符串（如 disease-00003093）稳：语义会变，数字不会。给每个疾病概念发身份证并承诺永续解析，这一承诺的维持成本（PURL 基础设施）远低于它节省的全行业链接修复成本。

件三：版本（Release + DOI）。三个可核验的运营细节：逐版发布带更新注记（Release 页可读每版改了什么）；逐版存档带独立 DOI（Zenodo，可精确引用）；仓库托管在 GitHub（公开展示每次提交，含社区 PR 入口）。三细节合起来回答了知识资源的复现性难题：任何历史时点的本体内容都可被精确还原。坑 4 的管线切换与坑 7 的双层 DOI 是这套体系仅有的两个使用注意点。

给治理团队的迁移清单：若要把这套范式搬到自有知识资源上，最小可行集是——CC0 或最宽松可行许可、数字 ID + PURL 类解析服务、GitHub Release + Zenodo 逐版 DOI。DO 证明这套组合在医学领域十五年可行。

常见误解澄清十二条

误解 1：「DO 是一个数据库，像 MySQL 那样可以查病例。」
错。DO 是本体——概念、层级、定义与映射，零病例、零文本原文。它的「数据」是知识结构本身。

误解 2：「DOID 是本体的名字。」
错。本体名是 Human Disease Ontology（缩写 DO）；DOID 是标识前缀体系。正确说法：「DO 的 DOID 编号」。

误解 3：「11,953 是 DO 的疾病数量，以后也都是。」
错。这是 v2025-09-30 版的瞬时值，随 Release 增长。引用必须带版本日期（坑 1）。

误解 4：「CC0 意味着不用署名，所以引用 DO 论文也可以省了。」
错上加错。法律上无署名义务，但学术规范上引数据必须引出处（NAR 论文 + 版本 DOI）——否则审稿直接挂。

误解 5：「cross references 等于说两个概念完全等同。」
错。cross refs 是对齐线索，粒度与方向语义各异；高风险场景逐条核验（坑 5）。

误解 6：「DO 能替代 ICD 做死因统计。」
错。层级本位不同：DO 疾病本位、ICD 统计本位；死因统计请走 ICD（§7 边界）。

误解 7：「DO 是 SNOMED CT 的免费版。」
错。覆盖面与设计目标不同：SNOMED 覆盖临床操作全栈（症状、操作、药品、标本……），DO 专注疾病语义整合。互补不互替。

误解 8：「定义覆盖率 80.8% 意味着两成本体是空的。」
错。无定义的类依然有标签、层级、同义词与 cross refs——缺的只是正式定义文本。对定义敏感的应用才需要筛子集。

误解 9：「MONDO 出来后 DO 就该淘汰了。」
错。MONDO 的构建管线以 DO 为上游输入；「合并派」离不开「精细树派」的源质量。两者互补分工（§9）。

误解 10：「从第三方镜像拿的计数和官方一致。」
未必。镜像同步有延迟，出数字以 GitHub Release / Zenodo 为准（坑 8）。

误解 11：「下载 doid.obo 就拿到了完整本体。」
不完整。doid.obo 不含 15 个 imports 的内容；完整闭包图分析要 doid-merged.obo（坑 2）。

误解 12：「DO 十五年没大更新，是个老古董。」
恰恰相反：v2025-09-30 相对 v2024-07-31 净增 1,793 新术语；2022 后工作重心转向治理与社区协作；2025 年还在切发布管线。持续演进中（§3）。

FAQ 续编·二十四问（组 F/G/H）

FAQ 组 F·版本与历史

Q33：DO 最早的定位是什么？
2012 创刊论文标题就是答案：disease semantic integration 的 backbone（语义整合骨干）——十六年未变的主线。

Q34：四个版本阶段的分水岭各是什么？
2012 立骨架；2015 扩罕见病亚型；2018 平台化与标注破百万；2022 治理与社区协作（imports/定义来源/ECO）。详见 §3。

Q35：为什么 2018 论文的卷期写 2019？
NAR 数据库专辑的惯例：在线发表 2018、专辑归属 2019 年卷（47 卷 D1 辑）。双口径并存，引用任一均可但别混写。

Q36：第 100 个 Release 有什么特别？
v2021-08-17 恰为第 100 个 Release，被 NAR 2022 论文作为里程碑引用；此时规模 10,862 terms、76% 定义覆盖。

Q37：2022 论文的审稿流程有档案吗？
有：Received 2021-09-22 / Accepted 2021-10-18 / 在线 2021-11-10——四周录用，数据库专辑的常规节奏。

Q38：ROBOT 切换会改变本体内容吗？
不会改内容，可能改产物细节（公理表达、序列化）。跨版本 diff 前先核对两个 Release 的管线版本（坑 4）。

Q39：旧版本还能拿到吗？
能——Zenodo 逐版存档 + GitHub Release 历史双保险，任何历史时点可精确还原（附录 E）。

Q40：更新频率怎么跟踪？
盯 GitHub 仓库的 Release 动态即可；按 2012-2021 的节奏估算年均约 4-5 个 Release。

FAQ 组 G·本体工程视角

Q41：DO 的层级是严格树吗？
是单根层级树（SubClassOf 构成），不是多继承有向无环图——单父链使向上聚合的语义无歧义。

Q42：为什么用数字编号而不是语义 ID？
数字永久不变、语义字符串会随概念认知漂移；DOID:3093 今天与二十年后指同一个概念，这是 PURL 永续解析的前提（专题 E 件二）。

Q43：同义词为什么分四种类型？
精确/宽泛/相关/缩写四型让下游能按场景调召回-精度：NER 词典用精确+缩写，检索扩展可放宽到相关型（§5）。

Q44：定义来源（definition sources）为什么重要？
没有来源的定义是「无主文本」，不可审、不可信、不可更新；12,739 条来源记录让每个定义可回溯（2022 版治理核心）。

Q45：ECO 证据类型对下游有什么用？
让「文献实证的关联」与「计算推断的关联」可被机器区分——做证据加权的下游（药物重定位、优先级排序）直接受益。

Q46：imports 机制解决了什么老问题？
把散落的外部引用（早期版本各自为政）收拢为 15 个标准化导入，使 DO 的外部依赖显式化、可版本化、可整体替换（2022 版「improved integration」的实指）。

Q47：新疾病条目怎么进树？
领域专家提案 → 本体编辑团队审核 → 入树发布；SARS-CoV-2 分支是这套流程的加速实战版（§5）。

Q48：想给 DO 提条目或报错怎么走？
GitHub 仓库的 issue 与 PR 是社区入口——这也是「仓库托管」相对「网站孤岛」的治理优势。

FAQ 组 H·边界与误区

Q49：DO 覆盖兽病吗？
不。Human Disease Ontology 专注人类疾病；模式生物的疾病表型经 MGI 等数据库与 DO 桥接，但本体本身是人类本位。

Q50：DO 有症状/体征节点吗？
不是重点。症状表型是 HPO(747) 的主场；DO 专注疾病实体，两本体经疾病-表型关联对接。

Q51：DO 有药品节点吗？
没有。药物是 ChEBI 等本体的事；DO 与药物本体的对接靠下游应用（如药物重定位项目）组合完成。

Q52：「 Disease Ontology」不带 Human 会检索到什么？
可能撞上动物疾病本体等他物；规范引用写全称 Human Disease Ontology（坑 3 第三重）。

Q53：DO 的中文版有吗？
本体文本以英文为官方语言；中文术语经同义词组与下游本地化项目补充，非官方层。本条目即中文世界的导航层之一。

Q54：能把 DO 直接导入 Neo4j 吗？
能——doid.owl（RDF/XML）经转换工具导入图数据库是常见管线；完整图分析记得用含 imports 的 merged 版（坑 2）。

Q55：DO 适合做疾病知识图谱的骨架吗？
适合——这正是它的本职：节点（疾病类）+ 层级（SubClassOf）+ 横向链接（cross refs）+ 语义配件（同义词/定义/证据）齐备（§8）。

Q56：这个条目没覆盖到的问题去哪问？
GitHub 仓库 issue（本体内容）、官网联系渠道（服务）、OBO Foundry 社区渠道（原则与生态）——三层支持网络。

版本深读·三个存档的并排对比

把 v2021-08-17、v2024-07-31、v2025-09-30 三个有硬数字存档的版本并排放，能看清 DO 的演进节奏：

观察项	v2021-08-17	v2024-07-31	v2025-09-30
疾病类数	10,862	11,612	11,953
定义覆盖	76%	79.9%	80.8%（9,656 个）
存档锚点	NAR 2022 论文表	Zenodo 13145656	Zenodo 17238005（ZIP 84.0MB）
阶段特征	治理后首个里程碑（第 100 个 Release）	定义工作持续还账期	净增 1,793 新术语的扩张期

三个版本、三年区间，类数增长约 10%（10,862→11,953）、定义覆盖升 4.8 个百分点（76%→80.8%）——扩张与还账并行是这一阶段的主题。对下游的实际含义：做长期研究时锁定版本号比追逐最新版更重要；引用 2021 版数字的旧论文与引用 2025 版的新论文并存且都对（坑 1 的历史容忍版）。

检索策略指南·四层查找法

第一层·官网检索（最直觉）：disease-ontology.org 的检索框输入疾病名或 DOID 号，直接跳概念页——查单个疾病的最快路径。

第二层·PURL 直达（最稳）：已知 DOID 号时拼 PURL 地址直取（purl.obolibrary.org/obo/DOID_3093 形式），不经过任何可能滞后的镜像（坑 8 的免疫版）。

第三层·镜像浏览（最全景观）：OLS/BioPortal 输入疾病名看跨本体命中（DO/MONDO/HPO 并列），适合「我想知道这个词在哪个本体里怎么放」的横向对比场景。

第四层·本地文件 grep（最硬核）：下载 doid.obo 后本地全文检索——批量查询、脚本化流程的唯一选择；grep 命中后按 stanza 读全节点（同义词/定义/cross refs 集中在一个块里）。

检索三忌：忌只搜「Disease Ontology」两词（撞名，坑 3）；忌把镜像计数写进论文（非官方口径）；忌在 SPA 检索框里贴 DOID 前缀全串（多数检索框只吃数字部分或标签）。

角色入门路线·五种人各该先读哪节

临床信息学工程师：§2 文件族 → §6 获取 → 专题 B 映射实战——你的核心需求是接入院内 ICD 体系，映射三问是保命符。

NLP 算法工程师：§5 用法一 → 专题 C 五步流水线 → §9 第二组语料对接——从 bc5cdr(415)/medmentions(390) 挑一个起步搭评测台。

生物信息分析师：§5 用法二/三 → 专题 D 富集工作流 → §0 读法三则——FunDO 先跑通，GeneAnswers 再批量。

本体工程师：§3 版本链 → 专题 E 治理三件套 → FAQ 组 G——抄作业就抄 DO 的许可/标识/版本三件套。

数据治理负责人：§6 许可三证 → 专题 E → §9 第一组许可光谱——CC0 意味着采购清单上可以少一项授权费。

深度专题 F·依赖治理：imports 机制与上游生态

一个本体不是孤岛。DO 的外部依赖管理是 2022 版治理的主战场，机制值得细看。

imports 是什么：把外部本体的相关片段（而非全文）显式导入并在本体头部声明依赖。DO 当前声明 15 个上游 imports——这 15 个依赖从「隐式假设」变成「显式契约」：版本可追、内容可查、替换可控。

为什么重要：本体工程的历史事故大多源于隐式依赖——某工具默默假定外部类的某个 ID 存在，外部一改，下游静默崩坏。imports 把这类事故从「运行时惊喜」变成「发布时可见」：DO 的每次 Release 都把 15 个依赖的当前状态一起打包，doid-merged.obo 直接合并依赖内容，下游拿到的永远是自洽快照。

ECO 接入是治理样板：证据类型标注采用 ECO（Evidence & Conclusion Ontology）框架，本版接入 11 个新增 ECO 类型。这不是简单引用——是让「断言的证据地位」成为本体的一等公民。做证据加权的下游（药物重定位、基因-疾病优先级排序）从此可以在查询层直接过滤证据类型，而不是读文本猜语气。

社区入口的治理意义：仓库托管在 GitHub 意味着依赖问题、内容纠错、条目提案都有公开通道（issue/PR）。十五年的持续维护靠的不是一个人扛，而是「PI 主导 + 编辑团队 + 领域专家社区 + OBO Foundry 规则」的四层结构（§4）。

给下游的依赖检查清单：用 DO 做长线项目时——锁定版本（版本级 DOI）；检查 imports 闭包（你的功能是否依赖某个 imports 的具体内容）；订阅仓库 Release 通知（依赖变更早知道）；把 merged 版与主干版分开测试（依赖噪音定位）。

深度专题 G·语义相似度：层级如何变成可计算的「病与病有多像」

DO 的树形结构让「两个病有多像」从修辞变成算术。方法通述（不含编造的实现细节）：

路径法：两疾病类在树上的路径长短决定相似度——同父的兄弟病种最近，跨分支的最远。简单、可解释，缺点是默认树上所有边等距（现实里「同一父节点」下的粒度并不均匀）。

信息量法：用标注统计给节点赋「信息量」（挂接标注越少的节点越特异、信息量越大），两节点的公共祖先中信息量最大者决定相似度。这是当前主流；前提是有大规模标注分布——DO 生态 >1.5M 标注元素正好供数。

下游应用三型：疾病聚类（把语义相近的疾病聚成模块，用于共病研究与文献挖掘去重）、基因功能推断（已知基因关联疾病 A，经疾病相似度外推到 A 的近邻疾病）、药物重定位（药物作用于疾病 A，A 的语义近邻成为候选适应症）。三型应用在文献中均以 DO 为常用疾病侧基础设施。

两条纪律：相似度分数只在同一本体版本内可比（树变了，距离就变了——坑 1 的度量版）；报告相似度结果时注明方法族与参数（路径法与信息量法的分数不可互比）。

深度专题 H·LLM 时代的疾病词表：DO 的三重新角色

（本专题为编辑部判读型内容：方法与场景为业界通行实践，DO 侧事实均带已存照锚点。）

角色一：幻觉抑制的落地锚点。大模型谈疾病时最危险的不是说错话，而是编造概念——「听起来很像真病的虚构病名」。把疾病断言锚定到 DOID 编号上（生成后校验：该编号存在、层级合理、定义匹配），虚构概念无处遁形。DO 的 11,953 个概念 + 80.8% 定义覆盖为此提供了校验字典。

角色二：RAG 的结构化检索层。医疗问答系统检索疾病知识时，「按向量相似度召回」之外增加「按 DO 层级召回」：命中病种节点时自动带上其父链与同义词组——上下文更有序，答案更稳。CC0 许可让词表可以直接进产品分发，无授权谈判成本（专题 E 件一在 LLM 场景的复利）。

角色三：NER 范式迁移后的常量。LLM 抽取实体成为新常态，但「抽取出来的提及映射到哪个概念体系」没有变——归一化目标的地位反而更突出：模型可以换，DOID 编号作为输出 ID 层保持稳定，评测与产品不随模型换代重做。这与库内 bc5cdr(415)/medmentions(390) 等语料的对接逻辑一脉相承（§5/专题 C）。

一条清醒剂：LLM 不是本体推理引擎——层级泛化（专题 A 三用法）、证据过滤（ECO）、版本化审计（Release/DOI）依然是结构化词表的独有能力。DO 与 LLM 是互补而非替代关系。

深度专题 I·已知局限清单：官方可见与本文可见的缺口

诚实的条目要有局限清单。以下缺口均有已存照锚点，无一是猜测：

1. 定义缺口：近两成疾病类（19.2%）暂无结构化定义，集中在深层的极罕见与新增条目（v2025-09-30 口径，9,656/11,953）。官方可见、逐版改善中（76%→79.9%→80.8%）。对定义敏感的应用需先筛子集。
2. cross ref 粒度不均：35,984 条链接的粒度与方向语义各异，非全量覆盖；高风险场景（计费、死因编码）必须人工核验（坑 5/专题 B）。
3. 管线切换过渡噪音：2025 年 ROBOT 1.9.10 切换（已宣布口径）可能造成跨版本产物的序列化差异，diff 需先排除管线噪音（坑 4）。
4. 镜像滞后：第三方镜像计数可能落后官方 Release，出数字以 GitHub/Zenodo 为准（坑 8）。
5. 深度教程相对薄：文档链以 NAR 论文 + GitHub README 为主， newcomers 需读论文才能理解治理细节（DAIMS D7 维度扣分项）。
6. 双口径并存的引用负担：2018 论文跨 2018/2019 卷期、Zenodo 双层 DOI、definitions 与 definition sources 两口径——对新手是真实的认知负担（坑 6/坑 7），本文用整套存照体系对冲。

局限的正确读法：这不是「DO 不好」，而是「知识基础设施的固有运维负担」。对照任何同类资源（OMIM 的许可限制、UMLS 的授权门槛、MONDO 的合并取舍），DO 的缺口清单已是最短一档。

深度专题 J·五词表全景对照：一张表看清疾病知识栈

维度	DO	MONDO	HPO	SNOMED CT	UMLS
组织本位	疾病（解剖/病理）	跨本体合并疾病	表型异常	临床全栈操作	词表超集索引
许可	CC0-1.0	开放（OBO 系）	开放	商业授权（各国许可）	授权获取（许可受限）
规模量级	11,953 类（v2025-09-30）	合并多源后的全集	表型条目量级不同	十万级概念	百万级概念汇总
粒度特色	OMIM 亚型级（>1,000 收编）	最大覆盖合并	症状级极细	操作/流程级	索引层无自有粒度
与 DO 关系	—	以 DO 为上游输入	疾病-表型姊妹对接	经 UMLS 间接对齐	CUI 互为映射枢纽
库内条目	本条目	mondo(748)	hpo(747)	snomed-ct(557)	umls(558)

选型速记：开放科学与出版——DO；最大覆盖合并视图——MONDO；症状表型侧——HPO；院内临床系统落地——SNOMED CT；跨词表桥接——UMLS（先过许可）。五个槽位各就各位，没有全能选手，也别让 DO 去打 ICD 的统计本位主场（§7 边界）。

场景速查表·十二个高频场景的对口方案

场景	对口资源	入口	关键注意
查单个疾病概念	官网检索	disease-ontology.org	吃标签或 DOID 数字
批量下载全量本体	PURL/GitHub/Zenodo	§6 五入口	先选对格式（坑 2）
论文引用数据版本	Zenodo 版本级 DOI	10.5281/zenodo.17238005（v2025-09-30）	别用概念级 DOI 锁版本（坑 7）
疾病 NER 归一化	DO 词典 + 库内语料	专题 C 五步	锁版本、报未归一化率
疾病富集分析	FunDO/GeneAnswers	§5 用法三	解释层选中间层
基因-疾病标注查询	AGR/MGI 挂接	§5 用法二	层级聚合用 SubClassOf
DOID↔OMIM 找基因	树上内联 cross refs	专题 B 方向一	亚型粒度逐一核
DOID→ICD 院内落地	UMLS 中转 + cross refs	专题 B 方向二	高风险逐条人工核验
跨源数据合并	UMLS CUI 枢纽	专题 B 方向三	UMLS 许可先过关
疾病语义相似度	树结构 + 标注分布	专题 G	同版本内比较
LLM 落地锚定	DOID 校验字典	专题 H	CC0 可进产品分发
引用单概念	PURL	purl.obolibrary.org/obo/DOID_3093	地址永续、版本解耦

DO 时间线总表·十六年十一事

年份	事件	锚点
2012	创刊论文发表；8,043 术语；DOID/PURL/OBO 形态确立	PMID 22080554
2015	第二篇更新论文；罕见病与亚型扩展	PMID 25348409
2018	第三篇更新论文（在线）；平台化转向	PMID 30407550
2018 前后	标注挂接量突破 150 万（>1.5M 口径确立）	NAR 2018/2022 论文
2020-2021	SARS-CoV-2 分支快速扩充；DOID:0080599 成为 AGR 专题锚点	NAR 2022 论文
2021-08-17	第 100 个 Release：10,862 terms / 76% 定义	NAR 2022 论文表
2021-09-22	2022 论文收稿	论文 Editorial History
2021-10-18	2022 论文录用	同上
2021-11-10	2022 论文在线发表	同上
2022	第四篇更新论文（专辑卷 2022;50(D1)）；imports/定义来源/ECO 治理	PMID 34755882
2024-2025	v2024-07-31（11,612/79.9%）→ v2025-09-30（11,953/80.8%，净增 1,793）；2025 宣布 ROBOT 1.9.10 管线切换	Zenodo 13145656 / 17238005 / GitHub 公告

FAQ 再续编·二十八问（组 I/J/K）

FAQ 组 I·数据口径与统计

Q57：84.0MB 的 ZIP 里都有什么？
v2025-09-30 的 Zenodo 存档包：本体文件族（五件套）+ 存档说明。体量主要来自 imports 合并与全量注解（同义词/定义/cross refs 全内联）。

Q58：疾病类数是怎么数的？
数本体中疾病类节点的总数（owl:Class / [Term] stanza 计数），官方在各 Release 与论文中给出口径；第三方再统计请声明所用文件与版本（坑 8）。

Q59：定义覆盖率 80.8% 的分母是什么？
v2025-09-30 的 11,953 个类。注意 76%/79.9%/80.8% 三值的分母各是当年类数——跨版比较只比比值，不混分母（坑 6）。

Q60：annotation elements（标注元素）指什么？
下游生态挂在 DO 节点上的标注断言总量（基因-疾病关联等），>1.5M 是 2018 确立、2022 延续的生态口径，不是本体文件内部的公理数。

Q61：22,137 条 SubClassOf 会不会有环？
OBO Foundry 本体要求无环有向（单根层级树）；环检出属于发布质检项，正式 Release 无环。

Q62：35,984 条 cross refs 里哪个词表最多？
官方未在本文引用的材料中给出分词表分布表；OMIM/UMLS/ICD 是已声明的三大对应对象（§2）。需要分布数据请对文件做逐条统计并声明版本。

Q63：同义词平均每类几个？
官方材料未给平均值；实际分布请对所用版本的同义词 stanza 做统计——自己数，别引用无版本出处的二手均值。

Q64：SARS-CoV-2 分支有多少节点？
本文引用材料未给节点数，只确认分支存在与 AGR 锚点（DOID:0080599）；确切计数以当前版本文件内分支子树统计为准。

Q65：为什么文件这么大？
OWL/RDF/XML 冗长 + imports 合并 + 全量注解内联；只要主干、不要 merged 与注解的场景，取 doid.obo 即可小很多（坑 2）。

Q66：哪里能看到每个 Release 改了什么？
GitHub Release 页的更新注记 + Zenodo 各版本存档说明——两处都可逐版回看。

FAQ 组 J·互操作实操

Q67：怎么把 DO 转成 CSV？
doid.obo 按 stanza 解析（脚本十行级工作量）导出「DOID/标签/父节点/定义/同义词」表；别直接转 RDF/XML（坑 2）。

Q68：怎么抽取一个子树（比如某系统全部疾病）？
先在树上定位该系统分支的根节点，再遍历其子树闭包——用 merged 版本保证依赖内容在场；图库场景用 SPARQL 更直接。

Q69：怎么和 OMIM 条目精确对上？
走树上内联的 cross refs（专题 B 方向一）；亚型粒度条目逐一核验，不假设一一对应。

Q70：怎么挂自己的疾病标注到 DO 节点？
归一化（专题 C）得到 DOID 后，标注直接以 DOID 为外键存储；后续统计用 SubClassOf 上溯聚合（专题 A 用法一）。

Q71：怎么处理「一个病有多个 DOID 候选」？
消歧三信号（上下文/频次先验/层级约束，专题 C 第三步）；仍悬而未决的标注「多候选」并进人工队列，不硬选。

Q72：Neo4j 导入后查询变慢怎么办？
检查是否导入了不必要的注解字段与 imports 全量；主干图（类 + SubClassOf + cross refs）通常够用，注解按需挂载。

Q73：SPARQL 端点能替代本地部署吗？
探索性查询可以；生产负载建议本地部署（官网端点无 SLA 承诺，且跨网络延迟不可控）。

Q74：怎么让 DO 与自研词表共存？
自研词表概念补 cross ref 指向 DOID（而不是改 DO）；把 DO 当「疾病概念层」、自研当「业务层」分层存储（§8 生态位逻辑）。

Q75：版本升级时标注要重跑吗？
DOID 永久不变，旧标注天然兼容新版本；但层级聚合与相似度结果会随树变化——聚合报表类产物建议随 Release 重算并双版本并存对照（坑 1）。

Q76：怎么自动跟踪 DO 更新？
订阅 GitHub Release 通知 + 定期拉 Zenodo 最新存档 diff；变更敏感管线把 diff 检查写进 CI（坑 4 的管线噪音先排除）。

FAQ 组 K·贡献、社区与供养

Q77：谁能给 DO 提新条目？
任何人——GitHub 仓库的 issue/PR 是公开入口；领域专家提案 + 本体编辑团队审核入库（§5 末）。

Q78：DO 的维护团队有多大？
以 Lynn Marie Schriml 为 PI 的马里兰大学 IGS 团队（2022 论文 15 位作者）；社区贡献者不在此列（§4）。

Q79：资金从哪来？
NHGRI 资助（论文基金栏）——公共资金供养公共基础设施的模式（专题 E 件一）。

Q80：为什么它十五年不收费？
CC0 许可 + 制度性供养的组合使其无需许可收入；这也是「知识基础设施」与「商业词表」的分野（§9 第一组光谱）。

Q81：发现某个定义有错怎么报？
GitHub issue，附 DOID 号与文献出处——定义来源体系（12,739 条）让纠错有据可循。

Q82：引用 DO 时致谢怎么写最规范？
引 NAR 论文（doi:10.1093/nar/gkab1063 或对应年份篇）+ 版本 DOI；致谢本体团队与资助方（NHGRI）是社区惯例（法律上非义务）。

Q83：MONDO 团队和 DO 团队是什么关系？
社区协作关系：MONDO 以 DO 为上游输入，2022 论文标题的「greater collaboration」即包含此类工程间协作机制（§4）。

Q84：OBO Foundry 在其中扮演什么角色？
规则制定者与生态协调者：CC0/单根/PURL/版本化原则由其维护，DO 是合规登记本体（obofoundry.org/ontology/doid.html）。

硬数字一屏卡·写作引用速查

数字	含义	版本/口径	出处锚点
8,043	创刊疾病术语数	2012	PMID 22080554
10,862 / 76%	第 100 个 Release 规模/定义率	v2021-08-17	NAR 2022 论文表
11,612 / 79.9%	版本规模/定义率	v2024-07-31	DOI 10.5281/zenodo.13145656
11,953 / 80.8%	版本规模/定义率（9,656 个带定义）	v2025-09-30	DOI 10.5281/zenodo.17238005
1,793	两版间净增新术语	2024-07→2025-09	Zenodo 17238005 注记
22,137	SubClassOf 层级公理	v2025-09-30	Zenodo 17238005
35,984	cross references	v2025-09-30	Zenodo 17238005
12,739	definition sources	2022 治理口径	PMID 34755882
15	上游 imports 数	2022 口径	PMID 34755882
11	新增 ECO 类型	2022 口径	PMID 34755882
>1.5M	生态标注元素	2018 确立	PMID 30407550
>50	引用 DO 的应用本体	2018/2022 口径	PMID 30407550/34755882
>1,000	收编 OMIM 亚型	2018/2022 口径	同上
84.0MB	存档 ZIP 体量	v2025-09-30	Zenodo 17238005
100	第 100 个 Release 里程碑	v2021-08-17	NAR 2022 论文
~363	2022 论文 Scholar 引用	2026-10 快照	Google Scholar
15	2022 论文署名作者	—	论文署名页

排障清单·十个高频异常

异 1：下载的 doid.owl 打不开/解析失败。
先查下载完整性（Zenodo 文件校验和），再查工具兼容性（OWL 2 语法）；九成是拿错了文件或版本混搭。

异 2：本地 grep doid.obo 找不到某个疾病。
doid.obo 只有主干；该疾病可能在 imports 依赖里——换 merged 版再查；也可能同义词写法不在你的检索词里，换首选标签试。

异 3：归一化结果大量落在无定义节点。
正常——深层亚型定义覆盖率低；策略：上报到最近的有定义祖先并在输出里保留原始 DOID 双记录（专题 C 第四步）。

异 4：跨版本 diff 出现海量格式性差异。
先核对两版管线版本（2025 ROBOT 1.9.10 切换前后，坑 4）；排除序列化噪音后再看内容差异。

异 5：镜像上的类数和论文对不上。
镜像滞后（坑 8）；以 GitHub Release/Zenodo 为准，论文数字核对版本口径链（附录 A）。

异 6：PURL 解析失败。
PURL 服务偶发抖动或本地网络问题；重试或改走官网/GitHub 直链；长期方案是本地镜像（异 1 的文件）。

异 7：富集结果全是顶层大类，没法解读。
聚合层选错——顶层只做总量校验，解释层选中间层（专题 D 解读三条）；检查是否忘了层级聚合只上溯一层。

异 8：两个工具算的疾病相似度对不上。
先对版本（树不同则距离不同，坑 1 度量版），再对方法族（路径法 vs 信息量法分数不可互比，专题 G）。

异 9：UMLS 许可挡住了 CUI 枢纽方案。
商业场景先走 UMLS 授权流程；授权成本超预算时评估 MONDO 的合并视图替代方案（专题 J 选型速记）。

异 10：老管线读 HumanDO.obo 报错。
历史文件名与新发布节奏的兼容缝隙（坑 2）；迁移到 doid.obo/doid.owl 现行文件族是治本方案。

术语表补遗·十条

31. stanza：OBO 平文本中一个术语条目的块结构（[Term] 起头）；grep 命中后读整块。
32. 闭包（closure）：沿层级把传递关系展开所得的全集；merged 版本保证闭包分析不缺料。
33. 公共祖先（common ancestor）：两节点在树上共享的上级；信息量法相似度的核心构件。
34. 信息量（information content）：节点特异性度量（标注越少越特异）；语义相似度的主流权重。
35. 外键（foreign key）：下游数据表中指向 DOID 的引用列；「标注挂接」的工程形态。
36. grounding（落地锚定）：LLM 生成断言后校验其在权威词表中的存在与一致性；专题 H 角色一。
37. SLA（服务等级协议）：服务可用性的正式承诺；官网端点不提供，生产负载需自部署（Q73）。
38. 校验和（checksum）：文件完整性指纹；Zenodo 存档提供，下载后先验（异 1）。
39. CI（持续集成）：把版本 diff 检查写进自动流程；跟踪 DO 更新的工程化做法（Q76）。
40. 双记录（dual record）：归一化输出同时保留原始提及与标准 DOID 的做法；可回溯、可重算（异 3）。

深度专题 K·三个库内协同案例：把互链变成流水线

（案例为编辑部构建的方法示范：资源事实均带库内 rid 与已存照锚点，流程为业界通行做法。）

案例一·疾病 NER 归一化评测台（对接 ncbi-disease(425)、bc5cdr(415)、medmentions(390)）

目标：为归一化算法搭一个同词表族的评测台。

• 资源装配：DO 词典（专题 C 第一步构建）+ 三套语料的疾病提及子集；三语料标签空间同属 DO/MeSH/OMIM 族（§9 第二组），概念层对齐经 UMLS CUI 桥即可起步。
• 评测设计：三语料各出一档难度——ncbi-disease 的摘要级提及（标准难度）、bc5cdr 的疾病子任务（化学-疾病关系语境，干扰更强）、medmentions 的多类型语料（疾病与它类实体共现，消歧压力最大）。
• 度量约定：准确率之外必报「未归一化率」与「多候选率」（专题 C 第五步）；版本锁定 v2025-09-30（DOI 10.5281/zenodo.17238005）。
• 产出含义：同一套 DO 词典跑三个语料，差异直接暴露「语境复杂度对归一化的影响」——这比单语料刷分更有信息量。

案例二·基因列表疾病富集报告（对接 gene-ontology(441)、disgenet(449)、ctd(749)）

目标：给一组差异表达基因出一份带疾病解读的富集报告。

• 词表装配：DO 供疾病侧骨架；GO(441) 同场出功能侧富集——两侧报告并排，「功能异常 ↔ 疾病风险」互为佐证。
• 标注来源：基因-疾病关联取自 DisGeNET(449) 类资源；毒理-疾病关联可从 CTD(749) 类资源补位——不同来源的关联分别标注证据强弱再合并。
• 解读纪律：解释层选 DO 中间层（专题 D）；跨分支信号分开陈述；结论挂词典版本与标注库版本双版本号。
• 产出含义：富集报告从「一堆显著 p 值」升级为「沿疾病树可读的叙事」——层级的叙事价值全在这。

案例三·疾病词表采购对照（对接 iqvia-disease-analyzer(510)、snomed-ct(557)、umls(558)、omim(159)）

目标：为数据平台选型疾病词表层，写出许可与功能的对照底稿。

• 光谱定位：DO（CC0，零成本零约束）→ OMIM(159)（学术资源，再分发受限）→ UMLS(558)（授权获取，许可受限）→ SNOMED CT(557)（各国授权，商业场景成本可控但流程在）→ IQVIA(510)（商业词表，许可收入供养）——从严到宽一表排开（§9 第一组）。
• 决策锚点：开放科学/出版场景 DO 即可闭环；临床落地与计费场景 SNOMED/ICD 不可绕；跨源桥接 UMLS 先过授权。
• 组合策略：常见最优解是「DO 做开放层 + SNOMED/ICD 做院内层 + UMLS 做桥接层」三层并存，DO 的 CC0 让开放层可以无顾虑分发给全部合作方。
• 产出含义：许可光谱表直接进采购评审材料——词表选型的真实成本从来不只是钱，还有许可谈判周期。

深度专题 L·从一段文本到 DOID：叙事走查

（走查使用合成示例句，演示专题 C 五步流水线；示例与结果均为教学构造，非真实评测结果。）

示例句：「患者确诊克罗恩病，既往有 UC 病史。」

第一步·词典就绪：doid.obo 已解析为词典——「Crohn disease」类的词条含首选标签、译名「克罗恩病」、缩写 CD（缩写型同义词）；「ulcerative colitis」类含 UC 缩写词条。

第二步·召回：NER 抽出两个疾病 span（「克罗恩病」「UC」）。前者精确命中克罗恩病词条；UC 作为缩写型命中溃疡性结肠炎，同时按字面也可模糊命中其他 UC 开头词条——缩写路召回进多候选。

第三步·消歧：「UC」的候选里，溃疡性结肠炎（缩写型、疾病语境）显著强于其他字面候选；上下文「既往有……病史」进一步确认疾病语境。定谳：ulcerative colitis。

第四步·层级校验：两结果均有定义、同属消化系统疾病分支、互为炎症性肠病下的兄弟节点——层级合理性通过；「克罗恩病 + 溃疡性结肠炎」共现模式与两病共存的临床常识相容。

第五步·落库：输出对（提及 span，DOID）双记录，版本戳 v2025-09-30。后续统计中，两者可沿 SubClassOf 上溯聚合到「炎症性肠病」层做专题分析——树的红利此刻兑现。

五步走完，一段自由文本变成了两个带永久编号、带层级位置、带版本戳的结构化断言——这就是「AI-Ready」在一句话上的具象。

深度专题 M·分类学传统一瞥：DO 站在哪条知识脉络上

（通识层概述，聚焦与 DO 直接相关的三个传统，不做史实考据。）

传统一·医学分类的实用主义。从早期疾病清单到 ICD 的死因统计本位，医学分类传统以「报表可用」为第一目标——类目随报表需求切分。DO 不走这条线：它按疾病本身的解剖与病理特征组织（疾病本位），为的是让语义整合不迁就报表口径（§7 边界）。

传统二·遗传条目目录。OMIM 以孟德尔遗传条目组织疾病-基因知识，一条目一传承——粒度细但组织逻辑是「条目」而非「疾病类目」。DO 选择收编而非替代：>1,000 个 OMIM 亚型进树成为疾病类的补充层，OMIM 的基因信息经 cross refs 互链（§4）。

传统三·本体工程（OBO Foundry）。基因本体（GO）运动催生的现代本体方法论：受控词表 + 形式化关系 + 社区治理 + 开放许可。DO 是这套方法论在疾病域的落地样本——单根树、PURL、imports、CC0，件件都是 OBO 原则（§7 维度一）。GO(441) 与 DO 的「功能侧/疾病侧」分工正是这一传统的内部协作（§8）。

三个传统的交汇点就是 DO 的生态位：用本体工程的方法，把医学分类与遗传条目两种素材，重组成语义整合可用的疾病知识结构。

FAQ 决策篇·二十二问（组 L/M）

FAQ 组 L·选型与决策

Q85：我要发论文引疾病词表，选 DO 还是 MONDO？
看论点：用「精细层级+定义溯源」论证选 DO；用「最大覆盖合并」论证选 MONDO(748)。两者可并用并声明分工。

Q86：院内系统要疾病编码，DO 能顶上吗？
不能单独顶——计费与上报场景需 ICD/SNOMED 授权体系；DO 作为研究层与院内层桥接（经 UMLS/ICD 映射，专题 B）。

Q87：创业产品要内嵌疾病词表，有法律风险吗？
DO 层无风险（CC0 可商用可分发）；若叠加 UMLS/SNOMED/IQVIA 层则各按其许可走流程——分层存储可隔离风险（案例三）。

Q88：做罕见病研究，DO 够细吗？
亚型层够用（OMIM 亚型收编 >1,000）；但罕见病定义覆盖偏低（深层欠账集中区），关键结论前先查节点定义与 Orphanet 对照（§7/§9 orphanet-ordo(812)）。

Q89：做传染病监测，DO 和专门词表怎么选？
DO 有感染性疾病分支与 SARS-CoV-2 实战扩充；大规模监测报表仍建议 ICD 本位——DO 做语义整合层叠加其上（专题 M 传统一）。

Q90：模型评测要不要把 DO 版本写进论文？
必须写——版本号 + DOI（v2025-09-30 / 10.5281/zenodo.17238005 式）；不写版本的评测在审稿人眼里不可复现（坑 1）。

Q91：图谱项目选 DO 还是自建疾病词表？
先 DO 后自建：DO 铺骨架与互链，自研概念以 cross ref 挂进业务层（Q74）；完全自建等于放弃 35,984 条现成互链。

Q92：多语言项目怎么处理？
DO 官方文本英文；中文场景以 DOID 为键、译文挂业务层（Q53）；别改本体文件本身。

Q93：要不要等 DO 完成定义全覆盖再上项目？
不等——80.8% 已够主干场景；定义筛选器（有定义子集）+ 上报祖先策略（异 3）可覆盖缺口。

Q94：预算只能买一份商业许可，怎么配？
先确认业务闭环卡在哪：临床操作闭环买 SNOMED 授权；跨源桥接买 UMLS 授权；疾病开放层继续用免费的 DO——通常只需买一份（案例三）。

Q95：导师要求「用标准词表」，DO 算标准吗？
算——OBO Foundry 登记本体 + NAR 四篇论文背书 + 生态采用（>50 本体/>1.5M 标注）；「标准性」三件证据齐备（§7）。

Q96：做知识图谱竞赛/毕设，最小可行方案是什么？
doid.obo + 三十行解析脚本建「类-父-标签-同义词」四列表 + 任一库内 NER 语料做归一化评测——一周内可跑通（专题 C/案例一）。

FAQ 组 M·杂项快答

Q97：DO 读作什么？
「D-O」两个字母分开读；全文 Human Disease Ontology。

Q98：doid.obo 与 doid.owl 内容一样吗？
同一本体两种序列化；owl 带完整公理表达，obo 更平易；工程上按工具链选（坑 2）。

Q99：能离线用吗？
能——文件族下载即离线；官网服务才需要联网（§6）。

Q100：DO 有 RSS/更新订阅吗？
GitHub Release 的 watch 通知是最可靠订阅通道（Q66/Q76）。

Q101：引用本条目该怎么写？
本条目是二手导航：引用 DO 本体请走一手锚点（NAR 论文 + 版本 DOI）；本条目适合作为中文世界的阅读入口引用（附库内 slug disease-ontology）。

Q102：条目里的「编辑部判读」有哪些？
专题 H（LLM 角色）、专题 K（协同案例流程）、专题 G 的应用分型——均已就地标注；其余事实层内容全部带锚点（附录 F 存照汇总）。

Q103：发现条目与官方最新口径不一致怎么办？
以官方 Release 为准并视为版本漂移（坑 1 的自然现象）；欢迎通过库内渠道反馈修订。

Q104：DO 与疾病编码 ICD-10/11 的映射在哪拿？
DO 文件内 cross refs 与 UMLS 桥接是两条路（专题 B 方向二）；DO 官方不维护 ICD 全量映射表——这正是坑 5 反复强调「链接非等价」的原因。

Q105：能把 DO 给生成式模型当 system prompt 知识吗？
可以但别全文灌——11,953 类超上下文预算；实用做法是检索式挂载（RAG，专题 H 角色二）或子树注入。

Q106：为什么本条目这么长？
因为 DO 的易用性建立在「绕开七个认知坑」上（§10）；条目的任务就是把坑提前铺平——宁长勿坑。

十六条目对接矩阵·一表总览

库内条目	rid	关系性质	首选对接方式	深读位置
本条目 disease-ontology	—	—	—	—
ncbi-disease	425	下游消费·NER 语料	归一化目标词典	案例一
bc5cdr	415	下游消费·NER 语料	同词表族评测	案例一
medmentions	390	下游消费·NER 语料	多类型消歧评测	案例一
gene-ontology	441	同族·OBO 姊妹	功能/疾病双侧富集	案例二
disgenet	449	下游消费·关联库	富集标注来源	案例二
ctd	749	下游消费·关联库	毒理-疾病补位	案例二
mondo	748	同主题·合并本体	上游输入关系对照	专题 J
hpo	747	同族·表型姊妹	疾病-表型对接	专题 J
orphanet-ordo	812	同主题·罕见病本体	罕见病亚型对照	Q88
snomed-ct	557	同主题·临床词表	三层并存策略	案例三
umls	558	同主题·索引器	CUI 桥接枢纽	专题 B
omim	159	上游·最大素材源	亚型 cross refs	专题 B
iqvia-disease-analyzer	510	同主题·商业词表	许可光谱对照	案例三
global-burden-of-disease	97	场景·负担统计	经 ICD 映射层桥接	§7 边界
chronic-kidney-disease-uci	726	场景·单病种数据	DOID 概念锚点示例	§9 第三组

如果只有五分钟·极速版

1. 它是什么：OBO Foundry 的疾病本体——11,953 个疾病类（v2025-09-30）、单根层级树、35,984 条跨库链接，CC0 完全免费。
2. 立刻能用：PURL 下 doid.owl 或 doid.obo（想清楚用途再选，坑 2）；论文引用走版本级 DOI。
3. 三个数字：定义覆盖 80.8%；生态标注 >150 万；应用本体 >50 个。
4. 三条铁律：引用带版本日期（坑 1）；cross refs 当线索不当等价（坑 5）；出数字认 GitHub/Zenodo 不认镜像（坑 8）。
5. 下一步：做 NLP 读专题 C，做富集读专题 D，做选型读专题 J 与案例三。

编辑部口径声明

本文为千方病案医数集「AI-Ready Wikipedia」系列条目，写作时点 2026 年 10 月。方法口径：事实层全部锚定一手来源（NAR 四篇论文、GitHub 仓库、Zenodo 存档、OBO Foundry 登记页）并以「事实——出处」成对存照（36 条清单 + 附录 F 汇总）；判读层（专题 H/K 流程设计、方法分型）就地标注「编辑部判读」；DO 为持续演进资源，任何硬数字引用请随最新 Release 核对（坑 1 通用条款）。库内 rid 反查时点 2026-10-04（只读查询）；发布互链最终取舍由主会话定夺。本文与库内其他条目（§9 十六条目）互为导航层——词表本身的一手之门永远是 PURL、GitHub 与 Zenodo。

深度专题 N·一条好定义长什么样：定义的写作学

DO 的 9,656 条结构化定义（v2025-09-30）是本体的「正文」。一条合格的本体定义有三个结构要素——这也是判读任何本体定义质量的通用尺子：

要素一·属加种差（genus + differentia）。定义先说「这病是哪类病」（上位属，通常指向树上的父类），再说「它区别于兄弟类的特征」（种差）。例如把某病定义为「一种位于某解剖部位的感染性疾病，由某病原引起」——属（感染性疾病）锚定层级位置，种差（部位+病原）锚定边界。这个结构使定义与树天然一致：定义读出来的位置，就是 SubClassOf 摆放的位置。

要素二·来源可溯。定义后附 definition source（12,739 条记录的每一部分）——没有来源的定义在治理视角下是「无主文本」，不可审、不可信、不可更新（Q44）。DO 的定义来源体系让每条定义都能回溯到文献或权威词表，这是 2022 版治理的核心工程。

要素三·无环嵌套。定义不应只用同义词或子类循环解释（「A 是 A 类病」式的定义是废定义）。本体定义的理想状态是：只读定义 + 树，就能把概念从其他兄弟概念里切出来。

下游视角的定义用法：归一化消歧时定义是「语义裁判」（专题 C 第三步的层级约束再进一步就是定义匹配）；LLM grounding 时定义是「存在性+语义双校验」的凭据（专题 H 角色一）；报告写作时定义是引用疾病概念时的「官方释义」——比任何二手解释都站得住。

缺定义时的补偿序列：查同义词组语义（虽无定义但同义词有信息）→ 查父链位置（树的位置本身就是半个定义）→ 查 cross refs 指向的外部词表定义 → 上报到最近的有定义祖先（异 3 的双记录策略）。四步走完仍不够用，说明该节点需要的是社区提案（Q77）而非继续挖掘。

深度专题 O·同义词工程：NER 词典质量的决定因素

归一化词典的上限不在算法在同义词。DO 的同义词组（每类携带、分四类型）值得单独一讲。

四类型的工程含义：精确型（EXACT）进主词典，命中即高置信；缩写型（ABBREVIATION）进缩写特典，配合消歧（缩写歧义是疾病归一化第一大噪音源，专题 L 的 UC 案例）；宽泛型（BROAD）与相关型（RELATED）默认不进自动词典——它们召回的候选常是「沾边但不同病」，误归一化的重灾区。四类型从本体出发就替下游做了第一批召回-精度决策。

缩写陷阱清单：一词多病（同一缩写在不同科室指不同病）；大小写与全半角变体；带修饰的缩写（如「UC 后结肠炎」里的 UC 不是独立提及）；新缩写未入典（文献速造的缩写快于本体更新）。对策组合：缩写型同义词打头、上下文分类器殿后、未知缩写进人工队列——全自动链路对缩写永不可信。

同义词的时效维度：疾病叫法随医学叙事演进（疫情期新词、药企造词、指南改词）；DO 的 Release 节奏（年均 4-5 个）决定了词典需要随版更新——这把「词典老化」从玄学变成工程：锁定版本 + 订阅 Release + 定期换弹（Q76/Q100）。

与库内语料的粒度校准：bc5cdr(415) 的疾病标注粒度与 DO 病种层对齐良好，同义词主词典直接可用；medmentions(390) 的粒度更碎，需在亚型层增设「上卷规则」（碎粒度提及归到病种层评测）；ncbi-disease(425) 的概念层经 CUI 桥接后同样落回病种层（案例一）。同义词工程 + 粒度校准，是三个语料共用一套 DO 词典的前提。

深度专题 P·跨源连接实操：当疾病本位遇上统计本位

以库内 global-burden-of-disease(97) 为例，走一遍「疾病本位（DO）× 统计本位（GBD cause list/ICD）」的对接——这是 §7 边界一句的展开，也是本条目最有普遍意义的跨源案例。

为什么难：GBD 的病因列表（cause list）为负担统计服务——类目按「死因/伤残归因的可加性」切分，一个 GBD 病因可能聚合多个 DO 疾病类（统计粗粒度），也可能把一个 DO 类按并发症状态拆开（统计细粒度）。两个体系没有同构关系，任何「一键翻译」的期望都会落空（坑 5 的跨体系放大版）。

可行路径：以 ICD 为中间层——GBD 病因与 ICD 编码有公布的对齐，DO 与 ICD 经 cross refs/UMLS 桥接（专题 B 方向二）；两段对齐拼接出 DO↔GBD 的映射，每条映射标注拼接来源与置信级，进人工抽检队列。

粒度补偿规则：GBD 粗粒度聚合多个 DO 类时，DO 侧经 SubClassOf 上卷聚合（树的红利）；GBD 细粒度拆分时，DO 侧信号按亚型分布折算或保守合并并声明——两种方向的处理规则写进数据字典，不临场发挥。

验证仪式：选 10-20 个高频病因做全链路人工核验（DO 节点 → ICD 码 → GBD 病因 → 回读语义），通过率达标后才放行批量映射——跨体系对接的信任是抽检出来的，不是声明出来的。

方法迁移：这一套「中间层桥接 + 拼接来源标注 + 粒度双向补偿 + 抽检放行」四步，适用于一切「疾病本位 × 统计本位」对接（院内 ICD 报表对接同理）——本专题的普适价值高于 GBD 单例。

FAQ 进阶篇·十二问（组 N）

Q107：为什么 DO 坚持单根树而有些本体用多继承 DAG？
单根让「向上聚合」语义无歧义（Q41）；多继承的表达力收益抵不过统计歧义成本——疾病统计要的是无歧义归口。

Q108：树的位置会变吗？某病从 A 分支挪到 B 分支怎么办？
会随认知演进调整；DOID 编号不变是稳定锚，层级变化随 Release 公布——引用层级结论时同样要挂版本（坑 1 的层级版）。

Q109：cross refs 会不会两个都过时（DO 变了对方也变了）？
会——所以高风险映射的核验要记录「核验时点+双方版本」；映射是三方关系（DOID、外部 ID、时点），不是两方（专题 B 自检三问的延伸）。

Q110：定义里的信息会与层级冲突吗（定义说 X 类，树却放在 Y 下）？
治理目标是不冲突（要素一的结构一致性）；发现冲突即 issue（Q81）——定义-树一致性是本体质检的常规项。

Q111：为什么不用 LLM 直接生成定义补齐 19.2% 缺口？
定义需要来源与责任主体（要素二）；生成文本无主即无治理地位。LLM 可起草、专家审定、来源挂靠后才能进正典——流程成本在审定不在生成。

Q112：subClassOf 关系能携带附加语义吗（如「部分即全部」vs「是一种」）？
OBO 语境区分 is-a 与 part-of 等关系类型；DO 的疾病树主体用 is-a 语义——消费时按关系类型过滤，别把结构关系当一锅煮。

Q113：两个疾病类语义重叠但不合并，是缺陷吗？
是有意的边界保守：合并等价断言交给 MONDO 类整合层做，DO 保留源词表细节供精细引用（§9 第一组的分工哲学）。

Q114：怎么评估我的归一化系统对 DO 的覆盖率？
报三元组：命中 DOID 的提及占比、落在有定义节点的占比、多候选未决占比（专题 C 第五步）——三个数一起看，单一准确率会骗人。

Q115：DO 的编号空间会用完吗？
数字编号空间在工程上不构成约束；编号不连续、不复用、只增不减是治理承诺的一部分（专题 E 件二）。

Q116：能只取 DO 的一个分支放进产品吗？
能——子树抽取是常见做法（§5 用法四）；记得记录抽取版本与根节点，闭包完整性用 merged 版校验（Q68）。

Q117：DO 与 ICD-11 的对接前景如何？
ICD-11 的本体化程度高于 ICD-10，跨体系对接的结构性障碍在下降；但「统计本位 vs 疾病本位」的根差异仍在（专题 P 的方法不因版本升级而失效）。

Q118：下一个十年 DO 会怎样？
可核的事实是趋势线：规模持续增长（+1,793/年段）、定义率爬坡（76→80.8%）、治理深化（imports/ECO/协作机制）；具体路线以官方发布为准——条目不写科幻。

全文阅读地图·一图导航

frontmatter/INFOBOX —— 一屏速览
导语 + 读法三则 —— 三种角色入口
§0 导读 —— 问题与三层回答
§1 十问十答 —— 身份/规模/许可/下载/生态快答
§2 数据构成 —— 文件族五件套 + 树上八层内容
§3 时间线 —— 四篇 NAR + 版本口径链表
§4 机构人物 —— Schriml/IGS/NHGRI/OBO 协作结构
§5 任务标注 —— 四类用法 + 治理细节
§6 获取许可 —— CC0 三证 + 五入口 + 引用规范
§7 评估 —— 四维验法 + 本位边界
§8 生态 —— 上游/下游/镜像三层
§9 库内互链 —— 三组十六条目（rid 全带）
§10 避坑 —— 八条实战坑
§11 总结 —— 三层价值 + 三件要事
FAQ A-E —— 32 问基础篇
深度专题 A-E —— 走树/映射/NER/富集/治理
常见误解澄清 —— 12 条对照
FAQ F-H —— 24 问版本/工程/边界篇
深度专题 F-J —— 依赖/相似度/LLM/局限/五词表
场景速查表 + 时间线总表
FAQ I-K —— 28 问口径/互操作/社区篇
硬数字一屏卡 + 排障十条 + 术语补遗
深度专题 K-M —— 协同案例/叙事走查/分类传统
FAQ L-M —— 22 问决策/杂项篇
十六条目对接矩阵 + 五分钟极速版
深度专题 N-P —— 定义/同义词/跨源连接
FAQ N —— 12 问进阶篇
事实清单 36 条 —— 出处对照
术语表 40 条 —— 主表 30 + 补遗 10
附录 A-F —— 口径链/DAIMS/论文档案/编号示例/入口清单/存照
尾注 —— 来源与方法声明

致谢与边界

DO 是 Lynn Marie Schriml 团队与本体社区十五年的作品，CC0 献给公共领域；本文是这一资源的中文导航与解读，判读责任在编辑部不在本体方。若本文与官方口径冲突，以官方（GitHub/Zenodo/官网）为准；若官方材料与本文引用时点后发生变化，属版本演进的自然结果（坑 1 通用条款的最终免责式）。

深度专题 Q·五个镜像与索引层使用手册

第三方镜像不是官网的复制品，各自有独特的使用时机：

OLS（EMBL-EBI 的 Ontology Lookup Service）。定位：跨本体统一检索入口。用它做「一个词在哪些本体里出现」的横向扫描（DO/MONDO/HPO 并列比较，专题 J 的现场工具）；它按本体隔离浏览时也可看 DO 的层级树。使用时机：探索期、跨本体对照期。出数字不用它（坑 8）。

BioPortal（Stanford）。定位：本体托管与注释服务的门户。用它看 DO 与其他本体的自动化对齐建议（BioPortal 自带 cross-ontology 映射层）与社区注释；REST API 适合轻量集成原型。使用时机：原型期、映射灵感期。生产负载自部署。

OntoBee。定位：OBO 本体的 SPARQL 端点与 URI 解析展示。用它查某个 DOID 的原始 RDF 三元组与被引用情况；是「PURL 解析之后看到什么」的透明窗。使用时机：调试期、溯源期。

AberOWL。定位：基于推理的本体检索。用它做带逻辑过滤的查询（如「找出所有被定义为涉及某解剖过程的疾病类」）——这是浏览器做不到的推理式检索。使用时机：语义查询期、机制研究期。

Bioregistry。定位：学术标识前缀的公平注册表。用它确认 DOID 前缀的官方元数据与解析模式；给自家系统注册新前缀前先来这里查重。使用时机：标识治理期。

一条总纪律：五个镜像都读官方同步源（GitHub/Zenodo），同步延迟与展示口径各异——任何要写进论文的计数，一律回官方 Release 取数（坑 8 的镜像版总纲）。

引用正误对照·五组示例

组一·引数据版本

• 错：「使用 Human Disease Ontology（共 11,953 个疾病类）。」——无版本戳，半年后悬空（坑 1）。
• 对：「使用 Human Disease Ontology v2025-09-30（DOI 10.5281/zenodo.17238005），共 11,953 个疾病类。」

组二·引学术成果

• 错：「数据来自 Disease Ontology 论文。」——无篇目无 DOI，无法核。
• 对：「数据来自 Disease Ontology 2022 年更新论文（Nucleic Acids Res 50(D1):D1255-1261，doi:10.1093/nar/gkab1063，PMID 34755882）。」

组三·引单概念

• 错：「克罗恩病（DOID 编号 3093）。」——可核但不可解析。
• 对：「克罗恩病（DOID:3093，purl.obolibrary.org/obo/DOID_3093）。」

组四·指称本体

• 错：「DOID 本体收录……」——前缀当本体名（坑 3 第二重）。
• 对：「Human Disease Ontology（DO）收录……其概念以 DOID 前缀标识。」

组五·映射表述

• 错：「该基因与 DOID 等价的 OMIM 条目相关。」——把链接当等价（坑 5）。
• 对：「该基因与 DO 节点 cross ref 指向的 OMIM 条目相关（映射经人工核验，核验时点 2026-10）。」

坑点-异常-误解交叉索引

主题	坑（§10）	异常（排障）	误解（澄清）
版本漂移	坑 1	异 4/异 5/异 8	误解 3/误解 12
文件格式	坑 2	异 1/异 2/异 10	误解 11
名称混淆	坑 3	—	误解 2
管线切换	坑 4	异 4	—
映射语义	坑 5	异 9	误解 5
口径混用	坑 6	异 5	误解 8
双层 DOI	坑 7	—	误解 4
镜像滞后	坑 8	异 5	误解 10
定位错配	—	异 7	误解 6/误解 7/误解 9
归一化落坑	—	异 3	—

FAQ 收尾·十问（组 O）

Q119：最快验证「我下对了文件」的方法？
行数与体积对 Release 页声明（如 v2025-09-30 ZIP 84.0MB）+ 打开文件头看版本注记——两查不过再怀疑下载（异 1）。

Q120：doid.obo 里 [Term] 块的必读字段有哪些？
id（DOID）、name（首选标签）、synonym（同义词带类型）、def（定义带来源）、xref（跨库链接）、is_a（父节点）——六字段覆盖归一化所需（专题 C）。

Q121：DO 的层级深度大概多少层？
官方材料未给统一深度口径；实测对所用版本做根到叶路径统计即可——引用时自报统计口径，不引二手深度值。

Q122：为什么有的疾病类没有 OMIM 链接？
多因子/常见病的基因归因弱（OMIM 条目本位是孟德尔遗传），收编集中于遗传侧（>1,000 亚型）；链接非全量是设计现状非缺陷（坑 5）。

Q123：同一疾病在不同 Release 换了首选标签怎么办？
以引用版本的标签为准写论文；跨版对照用 DOID 号连接（编号不变标签可变）——这是「编号稳定优于标签稳定」设计的兑现（Q42）。

Q124：能拿 DO 做疾病共现网络吗？
能——文献共现对映射到 DOID 后，用层级聚合到中间层去噪再建网（专题 A 用法三/专题 G）；注意去重同义词重复计数（专题 O）。

Q125：审核一篇用 DO 的稿子，先查哪三处？
版本戳（坑 1）、引用 DOI 层级（坑 7）、映射表述语义（坑 5）——三处过关，其余多为枝节。

Q126：本条目信息的最后核验时点？
2026-10-04（rid 反查与研究快照同日）；DO 内容与引用数随时间自然演进。

Q127：想系统学本体工程，从 DO 切入读什么顺序？
本条目 §7/§10 → OBO Foundry 原则页 → NAR 2022 论文（治理章节）→ GitHub issue/PR 实况——理论到实践四步（专题 E/Q48）。

Q128：一句话向管理层推荐 DO？
「免费（CC0）、永续（PURL/DOI）、标准（OBO/四篇 NAR）、生态成熟（>50 本体/>150 万标注）——疾病语义层没有更稳的起点。」

结语句

从 8,043 到 11,953，从一棵树到一个生态——Human Disease Ontology 证明了：把一件事（疾病命名）做到机器可读、许可无碍、标识永续，十五年后它就成为所有下游默认的地基。本条目千余行，若只让你记住一件事，请记住：引用它时，带上版本日期与 DOI——这是对一本持续生长的词典最基本的尊重。

事实清单：本文全部硬事实与硬数字的出处对照

以下 36 条事实均以「事实——出处」成对存照，任何一条被质疑时可直接回溯：

1. DO 创刊论文发表于 Nucleic Acids Research 2012 年数据库专辑（NAR 2012;40(D1):D940-946，doi:10.1093/nar/gkr972，PMID 22080554）——PubMed 收录记录。
2. 创刊论文标题为 Disease Ontology: a backbone for disease semantic integration——PubMed 22080554 题录。
3. 2012 创刊时收录 8,043 个疾病术语——NAR 2012 论文正文（PMC3245088 抓取受反爬限制，以 PubMed 摘要与 NAR 官网为准）。
4. 2015 更新论文 doi:10.1093/nar/gku1011，PMID 25348409——PubMed 收录记录。
5. 2018 更新论文 doi:10.1093/nar/gky1032，PMID 30407550，NAR 2019;47(D1):D955-D962（在线 2018/专辑 2019 双口径）——PubMed 收录记录。
6. 2022 更新论文 doi:10.1093/nar/gkab1063，PMID 34755882，PMC8728220，NAR 2022;50(D1):D1255-D1261——PubMed 收录记录。
7. 2022 论文流程：Received 2021-09-22 / Accepted 2021-10-18 / 在线发表 2021-11-10——论文页 Editorial History。
8. 2022 论文署名 15 位作者，通讯作者 Lynn Marie Schriml——论文署名页。
9. 2022 论文 Google Scholar 引用约 363 次（2026-10 查询快照）——Google Scholar 引用页。
10. v2021-08-17 是第 100 个 Release，规模 10,862 terms，76% 带定义——NAR 2022 论文正文。
11. v2024-07-31 版 11,612 classes，定义覆盖 79.9%——Zenodo 版本存档 DOI 10.5281/zenodo.13145656。
12. v2025-09-30 版 11,953 classes——Zenodo 版本存档 DOI 10.5281/zenodo.17238005。
13. v2025-09-30 版 9,656 个类带定义（80.8%）——同上（Zenodo 17238005）存档说明。
14. v2025-09-30 版存档 ZIP 84.0MB——同上（Zenodo 17238005）文件列表。
15. v2025-09-30 相对 v2024-07-31 净增 1,793 个新术语——两版存档 diff 说明（Zenodo 版本页更新注记）。
16. 22,137 条 SubClassOf 层级公理（v2025-09-30 口径）——同上版本存档说明。
17. 35,984 条 cross references（v2025-09-30 口径）——同上版本存档说明。
18. 12,739 条 definition sources——NAR 2022 论文与版本存档说明互证。
19. 15 个上游本体以 imports 方式接入——NAR 2022 论文正文。
20. 本版接入 11 个新增 ECO 类型——NAR 2022 论文正文。
21. 全生态标注元素超过 150 万条（>1.5M annotation elements）——NAR 2018 论文确立、NAR 2022 论文延续的说法。
22. 超过 50 个应用本体引用 DO——NAR 2018/2022 论文与 OBO Foundry 登记页。
23. PI Lynn Marie Schriml，ORCiD 0000-0001-8910-9851，任职 University of Maryland Institute for Genome Sciences——ORCiD 注册记录与机构页。
24. DO 由 NHGRI 资助——论文致谢与基金栏。
25. 许可 CC0-1.0 三证：GitHub LICENSE 文件、OBO Foundry 登记页（obofoundry.org/ontology/doid.html）、Zenodo 元数据——三处原文互证。
26. PURL http://purl.obolibrary.org/obo/doid.owl 永久解析主发布文件——OBO Foundry PURL 约定与 OBO 登记页。
27. Zenodo 仓库级（概念）DOI 10.5281/zenodo.10030383——Zenodo 社区页。
28. 文件族五件套：doid.owl / doid.obo / doid.json / HumanDO.obo / doid-merged.obo——GitHub 仓库与 Zenodo 存档文件列表。
29. SARS-CoV-2 疾病分支为 COVID-19 期间扩充的新发传染病子树——NAR 2022 论文与 AGR COVID-19 专题页。
30. AGR COVID-19 专题着陆页锚定 DOID:0080599（COVID-19）——AGR 专题页 URL 与 DO 浏览器。
31. OMIM 超过 1,000 个亚型条目被收编进 DO 对应疾病类——NAR 2018/2022 论文口径。
32. FunDO、GeneAnswers 以 DO 为疾病词表做富集分析——两工具官方文档。
33. AGR、MGI、IEDB 采用 DO 做基因-疾病/免疫标注——各数据库官方文档与 NAR 论文互证。
34. 2025 年官方宣布发布管线切换至 ROBOT 1.9.10（宣布口径，非已完成存照）——GitHub 仓库公告与官方文档。
35. OBO Foundry 登记本体身份（登记页 obofoundry.org/ontology/doid.html）——OBO Foundry 官网。
36. 官网 disease-ontology.org 提供浏览界面与 SPARQL/API 入口——官网导航实况（2026-10 快照）。

术语表：三十条关键术语

1. 本体（ontology）：对某领域概念及其关系的机器可读形式化刻画；DO 是疾病领域的本体，产出概念、层级、定义与映射而非记录行。
2. DOID：DO 的标识前缀与编号体系（如 DOID:3093）；每个疾病类的永久身份证号。
3. doid: 短格式：文本中引用 DOID 编号的紧凑写法（doid:3093），常见于 RDF 与文献注释。
4. PURL（Permanent URL）：永久统一资源定位符；purl.obolibrary.org/obo/doid.owl 等地址由 PURL 服务重定向到当前版本，实现「地址永存、版本演进」解耦。
5. OWL（Web Ontology Language）：W3C 本体语言，doid.owl 主发布格式，支持推理与图数据库导入。
6. RDF/XML：OWL 的常见序列化格式之一；适合机器处理、不适合人眼逐行阅读。
7. OBO 平文本：OBO Foundry 传统格式（stanza 结构），人类可读、脚本友好；doid.obo 的格式。
8. doid-merged.obo：把 15 个 imports 合并进单文件的 OBO 版本；做完整闭包图分析的专用格式。
9. SubClassOf：子类关系公理；DO 的 22,137 条 SubClassOf 构成疾病分类树的骨架。
10. 单根（single root）：全树只有一个根部类（disease）的设计；便于全局统计与遍历。
11. cross reference（交叉引用）：指向外部词表（OMIM/UMLS/ICD）的链接；是链接线索而非等价断言。
12. imports（导入）：本体对外部本体的标准化引用；2022 版把分散引用收拢为 15 个 imports。
13. 同义词组（synonym set）：一个疾病类的全部可接受叫法；分精确/宽泛/相关/缩写四类型。
14. 定义（definition）：类的受控正式文本描述；v2025-09-30 版 9,656 个类（80.8%）携带。
15. 定义来源（definition source）：定义的文献或词表出处记录；12,739 条，与定义数是两个口径。
16. ECO（Evidence & Conclusion Ontology）：证据类型本体；标注「这条断言如何得来」（文献实证/计算推断等）。
17. CC0-1.0：公有领域贡献许可；无署名要求、无商用限制，DO 的许可三证一致。
18. Zenodo：CERN 运营的科研存档平台；DO 逐版本存档并发放 DOI。
19. 概念级 DOI / 版本级 DOI：仓库级概念 DOI 永远指向最新版（10.5281/zenodo.10030383）；版本级 DOI 锁定具体内容（如 10.5281/zenodo.17238005）；引用规范见坑 7。
20. GitHub Release：软件仓库的版本发布机制；DO 的第 100 个 Release 是 v2021-08-17。
21. ROBOT：本体处理命令行工具链；2025 年官方宣布切换至 ROBOT 1.9.10 发布管线。
22. SPARQL：RDF 图谱查询语言；官网提供 SPARQL 端点做结构化查询。
23. OBO Foundry：开放生物医学本体联盟；DO 的登记母体，提供原则框架（CC0/单根/PURL/版本化）。
24. NER（命名实体识别）：从文本抽取实体提及的任务；疾病 NER 的输出经归一化接到 DOID。
25. 归一化（normalization）：把文本提及映射到标准概念 ID 的过程；DO 的同义词组与层级是归一化的基础设施。
26. 富集分析（enrichment analysis）：检验基因列表在某词表上是否过度代表的统计方法；FunDO/GeneAnswers 以 DO 执行疾病富集。
27. 语义相似度（semantic similarity）：基于本体层级度量概念/集合相似性的方法；DO 树形结构是疾病侧语义相似度的计算基础。
28. 疾病本位 vs 统计本位：两种疾病组织逻辑——DO 按解剖/病理组织（疾病本位），ICD 按报表/死因组织（统计本位）；混用层级会失真。
29. MONDO：跨本体疾病合并本体，以 DO 为上游输入；「合并派」与 DO「精细树派」互补（库内 748 号条目）。
30. 罕见病（rare/orphan disease）：患病率极低的疾病群体；DO 经 OMIM 亚型收编与 Orphanet 对接持续扩充罕见病覆盖。

附录 A·版本口径链速查

时点	类数	定义覆盖	里程碑	引用锚点
2012	8,043	—	创刊，确立 DOID/PURL/OBO 形态	doi:10.1093/nar/gkr972（PMID 22080554）
2015	扩充中	—	罕见病与亚型扩展	doi:10.1093/nar/gku1011（PMID 25348409）
2018/2019	增长中	—	平台化；标注挂接破 150 万	doi:10.1093/nar/gky1032（PMID 30407550）
v2021-08-17	10,862	76%	第 100 个 Release	NAR 2022 论文正文表
v2024-07-31	11,612	79.9%	—	DOI 10.5281/zenodo.13145656
v2025-09-30	11,953	80.8%（9,656 个）	净增 1,793 新术语	DOI 10.5281/zenodo.17238005

附录 B·DAIMS 评估全表（AI-Ready 八维打分）

DAIMS（Data AI-Readiness 全维度评估）对 DO 逐维打分（0-10 分，10 为该维理想值；评分为本条目编辑部的结构化判读，依据列给出客观锚点）：

维度	得分	依据
D1 可获得性	10	五入口零注册直下：PURL/GitHub Releases/Zenodo/官网服务/第三方镜像；无申请、无会员、无等待
D2 许可开放度	10	CC0-1.0 三证一致（GitHub/OBO Foundry/Zenodo），无署名要求、可商用、可再分发
D3 标识持久性	10	DOID 编号永久 + PURL 解析 + 双层 DOI（概念级/版本级）齐备；单概念、单版本、全库三层均可稳定引用
D4 格式机器可读性	9	OWL/RDF/XML + OBO 平文本 + JSON 三态齐备；扣 1 分因 RDF/XML 逐行处理不友好且老文件名 HumanDO.obo 长期并存易混淆
D5 元数据完备性	9	定义 80.8% 覆盖且逐版上升、定义来源 12,739 条可溯、ECO 证据类型接入；扣 1 分因近两成类暂无定义
D6 版本化与可引用性	10	100+ 个 Release、逐版 Zenodo DOI、版本更新注记齐备；跨版本 diff 唯一噪音是 2025 管线切换（坑 4），不影响可引用性
D7 文档与社区	8	官网文档、GitHub README、NAR 四篇论文构成文档链；扣 2 分因深度教程与用例库相对薄， newcomers 需读论文才能理解治理细节
D8 生态互操作性	10	OBO Foundry 原则全符合；15 个 imports 上游 + >50 应用本体下游 + OMIM/UMLS/ICD 横向 cross refs 35,984 条
综合	9.5	医学知识资源中 AI-Ready 程度最高一档：许可、标识、版本化三件套满格，唯内容覆盖（定义 80.8%）尚在还欠账

附录 C·四篇 NAR 论文档案

篇目	卷期页	DOI	PMID	核心贡献
2012 创刊	NAR 40(D1):D940-946	10.1093/nar/gkr972	22080554	提出「疾病语义整合骨干」；8,043 术语；确立 DOID/PURL/OBO 形态
2015 更新	NAR 43(D1):D1073-D1078	10.1093/nar/gku1011	25348409	罕见病与临床亚型扩展
2018 更新	NAR 47(D1):D955-D962（在线 2018，专辑归 2019）	10.1093/nar/gky1032	30407550	平台化维护；>1.5M 标注元素口径确立
2022 更新	NAR 50(D1):D1255-D1261	10.1093/nar/gkab1063	34755882（PMC8728220）	imports 标准化（15 个）、定义治理（12,739 来源）、11 个新 ECO、社区协作机制；15 作者；2021-09-22 收稿/2021-10-18 录用/2021-11-10 在线

附录 D·DOID 编号示例与 PURL 引用模板

DOID	疾病	层级角色
DOID:3093	Crohn disease	典型病种节点（炎症性肠病下级）
DOID:0080599	COVID-19	SARS-CoV-2 分支锚点（AGR 专题页引用）
disease（根类）	disease	全树单根（编号与结构以官方浏览器实时展示为准）

引用模板三式：单概念——purl.obolibrary.org/obo/DOID_3093；单版本——DOI 10.5281/zenodo.17238005（v2025-09-30）；学术成果——doi:10.1093/nar/gkab1063。

附录 E·获取入口清单

入口	地址/路径	适用场景
PURL 直链	purl.obolibrary.org/obo/doid.owl（及 doid.obo 等同名变体）	要最新版单文件
GitHub Releases	github.com/DiseaseOntology/HumanDiseaseOntology 的 Release 页	要版本历史与更新说明
Zenodo 存档	仓库级 DOI 10.5281/zenodo.10030383；版本级如 10.5281/zenodo.17238005	要可引用 DOI 与存档 ZIP
官网服务	disease-ontology.org（浏览/检索/SPARQL/API 入口）	探索性查词
第三方镜像	OLS、BioPortal、OntoBee、AberOWL、Bioregistry	交叉检索与生态索引（计数可能滞后，坑 8）

附录 F·存照与待核事项汇总

• 规模口径链四行数字（8,043/10,862/11,612/11,953）各自带版本与出处，正文 §3 与附录 A 双表互证——引用时任选一行但必须带版本戳。
• 2012 论文正文细节（8,043 之外的早期数字）因 PMC3245088 抓取受 PMC 反爬限制，本文一律只引 PubMed 题录与摘要层信息，未引正文表格。
• 2012/2015 两篇论文的完整作者名单本文未逐名列出（未核转抄源），如需引用请以 PubMed 题录为准；2022 论文 15 作者事实有论文署名页背书，正文亦只点名通讯。
• Google Scholar 引用约 363 次为 2026-10 查询快照，随时间自然增长。
• ROBOT 1.9.10 管线切换以「官方已宣布」口径存照；完成状态以 GitHub 仓库后续公告为准。
• 官网 SPARQL/API 的具体端点 URL 本文未固化（随基础设施演进），以官网导航实时入口为准。

尾注

本文为 Human Disease Ontology（DO/DOID）的中文 AI-Ready 百科条目，属千方病案医数集「AI-Ready Wikipedia」系列。事实层以 NAR 四篇论文（2012/2015/2018/2022）、GitHub 仓库 DiseaseOntology/HumanDiseaseOntology、Zenodo 版本存档（仓库级 DOI 10.5281/zenodo.10030383）与 OBO Foundry 登记页为源；全部硬数字带版本日期或 DOI（见事实清单 36 条与附录 A）。库内互链 rid（ncbi-disease 425、global-burden-of-disease 97、chronic-kidney-disease-uci 726、iqvia-disease-analyzer 510、omim 159、medmentions 390、bc5cdr 415、gene-ontology 441、disgenet 449、snomed-ct 557、umls 558、meddra 579、hpo 747、mondo 748、ctd 749、orphanet-ordo 812）为 2026-10-04 只读反查结果。本文写作时点为 2026 年 10 月；DO 为持续演进的知识资源，引用本文数字时请同时核对最新 Release。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• europepmc — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献 / 公共卫生与流行病学
• medmentions — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献
• biored — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献
• craft — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献
• semmeddb — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献
• medlexsp — 共享标签：医疗NLP / 知识图谱 / 命名实体识别 / 生物医学文献
• s2orc — 共享标签：医疗NLP / 知识图谱 / 生物医学文献
• cometa — 共享标签：医疗NLP / 知识图谱 / 命名实体识别
• ncbi-disease — 共享标签：医疗NLP / 命名实体识别 / 生物医学文献
• jnlpba — 共享标签：医疗NLP / 命名实体识别 / 生物医学文献

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。