Name: HRA Knowledge Graph (HRA KG)
Creator: Indiana University Cyberinfrastructure for Network Science Center + Stanford BMIR（HuBMAP HRA 联盟）
Published: 2026

信息速览

数据集名称HRA Knowledge Graph — 人体参考图谱 RDF 知识图谱：解剖-细胞-标志物主干

数据类型知识图谱,本体与术语,参考数据,元数据,人工标注

规模HRApop v1.1 汇聚 175 位捐献者（男 92 / 女 83）的组织块与数据集；本体层本身不含患者个体，hra-pop-full 扩展层含 32,047 个供体实体（跨门户去重前口径）

接入方式HuBMAP、SenNet、KPMP、GUDMAP/RBK、HCA、CZ CELLxGENE、GTEx、HTAN、GEO 等门户的已注册实验数据 + 专家人工编纂的 ASCT+B 表、OMAP 抗体面板、2D FTU 插图与 71 个 3D 参考器官

AI 就绪度

INFOBOX — HRA KG 一屏速览

维度内容

本质人体参考图谱（HRA）的 RDF 知识图谱发布，不是影像集也不是测序矩阵；是参考本体 + 元数据 + 派生统计的三合一

主导方 NIH HuBMAP 联盟；建设与运维由 Indiana University CNS（Börner 组）与 Stanford BMIR（Musen 组）承担

论文 Sci Data 12:1100（2025-07-01），doi:10.1038/s41597-025-05183-6，CC BY 4.0，114 条参考文献

v2.2 规模 10,064,033 节点 / 171,250,177 边 / 125.84 GB（2025-05 统计快照）

覆盖 71 个器官、5,800 个解剖结构、2,268 个细胞类型、2,531 个生物标志物

数字对象 13 类共 703 个：33 张 ASCT+B 表、23 个 OMAP、22 个 2D FTU、71 个 3D 参考器官、59 组地标

现行版本 v2.5（第 11 次发布，Zenodo 记录 2026-06-15，tar.xz 7.7 GB）

发布节奏每年两次：6 月 15 日与 12 月 15 日

入口 SPARQL 端点 lod.humanatlas.io/sparql；Zenodo 概念 DOI 10.5281/zenodo.15323983；REST API；上海/柏林镜像

许可数据 CC BY 4.0，代码 MIT——本库可获取性光谱里最开放的一档

库内互链 HuBMAP（rid 517，上游门户）、Human Cell Atlas（319）、KPMP（512）、GTEx（568）、Tabula Sapiens（329）、CZ CELLxGENE（38）

HRA 知识图谱是一张「给人体的解剖学、细胞学与分子标记建索引」的图。它不存储任何一张切片、任何一条测序读段，而是把「肾皮质里有哪些细胞类型」「哪些基因可以标记近端小管上皮」这类已经被专家写成表的关系，编译成机器可直接查询的 RDF 图。2025 年发表在 Scientific Data 的这篇论文给出的数字是：1006 万个节点、1.71 亿条边、125.84 GB，覆盖 71 个器官、5,800 个解剖结构、2,268 个细胞类型与 2,531 个生物标志物。这些数字放在通用知识图谱里不算大，但放在生物医学参考图谱这个细分赛道上，它罕见的不是规模，而是「每年两次、全部 CC BY 4.0、带 SPARQL 端点、带版本化 Zenodo 快照」的工程纪律。

导语读法三则：

只想用数据：直接跳 §6 的获取路径——SPARQL 端点、Zenodo 快照、REST API 三条路各有适用场景，选错了会浪费几天。
关心它到底装了什么：读 §2 与 §3——ASCT+B 表是全图的主干，OMAP 是蛋白质层的实测对照，2D FTU 与 3D 参考器官是空间层。
要做跨数据集整合：读 §5 的 hra-pop 与 §7 的生态——HRA KG 真正省时间的地方不在「查表」，而在「把不同来源的单细胞实验挂到同一套解剖坐标上」。

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

0.1 三件互相看不见的事

单细胞测序、空间转录组、多重免疫荧光这三类技术，在过去五年里把人体组织的分辨率推到了单细胞乃至亚细胞尺度。但它们各自产出的是三种「方言」：

单细胞研究说「cluster 7 是 CD16+ 单核细胞」，但不说这个细胞在人体的哪个位置；
空间组学说「某个 spot 高表达 NPHS1」，但用哪套解剖术语描述这个 spot，取决于作者熟悉哪个本体；
多重成像说「pan-cytokeratin 阳性的管状结构」，但不一定告诉你那是近端小管还是集合管。

三种方言之间没有共同的词典，也没有共同的地图。于是每个整合项目都要重新做一遍手工对照：先对齐术语（CD16+ 单核细胞 ↔ non-classical monocyte ↔ CL 里的哪个 ID），再对齐解剖（肾皮质 ↔ UBERON:0001225），最后对齐空间（这块组织在器官的哪一层）。这项工作在论文里通常只占一句「cell types were manually annotated」，实际上耗掉数月。

HRA KG 的定位就是把这三层对照预先做掉并且公开发布：解剖结构挂 Uberon，细胞类型挂 Cell Ontology（CL）与 Provisional Cell Ontology（PCL），生物标志物挂 HGNC（基因）与 UniProt（蛋白），三层用 ASCT+B 表组织成树；再把 3D 参考器官、2D 功能组织单元插图、抗体面板、组织块注册位置这四类空间与实验对象统一到 Common Coordinate Framework（CCF）下，最终编译成一张可 SPARQL 查询的图。

0.2 它与「数据集」的差别

多数 AI-Ready 数据集是「样本 × 特征」的矩阵，HRA KG 是「实体 × 关系」的图。这个差别决定了三件事：

它不能直接训练模型。没有标签、没有损失函数、没有 train/test 划分。它的用途是作为检索层与约束层：给模型提供解剖学先验、给标注流水线提供受控词表、给跨数据集整合提供对齐键。
它的「规模」不是样本量而是关系数。10,064,033 个节点里绝大多数是本体术语与派生记录（rdfs:label、subClassOf、record_number 等谓词各占百万级），真正「人写出来的」ASCT+B 单元格只有数十万量级。引用规模时必须说清是哪一层。
它的价值随时间累积而非一次交付。每年 6-15 与 12-15 各发一版，器官逐个补齐、术语逐个去 TEMP。用它做长期项目，版本管理比一次性下载更重要。

0.3 本条目与库内 HuBMAP 条目的分工

库内已有 HuBMAP 条目（rid 517），写的是数据门户：5,032 个数据集、310 位捐献者、22 种数据类型。本条目写的是这些数据之上的参考层：把 HuBMAP 及其他联盟的组织块挂进统一解剖坐标的那张图。两者关系不是「重复」而是「底座与索引」——HuBMAP 门户回答「有哪些数据」，HRA KG 回答「这些数据在人体的哪里、属于哪些细胞类型」。§9 会给出更细的分工表与互链建议。

0.4 一个被低估的设计选择：把「参考」与「观测」分开发布

多数数据集只发布观测：一批样本、一套测量、一份元数据。HRA 反过来，先发布「参考」，再把观测挂上去。这个顺序看起来只是工程偏好，实际决定了很多事情。

如果先有观测再有参考，每来一批新数据，就得重新定义一次器官边界、细胞类型与命名；如果先有参考再有观测，新数据只需要声明「我挂在哪个坐标、哪些细胞类型上」。前者是每次重建坐标系，后者是往坐标系里加点。HRA 选择后者，代价是参考层必须先被编纂出来——33 张 ASCT+B 表、23 个 OMAP、71 个三维参考器官，全部要专家逐行写、逐表评审；收益是后来的每一批数据都能低成本接入，hra-pop 里 807 个数据集正是靠这套参考才可能被横向比较。

这也解释了为什么它的数字对象里有一大半是「表」而不是「数据」：表是可继承的资产，数据是一次性的观测。理解这一点，就不会再问「为什么一个知识图谱里没有原始影像」。

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

Q1：HRA KG 的「KG」是知识图谱还是别的缩写？
Knowledge Graph。官方全称 Human Reference Atlas Knowledge Graph，项目代号 hra-kg。文献里也写作 HRA-KG、HRA KG，三者同指。

Q2：它和 HRA 是什么关系？
HRA（Human Reference Atlas，人体参考图谱）是一个包含多种产物的大工程：ASCT+B 表、3D 参考器官、OMAP、2D FTU 插图、millitome、注册工具等。HRA KG 是这些产物的图数据库形式——论文原话是 HRA 的「primary database」。

Q3：谁在做？
联盟层面由 NIH Common Fund 的 HuBMAP 牵头，联合 SenNet、KPMP、GUDMAP 与 NIDDK；技术建设在 Indiana University 的 Cyberinfrastructure for Network Science Center（Katy Börner 组）与 Stanford 的 Biomedical Informatics Research（Mark Musen 组）。

Q4：规模到底多大？
论文口径：v2.2（2025-05 统计）10,064,033 个节点、171,250,177 条边、125.84 GB。注意同一个论文的 Table 3 在横向对比时又写了 1,543,074 节点 / 101,720,865 边 / 30,848 MB——这不是笔误而是两套统计口径（详见坑 1）。

Q5：多少个器官？
v2.2 论文：71 个。这 71 个是 3D 参考器官的数量，其中仅 5 个女性独有（输卵管、乳腺、卵巢、胎盘、子宫）、1 个男性独有（前列腺），其余成对或共用。

Q6：ASCT+B 是什么？
Anatomical Structures, Cell Types, plus Biomarkers——解剖结构、细胞类型、生物标志物三层的逐层树表。每张表对应一个器官，由领域专家编纂、同行评审、附 DOI，最终编译为 RDF。

Q7：能直接下载吗？
能，且没有任何注册墙。Zenodo 上按版本打 tar.xz（v2.5 是 7.7 GB），或直接打 SPARQL 端点，或用 REST API 拉单个数字对象。

Q8：许可是什么？
数据 CC BY 4.0，代码 MIT。这是「署名即可商用」的档位，比多数生物医学数据集的 NC 条款宽松得多。

Q9：多久更新？
每年两次，6 月 15 日与 12 月 15 日。2026-06 发布的是第 11 次（v2.5）。论文基线是 v2.2。

Q10：与我熟悉的 Cell Ontology / Uberon 是什么关系？
HRA KG 不替代它们，而是使用它们。CL、PCL、Uberon 是本体（术语及其逻辑关系），HRA KG 是在这些术语之上追加「某个器官里确实存在这个细胞类型、用这些基因标记它」的实例级断言。

Q11：能不能拿它训练一个模型？
不能直接训练，但可以做：图嵌入预训练、细胞类型注释的约束后处理、跨数据集检索的 rerank、以及作为 LLM 的检索知识库（RAG）。§8 给出三条可落地的路线。

Q12：它对 AI-Ready 的核心意义是什么？
它是本库少见的「全开放 + 强版本化 + 机器原生」三重齐备的参考型数据集：没有注册墙、没有 NC 限制、没有 PDF 附录式的暗数据，元数据与数据同源同格式。

§2 数据构成与规格

2.1 三层架构：生物结构层、实验层、空间层

论文把整个图谱划分为若干子图（subgraph），从使用者的角度可以归纳成三层：

这三层不是三个并行的库，而是同一张图上的三类断言。生物结构层回答「有什么」：解剖结构、细胞类型、生物标志物之间的层级关系，来源是 33 张 ASCT+B 表。实验层回答「怎么看见」：抗体面板、检测靶标、实验条件，来源是 23 个 OMAP。空间层回答「在哪里」：三维参考器官、地标、组织块注册位置、碰撞体积与相关性走廊（corridor），来源是 71 个三维参考器官、59 组地标以及 RUI 留下的注册记录。三层之间靠 CCF 本体的谓词黏合，比如空间实体、放置关系、坐标轴、碰撞这些概念，都有标准的谓词可用。

三层之间用 CCF 本体（Common Coordinate Framework Ontology）黏合。CCF 提供的是「空间实体」「放置关系」「坐标轴」「碰撞」这些概念的标准谓词——例如 placed_relative_to 取代了早期的 has_placement（v1.2 起），这个改名看似微小，实际影响所有下游查询。

2.2 13 类数字对象与 v2.2 计数

论文给出的 v2.2 快照（703 个独立 DO）：

十三类数字对象里，体量最大的一类是单细胞数据集引用，共 11,698 个，作为数据集图的实例进入图谱；但它们是「引用」而不是「数据本体」，图谱里只保留指针与少量元数据。编纂类对象包括 33 张 ASCT+B 表（32 个器官加 1 个解剖系统）、23 个 OMAP（覆盖 13 个器官，含视网膜、阑尾等少见组织）、22 个二维功能组织单元插图（覆盖 10 个器官，肾脏最多有 8 个）、71 个三维参考器官（GLB 文件合计 301 MB）、59 组地标（覆盖 71 个参考器官中的 59 个，合计 261 MB）、1,224 个跨三维对象的三维解剖结构映射，以及覆盖 23 个器官的 CTann 交叉表（其中 12 个器官有多工具交叉）。剩余部分包括 millitome、血管几何、schema 与 vocab 等辅助对象。

到 v2.5（2026 年 6 月），LOD 目录页的实测计数已经变成：ASCT+B 目录 41 项、OMAP 38 个、2D FTU 29 项、参考器官 88 个、地标 61 组。这些数字不能与论文的 33/23/22/71/59 直接相减——LOD 目录是全版本累积的 Catalog（同一个器官的不同版本各占一个节点），而论文统计的是某一版本内的实体数（详见坑 2）。

2.3 ASCT+B 表：全图的主干

ASCT+B 是理解整个图谱的关键。以肾脏表 v1.8 为例（2026-06-15 发布，78 个数据行），CSV 的结构是：

CSV 的第一段是八行表头元数据，依次是标题、作者与 ORCID、评审人与 ORCID、一般出版物 DOI、Data DOI、日期与版本号——这八行就是这张表的「身份证」，复现时应当原样保留。紧随其后是 AS/1 至 AS/6 共六级解剖层级，每级三列（名称、标签、本体 ID），最多可容纳六层嵌套；CT/1 至 CT/2 两级细胞类型，每级带缩写与注释；BGene/1 至 BGene/7 与 Protein/1 至 Protein/7 两组标志物列，基因走 HGNC、蛋白走 UniProt；最后是参考文献列与「注释/理由」列。

关键设计：每一行都是从根到叶的一条完整路径。也就是说，表不是「树的一部分」，而是「树的全部叶路径」。这个扁平化设计让非程序员也能用 Excel 维护，代价是同一中间节点会在多行重复——这也解释了为什么 78 行只能折叠出 74 个不同的 AS 节点。

实测肾脏表 v1.8 的折叠结果：11 个带 UBERON ID 的解剖结构、67 个 CL 细胞类型、190 个 HGNC 基因。只有 11 个 AS 带 UBERON ID 这件事说明一个容易被误读的现象——ASCT+B 表的解剖层级远比 ID 覆盖深。很多中间层结构（如「肾小体」「髓放线」）在表里以自由文本出现，尚未获得 Uberon 术语。这正是论文所说的 TEMP 术语问题：v2.2 统计有 951 个 AS、221 个 CT、296 个 B 处于待补本体状态。

2.4 OMAP：把「细胞类型」落到「抗体」上

OMAP（Organ Mapping Antibody Panel）解决的是另一件事：ASCT+B 说「肾脏有足细胞、近端小管上皮细胞」，OMAP 说「要在一张片上同时看到它们，你需要这 24 个抗体」。

以 OMAP-3（肾 + CODEX）v1.4 为例，实测 CSV 结构包含：omap_id、UniProt 登录号、HGNC ID、靶标符号、宿主物种、同型、克隆性、克隆号、厂商、货号、批号、是否重组、浓度、稀释比、偶联物、RRID、方法、组织保存方式、循环编号、荧光报告基团、协议 DOI、作者 ORCID、核心面板标记、理由、器官与器官 UBERON ID。

该面板实测 24 个抗体靶标（外加 DAPI 作核染与配准），全部为新鲜冷冻样本、CODEX 方法、分 9 个循环成像；厂商集中在 Abcam（15 个）与 Akoya Biosciences（6 个）。RRID 与货号列是这张表最有工程价值的部分——它是「可复现」三个字在抗体层面的落地，让另一个实验室真的能买到同一支抗体。

2.5 2D FTU 与 3D 参考器官：空间层的两种精度

2D FTU（Functional Tissue Unit）是示意图 + 精确的 SVG 标注，描述「执行同一生理功能的最小组织单元」，如肾小体、肺泡、肝小叶。它解决的是「教学与标注参照」，不是测量。
3D 参考器官是 GLB 网格，带 UBERON 标注，可被注册工具（RUI）用作容器。它解决的是「这块组织在器官的哪个位置」。

两者配合地标（landmark）使用：地标是器官表面或内部的解剖参照点，v2.2 覆盖 59/71 个参考器官。注册一个组织块时，RUI 用这些地标做初始对齐，再让用户微调，最后输出 placed_relative_to 与碰撞体积。

2.6 存储与序列化规格

规格共八项。图模型是 RDF，命名图（named graph）按数字对象切分，一个 DO 一个图，这是后面所有「按图取数」操作的基础。序列化提供五种：Turtle、N-Triples、N-Quads、JSON-LD、RDF/XML，其中 N-Quads 保留图名，JSON-LD 最适合前端直接吃。端点是 SPARQL 1.1，地址 lod.humanatlas.io/sparql。打包形式为全量 tar.xz，v2.5 为 7.7 GB。单对象层面，每个 DO 有稳定 PURL，形如 purl.humanatlas.io/<type>/<name>/<version>。本体依赖共 10 个：CCF 3.0、CL、PCL、Uberon、FMA、HGNC、HRAVS、LMHA、RO、VCCF。标识符分三层：数字对象用 PURL，表用 HRA 自有的 Data DOI（10.48539/…），论文用 Crossref DOI。

§3 本体与受控词表：HRA KG 的「语法」

3.1 它依赖的十个本体

HRA KG 自己不发明术语体系，而是借用 + 扩展。论文列出的本体依赖共 10 个，每个都有明确分工：

本体生态在 v2.2 时点由十套外部或半内部本体共同支撑，按角色可以分成四组。

空间组三套：CCF（Common Coordinate Framework Ontology）3.0 承载空间、配准、坐标系、碰撞与相关性走廊的核心谓词，是整个图谱最底层的一套；VCCF（Vasculature Common Coordinate Framework）2024-02-23 版是血管专用坐标系，把血管树也纳入统一空间；HRAVS（HRA Vasculature Schema）2.5.3 则是血管模型的模式定义，管的是数据形状而不是术语。

解剖组两套：Uberon（2024-11-25）提供解剖结构（AS）的跨物种通用本体，是 5,800 个解剖结构的主命名来源；FMA（Foundational Model of Anatomy）5.0.0 与 Uberon 互补，覆盖 Uberon 未收的经典解剖术语，两者通过映射表互认。细胞组两套：CL（Cell Ontology）2024-09-26 收录成熟细胞类型的标准术语，PCL（Provisional Cell Ontology）2024-07-11 收的是 CL 尚未收录、但图谱已经需要的那部分，相当于临时收容所。

分子与关系组三套：HGNC（2024-03-04）管人类基因符号与 ID，2,531 个生物标志物里的基因部分全部落在这里；RO（Relation Ontology）2024-04-24 提供 part_of、located_in 这类通用关系谓词；LMHA（Landmark / HRA 辅助本体）1.4 定义地标与配准辅助概念，服务 59 组地标参考器官。

为什么需要 PCL：这是个容易被忽略但极重要的设计。CL 收录一个细胞类型通常要求有充分的文献支撑与命名共识，周期以年计；而图谱编纂者经常遇到「这个结构里确实有一群细胞，但还没有公认名字」的情况。PCL 就是为这类情形设的「灰度区」——先用 TEMP 或 PCL 术语占位，等 CL 正式收录后再迁移。论文报告：截至 2025-05，HRA 与其他图谱努力共向 Uberon 增加 162 个 AS 术语、向 CL 增加 155 个 CT 术语、向 PCL 增加 468 个 CT 术语（其中 461 个来自人脑）。这组数字说明本体不是静态字典，HRA 本身也是 Uberon 与 CL 的贡献者——它不只消费本体，还向上游回填术语。

3.2 TEMP 术语：图谱的「欠账表」

TEMP 是 HRA 内部约定的占位符前缀（如 TEMP-AS、TEMP-CT）。它标记的是「已进入图谱、但尚无正式本体 ID」的实体。v2.2 的欠账规模：

TEMP 是 HRA 内部约定的占位符前缀（如 TEMP-AS、TEMP-CT）。它标记的是「已进入图谱、但尚无正式本体 ID」的实体。v2.2 的欠账规模分三类：TEMP-CT 共 221 个，是跨 33 张表待补的细胞类型；TEMP-AS 共 951 个，是待补的解剖结构；TEMP-B 共 296 个，是待补的生物标志物。三者合计 1,468 个实体处于占位状态。

这组数字对使用者的含义非常直接：任何声称「HRA KG 覆盖了全部细胞类型」的说法都是错的。约 221 个细胞类型仍在占位状态，它们可以被查询、被用于可视化，但无法与外部本体直接 join。如果你的下游 pipeline 依赖 CL ID 做映射，必须显式处理 TEMP 行——是丢弃、是单独成类、还是按名称模糊匹配，必须在流程里写明，不能留给默认行为。

这组数字对使用者的含义非常直接：任何声称「HRA KG 覆盖了全部细胞类型」的说法都是错的。约 221 个细胞类型仍在占位状态，它们可以被查询、被用于可视化，但无法与外部本体直接 join。如果你的下游 pipeline 依赖 CL ID 做映射，必须显式处理 TEMP 行。

同时，951 个 TEMP-AS 远超 221 个 TEMP-CT，这个比例本身就是信息：解剖层级的细粒度远超细胞层。原因是解剖结构的拆分粒度在组织学上可以无限细（一个肾单位可以继续拆成十几个段落），而细胞类型的命名收敛更快。

3.3 标识符体系：四种 ID 混用

HRA KG 里同时存在四类标识符，混淆它们是新手最常见的错误：

四类标识符各有各的用途，混淆它们是新手最常见的错误。PURL 形如 https://purl.humanatlas.io/asct-b/kidney/v1.8，用于定位数字对象——表、OMAP、功能单元、参考器官——它带版本，写 latest 时会自动解析到当前版本，这正是它不适合作为复现依据的原因。Data DOI 形如 10.48539/HBM342.NFDL.535，是单个数字对象的可引用标识，由 DataCite 注册，永久有效。

本体 ID 形如 UBERON:0002113、CL:0000236、HGNC:3802，用于表内的实体，永久有效且由各自的本体维护机构负责。门户实体 UUID 形如 https://entity.api.hubmapconsortium.org/entities/1ef4a756…，用于实验数据（组织块、数据集、供体），稳定性最弱，门户迁移时可能变化。四者的稳定性从强到弱的顺序是本体 ID、Data DOI、PURL、UUID。

引用规范上，Data DOI 是唯一被官方要求引用的粒度。每个数字对象的 JSON-LD 里都有 schema1:citation 字段，例如肾脏表的 citation 是「Jain, Sanjay, M. Todd Valerius, Yongqun He, Tarek El-Achkar, Michael Eadon, and Jeffrey Spraggins. 2026. …」，并附 Data DOI。用 HRA 数据发论文时引「论文 + 你实际用到的每个 DO 的 citation」，缺一不可。

3.4 扁平表如何变图：hra-do-processor 三步

论文与仓库 README 描述的处理链是三步：

归一化（normalize）：把 CSV、GLB、SVG 等异构源文件转成统一 schema 的中间表示；
富化（enrich）：补充本体交叉引用、DOI、许可证、引用信息、跨对象链接；
部署（deploy）：输出 RDF 序列化（Turtle / N-Triples / N-Quads / JSON-LD / RDF/XML）并写入 LOD 命名图。

工具是开源的 hra-do-processor（GitHub hubmapconsortium 组织下，MIT 许可），v2.2 时点版本 0.10.0。它同时支持 Docker 镜像（ghcr.io/hubmapconsortium/hra-do-processor）与 CWL 工作流两种运行方式——前者给单机复现，后者给集群批处理。

这一步的工程意义在于：它让「专家用 Excel 维护表」与「机器用 SPARQL 查询图」这两件事解耦。专家不需要懂 RDF，程序员不需要懂组织学，中间由处理器保证一致性。这也是 HRA 能维持每年两版节奏的组织前提。

3.5 构建成本与扩展性

论文给出一个很实在的数字：在 256 GB 内存、20 核的本地 Linux 服务器上，从原始数字对象全量重建 KG 约需 13 小时。并行化的初步实验显示执行时间可再减少约三分之一。

对比 125.84 GB 的输出体积，13 小时的重建时间意味着：任何人只要有足够内存的机器，都能在一天内复刻整张图。这是 CC BY 4.0 + 开源处理器共同带来的可验证性，也是 HRA KG 与「只在云端提供 API 的黑箱图谱」的根本区别。

§4 规模解剖：1006 万节点里装的是什么

4.1 两个互相矛盾的统计口径

论文里有两个完全不同的规模数字：

出处	节点	边	体积
摘要 / 正文 / Zenodo 描述	10,064,033	171,250,177	125.84 GB
Table 3（与其他图谱横向对比）	1,543,074	101,720,865	30,848 MB

同一条目内相差 6.5 倍。合理的解释是：Table 3 的行对应的是某一特定构建/统计方式（可能是仅参考层、或某一较早的快照），而摘要用的是完整 KG 的统计。论文没有显式说明差异来源，这属于必须存照的双口径（坑 1）。

对使用者的建议：引用时统一用摘要口径（10,064,033 / 171,250,177 / 125.84 GB），并在脚注注明「Table 3 另有 1,543,074 口径」。

4.2 边从哪来：谓词分布

节点数只是表象，真正决定查询成本的是边的类型分布。论文的对比表与我们的端点实测给出了一致的图像：

节点数只是表象，真正决定查询成本的是边的类型分布。论文的对比表与我们的端点实测给出了一致的图像，按量级从高到低排：rdf:type 实体类型断言约 809 万条，rdfs:label 人类可读标签约 291 万条，rdfs:subClassOf 本体层级约 216 万条，ccf:record_number（ASCT+B 表的行号）约 207 万条，ccf:ccf_pref_label 与 ccf:order_number（图谱内规范标签与排序号）各约 190 万条，ccf:source_concept（指向源本体的概念）约 179 万条，RO:0002131（overlaps，空间重叠）约 163 万条，oboInOwl:hasDbXref（本体交叉引用）约 152 万条。

这组比例解释了为什么「1,006 万节点」听起来很大而实际内容并不庞大：绝大部分边是本体内部的层级、标签与交叉引用，真正的「生物学断言」（某细胞类型位于某结构内、用某基因标记）在总量里占比远小。查询时如果不对命名图做限定，很容易被本体层的大量边淹没——一条本意是「找出所有细胞类型」的查询，可能先命中几十万条 subClassOf。

这张表解释了为什么「1006 万节点」听起来很大而实际内容并不庞大：绝大部分边是本体内部的层级、标签与交叉引用，真正的「生物学断言」（某细胞类型位于某结构内、用某基因标记）占比远小。查询时如果不对命名图做限定，很容易被本体层的大量边淹没。

我们在 2026-10-17 对 v2.5 端点做的实测显示：不带命名图限定的 SELECT (COUNT(*) AS ?c) WHERE { GRAPH ?g { ?s ?p ?o } } 在 40 秒内无法完成。这说明 v2.5 的三元组规模已显著超过 v2.2 的量级——但具体数值未能取得，正文不做外推。

4.3 器官覆盖的性别与成对结构

71 个 3D 参考器官的构成中，性别维度值得单独说：

女性独有 5 个：输卵管、乳腺、卵巢、胎盘、子宫；
男性独有 1 个：前列腺；
成对结构（同一 Uberon ID、左右各一份网格）：眼、输卵管、肾、膝、乳腺、卵巢、腭扁桃体、肾盂、输尿管。

这意味着「71 个器官」里并不是 71 个互不相同的解剖实体，而是「实体 × 性别/侧别」的组合。做统计时按 Uberon ID 去重，实际唯一器官数会低于 71。

4.4 与通用知识图谱的相对位置

论文 Table 3 把 HRA KG 与五个图谱并列：

论文 Table 3 把 HRA KG 与五个图谱并列，规模差异极大。按表内口径，HRA KG 是 1,543,074 个节点、101,720,865 条边、30,848 MB，技术栈为 RDF / SPARQL。同表的 SPARC KG 是 188,146 个节点、812,969 条边、789 MB，同样跑 RDF / SPARQL，但在体量上比 HRA KG 小两个数量级。Petagraph 是 32,192,544 个节点、151,690,690 条边、138,571 MB，跑在 Neo4J 上。UBKG（UMLS 本体知识图谱）最大，54,154,737 个节点、227,826,739 条边、162,895 MB，也是 Neo4J。Ubergraph 是 4,071,817 个节点、458,605,464 条边、96,450 MB，边数比 HRA KG 还多，因为是 RDF / SPARQL 的原生本体合并图。最小的是 ORKG（开放研究知识图谱），557,821 个节点、1,853,694 条边、437 MB，同样 RDF / SPARQL。

读这组数字的正确方式不是比大小，而是看边节点比：Ubergraph 约 112 倍，HRA KG 表内口径约 66 倍，UBKG 约 4 倍。边节点比高说明图谱以「关系密集的本体」为主，低说明以「属性密集的实体」为主。HRA KG 落在中间偏本体侧——它既是本体（层级），又是实例图（断言）。这一定位决定了它的查询成本结构与纯本体库不同：简单的一跳查询很快，跨层的多跳聚合会迅速撞上引擎的超时。

读这张表的正确方式不是比大小，而是看边节点比：Ubergraph 的边/节点约 112 倍，HRA KG 表内口径约 66 倍，UBKG 约 4 倍。边节点比高说明图谱以「关系密集的本体」为主，低说明以「属性密集的实体」为主。HRA KG 落在中间偏本体侧——它既是本体（层级），又是实例图（断言）。

4.5 与本体生态的互补关系

一个必须澄清的误解：HRA KG 不是「又一个本体」。它与 Uberon/CL 的关系是「使用者」而非「竞争者」。论文专门统计了它对本体的回馈：向 Uberon 提交 162 个术语、向 CL 提交 155 个、向 PCL 提交 468 个。这个数字链说明的是双向关系——HRA 从本体借术语，也把组织学编纂过程中发现的缺失术语反哺给本体。

对使用者的实操含义：如果你的查询需要「某细胞类型的上位概念」，去 CL/Uberon 查；如果需要「某器官里到底有哪些细胞类型、用什么标记」，来 HRA KG。两者是不同层次的资源。

4.6 v2.5 的增量：从目录口径看增长方向

2026-10-17 实测的 LOD 目录计数与 v2.2 论文的对照：

对象	v2.2（论文，单版本）	v2.5（LOD 目录，含历史版本）	观察
ASCT+B 表	33	41	目录含跨版本，实际新增有限
OMAP	23（13 器官）	38	增长最快的一类，覆盖到脑、卵巢、食管等
2D FTU	22（10 器官）	29（26 个真 FTU）	仍是肾/肺/胰/肠为主
3D 参考器官	71	88	成对结构拆分与新增器官共同贡献
地标	59 组	61 组	基本稳定

OMAP 从 23 增至 38 的增速明显快于其他类别，原因不难理解：抗体面板是「可增量交付」的——新做一套 CODEX 或 IMC 实验就能产出一份 OMAP，不需要等待整个器官的解剖学编纂。而 ASCT+B 表必须以器官为单位整体修订，周期长得多。

这一结构性差异给使用者的提示是：如果你要找的是「某器官的多重成像方案」，HRA KG 的 OMAP 分支更新最快、覆盖最广；如果你要找「某器官的完整细胞类型清单」，ASCT+B 是唯一来源但更新更慢。

§5 hra-pop：把实验数据挂上参考坐标

5.1 为什么参考图谱还需要「实例」

到此为止描述的一切都是「参考层」：解剖结构该长什么样、该有哪些细胞、该用什么标记。但研究者打开 HRA KG 时，真正想问的问题往往是实例级的：

左肾皮质里有 CD4+ T 细胞吗？丰度大概多少？
我手上这批 scRNA-seq 数据，按 HRA 的坐标更可能来自肾皮质还是髓质？
全肺的细胞类型组成，和别的数据集比，差异是生物学差异还是来源差异？

回答这些问题需要把实验结果挂进参考坐标。这正是 hra-pop（HRA + population）的职责：它是 HRA 的「数据集图」分支（ds-graph 类型 DO），把各门户的数据集、样本、供体、注册位置与细胞类型丰度编译成可查询的图。

5.2 hra-pop v1.1 的实测画像

2026-10-17 直接下载 hra-pop/v1.1/graph.jsonld（2.7 MB）并统计：

2026-10-17 直接下载 hra-pop/v1.1/graph.jsonld（2.7 MB）并逐项统计，结果如下：图内被引用的实体总数（去重后的 subject）为 2,308 个；其中 Dataset 实体 807 个，Sample（组织块）实体 663 个，Donor 实体 175 个（男 92、女 83）；SpatialEntity 与 SpatialPlacement 各 289 个；按 UBERON ID 计覆盖 19 个器官；把所有带 cell_count 的数据集求和，细胞总数为 55,915,650。

把这七个数字放在一起看，可以读出两层结构。第一层是「数据集多于样本多于供体」的 807 → 663 → 175 漏斗，说明大量数据集共享同一块组织、同一份供体，定量统计时若按数据集简单平均会放大高频供体的权重。第二层是空间实体与数据集数量的错位：289 个空间放置点对应 807 个数据集，意味着平均每个位点挂了两三个数据集，这正是「按位点聚合」在方法上可行的前提。

器官分布高度集中：肾 207、肺 153、心 108、大肠 35、小肠 33、肝 31、子宫 23、膀胱 12；另有 164 个数据集未带 organ_id（多为泛组织或来源未标注）。技术分布同样集中：RNAseq 519、Slide-seq 112、CODEX 70、MxIF 27、Visium（无探针）23、PhenoCycler 16、GeoMx 12、Cell DIVE 10、OTHER 18。

门户来源：HuBMAP 485、SenNet 128、DOI 直链 105、CZ CELLxGENE 41、HTAN 29、GTEx 14、LungMAP 3、cycif.org 2。

5.3 hra-pop 与 hra-pop-full：精度与广度的两难

HRA 同时发布两个版本的数据集图，这个设计本身就是重要信息：

| hra-pop | 807 | 663 | 175 | 19 | 55,915,650 | HuBMAP、SenNet、CxG、HTAN、GTEx 为主 |
| hra-pop-full | 47,792 | 40,394 | 32,047 | 308 | 280,346,192 | 增加 ImmuneSingleCell、KPMP、GEO、bioRxiv 等 |

（hra-pop-full 为 93.8 MB JSON-LD；Donor 数为跨门户去重前口径，同一供体在多个门户注册会重复计数。）

两个版本的分工是清晰的。hra-pop 是「已人工质控、已做细胞类型对齐」的精选集：它小，但每个数据集都经过 Azimuth / CellTypist / popV 等工具注释并与 ASCT+B 表做了本体交叉对齐，适合做统计与可视化（HRA 的 Exploration User Interface 与 Cell Type Population Graphs 都读它）。hra-pop-full 是「能捞尽捞」的扩展集：47,792 个数据集、40,394 个样本、32,047 个供体、308 个 Uberon 器官 ID、2.803 亿细胞，质量参差、去重困难、注释未经统一校验，适合做覆盖度探索与跨库检索，不适合直接做定量比较。

对使用者的建议：做任何「细胞类型丰度」的定量结论必须用 hra-pop 而非 hra-pop-full；做「有没有这个器官的数据」的存在性检索可以用 full。

5.4 细胞类型注释三工具：Azimuth / CellTypist / popV

hra-pop 之所以能统计细胞类型丰度，前提是把各来源数据集的原始注释映射到统一词表。论文列出三种方法（外加 RUI 3D 注册与 OMAP 图像对齐，共五种映射路径）：

hra-pop 之所以能统计细胞类型丰度，前提是把各来源数据集的原始注释映射到统一词表。论文列出三种注释方法（外加 RUI 3D 注册与 OMAP 图像对齐，共五种映射路径）。Azimuth 由 Satija 实验室（NYGC）维护，基于 Seurat 参考映射，把查询单细胞投射到参考 UMAP 上再赋标签，是主力注释工具，与 HRA 的细胞类型层级配合最紧。CellTypist 由 Teichmann 实验室（EBI）维护，走逻辑回归分类器加大规模免疫细胞参考模型，主要用于免疫细胞注释的补充。popV 属于 HCA 生态的多工具共识投票方案，集成多个注释器做共识，用于降低单工具偏差。

三者的共同问题与论文的处理方式是关键：任何自动注释都会给出与专家不同的标签，因此 HRA 用 CTann（Cell Type Annotation Crosswalk）表把工具输出与 CL/PCL 术语做人工校订的交叉表，v2.2 覆盖 23 个器官，其中 12 个器官有多个工具的交叉表。这一层交叉表是把「工具注释」变成「可比统计」的必经环节。

5.5 两个官方 user story

论文与配套网站把 HRA KG 的典型用法浓缩成 USER STORY，其中前两条最能说明它的定位：

User Story 1：给定空间来源，预测细胞类型组成。
输入：一个 3D 提取位点（extraction site，即「从器官的哪一块取组织」）。输出：该位点可能包含的细胞类型及其丰度。机制：检索所有注册在该位点（或与其碰撞）的数据集，聚合其 cell summary。

User Story 2：给定细胞类型组成，反推空间来源。
输入：一组细胞类型丰度（例如来自一批未知来源的 scRNA-seq）。输出：最可能的解剖位置。机制：与 hra-pop 中各提取位点的细胞类型分布做匹配。

这两条 user story 的价值在于把「空间」与「组学」做成双向可查。对做空间转录组的研究者，这意味着可以用 HRA 做「我这个 spot 更像哪一层」的先验判断；对做经典 scRNA-seq 的研究者，这意味着即使样本已打散，也能给出解剖学上的概率推断。

5.6 数据缺口：无 organ_id 的 164 个数据集

实测 hra-pop 中 164 个数据集（约 20%）没有 organ_id 字段。这不是 bug，而是结构性的：很多数据集覆盖全身多器官（如 PBMC、外周血），或者原始门户未标注器官。这些数据集在图谱里存在、能被查到，但无法参与器官级的聚合统计。

使用者的应对：做器官级分析前先用 FILTER(?organId != 「」) 过滤；做全库检索时不要假设 organ 一定存在。这个 20% 的缺口是「参考图谱」与「真实世界数据」之间落差的直接体现。

§6 获取与许可：三条路怎么选

6.1 三种获取方式的适用场景

三条路的选择标准其实只有一条：需不需要把全量数据落到本地。SPARQL 端点（https://lod.humanatlas.io/sparql）适合需要精确关系查询、跨对象 join、且不打算落地全量的场景，代价是受端点性能与配额限制，复杂聚合可能直接超时。Zenodo 快照（概念 DOI 10.5281/zenodo.15323983，指向最新记录的 tar.xz）适合要离线复现、版本锁定、批量图分析的场景，代价是 v2.5 就有 7.7 GB，解压后更大，磁盘与内存都要预留。REST 与 LOD PURL（https://lod.humanatlas.io/<type>/<name>/<version>）适合只要单个数字对象的场景——某一版的表、某个 OMAP——代价是需要自己拼接 URL 且熟悉目录结构。

6.2 SPARQL 端点的实测表现

2026-10-17 实测结论（对使用者有直接参考价值）：

端点在线，ASK { <https://lod.humanatlas.io/collection/hra/v2.5> ?p ?o } 秒级返回 true；
谓词分布型聚合查询（GROUP BY ?p ORDER BY DESC(?n) LIMIT 12）可在数十秒内返回；
全量 COUNT(*)（含命名图通配）在 40 秒内无法完成。

这意味着：浅层查询（按 ID 取、按谓词聚合、限制 LIMIT）可用；跨全图的深层聚合应在本地 tape/解压后跑。这也是 HRA 提供 7.7 GB 打包下载的现实原因——端点不是为大规模分析设计的，它是为「精确取数」设计的。

6.3 版本管理：为什么必须锁版本

HRA 每年两次发布意味着：

latest 是滑动指针，今天解析到 v2.5，12 月可能变成 v2.6；
同一器官的表版本号独立演进（肾脏表已到 v1.8，而某些器官仍在 v1.2）；
论文引用的数字永远是某一快照（v2.2 = 2025-05 统计）。

工程上的铁律：任何要复现的分析，必须在代码里写死 PURL 的完整版本号，不用 latest。例如 https://purl.humanatlas.io/asct-b/kidney/v1.8 而不是 .../kidney/latest。

6.4 镜像：柏林与上海

官方列出两个数据镜像：

柏林：https://humanatlas.bihealth.org/mirror（BIH）；
上海：https://msdc.fudan.edu.cn/humanatlas-mirror（复旦大学医学大数据中心 MSDC）。

镜像的意义对中国用户尤其实际：全量 7.7 GB 从 Zenodo 下载在部分网络环境下缓慢，镜像可以显著改善。镜像的搭建本身也有 SOP（Zenodo DOI 10.5281/zenodo.17873664），意味着任何机构都可以自建镜像——这对需要长期归档的医院与研究机构是个可选项。

6.5 许可：CC BY 4.0 的实际含义

三点实操提醒：

CC BY 4.0 允许训练商业模型。这一点与大量 NC 许可的医学数据集形成鲜明对比，对产业用户是实质性利好。
署名要具体。官方要求引用论文（Sci Data 12:1100）+ 你实际用到的每个数字对象的 citation（含 Data DOI 10.48539/…）。只写「HRA」不够。
底层原始数据的许可不受 HRA 覆盖。HRA KG 本身是 CC BY 4.0，但图谱指向的 HuBMAP/SenNet 数据集各自有自己的许可与受控访问条款。参考层开放不等于数据层开放——这是最容易被误读的一条。

6.6 AI-Ready 检查单逐项核对

八项检查里，机器可读元数据、公开直链、许可明确、版本管理四项都评为优。机器可读这一项的判据是每个数字对象的 JSON-LD 都自带 title、license、citation、version、distribution 五个字段，不需要额外维护一张对照表。公开直链的判据是没有注册墙，PURL 与 CDN 直链稳定，Zenodo 可以直接下载。许可明确的判据是数据 CC BY 4.0、代码 MIT，并且逐条数字对象复查一致。版本管理更是同类中的优等生：每年两次固定日历、PURL 版本化、Zenodo 快照带 md5。

可复现性与文档完整度两项评为良。前者扣分不在设计而在门槛：处理器开源、构建时间与硬件都公开，但重建一次需要 256 GB 内存与 20 个核，普通团队很难在本地走完整条链路。后者扣分在分散：论文、配套网站、SOP、教程都齐，但部分端点文档散在 docs.humanatlas.io 的不同章节里，需要一点耐心才能拼全。

数据血缘与术语一致性两项只评为中。每个数字对象确实有作者与评审信息，但数据集图里实验数据的原始 DOI 并不统一暴露；术语方面十套本体并存再加上 TEMP 占位，跨对象 join 必须逐表确认。综合判断 AI-Ready 等级为高——这是本库少见的在公开直链、许可明确、版本管理三项全部拿满的条目，扣分项集中在血缘追溯与术语一致性这两个所有大型本体项目都绕不开的难点上。

§7 生态：一张图如何被使用

7.1 应用谱：从查询到教学

HRA 官方在同一套图谱之上构建了十余个应用，这些应用本身就是「图谱能做什么」的说明书。按面向角色归类，大致是四组。

面向开发者与数据管理员的是 Knowledge Graph Explorer：输入类型或器官筛选条件，输出可浏览、可筛选、可下载的数字对象与三元组，它是唯一能让人「看见 RDF 形状」的官方工具。面向找样本的研究者的是 Exploration User Interface（EUI）：给器官、性别、侧别三个参数，返回 3D 器官模型、已注册的组织块与落到块上的数据集，这是回答「这个器官的哪个部位有数据」最快的入口。与它成对的是 Registration User Interface（RUI），输入组织块尺寸与切片图像，输出 CCF 坐标、被碰撞的解剖结构以及 corridor，服务对象是做空间注册的实验室——RUI 产出坐标，EUI 消费坐标，两者构成一条闭环。

面向组学研究者的是两个预测器。Cell Type Population Predictor 吃空间位点、吐细胞类型组成预测（官方 User Story 1）；Tissue Origin Predictor 反过来，吃细胞类型丰度、吐解剖位置推断（User Story 2）。这一对的意义在于把图谱从「查询对象」变成了「推理先验」——它们证明 HRA KG 里的结构-细胞-标记关系足以支撑逆向推断。

面向教学与表编纂的是 Functional Tissue Unit Explorer、ASCT+B Reporter 与 HRA Organ Gallery。FTU Explorer 给器官与功能单元，出二维插图加关联细胞与标记，是病理教学最常用的参照；ASCT+B Reporter 把表渲染成交互式树，是表编纂者与评审人自查层级是否断裂的主要手段；Organ Gallery 则是器官选择加沉浸式 3D 浏览，用于展示与科普。最后两个偏分析工具：Cell Distance Explorer 输入位点对、输出细胞类型距离矩阵，Dashboard 汇总全局的 DO 数量、器官覆盖与 KG 增长曲线，供项目管理使用。

这个应用谱揭示了一个设计哲学：同一张图，不同的「视图」服务不同角色。表编纂者看树，组学研究者看预测，样本管理者看 3D 位置，工程师看三元组。图谱本身不带观点，观点由应用层提供。这也解释了为什么 HRA 论文把「应用」与「图谱构建」并列为同等重要的贡献——没有应用层的分流，一张 171M 边的图对绝大多数用户等同不可用。

这个应用谱揭示了一个设计哲学：同一张图，不同的「视图」服务不同角色。表编纂者看树，组学研究者看预测，样本管理者看 3D 位置，工程师看三元组。图谱本身不带观点，观点由应用层提供。

7.2 联盟结构：为什么需要 26 个联盟

HRA 落地页当前标注 26 个联盟、81 名以上专家、270 篇以上相关出版物。论文写「25+」，Zenodo 写「20+」——三个数字同时存在（坑 4）。

联盟结构的必要性来自数据来源的分散：HuBMAP 的 CODEX 与 scRNA-seq、SenNet 的衰老组织、KPMP 的肾脏穿刺、GUDMAP 的发育泌尿生殖系统、GTEx 的正常组织表达、HTAN 的肿瘤（作为对照）、HCA 的全球单细胞数据。没有任何单一机构能覆盖这些来源，所以必须靠联盟协议把它们挂到同一套术语下。

对使用者的含义：HRA KG 的「完整性」本质上是联盟覆盖度的函数。某个器官在图谱里薄弱，往往不是技术问题而是「没有联盟成员在供这个器官的数据」。

7.3 与本库其他条目的生态位关系

HRA KG 在本库里不是孤立条目，它与六条已有条目存在明确的上下游关系。HuBMAP（rid 517） 是直接上游，既是主要数据来源也是联盟母体：HuBMAP 提供原始数据与门户，HRA KG 提供参考坐标与对齐结果，两者的分工是「采集」与「定位」。Human Cell Atlas（rid 319） 是平行联盟，数据经 CELLxGENE 汇入 hra-pop，HCA 侧重全球样本覆盖，HRA KG 侧重解剖坐标下的可定位性。

KPMP（rid 512） 是联盟成员，也是肾脏数据的主要来源之一；KPMP 专注肾病病理，HRA KG 专注健康参考，二者在「病 vs 常」上互补。GTEx（rid 568） 作为正常组织表达数据的来源之一，在 hra-pop 中贡献了 14 个数据集；GTEx 给的是组织层面的表达谱，HRA KG 给它的是组织学定位与细胞类型分解。Tabula Sapiens（rid 329） 的数据可经 CELLxGENE 进入 hra-pop-full，提供多器官单细胞基线。CZ CELLxGENE（rid 38） 则是数据门户本身：hra-pop 中有 41 个数据集来自 CxG，hra-pop-full 中高达 12,227 个——CxG 是数据仓，HRA KG 是解剖索引。

一句话概括生态位：HuBMAP/HCA/GTEx 等提供「有什么」，HRA KG 提供「在哪里、是什么细胞、用什么标记」。它们是数据层与语义层的关系，不是竞争关系。这也意味着在千方库内做跨条目引用时，HRA KG 天然适合作为「空间与语义的锚点」，而其余条目适合作为「证据量的来源」。

一句话概括生态位：HuBMAP/HCA/GTEx 等提供「有什么」，HRA KG 提供「在哪里、是什么细胞、用什么标记」。它们是数据层与语义层的关系，不是竞争关系。

7.4 引用与致谢规范

官方要求使用 HRA 数据时：

引用论文：Bueckle A, Herr BW II, Hardi J, Quardokus EM, Musen MA, Börner K. Construction, Deployment, and Usage of the Human Reference Atlas Knowledge Graph. Sci Data 12:1100 (2025). doi:10.1038/s41597-025-05183-6；
引用你实际使用的每个数字对象的 citation（JSON-LD 里的 schema1:citation，含 Data DOI 如 10.48539/HBM342.NFDL.535）；
若用了 KG 快照，引用 Zenodo 概念 DOI 10.5281/zenodo.15323983 并注明版本（如 v2.5）。

这三条与 CC BY 4.0 的署名义务叠加，构成实际的操作规范。只引论文不引 DO，在 HRA 的规范里算不完全引用——因为论文不承载具体版本的表格内容。

§8 使用方法：三条可落地的技术路线

8.1 路线一：SPARQL 精确取数（不需要下载全量）

适合「我要某器官某细胞类型的所有标记基因」这类问题。骨架如下（示意，非官方逐字）：

PREFIX ccf: <http://purl.org/ccf/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?asLabel ?ctLabel ?geneLabel
WHERE {
  ?record a ccf:AsctbRecord ;
          ccf:as_label ?asLabel ;
          ccf:ct_label ?ctLabel ;
          ccf:gene_label ?geneLabel .
  FILTER(CONTAINS(LCASE(?asLabel), 「glomerulus」))
}
LIMIT 200

三条实战守则：

先 ASK 再 SELECT：用 ASK 确认某个谓词存在，比盲写 SELECT 快十倍；
务必带 LIMIT：无 LIMIT 的查询在 1000 万级图上极易超时；
限定命名图：如果端点支持 GRAPH，用它把范围压到某个 DO，避免扫到本体层的百万级边。

8.2 路线二：本地全量 + DuckDB（适合批量分析）

论文明确推荐了这条路径：先用 SPARQL 把数据取成长表，再导入 DuckDB 用 SQL 做窗口函数与聚合。对需要重复查询的研究，本地方案比端点稳定得多。

基本流程：

从 Zenodo 下载对应版本的 hra-kg.vX.Y.tar.xz（v2.5 为 7.7 GB）；
解压得到各 DO 的 RDF 序列化文件；
用 rdflib / RDFLib-Neo4j / Apache Jena 等解析为三元组表；
导入 DuckDB 或 PostgreSQL，建立 (subject, predicate, object) 表并加索引；
在此之上写 SQL，或导出为 Parquet 供 pandas/Polars 读取。

硬件门槛：论文的构建环境是 256 GB 内存 + 20 核。仅查询不需要这么高，但解压后的磁盘占用会显著大于 7.7 GB，规划时按 40-60 GB 预留。

8.3 路线三：以图为约束的下游模型（研究向）

HRA KG 最有研究价值的用法不是「查它」，而是「用它约束别的模型」。三个可操作的方向：

（a）细胞类型注释的约束后处理。
自动注释器（Azimuth/CellTypist）给出候选标签后，用 HRA KG 检查「该细胞类型在同一解剖结构里是否有记录」。若没有，则降低该标签的置信度。这把解剖学先验注入注释流程，是 hra-pop 与 CTann 之外的一条补充路径。

（b）图嵌入增强的表征。
把 CL 术语作为节点、ASCT+B 关系作为边，训练图神经网络得到细胞类型的拓扑嵌入，作为下游分类器的先验特征。这类工作在小样本场景下常有收益，因为本体层级本身编码了「哪些细胞类型更相似」。

（c）LLM 的检索知识库（RAG）。
把 ASCT+B 表、OMAP 面板、FTU 描述导出为结构化文本片段，构建检索索引。当用户问「肾小体的壁层上皮细胞用什么标记」时，检索到的是带 DOI 的一手表内容，而不是模型幻觉。相比直接把论文喂给 LLM，这种方式的可追溯性高一个量级。

8.4 反模式：三个不该做的事

不要把它当作「细胞类型数据库」直接比较数量。2,268 个细胞类型是 HRA 编纂范围内的计数，不是人体细胞类型的全貌；CL 本身收录数更多，PCL 更杂。
不要用 hra-pop-full 做定量统计。跨门户去重前口径会让丰度虚高，且注释未统一校验。
不要把 hra-pop 的细胞丰度当作「真实人体比例」。它是「已注册数据集的加权平均」，受采样偏差严重影响——肾数据集多，肾的细胞类型就自然更细。

§9 与库内条目的关系

9.1 家族图谱

HuBMAP（rid 517）：直接上游与联盟母体。HuBMAP 条目讲数据门户与采集技术，本条目讲这些数据之上的参考层。两篇连读才能完整理解「HuBMAP 生态」——一篇回答「有多少数据」，一篇回答「如何统一定位」。
Human Cell Atlas（rid 319）：平行联盟。HCA 侧重全球人群覆盖与细胞类型发现，HRA KG 侧重解剖坐标与空间注册；两者的数据经 CxG 门户互通（hra-pop 中 41 个、hra-pop-full 中 12,227 个数据集来自 CxG）。
KPMP（rid 512）：肾脏精准医学项目的联盟成员。KPMP 提供肾病穿刺数据（hra-pop-full 中 680 个），HRA KG 提供肾脏的 ASCT+B 表（v1.8）与 FTU 插图——肾脏是 HRA 覆盖最深的器官，8 个 2D FTU 冠绝全部器官，这与 KPMP 的投入直接相关。
GTEx（rid 568）：正常组织表达数据源，hra-pop 中 14 个数据集、hra-pop-full 中 74 个。GTEx 提供转录组，HRA KG 提供组织学定位。
Tabula Sapiens（rid 329）：多器官单细胞图谱，可经 CxG 进入 hra-pop-full，作为细胞类型基线。
CZ CELLxGENE（rid 38）：数据门户与 schema 标准。HRA KG 与其共享「用 Cell Ontology 做细胞类型词表」的底层约定。

9.2 检索路径建议

四条路径覆盖了绝大多数检索需求。想找某器官的细胞类型清单，直接取该器官的 ASCT+B 表（purl.humanatlas.io/asct-b/<organ>/<version>），不要一上来就 SPARQL 全库搜索——全库搜索既慢又容易漏掉版本差异。想找某器官的多重成像方案，看 OMAP（purl.humanatlas.io/omap/<id>/<version>），注意面板是按器官分版本的，同一器官可能存在多个面板（肾脏就有 CODEX、CYCIF、IMS-CODEX 等数个）。想做空间位置推断，用 Tissue Origin Predictor，或者直接读 hra-pop 的 cell summary，两者都能给出概率性的器官归属。想引用，引论文加数字对象的 Data DOI，不要只引 Zenodo 概念 DOI——后者指向的是一组版本，读者无法知道你用的是哪一版。

9.3 与库内「组织学参考类」条目的边界

本库中与 HRA KG 同属「参考/标准」性质的条目不多，容易被混淆的有两类：

医学影像参考图谱（如各类解剖图谱数据集）：这些提供的是影像，HRA KG 提供的是术语与坐标；前者可被后者标注，但两者不是替代关系。
本体资源（Uberon、CL 等）：HRA KG 消费它们，不与之竞争。若需要本体本身，应查 EBI OLS、BioPortal 等镜像，而非 HRA KG。

判断标准很简单：问「这个实体在哪里、由什么细胞组成、用什么标记」→ 用 HRA KG；问「这个词的上位概念是什么」→ 用本体。

§10 避坑清单：十个已踩过的坑

坑 1：规模数字有两套口径，不能混用。
论文摘要、正文、Zenodo 描述都写 10,064,033 节点 / 171,250,177 边 / 125.84 GB；但同一篇论文的 Table 3 在与其他图谱横向对比时写的是 1,543,074 节点 / 101,720,865 边 / 30,848 MB。相差 6.5 倍，论文没有显式解释差异来源。引用时统一用摘要口径并注明出处；若与他人讨论时数字对不上，先问「你引的是摘要还是 Table 3」。

坑 2：LOD 目录数与论文实体数不是一回事。
LOD 目录页（lod.humanatlas.io/asct-b 等）的计数是全版本累积：同一个肾脏表有 v1.0 到 v1.8 共 9 个节点，都被计入「41 个 ASCT+B 目录」。论文的 33 张是某一版本内的实体数。所以「LOD 显示 38 个 OMAP，论文说 23 个」不是矛盾，而是两种计量方式。做覆盖统计前先决定用哪个口径。

坑 3：hra-pop 与 hra-pop-full 的细胞数差 5 倍，不能互换。
hra-pop v1.1 实测 807 个数据集、5,591 万细胞；hra-pop-full v1.1 实测 47,792 个数据集、2.80 亿细胞。前者经过人工质控与注释对齐，后者是「能捞尽捞」。用 full 做丰度统计会得到虚高的数字。定量结论只认 hra-pop。

坑 4：联盟数有三个版本。
落地页写 26 个联盟，论文写 25+，Zenodo 描述写 20+。不是谁错，而是时点不同（落地页最实时）。引用时写「论文时点 25+，2026 年落地页标注 26」。

坑 5：latest 是滑动指针，会毁掉可复现性。
purl.humanatlas.io/asct-b/kidney/latest 今天指向 v1.8，12 月可能变 v1.9。所有要复现的分析必须写死版本号。另有一层实操陷阱：PURL 走内容协商，用 curl 裸请求不带 Accept: text/turtle 或 application/ld+json 时会拿到 404，同样的地址在浏览器里却能打开——这不是数据缺失，是协商失败。实测：purl.humanatlas.io/asct-b/kidney/latest 带 Turtle 头返回 200，不带则 404。

坑 6：ASCT+B 表里大量 AS 没有本体 ID。
实测肾脏表 v1.8：78 个数据行折叠出 74 个 AS 节点，但只有 11 个带 UBERON ID。其余是什么？是自由文本的中间层结构（「肾小体」「髓放线」「乳头」）与未获术语的细分。如果你的 pipeline 依赖本体 ID 做 join，会有大量行被静默丢弃。 必须显式处理空 ID 行。

坑 7：PCL 与 TEMP 是「未完成」标记，不是分类。
v2.2 有 221 个 TEMP-CT、951 个 TEMP-AS、296 个 TEMP-B。这些实体能被查出来、能在图上看到，但不能与外部本体直接对接。把「图谱能查到这个细胞类型」当成「这个细胞类型已被公认」是常见误读。

坑 8：参考层 CC BY 4.0 不代表底层数据也开放。
HRA KG 全部数字对象是 CC BY 4.0，可以商用、可以训练模型。但它指向的 HuBMAP/SenNet/KPMP 原始数据集各有各的许可与受控访问（很多需要 dbGaP 审批）。「我用了 HRA KG」不等于「我拿到了 HRA KG 指向的数据」。

坑 9：SPARQL 端点的通配 COUNT 会超时。
实测：不带命名图限定的 SELECT (COUNT(*) AS ?c) WHERE { GRAPH ?g { ?s ?p ?o } } 在 40 秒内无法完成；深层的 FILTER(CONTAINS(...)) 跨全图聚合会返回 504 Gateway Timeout。端点适合「按 ID 精确取」，不适合「全图统计」。 后者要下载 tar.xz 本地跑。

坑 10：hra-pop 中约 20% 的数据集没有 organ_id。
807 个数据集中有 164 个缺 organ_id 字段——原因包括纯外周血样本、多器官混合、门户未标注。做器官级聚合前必须过滤，否则会有 20% 的数据「消失」且不报错。这类静默丢失在跨库整合里最难排查。

FAQ（高频问答 30 问）

A. 基础认知

Q1：HRA KG 是数据集还是知识图谱？
两者都是。形式上它是 RDF 知识图谱，用途上它是可下载可引用的数据集（Zenodo 有 DOI、有版本、有 md5）。

Q2：它和 Wikidata、UBKG 有什么不同？
Wikidata 是通用图谱，UBKG 是 UMLS 本体图谱，HRA KG 专注「健康成人的解剖-细胞-标志物」这一个垂直域，并额外携带 3D 空间坐标与抗体面板。领域专精度是它的特点，规模不是。

Q3：为什么叫「参考」（Reference）？
因为描述的是正常状态下的规范模型，不是某一个人或某一批样本的观测结果。它与「实验数据」的关系是坐标系与坐标点。

Q4：它是 HuBMAP 独有的吗？
不是。HuBMAP 是牵头方与出资方，但 SenNet、KPMP、GUDMAP、NIDDK 共同开发，落地页标注 26 个联盟参与。

Q5：谁维护？迭代快吗？
Indiana 大学 CNS 与 Stanford BMIR。每年 6-15 与 12-15 各发一版，2026-06 是第 11 次发布（v2.5）。

B. 数据与获取

Q6：最小可用下载是什么？
只要一个器官的表：https://purl.humanatlas.io/asct-b/<organ>/<version> 下的 CSV，几十 KB。要全量：Zenodo tar.xz，7.7 GB。

Q7：不下载能查吗？
能。SPARQL 端点、REST API、各种 Web 应用都可用。端点适合精确查询，不适合大规模聚合。

Q8：国内访问慢怎么办？
官方列出上海镜像（复旦 MSDC：msdc.fudan.edu.cn/humanatlas-mirror）与柏林镜像（humanatlas.bihealth.org/mirror）。

Q9：可以商用吗？
可以，CC BY 4.0 允许商用。但必须署名（引论文 + DO 的 Data DOI）。

Q10：能用来训练模型吗？
CC BY 4.0 允许。实际用法更偏向「约束/检索/先验」而非直接监督训练（§8.3）。

Q11：有 API 文档吗？
有，docs.humanatlas.io/dev/api；SPARQL 的常见查询有 grlc.io 封装（apps.humanatlas.io/api/grlc/）。

Q12：数据多久过期？
不会过期，但会过时。历史版本永久保留在 Zenodo（每个版本一个记录号），可以随时回到旧版复现。

C. 内容与结构

Q13：71 个器官是怎么数的？
指 3D 参考器官数量，含成对结构（左右各一）与性别特有器官（女 5、男 1）。按 Uberon ID 去重后唯一器官数小于 71。

Q14：2,268 个细胞类型是全人体的吗？
不是。是 HRA 编纂范围内的计数，且其中 221 个仍是 TEMP 占位。CL 本身的收录范围不同，不能直接比较。

Q15：ASCT+B 的 B 是基因还是蛋白？
两者都有。BGene 用 HGNC，Protein 用 UniProt。肾脏表 v1.8 实测 190 个 HGNC 基因。

Q16：OMAP 和 ASCT+B 什么关系？
ASCT+B 说「有什么细胞」，OMAP 说「用什么抗体能看见它们」。OMAP 的 rationale 列会引用具体 ASCT+B 表版本。

Q17：3D 参考器官是什么格式？
GLB（glTF 二进制）。v2.2 时 71 个文件合计 301 MB，地标 261 MB。

Q18：什么是 millitome？
一种 3D 打印的组织切片夹具模板，把器官按固定网格切成可复现的小块，每块有稳定编号。用于大规模取样的一致性。

Q19：corridor 是什么？
当组织块的注册位置与多个解剖结构相交时，表示「这个组织块可能源自这几个结构中的任意一个」的候选集合概率分布。

Q20：collision summary 是什么？
记录注册组织块与 3D 解剖结构的相交关系，包含相交体积与占比——用来判断一个组织块到底属于哪一层。

D. 使用与技术

Q21：我该先学 SPARQL 吗？
不必。多数场景用图应用（EUI、FTU Explorer）或直接下 CSV 更快。SPARQL 只在需要跨对象 join 时才必要。

Q22：能直接导入 Neo4j 吗？
可以。RDF 到属性图有标准转换路径（如 neosemantics），但要处理命名图与字面量类型。

Q23：Python 怎么读？
rdflib 读 Turtle/N-Triples；或直接用 pandas 读导出的 CSV；或调 REST API 取 JSON-LD。

Q24：为什么我的查询查不到细胞类型？
三个常见原因：用了 CL 的 ID 但表里是 PCL/TEMP；器官名拼写与图谱不一致；没限定版本导致查到的是老版表。

Q25：怎么引用单个表？
用表里自带的 Data DOI（如 10.48539/HBM342.NFDL.535）与 schema1:citation 的作者列表。

Q26：v2.2 与 v2.5 的差别大吗？
结构上稳定（同一套 13 类 DO 与三层子图），规模与覆盖有增长（OMAP 从 23 增至 38 个目录项）。论文只覆盖到 v2.2，v2.5 无对应论文，引用 v2.5 时应以 Zenodo 记录为准。

E. 生态与关联

Q27：它与 Human Cell Atlas 是什么关系？
平级联盟，数据互通（经 CxG 门户）。HCA 侧重人群多样性与细胞类型发现，HRA KG 侧重解剖坐标。

Q28：KPMP 的肾病数据在 HRA 里吗？
KPMP 的组织块注册进 HRA 坐标，但疾病数据不是 HRA 主体（HRA 只描述健康成人）。hra-pop-full 中有 680 个来自 KPMP 的数据集。

Q29：能做疾病图谱吗？
不能直接用。HRA 是健康参考，疾病需要通过 HTAN 等肿瘤图谱或 KPMP 的病变数据另建映射。

Q30：未来会扩到儿科吗？
论文与落地页均未承诺。当前范围明确写「healthy adult」。

事实清单（硬事实 40 条，按主题归并）

四十条硬事实按主题归成八组。每组前半段陈述事实，后半段说明这条事实的来源与口径；凡有双口径的，两组数字都列出，不做取舍。

一、身份与发表（第 1-3 条）

官方全称是 Human Reference Atlas Knowledge Graph，项目代号 hra-kg。主论文为 Bueckle A、Herr BW II、Hardi J、Quardokus EM、Musen MA、Börner K 六人合著的《Construction, Deployment, and Usage of the Human Reference Atlas Knowledge Graph》，刊于 Scientific Data 第 12 卷文章号 1100，2025 年 7 月 1 日出版，DOI 为 10.1038/s41597-025-05183-6。卷期与文章号经 Crossref API 核实，许可为 CC BY 4.0，参考文献 114 条。作者机构分属两地：Indiana University 的 Cyberinfrastructure for Network Science Center 与 Stanford 的 BMIR。

二、规模与口径（第 4-6 条）

v2.2 的规模数字是 10,064,033 个节点、171,250,177 条边、125.84 GB，出自论文摘要并与 Zenodo 记录描述一致。但同一篇论文的 Table 3 在横向对比时给的是 1,543,074 个节点、101,720,865 条边、30,848 MB，与摘要相差约六点五倍，论文未显式解释。本条目统一采用摘要口径，并在避坑清单第 1 条与附录 I 中存照。两条口径之外还有一个时点差异：论文正文写统计于 2025 年 5 月，Zenodo 摘要写 2025 年 4 月。

三、覆盖范围（第 7-9 条）

v2.2 覆盖 71 个器官、5,800 个解剖结构、2,268 个细胞类型、2,531 个生物标志物。这组数字的计数方式需要留意：71 指的是三维参考器官文件数，包含左右成对结构与性别特有器官，按 Uberon ID 去重后唯一器官数小于 71；2,268 个细胞类型是 HRA 编纂范围内的计数，其中 221 个仍是 TEMP 占位，不能理解为人体全部细胞类型。官网落地页另有一组教学精选计数（27 器官、1,323 个 AS、621 个 CT、378 个 B），与论文口径不同，本条目不采用。

四、数字对象存量（第 10-15 条）

v2.2 有 13 类数字对象共 703 个独立 DO。其中 ASCT+B 表 33 张（32 个器官加 1 个解剖系统），OMAP 23 个覆盖 13 个器官，2D FTU 22 个覆盖 10 个器官（肾脏独占 8 个），三维参考器官 71 个（GLB 文件合计 301 MB），地标覆盖 59 个器官（261 MB），三维解剖结构 1,224 个，CTann 交叉表覆盖 23 个器官（其中 12 个器官有多工具交叉），另外记录了 11,698 个单细胞数据集。

五、本体增量（第 16-18 条）

v2.2 相对上一版的本体增量是：Uberon 增加 162 个术语，CL 增加 155 个，PCL 增加 468 个（其中 461 个用于人脑）。增量最大的 PCL 集中在脑，说明过去一年编纂资源向神经系统倾斜。尚待补齐的占位术语为 221 个 CT、951 个 AS、296 个 B，这组数字是衡量「语义完备度」最直接的指标。

六、工程与获取（第 19-24 条）

全量重建在 256 GB 内存、20 核的 Linux 本机上进行，约需 13 小时，这是使用者在本地复现构建时必须预留的资源量级。发布节奏为每年两次，固定在 6 月 15 日与 12 月 15 日。现行版本 v2.5 是第 11 次发布，Zenodo 记录创建于 2026 年 6 月 15 日，快照文件 hra-kg.v2.5.tar.xz 为 7.7 GB，md5 为 1bc5cdcf52a41754f7639ba580bc0e6c。概念 DOI 是 10.5281/zenodo.15323983，每次发布生成一个具体记录号，v2.5 对应 20671829。

七、许可与代码（第 25-30 条）

数据许可为 CC BY 4.0，覆盖全部 HRA 数字对象与知识图谱导出，LOD 上逐条数字对象的 dct:license 实测与之一致。代码许可为 MIT，仓库为 hubmapconsortium/hra-kg 与 hubmapconsortium/hra-do-processor。论文本身也是 CC BY 4.0。需要强调的是：参考层开放不等于底层数据开放，HRA KG 指向的 HuBMAP、SenNet、KPMP 原始数据集各有各的访问控制。

八、实测核对（第 31-40 条）

以下数字来自 2026 年 10 月 17 日当日的实测，与论文的 v2.2 口径分属不同版本，不可混用。LOD 目录页计数为 ASCT+B 41、OMAP 38、2D FTU 29、参考器官 88、地标 61、CTann 10、millitome 13、数据集图 7，这些是全版本累积目录，数量高于单版本实体数。肾脏 ASCT+B 表 v1.8 下载后统计得 78 个数据行、折叠为 74 个 AS 节点、67 个 CL 术语、190 个 HGNC 基因，其中仅 11 个 AS 带 UBERON ID。OMAP-3 的 v1.4 版本含 24 支抗体、9 个成像循环，其中 15 支来自 Abcam。hra-pop v1.1 实测 807 个数据集、663 个样本、175 位供体、19 个器官、55,915,650 个细胞；hra-pop-full v1.1 实测 47,792 个数据集、40,394 个样本、32,047 个供体、308 个器官、280,346,192 个细胞。SPARQL 端点上一条 ASK 查询约需 20 秒，不带命名图限定的全图 COUNT 在 40 秒内无法完成，深层 CONTAINS 聚合会返回 504。

术语表（30 条，按用途分四组）

本表不复述词典式定义，而是把每个术语放回它的使用场景里，说明「遇到这个词时你该想到什么」。三十条分成四组：结构与坐标、本体与标识符、数字对象与工具、数据层与许可。

结构与坐标（7 条）

HRA（Human Reference Atlas，人体参考图谱）是本条目描述的整体对象：一套覆盖健康成人的跨尺度解剖、细胞与分子参考模型。它不是一个文件夹，而是一整套「表 + 图 + 三维模型 + 词表」的组合，物理上分散在 CDN、Zenodo 与多个 Web 应用里。HRA KG 则是这套组合的 RDF 形式化发布，项目代号 hra-kg；读者若在 GitHub 上搜 hra-kg，找到的往往是构建代码而非数据本身，数据在 Zenodo 的快照里。

ASCT+B 是 Anatomical Structures, Cell Types, plus Biomarkers 的缩写，直译是「解剖结构、细胞类型、外加生物标志物」。它是 HRA 的编纂方法论，也是产出物——每张表以三列主干（AS/1、CT/1、B/1）为骨架，右侧再挂 2 到 6 列层级与标志物扩展列，形成一棵可以逐行展开的树。看到 ASCT+B 就该想到「这是一张由专家手工维护的树表，不是查询结果」。

AS、CT、B 分别是 ASCT+B 的三个层级：解剖结构（Anatomical Structure）、细胞类型（Cell Type）、生物标志物（Biomarker，可以是基因、蛋白或脂质）。这三个缩写在本条目里出现频率最高，读到「78 行折叠出 74 个 AS」时，指的是同一张肾脏表里去重后的解剖结构节点数。

CCF（Common Coordinate Framework，通用坐标框架）是 HRA 的空间本体，回答「这块组织在器官的哪个位置」。CCFO 是它的本体实现，从 v2.0 起 CCF 与 HRA 本体正式分离，CCF 成为一个独立的词表型数字对象。VCCF（Vasculature Common Coordinate Framework，血管通用坐标框架）是 CCF 的血管分支，用血管树的层级位置来定位组织块，适用于血管本身作为解剖参照的场合。

FTU（Functional Tissue Unit，功能组织单元）是介于器官与细胞之间的尺度：肾小体、肺泡、肝小叶都是典型例子。HRA 用 2D FTU（示意图加 SVG 标注）和部分 3D FTU 来描述这一层。3D 参考器官则是带 UBERON 标注的 GLB 网格模型，几何只是载体，语义标注才是它的价值所在。

本体与标识符（7 条）

Uberon 是跨物种解剖结构本体，HRA 里几乎所有 AS 的正式 ID 都来自它。FMA（Foundational Model of Anatomy，解剖学基础模型本体）是更早的解剖本体，Uberon 在建立时大量复用了它的术语，因此两套 ID 在旧文献里经常同时出现。

CL（Cell Ontology，细胞类型本体）是细胞类型的权威词表。PCL（Provisional Cell Ontology，临时收容本体）是 CL 的缓冲区：那些还不足以进入 CL 的细胞类型先放在这里，等证据充分再迁移。TEMP 是 HRA 内部的第三层占位前缀，比 PCL 更临时——它连 PCL 都还没进，只是为了让表能填满而设的占位符。三层的关系可以记成一句话：TEMP 是欠条，PCL 是候补，CL 是正式编制。

HGNC（HUGO Gene Nomenclature Committee，人类基因命名委员会）提供基因的标准符号与 ID，HRA 的 BGene 列用它。RO（Relation Ontology，关系本体）定义谓词，比如「位于」「部分属于」这类关系的语义约束。RRID（Research Resource Identifier，研究资源标识符）是抗体、试剂、工具的全球唯一标识，OMAP 表里的每一支抗体都应带 RRID，这是判断一个面板能否被复现的关键字段。

数字对象与工具（9 条）

DO（Digital Object，数字对象）是 HRA 的发布单元：一张表、一个面板、一个器官模型、一张交叉表，都是独立的 DO，各有自己的版本号、DOI 与许可声明。v2.2 有 13 类共 703 个 DO。

OMAP（Organ Mapping Antibody Panel，器官映射抗体面板）把「有什么细胞」翻译成「用什么抗体能看见」。RUI（Registration User Interface，注册用户界面）是组织块三维注册工具。EUI（Exploration User Interface，探索用户界面）用来浏览器官模型与挂在其中的数据集。Millitome 是三维打印的组织切片夹具模板，用固定网格把器官切成可复现的小块，每一块有稳定编号。

注册（Registration）是整个体系的关键动作：把一块实验组织放进三维参考器官，得到一个坐标。Corridor 是注册结果不确定时的候选位置概率分布——组织块与多个结构相交，系统只能给出「可能来自这几个结构中的任何一个」。Collision Summary 则记录组织块与各解剖结构的相交体积与占比，用来判断它到底属于哪一层。

Cell Summary 是细胞类型丰度与平均基因表达的摘要对象，可以挂在某个位点上，也可以挂在某个数据集上。

数据层、查询与许可（7 条）

hra-pop 是 HRA 的数据集图，汇聚经过质控与注释对齐的细胞类型丰度，v1.1 实测 807 个数据集、5,591 万细胞。hra-pop-full 是它的扩展版，47,792 个数据集、2.80 亿细胞，覆盖更广但未统一质控——两者的差别不是「新旧」，而是「精度与广度的取舍」。

LOD（Linked Open Data，关联开放数据）指按 RDF 规范发布、可被跨库解引用的数据形态，HRA KG 是它的一个实例。grlc 是把 SPARQL 查询封装成 RESTful 接口的服务，HRA 用它把常用查询变成可直接调用的 URL。

最后一条需要特别说明：本条目唯一与病理学术语无关的提示是「patch 无关」。若读者从病理图像数据集条目跳转过来，请勿把这里的 patch（补丁、片段）与 PANDA-PLUS 条目中的图像 patch 混淆，两者只是英文同形。

FAQ 续编：30 问之后的深水区

上一节的 30 问覆盖了入门到中级的问题。本节补 30 问，集中在实操细节、数据质量、机构与资助、与相邻项目的辨析四个方向。

F. 结构与语义的细节

Q31：为什么要分 AS/1 到 AS/6 六级？
解剖结构的嵌套在组织学上并不统一：有的器官只需三级（器官 → 区域 → 结构），有的需要六到七级（器官 → 叶 → 小叶 → 腺泡 → 细胞层 → 细胞）。取六级是「覆盖绝大多数情况又不至于让表宽到无法阅读」的折中。肾脏表 v1.8 实测有 2 行用到第 7 级，说明上限偶尔会被突破。

Q32：为什么 CT 只有两级？
细胞类型的层级化程度远低于解剖：多数情况下「某结构内有哪些细胞」是一层平铺的关系，再加一层「具体亚型」就够。两级设计的另一好处是降低维护复杂度——细胞类型本体（CL/PCL）本身的层级由本体维护，表里不需要重复。

Q33：B 为什么分成 BGene 和 Protein 两套列？
因为同一生物标志物可能以两种粒度被使用：基因符号（HGNC）用于单细胞分析中的基因名匹配，蛋白（UniProt）用于抗体靶标与免疫组化。分开列避免了「到底在说基因还是蛋白」的歧义。OMAP 走的是蛋白路径，ASCT+B 的 BGene 走的是基因路径。

Q34：ontology ID 为空的行怎么处理？
保留。它们是图谱的一部分（可以被查询、可以被可视化），只是无法与外部本体 join。下游 pipeline 应把空 ID 当作独立类别处理，而不是丢弃。

Q35：placed_relative_to 与 has_placement 的区别？
语义相同，前者是 v1.2 起的新名。改名原因是「placement」在 CCF 语境里被用于描述更广的放置关系，为避免歧义做了重命名。老查询若用 has_placement 会返回空——这是升级时的经典翻车点。

Q36：图谱里有没有「人体不存在」的解剖结构？
没有。所有 AS 都来自已发表的组织学共识或专家评审。但因为存在 TEMP 术语，某些 AS 的名称可能在不同表里写法不一（如「loop of Henle」的多种别名），join 时需做归一化。

Q37：同一器官的多个 OMAP 怎么选？
按成像技术选：CODEX 看抗体密度与新鲜冷冻兼容性，IMC/CyCIF 看金属标记与 FFPE 兼容性，Cell DIVE 看循环数。同一器官面板之间约有 40% 的靶标重叠（OMAP-3 的说明文档明确提到与 IMC 面板重叠 >40%），可以据此判断哪个面板更接近你的需求。

Q38：3D 参考器官的精度有多高？
它是「参考」级别，不是个体解剖：网格经过简化，适合做粗略的空间注册与可视化，不适合做形态学测量。需要精确解剖的研究应使用真实影像。

Q39：millitome 与 3D 参考器官的区别？
millitome 是「切块的夹具模板」（物理对象 + 数字定义），3D 参考器官是「器官的坐标容器」。前者解决「怎么切得可复现」，后者解决「切下来放在哪」。

Q40：corridor 的个数有上限吗？
没有硬上限，但实际查询中一个组织块通常只与 1-5 个候选位置相交。corridor 太大意味着注册太粗糙，应重新注册或标注为低置信度。

G. 数据质量与统计

Q41：hra-pop 的细胞总数 5,591 万是怎么算的？
把 807 个数据集各自的 cell_count 求和。这不是去重后的唯一细胞数——同一个细胞可能在不同分析版本中被重复计数。它是「语料规模」而非「人体细胞数」。

Q42：为什么肺的数据集比肝多？
因为联盟投入：LungMAP、HuBMAP 的肺项目、HTAN 的肺癌对照数据都在供肺。肺是 HRA 覆盖第二深的器官（仅次于肾）。

Q43：164 个缺 organ_id 的数据集会漏统计吗？
会。做器官级聚合时它们不在任何器官桶里。这就是坑 10 的实质——约 20% 的数据「静默消失」。

Q44：细胞类型注释的准确率有多高？
论文没有给出统一的准确率数字，因为注释质量随组织、工具、数据质量而变。CTann 的交叉表本身就是质量控制的产物：当一个细胞类型在 3 个工具里被标成不同类别，交叉表会给出专家裁定的统一答案。

Q45：可以用 HRA 的细胞类型丰度做疾病对比吗？
需要谨慎。HRA 描述健康成人，疾病数据来自 KPMP/HTAN 等，两者挂到同一坐标后可以对比，但差异既可能来自生物学也可能来自取样与注释差异。论文对此没有给出标准做法。

Q46：v2.2 的 10,064,033 节点里有多少是「真正的断言」？
无法从论文直接得出。谓词分布（rdf:type 809 万、rdfs:label 291 万、subClassOf 216 万）说明绝大部分是类型、标签与层级。粗略估计，生物学断言（细胞在结构内、基因标记细胞）的量级在数十万到百万之间。

Q47：为什么有 11,698 个单细胞数据集？
这是 ds-graph 的实例数，来自 HuBMAP/SenNet/CxG 等门户的注册数据集。注意这 11,698 与 hra-pop 的 807 不是同一层：前者是「图谱里出现的数据集引用」，后者是「经过质控与注释对齐、能做统计的数据集」。

H. 机构、资助与治理

Q48：HRA 的治理结构是什么？
HuBMAP 牵头 + 联合 SenNet/KPMP/GUDMAP/NIDDK + HRA 编辑委员会（Editorial Board）做内容评审 + 26 个联盟参与。每张 ASCT+B 表都要过作者与评审人两轮，表头里明确列出双方姓名与 ORCID。

Q49：资助来源有哪些？
NIH Common Fund 的 OT2 系列（OT2OD033756、OT2OD026671、OT2OD026675、OT2OD033759、OT2OD030545）、SenNet CODCC 的 U24CA268108-01、NIDDK 的 U24DK135157、KPMP 的 U2CDK114886、NIAID 的支持合同 HHSN316201300006W/HHSN27200002。另有美国牙科协会（ADA）与加拿大 CIFAR 的 MacMillan Multiscale Human 项目支持。

Q50：我能贡献数据吗？
可以，通过 HuBMAP/SenNet/KPMP 等门户提交，或在 HRA 工作组登记。落地页有 working group 的注册入口。

Q51：谁决定哪些器官进入图谱？
需求与联盟覆盖度共同决定。器官进入的前提是「有足够多的组织学文献与专家愿意编纂 ASCT+B 表」，而不是「技术上能建模」。

Q52：HRA 与 HuBMAP 的治理是同一批人吗？
有重叠但不完全一致：HuBMAP 是资助与联盟母体，HRA 的技术建设集中在 Indiana CNS 与 Stanford BMIR。Börner 同时是 HRA 与 CNS 的负责人。

I. 与相邻项目的辨析

Q53：HRA 与 HCA（Human Cell Atlas）会不会重复？
目标不同。HCA 是「发现并定义人体所有细胞类型」的全球计划，产出的是细胞类型目录与大规模测序数据；HRA 是「把这些细胞类型放到解剖坐标上」的参考骨架。两者在术语上互通（都用 CL），数据上经 CxG 互通。

Q54：HRA 与 HuBMAP 门户的区别？
门户是数据仓库（存放原始与处理后数据），HRA 是索引与坐标系统。一个组织块在门户里有 UUID，在 HRA 里有 CCF 坐标——两套标识分别服务「取数据」与「定位」。

Q55：HRA 与 GTEx 的关系？
GTEx 是正常组织的表达数据库，HRA 把 GTEx 的组织块注册进坐标（hra-pop 中 14 个数据集），使表达数据可以按解剖位置检索。

Q56：HRA 与 KPMP 的肾数据？
KPMP 供肾穿刺数据，HRA 供肾脏的 ASCT+B 表与 8 个 2D FTU。两者形成「参考 + 疾病」的配对，是 HRA 覆盖最深的器官组合。

Q57：HRA 与 SenNet 的关系？
SenNet（细胞衰老网络）使用 HRA 的工具栈与坐标，其数据也进入 hra-pop（128 个数据集）。SenNet 的 CODCC 由同一批人运营（U24CA268108-01），技术共线。

Q58：HRA 与传统解剖图谱（如 Gray’s Anatomy）的区别？
传统图谱是人读的插图，HRA 是机器读的图数据。前者的价值在视觉传达，后者的价值在可查询、可计算、可被下游 pipeline 消费。

Q59：HRA 与影像组学的解剖分割图谱是什么关系？
互补。影像分割图谱提供「这个像素是什么器官」的监督，HRA 提供「这个器官有哪些细胞类型与标志物」的先验。两者可以叠加使用。

Q60：如果只记住一件事？
HRA KG 是「健康成人人体的语义操作系统」：它不存数据，但决定数据怎么被命名、怎么被定位、怎么被比较。

附录

附录 A：条目信息速查卡

条目名 HRA Knowledge Graph，slug 为 hra-knowledge-graph，类型是参考型知识图谱数据集。首选引用为 Bueckle A, et al. Sci Data 12:1100 (2025)，doi 10.1038/s41597-025-05183-6；数据快照引用为 Zenodo 10.5281/zenodo.15323983，必须注明版本（如 v2.5）。许可方面数据为 CC BY 4.0、代码为 MIT。

主入口是 https://humanatlas.io 与 https://lod.humanatlas.io，SPARQL 端点为 https://lod.humanatlas.io/sparql。建议的获取方式是 v2.5 的 tar.xz 全量包（7.7 GB），或按需下载单个数字对象的 CSV。更新日历为每年 6 月 15 日与 12 月 15 日两次。v2.2 的体量是 10,064,033 个节点、171,250,177 条边、125.84 GB；覆盖 71 个器官、5,800 个解剖结构、2,268 个细胞类型、2,531 个生物标志物。

附录 B：DAIMS 评估全表

维度	评分（1-10）	依据
D 可发现性	9	论文开放获取 + 官网 + Zenodo + 多个镜像；但「HRA KG」与「HRA」常被混搜，术语消歧成本存在
A 可获取性	10	无注册墙、无审批、直链下载；CC BY 4.0 允许商用与模型训练
I 可互操作	9	RDF 五格式 + SPARQL + 与 Uberon/CL/PCL/HGNC 深度对齐；扣分在 TEMP 术语与四类 ID 混用
M 元数据质量	8	每个 DO 自带 title/license/citation/version/distribution；扣分在血缘字段不统一、论文内部两套统计口径
S 可持续性	9	NIH Common Fund 多年资助 + 固定双年发布 + Zenodo 永久归档 + 多机构镜像；单点风险低
综合评级	9.0/10（优）	本库可获取性与互操作性均属第一梯队；主要差距在语义完备性（TEMP 欠账）与文档分散

附录 C：逐项证据链自证

证据链按「读什么、在哪读、怎么核」三列排列，这里改成按来源分组的连续叙述，便于逐条回溯。第一组是主论文 Sci Data 12:1100：摘要同时给出三个总量数字——10,064,033 个节点、171,250,177 条边、125.84 GB 体积；同一篇论文的 Table 3 给出另一组 1,543,074 / 101,720,865 / 30,848 MB；覆盖度数字 71 个器官、5,800 个解剖结构、2,268 个细胞类型、2,531 个生物标志物出现在摘要与结果节两处，措辞一致。HRA Ecosystem 一节则列出 33 张 ASCT+B 表、23 个 OMAP、22 个二维功能单元、71 个参考器官，以及 59/71 个带地标参考器官、301 MB 与 261 MB 两笔附加资产体积。

第二组是 Zenodo 记录 10.5281/zenodo.20671829：记录描述里同样写 10,064,033，与论文摘要自洽；v2.5 归档包 7.7 GB、发布日期 2026-06-15，由 DataCite API 与 Zenodo 页面双向确认。

第三组是许可。CC BY 4.0 同时出现在仓库 README 与每个数字对象的 dct:license 字段里，代码侧为 MIT，只在 README 声明。第四组是书目元数据：卷 12、文章号 1100，通过 Crossref API 查询 DOI 10.1038/s41597-025-05183-6 得到。

第五组是抓取实测，全部发生在 2026-10-17。肾脏 ASCT+B 表 v1.8 从 cdn.humanatlas.io 下载 CSV 后统计得 78 行数据、74 个解剖结构、67 个细胞类型、190 个基因符号；OMAP-3 肾脏 CODEX 面板下载后数出 24 个抗体条目；hra-pop v1.1 的 graph.jsonld 给出 807 个数据集、663 个样本、175 个供体与 5,591.5 万细胞；hra-pop-full v1.1 则是 47,792 / 40,394 / 32,047 与 2.803 亿细胞。LOD 目录当日的计数为 ASCT+B 41、OMAP 38、二维功能单元 29、参考器官 88、地标 61。

第六组是端点行为：lod.humanatlas.io/sparql 上一条 ASK 查询约 20 秒返回，而 COUNT(*) 全图聚合直接超时。这条实测解释了为什么本条目反复强调「端点只做精确取数」——它不是建议，是被引擎的物理限制逼出来的结论。

附录 D：数据获取决策树

这张决策树只有一句话：先问你的问题需不需要全量。不需要全量的，走端点或直接取对象；需要全量的，下载快照本地跑。具体到八种常见需求：查某器官有哪些细胞类型，首选该器官的 ASCT+B 表 CSV，备选是用 SPARQL 按 as_label 过滤；查某器官的抗体面板，去 OMAP 目录页按器官筛选，或直接取该 OMAP 的 CSV（里面带 RRID）；做细胞类型丰度统计，只能用 hra-pop v1.1，没有备选方案；探索器官覆盖度，用 hra-pop-full v1.1 或看 Dashboard 的数字对象器官分布图。

复现某篇论文的分析，必须用 Zenodo 上对应版本的 tar.xz，latest 在这里等于不可用；只取几条关系，走 SPARQL 端点；需要跨对象批量 join，解压到本地用 DuckDB；教学与展示，用 FTU Explorer 或 Organ Gallery，不必碰端点。

附录 E：SPARQL 实战片段

E-1 确认某个数字对象存在与版本

SELECT ?version ?created
WHERE {
  <https://lod.humanatlas.io/asct-b/kidney> <http://www.w3.org/ns/dcat#hasCurrentVersion> ?v .
  ?v <http://schema.org/version> ?version ;
     <http://schema.org/dateCreated> ?created .
}

E-2 列出某器官可用的全部版本

SELECT ?v
WHERE {
  <https://lod.humanatlas.io/asct-b/kidney> <http://www.w3.org/ns/dcat#dataset> ?v .
}
ORDER BY ?v

E-3 查询集合的元数据（版本、许可、构建日）

SELECT ?p ?o
WHERE {
  <https://lod.humanatlas.io/collection/hra/v2.5> ?p ?o .
  FILTER(?p IN (<http://schema.org/version>,
                <http://purl.org/dc/terms/license>,
                <http://schema.org/dateCreated>))
}

（以上三段均于 2026-10-17 在 lod.humanatlas.io/sparql 实测可用；每次请求建议加 LIMIT 并在客户端设置 ≥60 s 超时，端点的首字节延迟通常在 1-20 秒之间。）

附录 F：命名图与版本对照

命名图与版本对照可以用一句口诀记住：PURL 的形式永远是 purl.humanatlas.io/<类型>/<对象>/<版本>，差别只在中间两段。集合是 collection/hra/v2.5；器官表是 asct-b/kidney/v1.8；OMAP 是 omap/3-kidney-codex/v1.4；二维功能单元是 2d-ftu/kidney-renal-corpuscle（FTU 通常只写一个版本）；参考器官是 ref-organ/kidney-male-left；数据集图是 ds-graph/hra-pop/v1.1。六类对象的 PURL 结构完全同构，因此写一个模板函数就能覆盖全部解析逻辑，这也是 HRA 在工程上比多数知识图谱规整的地方。

附录 G：hra-pop 器官覆盖表（v1.1 实测）

807 个数据集的器官分布极不均衡，这是理解 hra-pop 局限性的第一手材料。肾脏以 207 个数据集遥遥领先，接近总数的四分之一；紧随其后的是 164 个未标注器官的数据集，占两成以上，这个数字本身就是一条警示——任何按器官聚合的统计若不先过滤空值，会无声丢掉两成的样本权重。肺 153 个、心 108 个，两者构成第二梯队；大肠 35、小肠 33、肝 31，构成第三梯队；子宫 23、膀胱 12 已经进入个位数两位数区间；其余 10 个器官合计仅 41 个数据集，分摊下来平均每个不到 5 个。

把这张分布与「71 个参考器官」并置，落差非常直观：结构层承诺了 71 个器官的解剖与细胞定义，观测层真正有数据支撑的只有十余个，且重心明显偏向泌尿、呼吸、心血管三个系统。这不是 hra-pop 的缺陷，而是公共单细胞数据本身的分布现实——HCA 与 KPMP 等落地项目的样本采集就集中在这几个系统。使用这张图时应把它读作「证据密度图」而非「器官索引图」，密度高的地方适合做定量结论，密度低的地方只适合做覆盖度陈述。

附录 H：hra-pop 技术模态分布（v1.1 实测）

807 个数据集按实验技术拆开，单细胞与单核 RNA 测序以 519 个占据绝对主导，接近三分之二。这决定了 hra-pop 的细胞计数本质上是一份转录组视角的清单：它告诉你「这里有多少个细胞被 RNA 测序数过」，而不是「这里在物理上存在多少细胞」。

空间类技术构成第二大类：Slide-seq 112 个，靠高分辨率珠阵列把转录本落到坐标上；Visium（无探针版）23 个；GeoMx 12 个，以 ROI 选择方式工作。三者合计 147 个，说明空间信息在 hra-pop 里已经具备统计意义，但分辨率与平台差异极大，直接横向合并会引入坐标体系冲突。

多重蛋白成像合计 123 个：CODEX 70 个、MxIF 27 个、PhenoCycler 16 个、Cell DIVE 10 个。这四类在技术谱系上并不互斥——CODEX 与 PhenoCycler 同出一源，前者是学术命名、后者是商业命名，临床样本上时常混用；若按商品名去重统计，很容易把同一种循环染色技术数成两笔。这也是本条目主张「按技术族而非按商品名聚合」的直接理由。另有 18 个归入 OTHER 的未分类数据集，它们大多来自早期提交，元数据里只有自由文本的技术描述，无法自动归族。

模态分布与器官分布叠加后可以看出一条规律：有空间数据覆盖的器官，几乎总是同时有单细胞 RNA 数据；但反过来不成立——心脏有大量 RNA 数据，空间数据却稀少。做跨模态整合时，这个不对称性决定了你只能以 RNA 为骨架、把空间数据作为局部增强。

附录 I：双口径存照总表

十条双口径逐条存照如下。第一条到第三条是同一组数字：节点数摘要写 10,064,033、Table 3 写 1,543,074；边数摘要写 171,250,177、Table 3 写 101,720,865；体积摘要写 125.84 GB、Table 3 写 30,848 MB——三条都用摘要口径，并在避坑清单第 1 条说明。第四条是统计时点：论文正文写 2025 年 5 月，Zenodo 摘要写 4 月，正文按 5 月写并注明 Zenodo 口径。

第五条是联盟数：论文写 25+，落地页写 26，Zenodo 描述写 20+，三者并列并各自注明时点。第六条到第八条是「单版本实体数」与「LOD 累计目录数」的差异：OMAP 23 对 38，2D FTU 22 对 29（目录）或 26（实体），参考器官 71 对 88，一律分版本表述。第九条是落地页的教学精选计数（27 器官、1,323 个 AS、621 个 CT、378 个 B），与论文口径不同，本条目明确不采用。第十条是两个日期：Zenodo 记录创建于 2026 年 6 月 15 日，而集合的 schema:dateCreated 是 2026 年 9 月 11 日，分别标注为发布日与构建日。

附录 J：三大数据子图对照

HRA KG 内部实际上并行着三张子图，理解它们的差异比记住任何单个数字都重要。第一张是生物结构层，载体是 33 张 ASCT+B 表，回答「有什么结构、什么细胞、什么标记」，依赖 Uberon、CL、PCL、HGNC 四套本体，更新节奏最慢，通常是器官级整体修订，量级以数十万个 RDF 单元格计，引用颗粒度细到每张表的 Data DOI。

第二张是实验层，载体是 23 到 38 个 OMAP（单版本与累计目录两种口径），回答「怎么用抗体把细胞看见」，依赖 UniProt、HGNC 与 RRID，更新速度中等——每次新实验产出就多一个 OMAP，每个面板通常 20 到 40 个抗体，引用同样落到 Data DOI。这一层是把结构层的「名字」翻译成实验室可执行的「试剂清单」的桥梁。

第三张是数据集层，载体是 hra-pop 的 807 个数据集，回答「哪些数据集覆盖了哪里」，依赖 CL 与 Uberon 但通过 CTann 做间接对齐，更新最快、随门户滚动，量级是 5,591 万个细胞计数，引用用 Zenodo 的概念 DOI 以便跨版本追踪。

三张图的更新频率依次递增、语义精度依次递减，构成一个典型的「上游稳定、下游活跃」结构。实际使用时最常见的错误是拿第三张图的数字去支撑第一张图的结论——比如用 hra-pop 的细胞计数去论证某个器官的细胞类型清单，这在方法上是越层的。正确姿势是按问题选层：问概念查结构层，问实验设计查实验层，问样本与丰度查数据集层。

附录 K：使用 HRA KG 的十条工程守则

这十条是从实际踩坑中提炼的硬约束，按「版本、查询、数据、许可」四组记更牢。版本组三条：任何分析都写死版本号而不用 latest；引用时论文、数字对象的 Data DOI、Zenodo 概念 DOI 三者齐全；全量分析一律下载 tar.xz 用 DuckDB 或 Jena 本地跑。查询组三条：所有查询都加 LIMIT，客户端超时设到 60 秒以上；端点只用于精确取数，不做全图聚合；TEMP 前缀的行单独标记，不参与 CL join。

数据组三条：空本体 ID 是合法类别而不是脏数据，不要静默丢弃；hra-pop 用于定量、hra-pop-full 只用于覆盖度探索，两者不可互换；器官级统计之前先过滤空 organ_id，否则会有约两成数据无声消失。许可组一条：CC BY 4.0 允许商用，但「参考层开放」不等于「底层数据开放」，指向的原始数据集各有各的访问控制。

附录 L：条目维护备忘

本条目所有 v2.5 实测数据抓取于 2026-10-17；下一次 HRA 发布（v2.6）预计在 2026-12-15，届时需复核 LOD 目录计数与 hra-pop 版本号。
论文基线 v2.2 的数字不应随发布更新而替换——它们代表一个已发表的历史快照，需永久保留以便复现。
若 HRA 发布新的主论文（除 Sci Data 12:1100 外），本条目应新增「论文谱系」小节而非替换引用。

§11 深化：本体对齐的工程细节

11.1 为什么「对齐」比「建模」难

建模是给事物起名字，对齐是让两套命名承认彼此。HRA 的困难全部集中在后者：它需要让 Uberon 的解剖层级、CL 的细胞类型层级、HGNC 的基因符号、UniProt 的蛋白登录号在同一个图里互认。四条链路的对齐质量并不相同。

链路	对齐方式	成熟度	典型失败
AS ↔ Uberon	表内显式 ID + 人工校订	中（肾脏表 74 个 AS 中仅 11 个带 ID）	中间层结构无术语，只能自由文本
AS ↔ FMA	部分器官补充	低（FMA 只覆盖部分解剖）	与 Uberon 的粒度不一致
CT ↔ CL/PCL	表内显式 ID	较高（肾脏表 67 个 CT 全部带 CL ID）	CL 与 PCL 之间的迁移滞后
B ↔ HGNC/UniProt	基因列与蛋白列分开	高（肾脏表 190 个基因全带 HGNC）	同名基因与别名混淆

这张表的结论很直接：细胞与基因的对齐已经工业化，解剖的对齐仍处手工业阶段。原因不难理解——细胞类型的命名以分子标记为锚（CD4、CD8、FOXP3），有客观依据；解剖结构的边界则常有争议（「肾皮质的边界到哪」），只能靠专家约定。

11.2 CTann 交叉表：把工具输出翻译成人话

hra-pop 的细胞类型丰度来自各数据集的原始注释，而原始注释五花八门：有的用 Seurat cluster 编号，有的用作者自拟名，有的用 CL 术语。CTann（Cell Type Annotation Crosswalk）就是把这些翻译成统一词表的中间层。

v2.2 的规模：23 个器官有 CTann 表，其中 12 个器官有多个工具的交叉表。多工具交叉的价值在于暴露分歧——同一群细胞，Azimuth 说「近端小管上皮」，CellTypist 说「肾小管上皮」，popV 可能投出第三个答案。交叉表不强行调和，而是把三个答案并列，由专家标注推荐映射。

对使用者的实操含义：当你从 hra-pop 里取某个数据集的细胞类型丰度时，你拿到的是「经交叉表归一化后的类别」，不是该数据集作者的原始命名。如果需要追溯原始命名，要回到该数据集的源门户。

11.3 从 CSV 到三元组：一次具体的手工推演

取肾脏表 v1.8 的一行（简化）：AS/1 = kidney（UBERON:0002113），AS/2 = kidney capsule（UBERON:0002015），CT/1 = stromal cell（CL:0000499），CT/2 = capsule mesenchymal stromal cell（TEMP），B = Foxd1（HGNC:3802）、VSX2（HGNC:1975）。

它被编译成的三元组大致是：

<record> a ccf:AsctbRecord ;
    ccf:as_1_label 「kidney」 ; ccf:as_1_id UBERON:0002113 ;
    ccf:as_2_label 「kidney capsule」 ; ccf:as_2_id UBERON:0002015 ;
    ccf:ct_1_label 「stromal cell」 ; ccf:ct_1_id CL:0000499 ;
    ccf:ct_2_label 「capsule mesenchymal stromal cell」 ;
    ccf:bgene_1_label 「Foxd1」 ; ccf:bgene_1_id HGNC:3802 ;
    ccf:record_number 「...」 .

这条推演揭示了三个容易忽略的点：

一行 CSV 变成十几条三元组。这是 1006 万节点的来源之一——不是内容多，是扁平化后的展开。
层级关系没有被显式表述为 part_of。它靠列序（as_1 → as_2）隐含，查询时需要自己拼接。这意味着「肾小体属于肾吗」这类问题不能靠一条三元组回答，得读两级标签。
TEMP 项在这里出现：capsule mesenchymal stromal cell 在 CL 里没有正式 ID（表中标注为「New term request CL」），所以它只能以标签形式存在。

11.4 版本间的迁移成本

HRA 每年两版意味着下游必须处理迁移。实测到的三类变更：

加列：某些器官表在 v1.x 后期增加了 Protein 列或理由列；
改名：has_placement → placed_relative_to（v1.2），影响所有空间查询；
重排：同一结构的 AS 层级可能被调整（某个原来在第 3 级的结构升到第 2 级）。

第一类向后兼容，第二类破坏性，第三类会造成同一结构在新旧版本中标签相同但路径不同。做长期追踪的项目应当保存每次使用的版本快照，而不是每次重新拉 latest。

§12 深化：空间注册的机理与陷阱

12.1 RUI 的工作流

组织块注册（registration）是把「一块真实的组织」放进「一个虚拟的 3D 器官」的过程。HRA 的 Registration User Interface 提供四步：

选择参考器官与性别/侧别；
输入组织块的尺寸（或从上游系统带入）；
借助地标做初始摆放（RUI 会提示「这个位置与哪些结构相交」）；
微调后提交，系统输出 placed_relative_to 与碰撞摘要。

输出的关键字段：提取位点（extraction site）的空间坐标、与各 3D 解剖结构（3D AS）的交集、以及由交集推出的 corridor。

12.2 corridor 的概率含义

假设一个组织块注册后与 3 个结构相交：肾皮质 60%、肾髓质 35%、肾盂 5%。corridor 就是这组候选与权重的集合。它表达的是「如果这个组织块是从这个位置切下来的，那么它最可能来自皮质，但髓质与肾盂也不能排除」。

这个设计解决了一个现实问题：3D 参考器官是简化模型，真实取样会跨层。强行二选一会制造假精度，corridor 保留了不确定性。

陷阱在于：corridor 的权重来自几何交集，不是生物学先验。一个体积占比小的结构可能实际包含大量目标细胞（如肾小球只占皮质体积的极小部分，却是最重要的结构之一）。用 corridor 做「样本更可能来自哪里」的判断时，要叠加细胞密度或结构重要性的先验。

12.3 地标覆盖的缺口

v2.2 的地标覆盖 59/71 个参考器官。也就是说有 12 个器官没有地标，注册时只能靠手动目测摆放。这直接影响这些器官的空间数据质量。

对使用者的检查清单：取某器官的注册数据前，先确认该器官是否有地标；

有地标 → 注册位置的可信度较高；
无地标 → 位置存在系统性偏移风险，做精细空间分析时需在方法里声明。

12.4 millitome：把「切哪里」标准化

millitome 是为解决「不同实验室切同一器官切出不同块」的问题而设计的：它给出一个 3D 打印夹具，把器官按固定网格切成编号可复现的小块，每块的名称、位置、尺寸都是预先定义的。

它与 3D 参考器官的关系：millitome 定义切法，参考器官定义坐标。两者结合后，「第 7 号块」这个说法在不同实验室之间才有可比性。HRA v2.5 的 millitome 目录有 13 项，覆盖肾、心、肺等主要器官。

§13 深化：与通用知识图谱技术的对话

13.1 为什么选 RDF 而不是属性图

HRA 选 RDF + SPARQL，而非 Neo4j 等属性图，原因有三：

本体互操作：Uberon/CL 本身就是 OWL/RDF，直接用 RDF 存储避免了转换损耗；
命名图与版本：RDF 的 named graph 天然适合「每个 DO 一个图」的版本化结构；
LOD 原则：论文明确提到部署遵循 Linked Open Data 原则，PURL 与内容协商是这套生态的标配。

代价是查询性能：RDF 的复杂 join 在通用三元组库上通常比属性图慢，这也是端点在深查询上超时的原因之一。

13.2 与图神经网络的关系

把 HRA KG 当作 GNN 的输入，有三条现实路径：

节点分类：以 CL 术语为节点、ASCT+B 关系为边，预测 TEMP 术语应归属哪个 CL 类——这实际上可以辅助本体补全；
链接预测：预测「某细胞类型是否可能存在于某结构」——可用于发现表格遗漏；
图表征：为每个细胞类型学到嵌入向量，作为下游注释器的额外特征。

三条路径的共同前提是把图压缩到可训练规模。1006 万节点无法直接进 GNN，需要按器官切子图或按本体层聚合。

13.3 与 LLM 的协同

HRA KG 与 LLM 的组合是目前最活跃的应用方向，具体有三种形态：

形态	做法	优点	风险
RAG 检索增强	把 ASCT+B 表切片入向量库，检索后拼接给 LLM	可溯源、实时更新	切片破坏层级，检索可能丢上下文
工具调用	让 LLM 生成 SPARQL 查询，由端点执行	精确、不幻觉	生成的查询常因谓词名错误失败
约束解码	用本体词表约束 LLM 的输出类别	输出合法	只适用于封闭标签任务

实践中，第二种的可靠性最低（谓词太多、命名不统一），第一种性价比最高。我们实测的端点行为也支持这一判断：简单查询响应稳定，复杂查询易超时，因此 LLM 生成的查询应当限制在「单跳 + LIMIT」的范围内。

13.4 与生物医学本体的竞合

HRA KG 与 UMLS、UBKG、OBO Foundry 生态的关系可以概括为：

UMLS 是术语的超级容器（含同义词、跨语言），HRA 是解剖-细胞关系的实例图；
UBKG 是 UMLS 的图数据库化，规模更大但缺少 3D 空间与抗体面板；
OBO Foundry 是一批本体的联合体，HRA 是它们的消费者与合作者（回馈 162 个 Uberon 术语、155 个 CL 术语、468 个 PCL 术语）。

选择建议：需要同义词与跨语言映射用 UMLS；需要解剖-细胞-标记的实例关系用 HRA KG；需要两者都要，用 HRA KG 的术语 ID 回查 UMLS。

§14 深化：复现一份 ASCT+B 表的完整流程

14.1 从 PURL 到本地 CSV

要拿到某器官某版本的原始表，最稳的路径不是猜 PURL，而是走三步：

查该器官的当前版本：在 https://lod.humanatlas.io/asct-b/<organ>/ 的 JSON-LD 里找 hasCurrentVersion；
从该版本的 distribution 列表里找 assets/asct-b-vh-<organ>.csv；
拼成完整地址下载（例如肾脏 v1.8 的地址形如 cdn.humanatlas.io/digital-objects/asct-b/kidney/v1.8/assets/asct-b-vh-kidney.csv）。

实测肾脏表 v1.8 的下载体积约 78 KB、89 行（含 8 行表头元数据与若干空行），解析后 78 个数据行。

14.2 解析时的五个坑

坑	现象	处理
BOM 头	首行标题带 `\ufeff`	读入时用 `encoding=「utf-8-sig」`
表头不在第 1 行	前 8 行是元数据	用 `r[0] == 「AS/1」` 定位
尾部空列	每行有 105 列，多数为空	只取前 60 列，或按列名取
同名不同 ID	同一结构名出现多次	用 (名称, ID) 元组去重
空 ID	大量 AS 无本体 ID	视为合法类别，不要 drop

这五个坑每一个都会让「行数统计」与「节点数统计」对不上，是新手最容易在数据核验环节翻车的地方。

14.3 统计口径的三层

同一个器官表，可以算出三组数字，含义完全不同：

行数（78）：叶路径数，反映表的展开规模；
节点数（74 个 AS + 67 个 CT + 190 个 B）：去重后的实体数；
带 ID 的节点数（11 个 AS + 67 个 CT + 190 个 B）：可与外部本体 join 的实体数。

引用时若不说明是哪一层，「某器官有 74 个解剖结构」这句话可能被误读为「74 个都有本体 ID」。正确的表述是「78 条叶路径折叠出 74 个解剖结构节点，其中 11 个带 Uberon ID」。

14.4 校验表的完整性

官方对每张 ASCT+B 表有一套校验项（表头完整性、ID 格式、层级连续性、引用有效性）。复现时最实用的三项自检：

层级连续性：不存在 AS/3 有值而 AS/2 为空的行；
ID 前缀一致：AS 列应为 UBERON/FMA，CT 列应为 CL/PCL，B 列应为 HGNC/UniProt；
引用可达：Data DOI 能在 DataCite 解析。

这三项过不了，表基本是坏的；过了，也不代表内容对——内容正确性仍需领域专家评审，这也是为什么每张表都有 Reviewer 与 Reviewer ORCID 字段。

§15 深化：hra-pop 的统计陷阱

15.1 细胞数是「计数」不是「测序深度」

hra-pop 里每个数据集的 cell_count 是「该数据集报告分析的细胞数」，不是「该组织的真实细胞数」，也不是「测序深度」。同一个组织块被两个研究各分析一次，细胞数会被计两次。

推论：5,591 万这个数字不能解读为「HRA 收录了 5,591 万个细胞」，它是 807 个数据集的报告细胞数之和。做任何「人体某器官有多少细胞」的估算时，这个数字没有意义。

15.2 器官归属的模糊地带

除了 164 个缺 organ_id 的数据集，还有一批「有 organ_id 但器官归属存疑」的情况：例如「肾」这个大类的数据集，可能实际只取自皮质、也可能取自髓质；ASCT+B 的层级细到「肾小体」，而 hra-pop 的 organ_id 只到「肾」。

这意味着：hra-pop 的粒度是器官，不是解剖结构。想解析到「肾皮质 vs 髓质」需要看注册位置（corridor），而不是看 organ_id。这是 hra-pop 与 HRA 参考层之间的一道明确分界。

15.3 技术标签的粗粒度

hra-pop 的技术字段把 CODEX、MxIF、PhenoCycler、Cell DIVE 都列为独立标签，但把各种 10x 平台统一标成 RNAseq。这意味着：

想区分 3′ 与 5′ 化学：hra-pop 做不到，要去 hra-pop-full（那里有 10x3′、10x5′ 等细分标签）；
想区分 Visium 与 Visium HD：两者可能都落到「Visium (no probes)」下。

做方法学对比时必须回到原始门户确认技术细节，不能只信 hra-pop 的 technology 字段。

15.4 数据集数量与「知识增量」不成正比

807 个数据集听起来很多，但按器官与技术拆开后，某些组合只有个位数。例如「心肌 + CODEX」可能只有一两个数据集。这种稀疏性意味着：任何「某器官某技术的共识结论」都可能是基于个位数样本得出的。

实用的检查方式：在 hra-pop 里对目标组合做 cross-tab，若单元格计数低于 5，结论应标注为「初步」。

15.5 跨门户去重的困难

同一个示例在 HuBMAP 有 UUID、在 CxG 有 collection ID、在 GEO 有 GSM 号。hra-pop 用 rdfs:label 记录「Registered 日期, 注册人, 机构」作为弱标识，无法保证唯一。hra-pop-full 的 32,047 个供体几乎肯定包含重复。

这解释了为什么两个版本必须分开使用：hra-pop 经过人工去重与对齐，hra-pop-full 只是「尽量收集」。任何对 full 的定量分析都要先声明「未去重」。

§16 深化：许可与合规的边界案例

16.1 参考层与数据层的许可断层

这是使用 HRA 最容易出错的地方，值得单列一节。三层关系如下：

层	内容	许可	义务
参考层	ASCT+B 表、OMAP、FTU、3D 器官、KG 导出	CC BY 4.0	署名
指针层	ds-graph 中的数据集引用（UUID/URL）	随 HRA，CC BY 4.0	署名
数据层	HuBMAP/SenNet/KPMP/GTEx 的原始数据	各自许可，部分需审批	各自条款

CC BY 4.0 只覆盖前两层。把 HRA KG 拿去做商业产品的解剖学索引完全合法；但用它指引去下载的原始数据，仍受原始条款约束。

16.2 模型训练的合规判断

三个典型场景：

用 ASCT+B 表训练术语嵌入模型：CC BY 4.0 允许，署名即可；
用 hra-pop 的细胞丰度训练分类器：允许，但要注意丰度数据本身是从各数据集派生的，若下游涉及原始数据的再分发，需回到原条款；
用 HRA 的 3D 器官网格训练分割模型：允许，但网格是简化模型，训练出的模型在真实影像上的泛化有限——这是技术问题不是合规问题。

16.3 署名的最小合规写法

论文致谢中至少应包含：

论文引用（Sci Data 12:1100）；
实际使用的每个 DO 的 Data DOI（如 10.48539/HBM342.NFDL.535）；
若使用快照，注明版本号与 Zenodo DOI。

只在方法节写一句「data from HRA」不构成合规署名。

16.4 与国内数据合规的交叉

HRA 是健康成人的参考模型，不含可识别个体信息；hra-pop 的供体层只有性别与少量元数据，且原始去标识在门户侧完成。因此在中国境内部署 HRA 镜像或二次分发，通常不触发人类遗传资源审批——但若把 HRA 与本地临床数据关联，则本地数据部分仍受《人类遗传资源管理条例》约束。这是「参考开放、关联受控」的典型场景。

§17 深化：从 v2.0 到 v2.5 的版本考古

17.1 已有文献记录的三次结构性变更

论文的版本史部分给了三条可考的变化，它们共同说明「HRA KG 不是一次设计成型，而是逐年拆解重构」：

论文的版本史部分给了三条可考的变化，它们共同说明「HRA KG 不是一次设计成型，而是逐年拆解重构」。第一条在 v1.2（2023 年）：提取位点改用 placed_relative_to 指向参考器官，取代原先的 has_placement，影响面覆盖所有空间查询——这是一次谓词语义的收紧，旧查询必须改写。第二条在 v1.4（2023-06）：HRAlit 关联文献图层接入，把 136 个数字对象与文献挂上，影响面是文献与数据集的关联。

第三条影响最大，发生在 v2.0（2023-12）：CCF 本体（v3.0）从 HRA 中剥离，CCF 成为独立的 vocab DO，HRA 则降格为 collection DO。在 v2.0 之前，HRA 与 CCF 混在一个发布里；之后两者分离——CCF 是「坐标规则」，HRA 是「按规则构建的内容」。这次拆分的意义在于让 CCF 可以被别的图谱复用：一个不关心人体解剖、只想用 3D 坐标框架的项目，可以直接引用 CCF 而不必拉整个 HRA。

第三条影响最大。在 v2.0 之前，HRA 与 CCF 混在一个发布里；之后两者分离：CCF 是「坐标规则」，HRA 是「按规则构建的内容」。这次拆分的意义在于让 CCF 可以被别的图谱复用——一个不关心人体解剖、只想用 3D 坐标框架的项目，可以直接引用 CCF 而不必拉整个 HRA。

17.2 v2.2 到 v2.5 的可观察增量

论文只描述到 v2.2。v2.3、v2.4、v2.5 的内容变化没有对应的数据描述论文，只能从 LOD 目录与官网发布说明侧写。2026-10-17 实测到的增量方向：

OMAP 明显扩容：目录从 23 增至 38，新增覆盖脑（Cell DIVE）、卵巢、食管、涎腺、输卵管、子宫等此前没有面板的器官；
参考器官从 71 增至 88：既有新器官，也有原有器官的左右拆分与新版本；
地标从 59 组到 61 组：增幅很小，说明地标标注是最耗人力的环节；
ASCT+B 目录从 33 到 41：绝大多数是版本更迭，新器官有限。

一个值得注意的现象：OMAP 的增速（+65%）远高于 ASCT+B 的实质新增。这印证了 §4.6 的判断——实验类数字对象可以增量交付，编纂类数字对象必须以器官为单位整体推进。

17.3 版本号的三套编号

使用者最容易混淆的是「版本号」。HRA 里同时存在三套：

使用者最容易混淆的是「版本号」。HRA 里同时存在三套，必须分清。第一套是 HRA 集合版本，形态为 v2.x，例如 v2.5，含义是整体发布批次，每年两次。第二套是数字对象版本，形态为 v1.x 或 v1.8，例如 kidney v1.8，含义是单个表或面板的演进轨迹。第三套是本体版本，各自独立编号，例如 Uberon 的 2024-11-25，含义是依赖的外部本体快照。

三者不是同步的：HRA 集合版本每年跳两次，单个数字对象可能一个批次跳好几版、也可能几个批次不动，外部本体则按自身节奏发布。引用时若只写「v2.5」而没说哪张表，别人无法复现——因为 v2.5 批次里的 kidney 可能是 v1.8，而半年前的 v2.4 批次里是 v1.7。完整引用应写到 DO 级：asct-b/kidney/v1.8 才是终态标识。

引用时若只写「v2.5」而没说哪张表，别人无法复现——因为 v2.5 批次里的 kidney 可能是 v1.8，而半年前的 v2.4 批次里是 v1.7。完整引用应写到 DO 级：asct-b/kidney/v1.8 才是终态标识。

17.4 发布日的两个日期

实测发现 v2.5 有两个日期：Zenodo 记录的 created 是 2026-06-15，而 KG collection 的 schema.org/dateCreated 是 2026-09-11。合理解释是前者为计划发布日（对齐 6-15 的固定日历），后者为实际构建完成日。引用时以 Zenodo 记录为准，因为它是对外的公开承诺点。

§18 深化：与三个「看起来很像」的项目辨析

论文 Table 3 把 HRA KG 与其他图资源并列，最容易被误认的是 SPARC、Ubergraph、Petagraph 三个。它们规模各不相同，用途也完全不同，误用的代价是拿错坐标系。

SPARC（Stimulating Peripheral Activity to Relieve Conditions）同样构建生物医学知识图谱，Table 3 给出的规模是 188,146 个节点、812,969 条边、789 MB，比 HRA KG 小两个数量级。差别在领域：SPARC 聚焦外周神经系统与器官的神经支配，HRA 聚焦全身器官的解剖、细胞与标记。做神经调控研究应选 SPARC，做全身细胞图谱应选 HRA；两者的接缝在器官层级，可以在那里拼接。

Ubergraph 是 OBO 本体的合并图，Table 3 口径为 4,071,817 个节点、458,605,464 条边、96,450 MB——边数比 HRA KG 还多，因为它收录的是多个本体的逻辑公理全集，而不是关于人体的断言。HRA KG 与它是「部分消费」关系：HRA 引用的 Uberon、CL、PCL 都能在 Ubergraph 里找到完整上位关系。实操上一句话就能分开：查「某个术语的所有上位概念」去 Ubergraph，查「某个器官里有什么细胞」来 HRA KG，两者都是 SPARQL，可以在同一套工具里切换。

Petagraph 是嵌在 Neo4j 里的多组学图，Table 3 口径为 32,192,544 个节点、151,690,690 条边、138,571 MB，强项是把基因、变异、疾病、通路的关联做成可遍历的网络。HRA KG 既不含疾病关联也不含变异，因此两者的互补性极强：Petagraph 回答「这个基因与哪些疾病相关」，HRA KG 回答「这个基因在人体哪些细胞里表达」。做「从基因到组织到疾病」的三段推理时，把两张图拼起来是自然的做法。

§19 深化：AI-Ready 视角下的再评估

19.1 五个面向逐项打分

本库使用的 AI-Ready 判据包含五个面向，逐项给 HRA KG 打分的结果如下。机器可解析一项是满分：五种 RDF 序列化、SPARQL 端点、REST API 齐备，没有埋在 PDF 附录里的暗数据。许可清晰也是满分：数据 CC BY 4.0、代码 MIT，逐条数字对象核对 dct:license 与之一致。获取无阻同样满分：没有注册墙、没有审批流程、柏林与上海都有镜像。

版本可溯接近满分：双年发布、Zenodo 永久归档、PURL 版本化，三项都做到了；扣分只在于缺少机器可读的变更日志，想比较两个批次之间的差异只能人工比对。语义可对齐一项为良：与 Uberon、CL、PCL 深度对齐，但仍有 TEMP 欠账与大量 AS 缺本体 ID，做跨库 join 时必须显式处理这些行。

19.2 边界要诚实地划

比夸大能力更有用的是把「不适合」写清楚。它不适合当训练集，因为没有样本级特征与标签；不适合做疾病研究，因为只覆盖健康成人；不适合做细粒度空间分析，因为三维参考器官是简化模型、corridor 是概率估计而非测量值；不适合作为细胞类型发现的唯一依据，因为 TEMP 术语本身就说明这套词表还在完善；也不适合做实时线上服务，因为端点响应从秒级到超时不等，全图聚合查询会直接返回 504。

19.3 它真正适合的五件事

最核心的用途是跨数据集整合的对齐骨架。其次是作为标注流水线的受控词表来源——病理、影像、空间组学的标注都可以复用同一套 CL 与 Uberon 术语。第三是检索与问答的知识底座，尤其在 RAG 场景里，它能提供可引用的结构化先验。第四是本体补全的训练信号，TEMP 到 CL 的迁移本身就是一个有监督任务。第五是教学与展示，FTU Explorer 与 Organ Gallery 适合在课堂或科普场合使用。

19.4 一个具体的使用案例推演

假设一个团队要做「肺腺癌的空间转录组与正常肺对照」，完整链路是这样的。先从 HRA 取肺的 ASCT+B 表，得到肺泡、支气管、血管、胸膜等结构及其细胞类型清单；再从 OMAP 取肺的面板用于蛋白层验证；然后用 RUI 把患者的正常对照组织块注册到肺的三维参考器官，得到 CCF 坐标；接着从 hra-pop 取肺的 153 个数据集，得到细胞类型丰度基线；随后把肿瘤数据的注释用 CTann 交叉表映射到同一套 CL 词表；最后在统一的坐标与词表下比较肿瘤与正常。

这条链路里 HRA KG 在四个环节发挥作用：结构词表、抗体方案、空间坐标、丰度基线；但它自己一个样本都不提供。这正是「参考图谱」的价值形态——它不生产数据，它让别人的数据可以互相比较。

§20 深化：常见查询的语义解释

同一个问题在 HRA KG 里往往有三四个不同的答案这个问题有三个不同的答案，取决于问的是什么。以肾脏为例：ASCT+B 表里 CT 列去重后是 67 个细胞类型，这 67 个全部带 CL ID；而 hra-pop 的 cell summary 里实际观察到的数量通常少于表列，因为有些类型只在少数数据集里出现。三个数字都能叫「细胞类型数」，含义却天差地别：表列是编纂结果，带 ID 数是可 join 的比例，实测数是覆盖面。最稳妥的表述是「ASCT+B 肾脏表 v1.8 列出 67 个细胞类型」，并注明这是表列而非实测。

问「某基因是不是某细胞的标志物」时，要理解 BGene 列给的是专家认定的标志物，不是「该基因只在该细胞表达」。一个基因完全可能同时被列为多个细胞类型的标志物——肾脏表 190 个条目里就存在重复基因名，CCL4 出现在多个条目中。正确的解读是「该基因被专家列为该细胞类型的特征标记之一」；做单细胞注释时，标志物应当按组合使用，而不是指望单基因决定归属。

问「某组织块来自哪里」时，答案有三个层次：门户元数据里数据集自己声明的器官（可能缺失，hra-pop 中有 164 个数据集缺 organ_id）；RUI 记录的 CCF 坐标与 corridor（前提是有人做过注册）；以及用 Tissue Origin Predictor 基于 hra-pop 统计先验反推的细胞类型来源。三者互相矛盾时，优先级应是注册位置高于门户元数据，门户元数据高于细胞类型推断，因为前两者是直接观测，后者是统计推测。

问「这张表能不能用」时，只需四问：版本是否明确（不能是 latest）、有多少 AS 带本体 ID（决定可 join 的比例）、表头是否有作者与评审人（决定可信度）、Data DOI 是否可解析（决定可引用性）。四问都过，表就可以用；缺任何一问，都要在方法节声明对应的局限。

§21 深化：从图谱到产品的路径

21.1 三类可落地的产品形态

第一类是标注辅助工具：输入病理或影像切片，输出带解剖与细胞类型建议的标注，依赖 ASCT+B 与 FTU。第二类是数据目录检索：输入自然语言问题，输出相关数据集列表及其位置，依赖 hra-pop 与数据集图。第三类是空间注册服务：输入组织块信息，输出 CCF 坐标与碰撞摘要，依赖三维参考器官与地标。三者的共同点是都不需要搬运原始数据，只引用 HRA 的语义层——这正是 CC BY 4.0 全开放带来的直接商业可行性。

21.2 工程落地的四个检查点

缓存策略是第一关：端点延迟不稳定，生产系统必须缓存常用查询结果（例如各器官的 ASCT+B 表），并按版本号失效，不能按时间失效。第二关是降级路径：端点不可用时能回落到本地快照，否则一次 504 就会让整个功能不可用。第三关是版本冻结：产品上线时锁定数字对象版本，升级走变更流程，而不是跟着 latest 自动漂移。第四关是署名合规：前端的数据来源页要列出论文引用与每个数字对象的 Data DOI，这是 CC BY 4.0 的最低要求。

21.3 一个反面案例

最常见的失败模式是直接把 hra-pop 的细胞丰度做成热图对外发布，标题写「人体各器官细胞组成」。这个做法有三处错误：样本偏差被抹掉了（807 个数据集不是人体的随机抽样）、器官归属模糊被忽略了（164 个数据集根本没有 organ_id）、细胞计数被当成了真实比例（计数取决于测序深度与细胞捕获率）。正确的做法是在图上标注「基于 807 个已注册数据集的加权统计，非人体真实比例」，并附上数据来源清单与版本号。

§22 深化：维护节奏、版本语义与半衰期

22.1 三类数字的寿命不一样

判断一个数字能不能直接引用，先看它的半衰期。节点数、边数、体积这一类随每次发布整体重算的数字，半衰期就是半年——下次发布一定变；器官数、数字对象数这类跟着版本走的，半衰期在半年到一年之间；某张器官表里的细胞类型数、标志物数，只要该表没有新版本就保持不变，半衰期可以到一到两年；本体版本号与联盟数则是另一类，前者半年一变且必须记录依赖快照，后者通常一年才动一次且在官网、论文、Zenodo 三处口径不一。凡是引用了这些数字的结论，都应在正文里带上版本与抓取日期，否则半年后无法自证。

相对稳定的是四样东西：三层子图加十三类数字对象的架构设计，两三年内不会改；CC BY 4.0 的许可条款，除非政策层面变动；每年 6 月 15 日与 12 月 15 日的双发节奏，已在官网明文承诺；Uberon、CL、PCL 作为核心本体的选择，经过多年沉淀已经形成路径依赖。这四样构成了「不会因为升级而全部推倒重来」的基础，也是长期使用者敢于投入工程资源的理由。

22.2 版本号有三层，混用会出错

最容易混淆的是「批次版本」与「对象版本」。v2.5 是知识图谱集合的批次版本，每半年一个；而单张 ASCT+B 表有自己的版本号，肾脏表当前是 v1.8，OMAP-3 当前是 v1.4，两者升级节奏与批次完全不同步。一个数据集在 v2.5 里被引用时，它携带的是「某个具体对象版本」，不是「v2.5」，因此在正文里写「依据 HRA v2.5 的肾脏表」是不够的，必须写到 v1.8。

第二层混淆是「构建版本」与「发布版本」。构建版本是数据处理管线产出的内部标识，发布版本是 Zenodo 上生成记录的那个版本。v2.5 的 Zenodo 记录创建于 2026 年 6 月 15 日，而 KG 集合的 schema:dateCreated 写的是 2026 年 9 月 11 日——后者是构建时间，前者是发布动作发生的时间。论文正文写统计于 2025 年 5 月，Zenodo 摘要写 4 月，也属于这一类差异。看到日期对不上时，先分清是构建、发布还是统计时点。

第三层是「本体版本」与「图谱版本」。HRA KG 依赖 Uberon、CL、PCL 等外部本体，这些本体自己有发布节奏（通常按月或按季度），HRA 在一个批次里锁定的是某个特定快照。要复现一次查询，除了写死 HRA 批次号，还应记录当时依赖的本体版本；否则半年后同一句 SPARQL 可能因为本体新增了等价公理而返回不同结果。

22.3 给长期使用者的三条动作

第一，项目启动时就把所用版本的 tar.xz 归档到本地或机构存储，不要依赖端点长期可用。端点会升级、会限流、会在发布窗口前后短暂不一致，而归档文件不会。第二，把 PURL 全部抽成配置文件里的常量，代码里不允许出现硬编码的 latest 或裸域名；升级时只改一处，回归测试的成本就降到最低。第三，每次升级做一次差异比对：新增了哪些器官、哪些 OMAP、哪些 TEMP 被替换成了正式术语、哪些表改了版本号，把这份差异写进项目日志。三次升级之后，这份日志本身就成了团队最有价值的资产。

22.4 这张图对教学的用处

HRA 是一个罕见的「开放知识工程」完整样本：有同行评审论文、有开源代码、有带 DOI 的数据快照、有语义化版本、有明确许可、有公开的评审记录（表头逐行列评审人与 ORCID）。用它讲三个区分最有效：参考数据与观测数据的区分、本体与实例图的区分、开放许可与受控访问的区分。这三个区分是生物医学数据素养的核心，而 HRA 恰好每一条都能拿出具体例子，不需要编造教学案例。

22.5 一句提醒

HRA KG 最大的诱惑是「看起来什么都有」，最大的风险也在这里。一千万个节点里，真正能直接支撑生物学结论的断言只占一小部分，其余是标签、层级与元数据。把它当成索引而不是数据库，把它当成坐标系而不是地图，才是正确的打开方式。

§23 深化：参考坐标的医学意义

23.1 为什么「正常」值得单独建一张图谱

现代医学数据的主流是「病例」：肿瘤切片、患者影像、病历文本。健康对照往往只在研究里作为背景出现，且采样零散——不同研究用不同医院、不同年份、不同取材规范的健康组织，结果彼此无法对齐。

这带来一个结构性后果：疾病研究缺少一个稳定的「正常基线」。当你看到「肿瘤组织里 CD8+ T 细胞比例下降」，你需要一个可信的正常参考来比较；如果参考来自另一个实验室的十个样本，这个「下降」可能只是批次效应。

HRA 的第一层意义就在这里：它不是「再收集一批健康样本」，而是把已有的健康样本挂到统一的解剖坐标与细胞词表上，让「正常」变成一个可计算的对象。每一个注册到 CCF 的组织块，都成为这个基线的一个坐标点；每一个经过 CTann 归一化的细胞类型，都成为基线上的一格丰度。

23.2 从「器官」到「功能组织单元」的降维

临床病理与影像的描述习惯停在器官层级：这是肺、这是肾。但生理功能发生在更小的单元：气体交换在肺泡、滤过在肾小体、代谢在肝小叶。HRA 的 2D FTU 就是为这个尺度准备的：22 个单元（v2.2），覆盖 10 个器官。

FTU 的意义在于它提供了一种「跨器官可比的最小单元」：肺泡与肾小体在结构上完全不同，但都是「一种细胞排列执行一种功能」的实例。当你要做「不同器官的上皮屏障功能」比较时，FTU 层级比器官层级更合适。

现实限制也很明显：v2.2 只有 10 个器官有 FTU，肾脏独占 8 个。这意味着 FTU 层级的跨器官研究目前只在少数器官间可行。

23.3 抗体面板与「可观测性」

OMAP 解决的是一个常被忽略的问题：不是所有细胞类型都能被观测。ASCT+B 表说某个结构里有五个细胞类型，但如果你手上只有三个抗体，你只能看到三个。

OMAP 在实践中承担两个功能：

可行性评估：某个器官的细胞类型能否用现有面板全部覆盖？
实验设计起点：新实验室可以复用面板而不必从零摸索。

OMAP-3 的说明文档坦率地承认了局限：它「提供肾脏细胞类型的概览，但不支持免疫细胞群的细粒度分型」。这句话值得所有使用者留意——面板的覆盖面是有边界的，且作者自己会写出来。

23.4 空间注册对临床样本的价值

临床上，手术切除标本的取材位置往往由外科医生按经验决定，缺乏标准化记录。这意味着十年后回看一份标本，很难说清「这块组织到底取自哪里」。

如果标本在取材时就用 RUI 注册到 3D 参考器官，这个信息就被永久记录：坐标、与哪些结构相交、可能的 corridor。这不是为了今天的诊断，而是为了十年后的再利用。

对生物样本库的意义尤其大：一个库里如果有上万份标本都带 CCF 坐标，它就从一个「冰箱」变成了「可检索的空间资源」。

23.5 局限：健康成人之外

必须明确，HRA 的范围严格限定在健康成人（healthy adult），由此派生三条硬边界。儿科不覆盖：儿童器官的尺寸、细胞组成与比例和成人差异显著，直接套用成人参考会系统性偏移。疾病不覆盖：肿瘤、炎症、纤维化改变后的组织结构不在参考层，参考层描述的是未受病理扰动的一般状态。衰老不覆盖：SenNet 的数据确实进入了 hra-pop 实例层，但参考层的 ASCT+B 表写的仍是「一般成人」，没有按年龄段分层。这三条限制决定了 HRA 不能被当作全生命周期的人体模型；做儿科或老年研究时，它是起点而不是终点，任何结论都要另找对应年龄段的参考来校验。

§24 深化：一份可执行的复现脚本思路

24.1 目标

在不依赖交互界面的前提下，用命令行完成：取肾脏表 v1.8 → 解析 → 统计三层口径 → 输出一份可比对的摘要。整个过程只用公开端点与公开 CDN。

24.2 步骤拆解

第一步：定位版本。 访问 https://lod.humanatlas.io/asct-b/kidney/ 的 JSON-LD，读出 hasCurrentVersion 指向的版本 URI。若要做历史复现，直接在 URI 里写死 v1.8。

第二步：取 CSV。 拼接形如 https://cdn.humanatlas.io/digital-objects/asct-b/kidney/v1.8/assets/asct-b-vh-kidney.csv 的地址下载。实测体积约 78 KB。

第三步：解析。 用 utf-8-sig 读取（去 BOM），以 AS/1 为表头定位行，跳过前 8 行元数据。列索引按官方 schema：AS 三列一组从 0 起，CT 从 21 起，BGene 从 31 起，每组四列（标签、名称、ID、注释）。

第四步：统计。 分别计算行数、AS 去重节点数、带 UBERON ID 的 AS 数、CT 去重数、B 去重数。注意去重键是 (标签, ID) 而不是仅标签——同名不同 ID 的情况真实存在。

第五步：交叉校验。 用 lod 上该版本的元数据核对：版本号、发布日、作者、评审人是否与 CSV 表头一致。不一致说明取错了对象。

24.3 预期输出

对肾脏 v1.8，应得到：78 行 / 74 个 AS 节点 / 11 个带 UBERON ID / 67 个 CT / 190 个 B。若数字不对，先查 BOM 与表头定位，再查去重键。

24.4 为什么值得写这个脚本

因为**「表里有多少实体」是所有下游分析的分母**。分母错了，后面的比例、覆盖率、缺失率全错。而这个分母恰恰是最容易被随手估计错的：行数、节点数、带 ID 节点数三者差异巨大，而论文与官网都不会直接告诉你。

§25 深化：常见误读的逐条纠正

25.1 「HRA KG 有 1006 万个节点，所以它是最大的生物医学知识图谱之一」

不成立。节点数不等于知识量。Wikidata、UBKG、Petagraph 的节点数都远大于它（表 3 里 UBKG 是 5415 万）。HRA KG 的定位是垂直深而非规模大。

25.2 「它有 2,268 个细胞类型，覆盖了人体全部细胞类型」

不成立。2,268 是编纂范围内的计数，其中 221 个仍是 TEMP。CL 本身收录的细胞类型数与 HRA 编纂数不可直接比较，因为口径不同。

25.3 「它是 HuBMAP 的数据仓库」

不成立。HuBMAP 门户才是数据仓库；HRA KG 是索引与坐标系。两者共用联盟与部分基础设施，但功能不同。

25.4 「用它可以做疾病诊断」

不成立。它只描述健康成人，不含疾病特征，也不能作为诊断依据。官网明确写有 medical disclaimer。

25.5 「CC BY 4.0 意味着里面所有数据都能商用」

不成立。CC BY 4.0 覆盖 HRA 自己的数字对象；它指向的原始数据受各自条款约束（详见 §16.1）。

25.6 「v2.5 是最新版，所以论文的数字过时了」

不成立。论文的 v2.2 数字代表一个已发表的历史快照，在复现语境下仍然有效且必须保留。新版数字与旧版数字应并列，而不是替换。

25.7 「ASCT+B 表就是一张 Excel」

形式上接近，实质上不同：它有 Data DOI、有评审人、有版本、有编译管道。把它当普通 Excel 对待，就会忽略它的可引用性与可追溯性。

25.8 「hra-pop 的细胞数就是人体细胞数」

不成立。它是数据集报告细胞数之和，存在重复计数与采样偏差（详见 §15.1）。

§26 深化：跨库整合的三个实操配方

26.1 配方一：用 HRA 词表统一三个单细胞数据集

场景：三个来源的单细胞数据（HuBMAP、CxG、GTEx 各一），细胞类型命名各不相同。

步骤：

对每个数据集，用 CellTypist 或 Azimuth 重新注释，得到工具标签；
通过 CTann 交叉表把工具标签映射到 CL/PCL；
用 HRA 的 ASCT+B 表校验：这些细胞类型是否可能在声明的器官里出现；
不一致的条目单独列出，人工复核；
统一后的矩阵按 CL 术语汇总。

关键点：第 3 步是过滤器不是判据——ASCT+B 可能漏收某些细胞类型，不能因为「表里没有」就丢弃。

26.2 配方二：把临床标本挂进 CCF

场景：一个生物样本库想把历史标本的取材位置标准化。

步骤：

按器官选择 3D 参考器官（注意性别与侧别）；
用 RUI 逐块注册，记录尺寸与摆放；
导出 corridor 与碰撞摘要；
对没有地标的器官，标注「低置信度」；
把坐标与原有病理描述并列保存，不覆盖原有记录。

关键点：坐标是增量信息，不是替代信息。原病理描述往往包含取材时的现场判断，不应丢弃。

26.3 配方三：构建一个器官知识问答系统

场景：给病理科做一个「这个结构里有什么细胞、用什么标记」的问答工具。

步骤：

导出目标器官的 ASCT+B 表与相关 OMAP；
按结构切分为问答单元（每条记录 = 一个结构-细胞-标记三元组）；
为每个单元生成自然语言描述 + 结构化字段；
建立检索索引（关键词 + 向量双路）；
回答时强制附带来源（表名、版本、Data DOI）。

关键点：强制溯源。医学问答里最危险的不是答不出，而是答得流畅却没有出处。HRA 的 Data DOI 体系让「每句话都有出处」成为可能。

26.4 三个配方的共同点

都遵循同一模式：HRA 提供约束与词汇，本地数据提供内容，两者不混存。这个分离设计让 HRA 的版本升级不会破坏本地数据，也让本地数据的更新不需要等待 HRA 发布。

§27 深化：给不同读者的最短路径

五类读者的入口完全不同，走错顺序会浪费一周以上。病理与影像科医生应先把 FTU Explorer 打开，看看功能组织单元长什么样，再翻 OMAP 理解多重成像能看到什么，最后用 EUI 看标本在器官里的位置；全程不需要学 SPARQL，这三步能建立的直觉比读十篇论文都直接。生物信息学家的路径相反：先按 §24 的方法取一张 ASCT+B 表跑通解析，再查 hra-pop 的细胞丰度，最后才碰 SPARQL 端点。一上来就陷进本体细节是最常见的浪费，因为多数分析并不需要理解 PCL 与 CL 的全部分工。

知识图谱工程师应当先读论文里构建与部署两节，再看 hra-do-processor 的 README 与 Docker 用法，然后照 §20 的查询模式练手。重点是理解命名图与版本策略：HRA 用命名图把每个数字对象隔离开，这决定了 join 的写法；版本策略决定了你写死哪个 URI。数据管理者关心的是另外三件事：许可的三层结构（§16.1）、版本与归档机制（§17.3 与 §22）、镜像搭建的标准流程（Zenodo 记录 10.5281/zenodo.17873664 有完整 SOP）。这三件事决定了数据三年后还能不能用。项目负责人只需要读 §19 的 AI-Ready 再评估与 §26 的三个整合配方，据此判断自己的项目属于哪一类用法，再决定投入多少工程资源——判断错了，后面所有投入都会打折。

§28 收束：一个判断

HRA KG 的价值不在它现在覆盖了多少，而在它建立了一种可被他人继承的秩序：解剖有 ID、细胞有词表、标记有抗体、样本有坐标、版本有快照、许可有边界。这套秩序一旦被足够多的项目采用，就会成为事实标准；而它能否成为标准，取决于后来者是否愿意在自己的数据上多花那一步注册的功夫。

对使用者最实际的一句话是：如果你在做跨数据集、跨器官、跨模态的整合，先从 HRA 借一套词表与坐标；如果你只做单一数据集的建模，它可能帮不上太多忙。写作本文时的基准也一并交代在此：论文基线 v2.2（2025 年 5 月统计），现行版本 v2.5（2026 年 6 月发布），端点实测与目录抓取均在 2026 年 10 月 17 日。读者若发现本文数字与官网不一致，请先确认三件事——版本是否相同、统计口径是否相同、抓取时间是否相同；三者任有一项不同，差异就是正常的，而非错误。

§29 深化：数据血缘的追溯方法

29.1 一条断了的链

参考图谱的使用者迟早会遇到这个场景：hra-pop 里某个数据集显示「肺、RNAseq、12,345 个细胞」，你想知道它来自哪篇论文、这台机器做的、用了什么注释工具——然后就发现信息不全。

HRA 的血缘链设计上有五环，但每一环的完整度不同：

环节	载体	完整度	缺口
参考对象	DO 的 PURL + Data DOI	高	无
数据集标识	门户 UUID / CxG collection ID	高	跨门户不一致
论文关联	`ccf:publication` 字段	中	部分数据集无
注释方法	CTann 交叉表	中	只记录工具，不记录版本
原始文件	门户链接	高	受门户许可约束

最弱的一环是第三与第四：很多数据集在图里存在，但查不到对应论文或注释工具版本。这对需要严格复现的研究是实质障碍。

29.2 三步补全法

要在实践中补全血缘，可以按这个顺序：

以 UUID 回查门户：HuBMAP 的 https://entity.api.hubmapconsortium.org/entities/<uuid> 返回完整元数据（含 data_types、status、last_modified）；SenNet 有同类接口；CxG 用 collection ID；
从门户拿到 publication DOI：多数门户记录了关联论文；
从论文拿到方法与版本：注释工具版本通常写在方法节，需要人工提取。

三步都走完，才得到一条可复现的链。只依赖 HRA KG 本身无法完成全部三步，这是必须向使用者说明的边界。

29.3 为什么血缘不能「自动化」到完美

根本原因是异构：HuBMAP 记录 data_types，CxG 记录 assay_ontology_term_id，GTEx 记录 SMTSD（组织细分代码）。三套字段无法无损映射，任何自动化都只能做到「近似对齐」。HRA 的 CTann 是在细胞类型层做这件事，但没有在「数据集元数据层」做同样的事。

这也解释了为什么 hra-pop 只有 807 个数据集，而 full 有 47,792 个：质控与血缘补全的成本，决定了能被精选的数量。

§30 深化：与影像组学的接口

30.1 两套解剖语言的翻译需求

放射影像的解剖标注通常用 DICOM 的 SNOMED CT 编码或 RadLex 术语；病理影像的标注则多用自建标签。HRA 用 Uberon。三套术语之间没有现成映射。

对希望把影像数据接入 HRA 的团队，实际做法是：

建立一个器官级的对照表（如「左肾」 → UBERON:0004538 的侧别变体 → DICOM 的肾脏编码）；
只做到器官级，不追求结构级（因为影像分辨率与组织学结构不匹配）；
把对照表本身当作资产发布，便于他人复用。

30.2 分割模型能用 HRA 做什么

三个具体用法：

类别体系设计：做器官分割模型时，类别定义可参照 ASCT+B 的结构层级，避免自造词；
标签校验：模型输出的类别若在 ASCT+B 表里不存在于该器官，提示可能的标注错误；
报告生成：分割结果转文字报告时，用 HRA 的术语生成标准表述。

30.3 一个现实差距

影像的空间分辨率（毫米级）与 HRA 的 3D 参考器官（厘米级网格）不在一个量级。这意味着影像无法直接「注册」到 HRA 的参考器官上并得到有意义的细胞级信息——中间必须经过组织学取样这一环。目前的实际路径是：影像定位 → 取材 → 组织块注册 → 细胞类型推断，每一环都会损失精度。

对这个损失链的诚实描述，比宣称「影像可以直接映射到细胞图谱」更有价值。

§31 深化：教材化的三个小节

31.1 参考数据与观测数据的区别

观测数据是「测量得到的」，参考数据是「约定形成的」。前者有误差分布，后者有版本与共识。把参考数据当观测数据用（例如把 ASCT+B 的细胞类型数当成实测计数），是初学者最典型的错误。

判断方法：问一句「这个数字会不会因为新测一批样本而改变？」会变的是观测，只会因修订而变的是参考。

31.2 本体与实例图的区别

本体回答「概念之间的关系」（T 盒），实例图回答「具体实体归属于哪个概念」（A 盒）。HRA KG 两者都有：Uberon/CL 的部分是 T 盒，ASCT+B 的断言是 A 盒。

这一区分在查询时很重要：查上位概念走 T 盒（subClassOf 链），查具体归属走 A 盒（实例的 type 与属性）。

31.3 开放许可与受控访问的区别

开放许可是「许可条款允许」，受控访问是「技术上需要授权」。HRA 属于前者，多数临床数据属于后者。两者可以组合：HRA 开放，但它指向的临床数据可能受控。

常见的误解是「只要数据是开放的就没有隐私问题」——参考层确实没有个体信息，但一旦与受控数据关联，整体就落入受控范围。

§32 深化：给数据集的体检清单

这份清单可以拿去评估任何参考型数据集，不必是 HRA。十项里 HRA 八项明确合格、两项部分合格，这个画像本身就说明了「高质量参考数据集」长什么样。

前十项问的是「有没有」：有没有独立 DOI（HRA 有论文与 Zenodo 双 DOI）；有没有版本号（有，且是批次版本与对象版本双层）；有没有逐对象的许可声明（有，每个数字对象都带 dct:license）；能不能机器读取（能，五种 RDF 序列化）；有没有明确的更新计划（有，6 月 15 日与 12 月 15 日双发）；有没有评审记录（有，表头逐行列评审人与 ORCID）；有没有引用规范（有，论文加每个对象的 citation 字段）；有没有归档（有，Zenodo 加柏林、上海双镜像）。这八项全部过关，剩下的两项才是真正的难点。

后两项问的是「好不好用」：有没有质量指标，有没有变更日志。HRA 在这两项上都只做到「部分」——质量指标体现在 TEMP 术语的计数与 CTann 交叉表的覆盖率上，但没有一个统一的、可以直接读的「语义完备度」仪表盘；变更日志存在于官网的发布说明里，是人写的散文，不是机器可解析的结构化记录。这意味着使用者若想知道「v2.4 到 v2.5 之间肾脏表变了什么」，只能人工比对两个版本的 CSV。这两项正是所有参考型数据集的共同短板，也是评估时最该追问的地方。

§33 深化：三个容易混淆的「版本」

33.1 批次版本与对象版本

v2.5 是一个批次（11th Release）， kidney v1.8 是一个对象版本。批次是「在某天打包发布的一组对象」，对象版本是「某个对象的第几次修订」。

一个对象可以在多个批次里保持同一版本号（未修订），也可以在一个批次内被跳过（未包含）。因此「v2.5 里的肾脏表」这句话本身不精确，必须说「v2.5 批次中肾脏表的版本是 v1.8」。

33.2 构建版本与发布版本

Zenodo 的 v2.5 记录日期是 2026-06-15，而 KG 集合的 dateCreated 是 2026-09-11。前者是发布承诺日，后者是构建完成日。两者不一致说明构建过程有延迟，但对外仍按日历发布。

33.3 本体版本与图谱版本

HRA KG 依赖 10 个本体，每个有自己的版本与发布日期。图谱发布时会锁定依赖快照（如 Uberon 2024-11-25）。这意味着「用 v2.5 的 HRA KG」实际上也确定了「用哪个版本的 Uberon」——这对复现是好事，对想用最新本体的用户是约束。

§34 深化：误差来源的清单

任何基于 HRA KG 的结论都带有误差，来源可以穷举为七类：

误差源	表现	缓解
编纂误差	专家写错结构或标记	评审流程、Data DOI 追溯
术语误差	同物异名、异物同名	本体 ID 优先于名称
覆盖误差	器官/细胞未被收录	查 TEMP 计数、查目录覆盖
空间误差	注册位置偏移	有地标的器官优先
注释误差	工具注释与专家分歧	CTann 交叉表
采样误差	数据来源不均	用 hra-pop 而非 full
版本误差	混用不同版本	全链路锁定版本

七类误差里，前四类来自「参考层」，后三类来自「实例层」。做结论时应明确你的结论依赖哪一层，从而知道该缓解哪几类误差。

§35 词表与标识符的深水区

36.1 四类 ID 在查询中的优先级

在 HRA KG 里定位一个实体，可能同时有名称、ID、PURL、UUID。正确顺序是：本体 ID > PURL > 名称 > UUID。

理由是稳定性与唯一性：本体 ID 全球唯一且跨库通用；PURL 在 HRA 内稳定；名称有同义与歧义；UUID 只在特定门户内有效，门户迁移就会变。

具体到查询：

找解剖结构：用 UBERON ID（若表里没有，退回名称模糊匹配）；
找细胞类型：用 CL/PCL ID；
找基因：用 HGNC ID（不要用基因符号，因为符号会随命名委员会更新而变）；
找数字对象：用 PURL（带版本号）。

36.2 名称匹配的三个失败模式

失败一：大小写与标点。 「loop of Henle」与「Loop of Henle」、「loop of henle」在字符串比较里是三个不同值。HRA 的标签并不保证统一大小写，跨表比较必须做归一化（小写 + 去标点 + 合并空白）。

失败二：同物异名。 同一结构在不同表里可能用全称与缩写（「glomerulus」 vs 「renal corpuscle」在不同语境下指代不同，但常被混用）。稳妥做法是先查 UBERON 的同义词表，再匹配。

失败三：异物同名。 同一个词在不同器官里指不同结构（「capsule」在肾、肝、肾上腺里各有所指）。因此名称匹配必须限定在器官范围内，否则会跨器官误配。

36.3 空 ID 行的三种处置

实测肾脏表 74 个 AS 节点中只有 11 个带 UBERON ID。对其余 63 个空 ID 节点，有三种处置策略：

策略	做法	适用
保留为独立类别	用「器官前缀 + 名称」造本地键	内部一致性优先，不需外部 join
映射到最近的上级	归到最近的有 ID 的祖先	做粗粒度统计
丢弃	只保留带 ID 的行	需要严格外部可比时

三种策略各有代价：第一种失去跨库可比性，第二种损失分辨率，第三种丢失信息。推荐默认采用第一种，因为 HRA 本身就把它们当作合法节点。

36.4 术语的跨语言问题

HRA 的标签全是英文。做中文应用时，常见做法是：

用官方中文解剖学名词（如《人体解剖学名词》2014 版）做映射；
细胞类型沿用英文或采用学界通用译名；
保留英文原名为检索主键，中文为展示层。

这条建议的理由很实际：中文解剖学名词与 Uberon 的层级不完全对应，强行对齐会引入额外误差。双语并存、以英文为准是更稳的做法。

§36 时间维度的处理

37.1 图谱里有时间吗

HRA 描述的是「健康成人的一般状态」，不按年龄分层。这意味着图谱本身是时间无关的——同一个肾小体在 25 岁与 65 岁的差异，图谱不表达。

但图谱里确实有三类时间信息：

数字对象的创建与修订日期（DO 元数据）；
数据集的注册日期（rdfs:label 里的「Registered 5/7/2022」）；
文献关联的发表年（HRAlit 图层）。

前两类是管理时间（metadata time），第三类是学术时间。三者都不是生物学时间（样本年龄、病程）。

37.2 想做年龄分层怎么办

两条路径：

用 SenNet 的数据：衰老网络的数据进入 hra-pop-full，可按供体年龄筛选（若原始门户记录了年龄）；
自建分层：把 HRA 作为骨架，按年龄分箱挂接本地或公开数据的细胞丰度。

两条路径的共同限制：参考层（ASCT+B）不变，只有实例层可分年龄。也就是说，你可以得到「老年肾皮质的细胞组成」，但得不到「老年肾皮质的解剖结构定义」——后者在 HRA 里仍按成人通用描述。

37.3 版本时间与生物时间的混淆

一个常见错误是把「HRA v2.0 到 v2.5 的变化」解读为「人体随时间的生物学变化」。实际上版本变化反映的是编纂进度与数据积累，与生物学无关。任何把版本变迁当作时间序列分析的尝试都是范畴错误。

§37 跨图谱连接的三种模式

38.1 模式一：共享本体（最稳）

两个图谱都使用 Uberon/CL 时，通过本体 ID 直接 join。HRA 与 Ubergraph、CL 生态、多数 OBO 图谱都属于这一类。

优点：无需人工映射；缺点：只在本体覆盖的范围内有效，TEMP 术语无法 join。

38.2 模式二：共享实体（需对账）

两个图谱都引用同一个数据集或同一篇论文时，通过 DOI 或 UUID join。HRA 与 HuBMAP、CxG 的关系属于这一类。

优点：粒度细；缺点：需要对账（同一数据集在不同门户可能有不同 ID），且覆盖率低（不是所有数据都被多个图谱收录）。

38.3 模式三：共享坐标（最弱但最通用）

两个图谱都用 CCF 或类似的空间框架时，通过坐标邻近 join。HRA 与任何做了 3D 注册的项目都属于这一类。

优点：不依赖术语一致性；缺点：精度受注册质量限制，且只能连接「有空间位置」的实体。

38.4 选择建议

优先级从高到低：共享本体 → 共享实体 → 共享坐标。原因是精度依次下降。实际项目中常常三者混用：先本体 join 拿到候选，再用实体对账确认，最后用坐标做空间一致性检查。

§38 图谱的「读法」：三种查询心智模型

40.1 树模型：顺着层级往下走

把 HRA KG 当树看，是从「器官」出发逐层下钻：器官 → 结构 → 子结构 → 细胞类型 → 标志物。这是最直观的读法，也是 ASCT+B 表本身的结构。

适用场景：写综述、做教材、给团队讲清楚「这个器官里有什么」。
局限：树模型忽略了跨表关系（同一细胞类型出现在多个器官），也忽略了空间信息。

40.2 图模型：任意两点的最短路径

把 HRA KG 当图看，问的是「两个实体之间有什么关系」。例如「足细胞」与「肾病综合征」在图里没有直接边，但可以通过「足细胞 → 位于 → 肾小体 → 属于 → 肾皮质」这条路径建立解剖学关联。

适用场景：做检索、做推荐、做知识补全。
局限：路径不等于因果，也不能自动推出临床结论。

40.3 坐标系模型：位置先于分类

把 HRA KG 当坐标系看，问的是「这块组织在哪、周围有什么」。此时分类（这是肾皮质）是坐标的附带属性，而不是查询的起点。

适用场景：空间组学、样本管理、跨研究对齐。
局限：需要有注册数据，否则坐标系是空的。

40.4 三种模型的选择

选哪种模型，取决于你问的是哪一类问题。问「这个器官有哪些细胞」，用树模型，入口是 ASCT+B 表——表本身就是一棵树，顺着 AS 列往下读就是答案。问「这个细胞和那个结构是什么关系」，用图模型，入口是 SPARQL——这类问题在树里问不出来，因为跨表关系只在图里显式存在。问「这批样本在哪」，用坐标模型，入口是 EUI 与 RUI——此时分类只是坐标的附带属性。问「这个基因标记哪些细胞」，需要树与图配合：先从 BGene 列拿到基因，再沿逆向边找到它标注的细胞类型。

三种模型不是互斥的，同一个项目里常常交替切换：先用坐标模型筛出目标区域的样本，再用树模型看该区域的细胞构成，最后用图模型验证某个细胞类型的跨器官分布。理解三种模型的差别，比记住任何单个查询都重要。

§39 参考图谱的维护经济学

41.1 成本构成

维护一张参考图谱的成本主要不在存储，而在人力：

成本项	承担者	特性
专家编纂表	领域专家（多为临床医生与基础研究者）	时间稀缺，按器官计
同行评审	编辑委员会	每表至少两位评审
工具与管道	工程团队	一次性投入 + 持续维护
空间标注	标注员	按器官/组织块计
社区支持	工单与教程	持续
基础设施	云与镜像	可预估

其中「专家编纂」是最难扩展的一环：一个器官的表可能需要数月，因为专家必须在「完整」与「可用」之间反复折中。

41.2 为什么 OMAP 增长快

对比 §4.6 的观察：OMAP 从 23 增至 38（+65%），而 ASCT+B 的实质新增有限。原因在成本结构：

OMAP 的作者是做实验的人——他们本来就要设计面板，把它整理成标准表格是「顺便」；
ASCT+B 的作者是做编纂的人——他们需要覆盖整个器官，工作量大且难以拆分。

这个差异对所有参考型项目都成立：「由使用者顺手生产」的数据增长最快，「由专家专门生产」的数据增长最慢。

41.3 可持续性的判断

一个参考图谱能活多久，取决于三件事：资助周期、社区依赖度、替代品的出现。HRA 目前三项都偏正面：NIH Common Fund 多年资助、26 个联盟依赖、暂无同等规模的替代品。但这不等于永久——资助到期与联盟重组都可能改变轨迹。

对使用者的含义：不要把 HRA 当作永久基础设施来设计系统，要有「数据本地化 + 版本归档」的备份策略。

§40 一份可打印的检查卡

下面这份清单可以打印出来贴在工位上。它不解决技术问题，但能防住最常见的一类事故：用了对的数据、错了的版本、漏了的引用。四个阶段各四条，一共十六个动作。

使用前，先把问题归位。 第一条是判断你的问题属于树、图、坐标三种模型中的哪一种——这决定了后面整条技术路线（详见 §38）。第二条是确认目标器官的 ASCT+B 表当前版本号，PURL 里的 latest 不能作为记录。第三条是确认目标器官是否具备 2D FTU、OMAP 与地标：这三个对象不是每个器官都有，v2.2 只有 10 个器官有 FTU，肾脏独占 8 个，如果研究设计建立在「所有器官都有 FTU」的假设上，第一天就会卡住。第四条是核对许可范围，CC BY 4.0 覆盖的是参考层。

使用中，守住五条查询纪律。 查询一律带 LIMIT，端点的首字节延迟在 1 到 20 秒之间，不带限定的聚合查询会直接吃满超时；PURL 一律写死版本号，latest 是滑动指针；做名称匹配时先限定器官范围再匹配，否则「皮质」这类词会跨器官命中；遇到空本体 ID 的行要单独处理，不能静默丢弃；hra-pop 与 hra-pop-full 要分开使用，前者做定量，后者只做覆盖度探索。

使用后，把可复现性补齐。 记录所用版本号与抓取日期，精确到日；引用时论文、数字对象的 Data DOI、Zenodo 概念 DOI 三者齐全；在方法节写明局限，至少包括 TEMP 术语、器官覆盖不均、采样偏差三项；把实际用到的快照归档一份，不要只留一个 URL。

复查，跟着发布节奏走。 HRA 每年 6 月 15 日与 12 月 15 日各发一版，复查动作应挂在发布之后：检查目标器官是否有新版本表，检查 TEMP 是否被替换为正式术语，检查是否有新的 OMAP 可以替代你正在用的旧面板。三项检查做完，通常只需要半小时，但能避免你在半年后才发现自己引用的是两代之前的面板。

§41 与其他「图形式」数据资源的边界

43.1 与本体文件（OWL）的区别

下载一个 CL 的 OWL 文件，你得到的是概念及其公理；下载 HRA KG，你得到的是概念 + 实例断言 + 空间对象 + 实验面板。前者是词典，后者是「词典 + 例句 + 地图 + 菜谱」。

实践差别：OWL 文件用 Protégé 打开，HRA KG 用 SPARQL 端点或图浏览器；OWL 的推理是逻辑推演，HRA KG 的推理主要是路径遍历。

43.2 与数据目录（Catalog）的区别

数据目录（如 HuBMAP 门户的浏览页）是列表：按器官、技术、状态筛选数据集。HRA KG 是图：不仅列出数据集，还描述它们与解剖结构、细胞类型、空间位置的关系。

对使用者：目录回答「有哪些」，图谱回答「它们之间怎么连」。两者都需要，但用途不同。

43.3 与 CAD 模型库的区别

3D 参考器官看起来像 CAD 模型，但它的重心不在几何精度，而在语义标注：每个网格区域挂 UBERON ID，每个地标有名字与位置，每个注册的组织块有坐标与碰撞记录。几何只是载体。

如果只想要器官的 3D 形状做可视化，任何解剖模型库都能满足；如果要让模型「知道」某个区域是肾皮质，就必须用 HRA 这类带语义的参考器官。

§42 中国用户的实用提示

44.1 网络与镜像

上海镜像（复旦 MSDC）是首选：https://msdc.fudan.edu.cn/humanatlas-mirror。对 7.7 GB 级别的下载，镜像通常显著快于 Zenodo。

若镜像未覆盖某个对象，可回落到 lod.humanatlas.io 的 CDN（cdn.humanatlas.io），该域名在国内可达性一般好于 Zenodo。

44.2 时区与发布日

HRA 的发布日固定为 6-15 与 12-15，按美国时间计。北京时间可能顺延一天。做自动化拉取时，建议在 6-18 与 12-18 之后再触发，避免拿到尚未同步完成的版本。

44.3 中文术语

如需中文展示，建议采用「英文原名 + 中文译名」双列，英文为准。解剖学名词参考《人体解剖学名词》（2014），细胞类型参考国内单细胞领域通用译名。不要自创译名，否则跨团队协作时会再次面临对齐问题。

44.4 合规提示

HRA 本身不含可识别个体信息，二次分发与本地部署通常无障碍。但若把 HRA 与本机构临床数据关联，临床数据部分仍须遵守国内相关规定（详见 §16.4）。

§43 最后一份速查：十个关键 URL

这十个地址构成了使用 HRA KG 的最小入口集合，其余具体对象地址都可以从这十个出发找到。按用途分成四组，每组说明「什么时候该来这里」。

总入口两个。 官网 https://humanatlas.io 是门面，提供各器官表的浏览、工具入口与新闻；数据总览页 https://humanatlas.io/overview-data 是判断「当前有哪些数字对象、各自什么版本」的第一站，写方法节时引用版本号应以此页为准。关联数据根 https://lod.humanatlas.io 是机器入口，按对象类型分成 asct-b、omap、2d-ftu、ref-organ、landmark 等目录，每个目录页本身就是 JSON-LD。

查询入口两个。 SPARQL 端点 https://lod.humanatlas.io/sparql 提供标准的 SPARQL 1.1 协议接口，浏览器可直接打开一个简易界面；开发者文档 https://docs.humanatlas.io 里有 REST API 的端点说明与示例，封装常用查询的 grlc 服务挂在 apps.humanatlas.io/api/grlc/ 下。

溯源入口三个。 知识图谱快照的概念 DOI https://doi.org/10.5281/zenodo.15323983 永远指向最新一版，要复现就点进去找具体记录号；论文 https://doi.org/10.1038/s41597-025-05183-6 是引用数字的唯一权威来源；代码仓库 https://github.com/hubmapconsortium/hra-kg 里有构建脚本与问题追踪，遇到「为什么这一版少了某个器官」这类问题，答案往往在 issue 里而不在文档里。

实现与镜像三个。 处理器仓库 https://github.com/hubmapconsortium/hra-do-processor 是「扁平表如何变成 RDF」的实现，读它可以理解归一化与富化的每一步；上海镜像 https://msdc.fudan.edu.cn/humanatlas-mirror 由复旦 MSDC 维护，对国内下载 7.7 GB 级快照通常显著快于 Zenodo；柏林的 Bihealth 镜像 humanatlas.bihealth.org/mirror 是欧洲的备用入口，上海镜像不通时可以用它。

维度	内容
本质	人体参考图谱（HRA）的 RDF 知识图谱发布，不是影像集也不是测序矩阵；是参考本体 + 元数据 + 派生统计的三合一
主导方	NIH HuBMAP 联盟；建设与运维由 Indiana University CNS（Börner 组）与 Stanford BMIR（Musen 组）承担
论文	Sci Data 12:1100（2025-07-01），doi:10.1038/s41597-025-05183-6，CC BY 4.0，114 条参考文献
v2.2 规模	10,064,033 节点 / 171,250,177 边 / 125.84 GB（2025-05 统计快照）
覆盖	71 个器官、5,800 个解剖结构、2,268 个细胞类型、2,531 个生物标志物
数字对象	13 类共 703 个：33 张 ASCT+B 表、23 个 OMAP、22 个 2D FTU、71 个 3D 参考器官、59 组地标
现行版本	v2.5（第 11 次发布，Zenodo 记录 2026-06-15，tar.xz 7.7 GB）
发布节奏	每年两次：6 月 15 日与 12 月 15 日
入口	SPARQL 端点 lod.humanatlas.io/sparql；Zenodo 概念 DOI 10.5281/zenodo.15323983；REST API；上海/柏林镜像
许可	数据 CC BY 4.0，代码 MIT——本库可获取性光谱里最开放的一档
库内互链	HuBMAP（rid 517，上游门户）、Human Cell Atlas（319）、KPMP（512）、GTEx（568）、Tabula Sapiens（329）、CZ CELLxGENE（38）