信息速览

数据集名称RTX-KG2 — 转化医学语义标准化知识图谱

数据类型知识图谱,多源整合,公开获取

规模非患者数据集：KG2.7.3 为 6,400,000 节点 / 39,300,000 边 / 77 种 Biolink 关系类型；KG2.10.1c 分发体积节点 JSONL 359.1 MB、边 J

接入方式整合 70+ 上游生物医学知识源：UMLS Metathesaurus（含 RxNorm/MESH/GO/HPO/MONDO/ChEBI 等子源）、SemMedDB、ChEMBL、DrugBank、Reactome、SMPDB、DisGeNET、DGIdb、HMDB、UniProtKB、IntAct、NCBIGene、KEGG、NCBI Taxonomy、Uberon 等，统一映射至 Biolink Model

AI 就绪度

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

现代转化医学研究面临一个共同困境：药物、疾病、基因、蛋白、通路、化学品的证据散落在几十个彼此异构的数据库里。DrugBank 用自己的 ID 命名一个药物靶点关系，ChEMBL 用另一套标识符，Reactome 又是另一套本体；同一个疾病在 MONDO、Disease Ontology、UMLS 里各有各的编码。想回答「哪些已知药物可能对疾病 X 有效，机制上要经过哪些蛋白」这类问题，研究者往往要先花数月写胶水代码做数据清洗与 ID 对齐，然后才能开始真正的科学问题。

RTX-KG2 就是为消灭这层胶水代码而生。它是美国 NIH 国家转化科学促进中心（NCATS）资助的 Biomedical Data Translator（生物医学数据翻译器）项目中，由俄勒冈州立大学 Stephen Ramsey 团队开发的开源软件系统：用一条 Snakemake 管理的 ETL（抽取-转换-加载）流水线，把 70 余个上游结构化知识源整合进一张图，并把所有实体与关系统一映射到社区标准 Biolink Model 的语义层上。图中的每条边都携带边级溯源（来自哪个上游源、依据哪篇文献、原始谓词是什么），使下游推理系统能够按证据等级加权消费。

它在生态里扮演的角色可以一句话概括：Translator 项目的「通用知识底座」。ARAX 推理系统把它当知识提供者（Knowledge Provider, KP）查询；mediKanren 从它导出运行图；Every Cure 的 KGML-xDTD 药物重定位模型直接在它的 canonical 版本 KG2c 上训练图神经网络。截至论文发表的 KG2.7.3 版本规模为 640 万节点、3930 万边、77 种关系类型；现行分发的 KG2.10.1c 系列以 KGX JSONL 格式提供节点 359.1 MB、边 1.7 GB 的下载体量。

需要特别提醒的是许可结构：RTX-KG2 的构建代码是 MIT、文档与图格式产物是 CC BY-4.0，但图的内容本体继承了上游各源（尤其是 UMLS、DrugBank、OMIM）的许可限制，不允许再分发。这意味着任何人想合法使用整张图，必须先自己完成上游许可的签署与核查——这也是本条目不做本体镜像、只做百科介绍的根本原因。本条目其余部分将围绕：它整合了什么、如何标准化、如何构建与获取、如何被评估与使用、以及踩过哪些坑，逐一展开。

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

1. RTX-KG2 到底是数据集还是软件？
两者都是，且强调「软件系统」。它首先是一套可复现的开源构建系统（Snakemake 流水线，MIT 许可），其次才是流水线产出的知识图谱本体（KG2pre / KG2c 双形态分发）。这种「工具+产物」一体设计使图谱可以约每月重建一次，始终保持与上游数据库同步。

2. 它整合了哪些知识源？
论文口径 70 个，涵盖六大核心源：UMLS（统一医学语言系统，本身又含 RxNorm、MESH、GO、HPO 等数十个子词表）、SemMedDB（从 MEDLINE 文献挖掘的语义谓词库）、ChEMBL（生物活性分子）、DrugBank（药物与靶点）、Reactome（通路）、SMPDB（小分子通路图）。此外还有 DisGeNET、DGIdb、HMDB、UniProtKB、IntAct、NCBIGene、KEGG、NCBI Taxonomy、Uberon、MONDO 等数十个基因-疾病、蛋白相互作用、代谢与本体类源。现行版本的注册口径已超 80 个上游资源。

3. 语义标准是什么？
Biolink Model——Translator 社区的统一图谱模式（schema）。所有节点带 CURIE 标识与 Biolink 类别（如 biolink:Drug、biolink:Disease），所有边的主谓宾都用 Biolink 关系类型（如 biolink:causes、biolink:treats）表达。KG2.7.3 使用 77 种关系类型构成层级。上游五花八门的谓词（如 UMLS 的 RB/RN 缩写、ChEMBL 的 activity 描述）经映射表（predicate-remap.yaml，数千行）归一到标准谓词。

4. KG2pre 和 KG2c 有什么区别？
KG2pre 是同义词合并（conflation）前的原始形态；KG2c 是 canonical（规范化）版本，其中基因与其编码蛋白（HGNC 两侧）、疾病同义词等被合并为单一节点。下游做药物重定位建模（如 KGML-xDTD）通常用 KG2c，因为它减少了冗余节点、图更稠密。

5. 规模多大？
论文时点的 KG2.7.3：6,400,000 节点、39,300,000 边、77 种关系类型。现行 KG2.10.1c 分发：节点 JSONL 359.1 MB、边 JSONL 1.7 GB（gzip）。KG2 团队未在文档中公布现行版本的节点/边总数（遗留疑点，见 §10）。

6. 每条边有哪些字段？
核心是 subject/predicate/object 三元组 CURIE，外加：primary_knowledge_source（报告这条边上游源 CURIE 列表）、publications（PMID/DOI 引文 CURIE 列表）、publications_info（按引文给出原句、置信分、出版日期——目前仅 SemMedDB 边携带原句）、source_predicate（上游原始谓词）、predicate/predicate_label（简化后的标准谓词）、qualified_predicate 等限定字段、update_date（上游更新时间，格式不统一）。

7. 怎么获取？
四个途径：① GitHub 项目 ncats/translator-lfs-artifacts 提供预构建的 KG2pre 与 KG2c dump 文件；② AWS S3 bucket rtx-kg2-public（含公开静态网站端点，提供构建配置与日志等产物）；③ SmartAPI 注册的查询 API（arax.rtx.ai）；④ Neo4j 只读端点（限 KG2 团队成员）。KG Hub 的 kg-registry 页面汇总了各产物的直链。

8. 许可怎么算？
三层：构建代码 MIT；文档、报告与 GitHub/S3 上的图格式产物 CC BY-4.0（署名要求「RTX KG2 development team, github.com/RTXteam」）；图内容本体受上游许可约束不可再分发。仓库 source-licenses/ 目录按源枚举了 UMLS 各子词表的 license category（0-4 级）与特别条款（SNOMED CT 有附录 2 专属条款、LOINC 需特别声明）。

9. 谁在用？
Translator 项目的多个推理 agent（ARAX、mediKanren 等）把它作为 KP 查询；Every Cure 的 KGML-xDTD 在 KG2c 上训练药物-疾病治疗预测模型并发布对比基准；学术界用它做药物重定位假设生成与知识发现研究。

10. 与 SPOKE、Hetionet 这类整合图谱有何不同？
共同点都是「多源整合 + 单图」。差异在于：RTX-KG2 严格遵循 Biolink Model 并内置于 Translator 的联邦查询协议（TRAPI/SmartAPI）生态，强调边级溯源字段与月度重建的工程化；SPOKE 偏重精准医学邻域探索、Hetionet 是一次性整合的经典快照。三者互补而非替代（详见 §7 与 §9）。

§2 数据构成与规格

2.1 逻辑结构：节点、边与溯源三件套

RTX-KG2 的逻辑模型非常克制：一张同质有向属性图，节点与边都带类型与属性，没有自造的复杂嵌套结构。节点级核心字段是 id（CURIE，如 UMLS:C0006826、ChEMBL:COMPOUND_CHEMBL25）与 category（Biolink 类别）及名称、同义词列表。边的价值主要在溯源三件套：

字段	内容	典型示例
primary_knowledge_source	报告该边组合的上游源 CURIE 列表	`infores:semmeddb`、`infores:chembl`
publications	支持该边的引文 CURIE 列表	`PMID:32196849`、`DOI:10.1038/...`
publications_info	每条引文的元数据对象	SemMedDB 原句、subject/object 置信分、ISO 8601 出版日期

再往下一层是谓词的双轨制：source_predicate 保留上游原始谓词（如 UMLS:RB），predicate 是简化后的 Biolink 标准谓词（如 biolink:related_to），predicate_label 是其 snake_case 英文标签。这组设计让下游既能在标准语义层做通用推理，又能回溯到上游的细粒度语义。还有一组 Biolink 限定符字段（qualified_predicate、qualified_object_aspect、qualified_object_direction）用于表达「上游调高/调低」「导致/治疗方向」等细微语义。

2.2 物理形态：三种分发格式

KG2 团队提供三种物理形态，服务不同消费方式：

KGX JSONL（推荐，KG Hub 注册的官方产物）：nodes 与 edges 两个 .jsonl.gz 文件，每行一个 JSON 对象。KG2.10.1c 节点文件 359.1 MB、边文件 1.7 GB。KGX 是 Translator 社区的标准交换格式，任何支持流式读取 JSON Lines 的语言都能直接消费。
Neo4j TSV 包：kg2-tsv-KG2.{version}.tar.gz，配 tsv-to-neo4j.sh 脚本导入 Neo4j 3.5.13（需 APOC 3.5.0.4），适合想用 Cypher 做图查询的团队。官方维护的 Neo4j 只读服务端点仅对团队成员开放，自建是最现实的 Cypher 路线。
SmartAPI 注册 API：通过 arax.rtx.ai 的 OpenAPI 接口在线查询，按 Translator 生态的约定提供节点邻域查询能力，适合不需要本地部署、只想做偶发查询的使用者。

2.3 上游源的地形图

按内容类型，上游源可粗分五类（各类在图中的角色不同）：

本体类：UMLS Metathesaurus 是节点命名的主干——KG2 直接复用 UMLS 的概念标识与同义词网络；GO（基因本体）、HPO（人类表型本体）、MONDO（疾病本体）、ChEBI（化学实体）、Uberon（解剖学）、NCBITaxon（分类学）等提供领域内的层级结构与定义。这一类贡献了图中绝大部分节点。
药物与化学类：ChEMBL（药物样分子及其活性预测）、DrugBank（药物-靶点关系，人工策展）、SMPDB（小分子通路）、HMDB（人类代谢物）。这一类承载药物重定位任务的「药物侧」。
基因-疾病关联类：DisGeNET（文献挖掘的基因-疾病关联）、DGIdb（药物-基因相互作用）、OMIM（经 UMLS 引入的遗传病-基因关系）。这一类是「疾病侧」与治疗假设的桥梁。
蛋白与通路类：UniProtKB（蛋白注释）、IntAct（分子相互作用）、Reactome（反应通路）、KEGG。它们把药物靶点连接到细胞过程。
文献挖掘类：SemMedDB 从 MEDLINE 标题摘要中抽取「主体-谓词-客体」语义三元组，是图中唯一携带自然语言原句与句级置信分的边源，贡献了大量长尾边但也带来噪声（见 §10 坑 4）。

2.4 版本链与命名规则

版本号格式为 KG2.{major}.{minor}，图结构版本恒为 2。同一版本号下还有形态后缀：KG2pre（canonical 化前）与 KG2c（canonical 化后，c 即 canonical），以及 KG Hub 分发使用的构建序号（如 kg2c-2.10.1-v1.0）。版本号本身可通过三个渠道核实：构建 JSON 的 build slot、图中 RTX:KG2 节点的 name 字段、S3 上的 kg2-version.txt 文件。下表汇总关键版本的已知事实：

版本	时点	规模/体量	说明
KG2.7.3	2022（论文发表时）	6.4M 节点 / 39.3M 边 / 77 关系类型	论文报道的 canonical 版本
KG2.10.1c	2024-2025（KG Hub 现行分发）	节点 JSONL 359.1 MB / 边 JSONL 1.7 GB	KG Hub 注册的官方产物对
KG2.10.3	2025-2026（README 示例）	未公布	仅作为 KGX 验证示例出现

2.5 源遴选准则：为什么是这些源

KG2 团队在 README 中明确了选源五准则，这解释了为什么很多知名数据库不在图里：① 有扁平文件下载（TSV/XML/JSON/DAT/SQL dump），不提供批量下载、只提供网页或 API 的源难以进入流水线；② 持续维护更新；③ 与既有内容互补而非重复；④ 概念标识符能连接到 KG2 已有的 CURIE；⑤ 优先人工策展内容而非计算文本挖掘（SemMedDB 是唯一的文本挖掘例外，因其覆盖面无可替代）。这套准则对任何想构建整合图谱的团队都有直接的方法论参考价值。

§3 构建流水线：Snakemake、验证与规范化

3.1 硬件与环境门槛

RTX-KG2 的构建不是普通笔记本能完成的任务。官方 README 给出的最低要求：128 GiB 内存、约 1,023 GiB 磁盘、20 Gb/s 网络；参考硬件是 AWS EC2 r5a.4xlarge 实例。软件环境为 Ubuntu 22.04、Python 3.13、Snakemake 流水线管理器与 AWS CLI（构建过程需要访问 us-west-2 的 S3 bucket 交换中间产物）。全量构建约 25 小时，按官方口径成本约 23 美元（±20%）；部分重建约 12 小时。构建频率约每月一次，这也是「知识图谱版本月更」说法的来源。

3.2 流水线步骤解剖

一次全量构建的执行骨架如下（入口脚本 build-kg2-snakemake.sh）：

环境准备：运行 setup-kg2-build.sh 配置 AWS 凭据与依赖；clone 代码后先做 Snakemake dry-run（约 50 个任务节点），确认 DAG 完整——DAG 中包括 ChEMBL、UMLS、DrugBank、SemMedDB 等各源的下载与解析任务，以及后续的转换、合并、简化、TSV 导出与验证任务。
各源 ETL：每个上游源有独立的下载-解析任务，把扁平文件转换成中间表示。这一步会产生大量日志，团队通过 rtx-kg2-public 的公开网站端点提供构建配置与日志存档。
合并与简化：各源中间产物合并为单图，然后做谓词映射（predicate-remap.yaml 数千行映射规则，把 UMLS 的 RB/RN/RO 等缩写谓词翻成 Biolink 标准谓词）。
KGX/Biolink 验证：使用 NCATSTranslator/translator-ingests 社区工具对 kg2-normalized-*.jsonl 做严格验证——这一步必须 PASSED 才允许进入下一步，是流水线的质量闸门。
Conflation（同义词合并）：执行规范化，把基因与蛋白、疾病同义词等合并，产出 KG2c；合并前形态保留为 KG2pre。
分发：输出 KGX JSONL 与 Neo4j TSV 两种格式，推送到 S3 与 translator-lfs-artifacts。

3.3 质量控制的三道防线

除了上述第 4 步的强制验证，流水线还有两道人工检查：每次构建生成 kg-simplified-report-KG2.{version}.json（图简化统计报告）与孤立边（orphan edges）清单，由团队成员人工审查后才发布。第三道防线是下游的持续消费——ARAX 等推理系统每日使用图服务，图质量的退化会第一时间被推理质量异常暴露。这种「机器验证 + 人工报告审查 + 下游众测」的三层质检，是小型学术团队维护月更大图的现实可行方案。

3.4 复现成本的现实评估

对想本地重建的研究者，诚实的成本账是：EC2 费用约 23 美元看似低廉，但 128 GiB 内存门槛、20 Gb/s 网络要求与每月一次的同步义务意味着持续运维投入。更现实的策略是：直接下载 translator-lfs-artifacts 的预构建 dump 做分析；只在需要改谓词映射或增删源时才启动自建。这个判断也适用于本站读者——先消费现成产物，再考虑复现流水线。

§4 论文、团队与时间线

4.1 主论文逐段导读

RTX-KG2 的方法学出处是一篇开放获取的系统论文：

Wood E.C., Glen A.K., Kvarfordt L.G., et al. (2022). RTX-KG2: a system for building a semantically standardized knowledge graph for translational biomedicine. BMC Bioinformatics 23:400. DOI: 10.1186/s12859-022-04932-3. PMID: 36175836.（17 位作者，CC BY-4.0）

论文摘要给出的一组关键数字值得原文引用：整合 70 个知识源（含 UMLS、SemMedDB、ChEMBL、DrugBank、Reactome、SMPDB 六个核心源）；语义层与模式遵循 Biolink 标准；当时的 canonical 版本 KG2.7.3 含 6.4M 节点、39.3M 边、77 种关系类型层级；论文自评其为「首个整合了 UMLS + SemMedDB + ChEMBL + DrugBank + Reactome + SMPDB 且符合 Biolink 标准的知识图谱」。

论文的贡献声明有三条，分别对应三类读者：对 Translator 项目内读者，它是一个可联邦查询的 KP（知识提供者）；对项目外读者，它是一套可下载、可复现的开源建图系统；对图谱工程研究者，它是一份「如何把异构源规范化到统一语义层」的完整工程报告——谓词映射表、源遴选准则、验证闸门设计这些通常不写进论文的细节，在它的 README 与代码里是全部公开的。

4.2 团队与资助谱系

牵头机构：Oregon State University（俄勒冈州立大学）。
PI：Stephen Ramsey（ORCID 0000-0002-2168-5403），团队名 RTXteam，GitHub 组织 RTXteam 同时托管 RTX-KG2 与 ARAX 推理系统。
核心作者：E. C. Wood（主论文第一作者）、Amy K. Glen（后为 ARAX 论文第一作者）、Lindsey G. Kvarfordt 等。
资助：NIH NCATS Translator 项目，合同号 OT2TR002520 与 3OT2TR003428-01S1。Translator 是 NCATS 旗下面向「把海量生物医学数据翻译成可操作洞见」的长期项目，采用联邦式架构：多个自主的 reasoning agents（推理代理）与 KPs（知识提供者）通过标准协议协作，RTX-KG2 是其中最重要的 KP 之一。

4.3 时间线

时间	事件
2020-2021	KG2 作为 ARAX 的第二代知识图谱立项构建（第一代为 RTX KG1，基于 Scala）
2022-09	主论文发表于 BMC Bioinformatics 23:400；KG2.7.3 为论文时点版本
2022-10	NCATS/translator-lfs-artifacts 开始定期发布 KG2pre/KG2c 预构建 dump
2023-03	ARAX 论文发表（Bioinformatics 39(3):btad082, PMID 36752514），系统描述以 KG2 为知识底座的模块化推理
2023-09	KGML-xDTD 论文（PMID 37602759）展示在 KG2c 上训练 GNN 做药物-疾病治疗预测
2024-2025	KG2.10.x 系列成为 KG Hub 现行分发；源注册口径扩展至 80+
2025-2026	README 示例出现 KG2.10.3；流水线升级至 Ubuntu 22.04 + Python 3.13，全量构建约 25 小时

4.4 关联论文矩阵

RTX-KG2 相关的三篇核心文献构成一个「构建-推理-应用」三角：

构建层：Wood et al. 2022（主论文）——流水线与图本身。
推理层：Glen et al. 2023（ARAX）——如何以 KG2 为 KP 回答转化医学问题，包括「恢复已知药物-疾病关系」这一验证型工作流。
应用层：Ma et al. 2023（KGML-xDTD）——把 KG2c 当作 GNN 训练图，做药物-疾病治疗概率预测与机制路径解释，在药物重定位对比中展示更高准确率与更低假阳性。

对检索者的意义：如果你只读一篇，读主论文了解「图是什么」；如果你要做药物重定位建模，先读 KGML-xDTD 了解「别人怎么消费这张图」；如果你要构建自己的推理 agent，读 ARAX 了解「查询协议与模块化推理怎么设计」。

§5 评估与基准

5.1 官方评估渠道

KG Hub（kghub.org）为 RTX-KG2 维护了官方 evaluation 页面，汇总图谱产物的合规检查结果。构建流水线内部则有强制 KGX/Biolink 验证闸门：使用 NCATSTranslator/translator-ingests 社区工具验证归一化后的 JSONL，验证失败则流水线中止、不进入 conflation。这是「图谱内容符合 Biolink 标准」这一承诺的机器化保证，而非仅靠人工抽查。

5.2 构建期质量控制指标

每次构建输出两类人工审查材料：kg-simplified-report-KG2.{version}.json（节点/边统计、类别分布等简化报告）与孤立边清单（subject 或 object 缺失的边）。孤立边的存在是整合图谱的常见病灶——上游源之间的 ID 断链会导致边悬空；KG2 把它做成显式清单交付审查，而不是默默丢弃或默默保留，这个做法对同类项目有借鉴价值。

5.3 下游任务基准

KG2 图质量最硬的证据来自下游任务表现：

药物重定位（KGML-xDTD）：在 KG2c 上训练的图神经网络做药物-疾病治疗预测，与对照方法相比展示更高准确率与更低假阳性（Ma et al., PMID 37602759）。该模型还能输出可解释的机制路径，即从药物节点到疾病节点的高置信边序列。
推理系统自检（ARAX）：ARAX 内置「恢复已知药物-疾病关系」工作流，用已知治疗关系做检索召回式验证——图若退化，这类工作流的召回率会立即下降（Glen et al., PMID 36752514）。
工业采用（Every Cure）：Every Cure 的 KGML 流水线将 RTX-KG2c 列为其药物重定位项目的基础知识图，其技术文档明确记录了选择理由：大规模、语义标准化、药-靶-病推理覆盖强、与下游推理 agent 兼容。

5.4 与同类整合图谱的横向对比

维度	RTX-KG2	SPOKE	Hetionet
整合源数量	70（论文口径，现 80+）	20+	29
语义标准	Biolink Model（77 关系类型）	自有节点/边类型体系	自有 metagraph
更新方式	约每月 Snakemake 全量重建	持续维护、定期发布	2017 后基本静态
溯源粒度	边级（源+引文+原句+置信分）	部分边携带来源	边级来源字段
查询协议	SmartAPI/TRAPI 生态 + 下载	Neighborhood Explorer + API	下载 + Neo4j
典型下游	ARAX、mediKanren、KGML-xDTD	精准医学邻域探索	Rephetio 等重定位研究

结论：RTX-KG2 的差异化优势是工程化 freshness（月更）+ 标准化（Biolink/TRAPI 生态兼容）+ 溯源深度；SPOKE 与 Hetionet 则在历史分析与教学场景更易上手。三者拼接使用（如以 RTX-KG2 为主图、Hetionet 做历史基线）是常见做法。

§6 生态与应用场景

6.1 Translator 联邦生态中的位置

NCATS Translator 采用联邦架构：用户问题由 reasoning agents 接收，agent 向多个 KP 并行查询，再汇总推理。RTX-KG2 在其中是「最大单一 KP」——由于它已经整合了 70+ 源，很多 agent 只查它一个就能覆盖大部分所需证据。它通过 SmartAPI 注册服务描述，支持 Translator 的标准查询协议（TRAPI）。对生态外的开发者，这意味着：实现一次 TRAPI 客户端，即可同时查询 RTX-KG2 与生态内其他注册了 SmartAPI 的 KP。

6.2 ARAX：以 KG2 为底座的推理系统

ARAX（Reasoning Tool X 的推理引擎）展示了 KG2 的「设计用途」：模块化推理。其典型工作流是把一个转化医学问题（如「药物 D 对疾病 E 是否可能有效，机制是什么」）分解为若干子查询——邻域扩展、路径寻找、已知关系恢复——每个子查询都是对 KG2 的一次图操作，最后按证据等级合成答案。ARAX 论文（PMID 36752514）给出的验证方式极具实用主义色彩：直接检验系统能否恢复已知药物-疾病关系，因为若图整合有问题，这类「已知答案」的召回会立刻崩塌。

6.3 mediKanren 与图导出

mediKanren 是 Translator 生态中另一个推理系统，采用 Scheme 生态实现。KG2 团队维护了向 mediKanren 导出图的通道，说明 KG2 的分发设计是「格式中立」的：同一张图可以以 KGX JSONL、Neo4j TSV、mediKanren 内部格式三种形态存在。这是「先定语义标准（Biolink）、再适配多种物理格式」策略的直接收益。

6.4 药物重定位：从假设生成到机制解释

药物重定位（drug repurposing）是 KG2 最大的应用舞台，典型流程三段式：

候选生成：在 KG2c 上用图特征（邻域相似度、路径存在性、元路径）或 GNN（KGML-xDTD 路线）为疾病找候选药物。
机制解释：对高置信候选，抽取药物→靶点→通路→疾病的高置信路径作为机制假设，路径上每条边都可回溯到 primary_knowledge_source 与 publications。
人工评审：领域专家按机制合理性排序并决定湿实验验证优先级。

KGML-xDTD 的经验值得强调：直接在 KG2c 上训练比在 KG2pre 上训练效果好——同义词合并后的图更稠密、节点更少，GNN 的消息传递更高效。这个「canonical 化利于嵌入学习」的经验对任何要做图机器学习的整合图谱项目都适用。

6.5 LLM 时代的知识图谱价值

在大型语言模型时代，有人质疑结构化知识图谱的价值。KG2 生态给出三个反问式回答：① LLM 的药物-疾病断言无法逐条溯源，KG2 的每条边都带引文与原句（SemMedDB 边），可审计；② LLM 幻觉率在长尾（罕见病、冷门药物）问题上显著，而 KG2 的长尾覆盖来自系统化 ETL 而非模型记忆；③ KG2 可作为 RAG（检索增强生成）的结构化检索层——先在图上定位证据子图，再让 LLM 组织语言。Translator 生态与 Every Cure 的实践都在沿这个方向演化。

§7 获取与许可：四扇门与三张许可层

7.1 获取途径全景

途径	形态	适合谁	门槛
ncats/translator-lfs-artifacts（GitHub）	KG2pre/KG2c 预构建 dump 文件	数据分析者、GNN 建模者	直接下载
S3 rtx-kg2-public（bucket + 公开网站端点）	构建配置、日志、版本文件等 artifacts	工程复现者、审计者	AWS CLI 或 HTTP
KG Hub kg-registry 注册页	KGX JSONL 官方产物直链（节点 359.1 MB / 边 1.7 GB，KG2.10.1c）	全部检索者	直接下载
arax.rtx.ai SmartAPI 接口	在线查询（OpenAPI 文档公开）	偶发查询、agent 开发者	无需部署
Neo4j 只读服务端点	Cypher 查询	团队成员	需联系维护者取凭据；自建 Neo4j 3.5.13 + TSV 是公开替代路线

实操建议排序：只想探索数据 → 先用 SmartAPI 接口；要做建模或全文分析 → 下载 translator-lfs-artifacts 的 KG2c dump；要复现或改造流水线 → 走 GitHub 源码 + S3 构建产物路线；要 Cypher 交互 → 自建 Neo4j 导入 TSV 包。

7.2 许可三层结构（风险项，务必逐条读懂）

这是 RTX-KG2 最容易踩坑、也最容易造成合规事故的部分。官方 FAQ 原文表述非常直白：「这很复杂（It’s complicated）」。拆解如下：

构建代码：MIT License。使用、修改、再分发几乎无限制，保留版权声明即可。
文档与可下载构建产物（图格式本身）：CC BY-4.0。KG2 团队的 CC BY 声明明确只覆盖「我们团队创作的创意产物——文档、报告与知识图谱格式」，署名要求为「RTX KG2 development team, github.com/RTXteam」。
图内容本体：受上游各源许可约束，不允许再分发。KG2 的内容继承自 UMLS、DrugBank、OMIM 等数十个上游源，各自带有不同许可。其中最关键的是 UMLS License：使用者必须通过 UMLS Terminology Services 签署使用协议（个人/机构均可，免费但需申请）。仓库 source-licenses/README.md 按 UMLS license category（0-4 级，4 为限制最强）逐子源枚举：SNOMED CT 有附录 2 专属条款；LOINC 在标准条款外还需显示特别声明；DrugBank 的数据使用需商业许可协议；OMIM 对再分发有明确限制。

对本站读者的直接含义：千方病案医数集因上述第 3 层原因，不提供 RTX-KG2 图本体的任何镜像、切片或再分发——这不是技术保守，而是许可红线。检索者若要在自己项目中使用图内容，正确姿势是：自己从官方渠道下载 → 自己签署 UMLS 等上游协议 → 在自己的许可范围内使用，且对外发布衍生内容前逐源核查上游条款。

7.3 UMLS 许可细读

由于 UMLS 是 KG2 节点命名的主干，UMLS 许可事实上决定了「能否合法持有整张图」。要点：① 签署是免费的，通过 UTS（UMLS Terminology Services）在线申请，通常数日内获批；② 协议要求持有者不得向第三方再分发 UMLS 内容（包括以整合图形式）；③ 部分子词表（category 3/4，如 MEDDRA、CPT、HCPT、ICD10 部分）有额外限制，KG2 的 source-licenses 表按子源标注了等级；④ 学术发表中引用 UMLS 概念名与 CUI 通常视为合理使用，但整段图数据发布不行。理解这四点后，「为什么 KG Hub 分发的 JSONL 允许下载、却不允许你再上传到自己的公开数据平台」就清楚了：下载是源方许可的获取行为，再分发是协议禁止的传播行为。

7.4 版本链与获取的版本选择

获取时选版本的三条经验：① 生产/建模用途选最新 KG2c（canonical，合并后），不要用 KG2pre，除非你要研究同义词映射本身；② 复现论文结果需锁定 KG2.7.3 时代附近版本，注意 translator-lfs-artifacts 只保留有限历史版本，需要尽早归档；③ 每个版本的 build 元数据在 JSON 的 build slot 与 S3 的 kg2-version.txt，引用时以此为版本指纹，不要依赖文件名（文件名可能带构建序号 v1.0 之类，与图版本是两套编号）。

§8 与库内条目的关系：一张图的上游全家桶

RTX-KG2 在本库中的定位非常特殊：它不是一个「原始数据集」，而是本库多个上游数据集条目的下游整合视图。理解这层关系，可以帮检索者把本库知识图谱类条目串成一张学习地图。

8.1 直接上游（KG2 吸收的库内条目）

UMLS（umls，rid=558）：KG2 的节点命名主干。KG2 节点大量使用 UMLS CUI 作为 CURIE，复用其同义词网络与语义类型。想深挖 KG2 节点体系，先读 UMLS 条目。
SemMedDB（semmeddb，rid=836）：KG2 文献挖掘边的主要来源，也是图中唯一携带自然语言原句与句级置信分的边源。想理解 KG2 哪些边「噪声大但覆盖广」，读 SemMedDB 条目。
DrugBank（drugbank，rid=89）：药物-靶点边的人工策展金标准来源，同时也是 KG2 许可链中最典型的商业许可约束代表。做药物重定位的人应把两者对照读。
Reactome（reactome，rid=424）：通路结构边来源，连接药物靶点与细胞过程。
DGIdb（dgidb，rid=419）：药物-基因相互作用边的来源之一。

8.2 同类对照（整合型知识图谱横向比较）

Hetionet（hetionet，rid=832）：2017 年一次性整合 29 源的经典图谱，是 Rephetio 药物重定位方法的载体。与 RTX-KG2 对照读，能直观看到「整合图谱五年间的工程进步」：溯源字段标准化（Biolink infores）、月度重建、强制 schema 验证都是 Hetionet 之后才普及的实践。

8.3 建议互链点清单（供站内导航生成）

目标条目	关系方向	链接语义
umls（rid=558）	RTX-KG2 → UMLS	上游命名主干/许可约束源
semmeddb（rid=836）	RTX-KG2 → SemMedDB	文献挖掘边来源
drugbank（rid=89）	RTX-KG2 → DrugBank	药物-靶点边来源/商业许可代表
reactome（rid=424）	RTX-KG2 → Reactome	通路边来源
dgidb（rid=419）	RTX-KG2 → DGIdb	药物-基因相互作用边来源
hetionet（rid=832）	Hetionet ↔ RTX-KG2	同类整合图谱对照

以上 rid 均为写作时点 DB 实查值（status=1 AND del_sign=0）；站内导航最终以发布时 DB 回填为准。

§9 避坑清单：八个已踩过的坑

以下坑位来自官方文档、FAQ 与下游使用经验的显式记录，每条都给出识别信号与处置建议。

坑 1：把 CC BY 4.0 当成整张图的许可。
识别信号：看到「KG2 artifacts are CC BY」就以为图内容随便再分发。事实是 KG2 团队的 CC BY 只覆盖其自创创作物（文档/报告/图格式），图内容本体受上游许可约束禁止再分发。处置：对外发布任何含 KG2 内容的衍生数据前，逐源核查 source-licenses 表并签署 UMLS 协议。

坑 2：用文件名判断版本。
识别信号：看到 kg2c-2.10.1-v1.0-nodes.jsonl.gz 就引用「版本 v1.0」。v1.0 是 KG Hub 分发序号，图版本是 2.10.1（c 形态）。处置：以 JSON build slot 或 S3 kg2-version.txt 为版本指纹。

坑 3：跨源比较置信分。
识别信号：把 SemMedDB 边的 subject score 与 ChEMBL 预测边的 score 放进同一个阈值过滤。官方文档明言「分数没有统一量表」。处置：先按 primary_knowledge_source 分组，再在组内各自定阈值。

坑 4：把 SemMedDB 边当高置信证据。
识别信号：发现某药物-疾病关系只有 SemMedDB 一条边就写进结论。文本挖掘边覆盖广但噪声高（标题摘要级抽取，无实验验证）。处置：要求至少一条人工策展边（DrugBank/OMIM/DisGeNET 策展部分）或复核引文原句。

坑 5：用 update_date 做统一时间过滤。
识别信号：试图按「2023 年后更新」筛选边。官方文档明言该字段格式在各源之间不一致，「usually not null」且无统一规范。处置：时间过滤改用 publications_info 里的出版日期（ISO 8601，仅部分边有），或按源分组处理。

坑 6：在 KG2pre 上训练 GNN。
识别信号：模型收敛慢、节点冗余（同一基因的 gene/protein 双节点分裂消息传递）。KGML-xDTD 的经验是 canonical 版 KG2c 更适合嵌入学习。处置：建模用 KG2c；研究同义词映射本身才用 KG2pre。

坑 7：低估 Neo4j 导入的版本耦合。
识别信号：用新版 Neo4j 导入 TSV 报 APOC 错。官方配对是 Neo4j 3.5.13 + APOC 3.5.0.4，tsv-to-neo4j.sh 脚本还有首启密码设置的老坑（FAQ 有专门排障条目）。处置：严格按官方版本配对，首启等待服务就绪再设密码。

坑 8：Snakemake 构建中断后直接重跑。
识别信号：构建机器断电/强杀后重跑报 DAG 锁错误。官方 FAQ 给出的处置是运行 snakemake --snakefile .../Snakefile --unlock 解锁后再重跑。处置：把解锁命令写进构建手册；更根本的是构建机要配不间断电源与 screen 会话。

§10 常见误解澄清

误解 1：「RTX-KG2 是一个大下载包，像一个静态数据集。」
它是「软件系统 + 产出物」的复合体，核心资产其实是那条月度重建、带强制验证闸门的流水线。把下载包当全部会错过它最可复用的部分——谓词映射、验证设计、源遴选准则。

误解 2：「Biolink 兼容 = 能直接进任何 Biolink 工具。」
KG2 声明的是「aims to comply」；实际消费仍需注意版本配对（Biolink Model 自身在演进，KG2 文档未指明所用的具体版本号，属遗留疑点）。

误解 3：「图里有 80+ 源，所以每条边都有 80 选 1 的丰富来源。」
源数量是图的整图口径；单条边通常只有 1 个 primary_knowledge_source，个别热门关系才会多源合并（此时 publications 等字段才做合并）。

误解 4：「下载了 JSONL 就能合法公开任何衍生产品。」
见 §7.2 的三层许可。再分发红线卡在 UMLS 等上游，与你的衍生技术含量无关。

误解 5：「6.4M 节点 / 39.3M 边是现行版本的规模。」
这是 2022 年论文报道的 KG2.7.3 数字。现行 KG2.10.x 未公布节点/边总数（官方只给文件体积），引用时务必带版本号。

误解 6：「KG2c 的 c 是 complete。」
c 是 canonical（规范化/同义词合并后）。KG2pre 才是未合并的原始形态。

§11 按角色阅读路径与一页速查卡

11.1 按角色推荐路径

药物重定位建模者：§1（速览）→ §2.4/§5.4（版本与对比）→ §6.4（建模流程）→ §9 坑 6 → 下载 KG2c 开工。
知识图谱工程师：§3（流水线全解）→ §2.1/2.2（数据模型与格式）→ §9 坑 2/7/8 → 读 README 与 predicate-remap.yaml 源码。
合规/数据治理角色：§7.2/§7.3（许可三层与 UMLS 细读）→ §9 坑 1 → source-licenses/README.md 原文。
医学信息学教学者：§0 → §4.4（三篇论文矩阵）→ §5.4/§8（生态地图）→ 用 Hetionet/RTX-KG2/SPOKE 做课程对比案例。
agent/TRAPI 开发者：§6.1-6.2（生态与 ARAX）→ §7.1（API 途径）→ SmartAPI 注册描述与 TRAPI 规范原文。

11.2 一页速查卡

名称      RTX-KG2（infores:rtx-kg2）
是什么    NCATS Translator 的语义标准化生物医学知识图谱 + 建图系统
谁建的    Oregon State University，RTXteam（PI: Stephen Ramsey）
论文      BMC Bioinformatics 2022;23:400, DOI 10.1186/s12859-022-04932-3
规模      KG2.7.3: 6.4M 节点 / 39.3M 边 / 77 关系类型（论文时点）
现行分发  KG2.10.1c: 节点 JSONL 359.1 MB / 边 JSONL 1.7 GB（KG Hub）
形态      KG2pre（未合并）与 KG2c（canonical，建模用）
源        70（论文）/ 80+（现行注册）/ 源表 50+ 条目（口径见 FACTS §9）
许可      代码 MIT ｜ 文档+图格式 CC BY-4.0 ｜ 图内容不可再分发
获取      translator-lfs-artifacts / S3 rtx-kg2-public / KG Hub / arax.rtx.ai API
构建      Snakemake, ~25h 全量, r5a.4xlarge ~$23, 月更, KGX 验证强制闸门
下游      ARAX, mediKanren, KGML-xDTD, Every Cure KGML
最大坑    图内容许可不可再分发（UMLS 需签署 UTS 协议）

FAQ（高频问答 32 问）

Q1：RTX-KG2 中的 RTX 是什么意思？
Reasoning Tool X（推理工具 X），是 Translator 项目内一个推理系统的代号；KG2 是其知识图谱的第二代（第一代 KG1 基于 Scala 构建，已被替代）。

Q2：KG2 和 ARAX 是什么关系？
ARAX 是推理引擎（消费方），KG2 是它查询的知识底座（供给方）。两者同属 RTXteam 维护，代码分仓（RTXteam/RTX 与 RTXteam/RTX-KG2）。

Q3：KG2c 和 KG2pre 应该用哪个？
建模与常规分析用 KG2c（同义词合并后的 canonical 版，图更稠密）；研究同义词映射或做 ID 对齐工具开发时才需要 KG2pre。

Q4：下载 KG2c 需要注册什么吗？
下载本身（GitHub translator-lfs-artifacts、KG Hub、S3 公开端点）无需注册。但合法使用图内容需签署 UMLS UTS 协议等上游许可——下载可达不等于使用合法。

Q5：KG2 支持中文吗？
上游源以英语为主干，UMLS 含少量多语言同义词但覆盖有限。中文检索者通常需先经 UMLS CUI 对齐到中文术语表（如中文 Mesh 译名）。

Q6：一条边可以信任到什么程度？
看三层信号：primary_knowledge_source 是人工策展源还是文本挖掘源；publications 是否有具体引文；publications_info 里是否有原句与置信分。策展源+引文+高分三层齐备才可当强证据。

Q7：为什么我的药物-疾病关系在图里找不到？
三个可能：上游源没有该证据（图不生产知识，只整合）；该关系在 SemMedDB 长尾中但你的查询方式过滤掉了文本挖掘边；或你查的版本太旧。先确认版本，再放宽谓词范围。

Q8：能从 KG2 里抽取一个子图发布吗？
风险高。子图内容仍继承上游许可，UMLS 等禁止再分发。学术论文中的小型示例边（几条）配合引文通常可接受，规模化发布子图需逐源法务核查。

Q9：KG2 多久更新一次？
约每月一次全量重建（Snakemake 流水线，约 25 小时）。各版本在 translator-lfs-artifacts 与 S3 上的存留时间有限，要用特定版本需尽早归档。

Q10：怎么确认我下载的文件是哪个版本？
三渠道交叉验证：文件内 JSON 的 build slot、图中 RTX:KG2 节点的 name 字段、S3 的 kg2-version.txt。不要依赖文件名。

Q11：KG2 有 API 吗？有速率限制吗？
有，SmartAPI 注册的 OpenAPI 接口（arax.rtx.ai）。这是团队维护的公共服务，大规模批量抓取请改用下载版 dump，不要用 API 爬图。

Q12：能贡献新数据源吗？
可以提 issue 或 PR。选源按五准则审查：扁平文件可下载、持续维护、内容互补、CURIE 可连接、优先人工策展。贡献谓词映射（predicate-remap.yaml）是低门槛高价值的参与方式。

Q13：KG2 里有多少种谓词？
论文时点为 77 种 Biolink 关系类型的层级；上游原始谓词经数千行映射表归一。实际边分布高度长尾，related_to 类弱关系占大头。

Q14：Gene 和 Protein 在 KG2c 里是一个节点吗？
canonical 化后 gene/protein conflation 合并（HGNC 两侧）。这是 KG2c 与 KG2pre 最重要的结构差异，直接影响 GNN 消息传递效率。

Q15：publications_info 里的 sentence 字段为什么大多是空的？
该字段目前仅 SemMedDB 边非空——只有文本挖掘边携带抽取原句。策展边（DrugBank 等）的支撑证据请查 publications 引文原文。

Q16：subject/object score 怎么解释？
无统一量表。SemMedDB 边的分数是三元组抽取正确性的置信估计；ChEMBL 类预测边的分数对应配体-靶点结合预测强度。只能组内比较。

Q17：KG2 能替代 PubMed 检索吗？
不能。它是结构化证据的整合视图，文献细节（全文、上下文、限定条件）仍要回到原文。KG2 的价值是把检索起点从「数百万篇文献」压缩为「带溯源的候选关系清单」。

Q18：和 Embedding 模型什么关系？
KG2 是嵌入训练的图结构输入：KGML-xDTD 等工作在其上训练 GNN/知识图谱嵌入。KG2 本身不发布官方嵌入向量。

Q19：LLM 能直接读 KG2 的 JSONL 吗？
技术上可以，但不经济（1.7 GB 边文件）。正确姿势是图检索定位证据子图（几十条边）再喂给 LLM，即结构化 RAG。

Q20：为什么有些节点的名字很奇怪？
名称继承自上游源；同一概念在不同源中有不同首选名时，canonical 化会选定其一。遇到怪名字建议用 CURIE 回 UMLS/MESH 原源核对。

Q21：孤立边（orphan edges）是什么？我要担心吗？
subject 或 object 缺失的边，源于上游 ID 断链。官方每次构建生成孤立边清单供人工审查。消费侧做子图抽取时按 CURIE 完整性过滤即可。

Q22：可以本地起 Neo4j 服务吗？
可以，用 TSV 包 + tsv-to-neo4j.sh，严格配对 Neo4j 3.5.13 + APOC 3.5.0.4。官方托管端点仅限团队成员。

Q23：KG2 覆盖罕见病吗？
OMIM、HPO、MONDO 的引入使罕见病覆盖显著好于纯文献挖掘图；但极罕见病仍可能只有一两层证据。这正是「边级溯源」的价值——你能直接看到证据薄厚。

Q24：怎么引用 KG2？
引主论文（Wood et al. 2022, BMC Bioinformatics 23:400）+ 仓库（github.com/RTXteam/RTX-KG2）+ 使用版本号（如 KG2c 2.10.1）。CC BY 署名要求写「RTX KG2 development team, github.com/RTXteam」。

Q25：SPOKE 和 KG2 怎么选？
需 TRAPI/SmartAPI 联邦查询、月度更新、边级溯源 → KG2；需精准医学邻域可视化探索 → SPOKE 的 Neighborhood Explorer。两者都下载对照也是常见做法。

Q26：Hetionet 还值得用吗？
作为历史基线与教学素材仍优秀（整合方法学经典），但数据停在 2017。新研究建议主用 KG2，Hetionet 做可复现对照。

Q27：Every Cure 是什么？为什么在用它？
一家非营利药物重定位组织，其 KGML 流水线把 KG2c 作为基础图训练治疗预测模型。工业界的采用是 KG2 工程质量的旁证。

Q28：构建一版图要花多少钱？
官方口径约 23 美元（±20%，EC2 r5a.4xlarge 约 25 小时）。真实成本在人力：月度运维、验证审查、上游源变更跟进。

Q29：我改了映射规则能重建吗？
能，这是开源系统的意义。门槛是 128 GiB 内存 + 约 1 TB 磁盘 + AWS CLI。建议先在 test 模式（小规模）跑通再全量。

Q30：predicate 和 predicate_label 为什么要两个字段？
predicate 是 CURIE（机器可解析，如 biolink:related_to），predicate_label 是 snake_case 英文标签（人类可读，如 related_to）。存两份避免运行时反查。

Q31：qualified_predicate 这组字段是干什么的？
Biolink 限定符，表达方向性细节（如「上游调高」「导致方向」）。做精细机制推理时有用；做粗粒度关联挖掘可忽略。

Q32：这个条目为什么不提供 KG2 数据本身的下载链接清单？
因为图内容本体受上游许可（UMLS 等）约束不可再分发，本站只做百科介绍与许可路径指引。获取入口见 §7.1 表格，许可义务见 §7.2-7.3。

§12 案例解剖：三个典型查询从头走到尾

本节用三个具体任务演示 KG2 的实际用法，让「知识图谱」从抽象名词变成可操作的步骤。示例中的字段名与文件名均以 KGX JSONL 分发形态为准。

12.1 案例一：药物重定位候选生成（伊马替尼式推理）

任务：为疾病 D 找候选药物，并解释机制。

步骤一，定位疾病节点。在 KG2c 的 nodes JSONL 中按名称检索疾病概念，取其 CURIE（如某疾病对应 MONDO:0005180）。注意同一疾病可能在 UMLS 与 MONDO 各有节点——KG2c 的 conflation 已合并疾病同义词，但跨本体根节点的对齐仍可能保留别名节点，建议用 category 字段过滤 biolink:Disease 后人工确认。

步骤二，抽取候选路径。遍历所有「药物 → 基因/蛋白 ← 疾病」的两跳路径：药物边来自 DrugBank/ChEMBL/DGIdb（primary_knowledge_source 甄别），疾病-基因边来自 DisGeNET/OMIM。取共享靶点数最多的药物作为候选。

步骤三，按证据等级排序。对每条候选，检查三层信号（见 FAQ Q6）：策展源权重高于文本挖掘源；有 publications 的边高于无引文边；SemMedDB 原句置信分做组内过滤。

步骤四，人工评审。把 top-N 候选的完整路径（含每条边的引文）导出为表格交给领域专家。整个过程不需要训练模型——纯图拓扑 + 溯源过滤就能产出可辩护的候选清单，这也是 KG2「边级溯源」设计的直接收益。

12.2 案例二：机制路径解释（药物为什么可能对疾病有效）

任务：对案例一选出的候选药物，抽取「药物 → 靶点 → 通路 → 疾病」的可解释路径。

实现思路：在 KG2c 中以药物节点为源做广度优先搜索，限制中间节点类别为 biolink:Gene/biolink:Protein（注意 KG2c 中两者已 conflation 合并）与 biolink:Pathway（Reactome 边），目标为疾病节点。对找到的每条路径计算「证据密度」：路径上每条边的 primary_knowledge_source 数量与 publications 数量之和。

输出物：路径列表 + 每条路径的证据汇总。KGML-xDTD 的做法更精一步——用 GNN 学边权重后抽高置信路径，但基础版流程用纯图算法已够发表论文的附图。

12.3 案例三：用 API 做偶发查询（不下载图）

任务：快速查「某蛋白有哪些已知抑制剂」，不想下 1.7 GB 的边文件。

路线：调用 arax.rtx.ai 的 SmartAPI 注册接口（OpenAPI 文档公开）。构造按 Biolink 谓词过滤的邻域查询，限定 subject 为目标蛋白 CURIE、predicate 为 biolink:inhibitor 类关系。返回结果中的每条边自带 primary_knowledge_source 与 publications，可直接在回复中标注证据等级。

注意礼仪：这是团队维护的公益服务，脚本批量抓取请改用下载版；API 适合交互式探索与 agent 实时查询。

12.4 三个案例的共性总结

三个案例共享同一个方法论骨架：先定位节点（CURIE 是一切操作的钥匙）→ 图遍历产生候选 → 溯源字段过滤排序 → 人工/模型做最后裁决。CURIE 的重要性贯穿始终——这也是为什么本条目把 UMLS 列为最重要的上游条目互链。

§13 下游实操手册：从下载到第一张子图

13.1 下载与解压

# 从 KG Hub / translator-lfs-artifacts 获取（版本以当时最新为准）
wget https://github.com/ncats/translator-lfs-artifacts/raw/main/files/kg2c-2.10.1-v1.0-nodes.jsonl.gz
wget https://github.com/ncats/translator-lfs-artifacts/raw/main/files/kg2c-2.10.1-v1.0-edges.jsonl.gz
gunzip kg2c-2.10.1-v1.0-nodes.jsonl.gz
gunzip kg2c-2.10.1-v1.0-edges.jsonl.gz
# 校验版本指纹（不要信文件名，见坑 2）
python3.11 -c "import json;print(json.loads(next(open('kg2c-2.10.1-v1.0-nodes.jsonl'))).get('build'))"

13.2 Python 流式加载（iJSON 模式）

import json

def iter_nodes(path):
    with open(path) as f:
        for line in f:
            yield json.loads(line)

def iter_edges(path):
    with open(path) as f:
        for line in f:
            yield json.loads(line)

# 统计 Biolink 类别分布（内存友好：流式 + 计数字典）
from collections import Counter
cat_counter = Counter()
for n in iter_nodes("kg2c-2.10.1-v1.0-nodes.jsonl"):
    for c in n.get("category", []):
        cat_counter[c] += 1
print(cat_counter.most_common(20))

13.3 抽取药物-疾病二跳子图

# 索引：邻接表（靶点 -> 药物；靶点 -> 疾病）
from collections import defaultdict
drug2gene = defaultdict(set)   # 通过 DrugBank/ChEMBL/DGIdb 边
gene2dis  = defaultdict(set)   # 通过 DisGeNET/OMIM 边
DRUG_GENE_PREDS = {"biolink:affects", "biolink:interacts_with", "biolink:targets"}
GENE_DIS_PREDS  = {"biolink:associated_with", "biolink:contributes_to"}

for e in iter_edges("kg2c-2.10.1-v1.0-edges.jsonl"):
    src = e.get("primary_knowledge_source") or []
    if not isinstance(src, list):
        src = [src]
    pred = e.get("predicate")
    if pred in DRUG_GENE_PREDS and any("drugbank" in s or "chembl" in s or "dgidb" in s for s in src):
        drug2gene[e["subject"]].add(e["object"])
    elif pred in GENE_DIS_PREDS and any("disgenet" in s or "omim" in s for s in src):
        gene2dis[e["object"]].add(e["subject"])

# 为疾病 D 列候选药物（共享靶点计数排序）
target_disease = "MONDO:0005180"  # 替换为你的疾病 CURIE
from collections import Counter
candidates = Counter()
for dis_gene in gene2dis[target_disease]:
    for drug in drug2gene:
        if dis_gene in drug2gene[drug]:
            candidates[drug] += 1
for drug, n in candidates.most_common(20):
    print(drug, n)

要点：① 边文件 1.7 GB，流式单遍扫描是标准姿势，不要 json.load 全量；② primary_knowledge_source 的类型可能是字符串或列表，容错处理；③ 谓词过滤条件按你的研究问题调整，上面的集合只是起点。

13.4 Neo4j 自建路线

# 版本必须配对（坑 7）
docker run -d --name kg2neo4j -p 7474:7474 -p 7687:7687 \
  -e NEO4J_AUTH=none neo4j:3.5.13
# 安装 APOC 3.5.0.4 后，用官方 tsv-to-neo4j.sh 导入 TSV 包
# 导入完成后验证：
# MATCH (n) RETURN count(n)   -- 对照 kg-simplified-report 的节点数

13.5 TRAPI/API 路线

import requests
# SmartAPI 注册的服务；具体 endpoint 以 arax.rtx.ai 的 OpenAPI 文档为准
resp = requests.get("https://arax.rtx.ai/api/rtxkg2/v1.2/openapi.json")
print(resp.status_code)  # 200 即服务可达；按文档构造邻域查询

13.6 轻量替代：转成 DuckDB/pandas

对小规模分析，把 JSONL 转成 Parquet 或 DuckDB 表后用 SQL 查询往往比图数据库更快上手：

import duckdb
# 先用上面的流式脚本把 edges 精简为 (subject, predicate, object, source) 四列 CSV
con = duckdb.connect()
con.execute("CREATE TABLE edges AS SELECT * FROM read_csv_auto('edges_slim.csv')")
print(con.execute("SELECT predicate, count(*) FROM edges GROUP BY 1 ORDER BY 2 DESC").fetchall())

§14 ID 对齐与数据工程手册

14.1 KG2 中的 CURIE 前缀地形

KG2 节点标识的前缀空间大致对应上游源：UMLS CUI（UMLS:）、HGNC（基因）、UniProtKB（UniProtKB:）、ChEMBL（ChEMBL:COMPOUND_...）、MONDO、DOID、HP（表型）、MESH、RxNorm（RxNorm:）、NCBIGene、Reactome（Reactome:）等。做跨库对齐前，先对自己关心的类别统计前缀分布——这决定了你该用哪张 ID 映射表（UMLS 的 MRCONSO、UniProt 的 cross-reference、HGNC 的 SQLite 导出等）。

14.2 对齐实践中的三类高频问题

同一实体多前缀并存：KG2pre 里基因与蛋白是两个节点；KG2c 已合并，但 name 字段只保留一个首选名。对齐旧数据集时注意区分你处理的是哪个形态版本。
前缀继承的语义漂移：部分 UMLS CUI 指向的概念在不同子词表中粒度不同（如 MESH 与 SNOMED 的疾病粒度差异），图上相邻的节点可能是「同一疾病的不同粒度描述」。做严格统计前建议按 CUI 根概念做二次归并。
化学品标识的双轨：小分子可能同时有 ChEMBL 与 MESH/RxNorm 标识，conflation 的化学品合并规则覆盖了部分场景但非全部；对药物侧分析，建议以 ChEMBL ID 为主键再反查。

14.3 与库内上游条目的 ID 换算路径

你手上是	换到 KG2 节点	推荐映射源
DrugBank 药物 ID	ChEMBL/UMLS 节点	DrugBank 自带 external identifiers 字段
MESH 疾病号	MONDO/UMLS 节点	MONDO 的 cross-ontology 映射
Entrez Gene ID	NCBIGene/HGNC 节点	HGNC downloadable files
ICD-10 码	UMLS 节点	UMLS MRCONSO（注意 ICD10 为 category 4 许可，对齐结果的使用需核查）
MeSH 补充概念	MESH/UMLS 节点	UMLS MRCONSO

14.4 版本漂移管理

月更的图意味着 CURIE 集合也在漂移：上游源改名、删除、合并都会传导。生产系统的建议：① 把你的分析锚定在 CURIE 集合的快照上（记录版本指纹）；② 每次升级图版本后跑一次「锚点回归」——用上一版的关键节点清单核对新版的存活率；③ 对存活率骤降的节点类别（常见于上游源切换发布格式时）排查 changelog。

§15 数据质量深度观察

15.1 密度与长尾

整合图谱的边分布呈极端长尾：少数明星节点（p53、阿司匹林、阿尔茨海默病类概念）拥有数万条边，而长尾节点只有一两条。对建模者，这意味着 Degree-based 采样策略比均匀采样合理；对统计推断，意味着网络指标（介数中心性之类）会被度分布主导，需先做度保持的随机化对照。

15.2 噪声的三个已知来源与管理

文本挖掘边（SemMedDB）：覆盖广但标题摘要级抽取，否定句、假设句的误抽是已知弱点。管理：需要强证据的结论只用策展边；探索性分析可保留。
谓词归一损耗：上游细粒度谓词归一到 77 种 Biolink 类型时信息必然压缩（如各种「抑制」变体可能归到不同标准谓词，也可能落到 related_to 的弱桶）。管理：精细分析用 source_predicate 回溯原始语义。
源间冲突：两个上游源对同一药物-疾病给出矛盾边时，KG2 不做仲裁而是并存（各自溯源）。管理：消费侧按 primary_knowledge_source 分组自行裁决，这恰恰是溯源字段的设计意图。

15.3 时效性结构

不同源更新节奏不同：UMLS 语义版本按季度、DrugBank 半年、SemMedDB 随文献流。KG2 月度重建把所有源拉到「最近可用快照」，但单条边的时效取决于其上游源——查 update_date（按源分组解读，坑 5）比查构建日期更能反映单条边的新鲜度。

15.4 与同类图谱的覆盖互补性

实践中发现的三类「KG2 有而 Hetionet 没有」内容： Translator 生态特有的谓词规范化体系与限定符；更全的 UMLS 子词表覆盖；月度演进的历史版本能力（Hetionet 静态）。反过来 Hetionet 的 Rephetio 权重回归方法与配套数据是 KG2 不提供的。两者拼接的典型用法：用 Hetionet 的方法学论文做基线，用 KG2 做扩展验证。

§16 项目背景：Translator 计划与知识图谱工程化的十年

16.1 NCATS Translator 是什么

Biomedical Data Translator 是 NCATS 于 2016 年前后启动的长期项目，愿景是把分散的生物医学数据「翻译」成可回答转化医学问题的推理服务。技术路线几经调整，最终形态是联邦式架构：多个 reasoning agents 与 KPs 通过 TRAPI 协议互联，各 KP 独立建设、独立许可、独立演进。RTX-KG2 是这个生态中覆盖面最大的单一 KP。

16.2 从 KG1 到 KG2 的重构逻辑

第一代 RTX 知识图谱（KG1）以 Scala 实现，暴露了「建图代码与图语义耦合过紧」的问题：加一个源要改多处核心代码。KG2 的重构核心决策是：① 建图逻辑数据化（谓词映射进 YAML、源清单进 inventory）；② 语义层外包给社区标准（Biolink）；③ 流水线交给通用工作流引擎（Snakemake）；④ 验证交给社区工具（KGX/translator-ingests）。结果是加新源变成「写一个解析任务 + 加几行映射」，这是它能维持月更的根本原因。

16.3 学术团队维护大型公共基础设施的经验

KG2 的运营模式对同类项目有普遍参考价值：公开构建日志与报告（S3 网站端点）、把质检做成强制流水线闸门而非事后审查、许可问题显式 FAQ 化、下游消费方（ARAX/mediKanren/Every Cure）形成天然的持续测试网络。这四件事共同构成「小团队维持可信公共图」的最小可行配置。

§17 展望：知识图谱与 LLM 的融合路线

Translator 生态 2024 年以来的演化方向包括：① LLM 辅助的查询接口（自然语言到 TRAPI 查询的翻译）；② 知识图谱作为 LLM 的结构化证据层（先图检索后生成）；③ 边级溯源字段成为「可审计 AI 问答」的关键基础设施——当模型给出一个药物-疾病断言时，可回链到 KG2 边的引文与原句。KG2 的月更节奏与标准化的溯源字段，恰好是这些方向的前置条件。对检索者的建议：把 KG2 当作「可审计证据层」纳入自己的 AI 流水线，而不是当作另一个待训练的语料。

§18 按用户角色的常见误解澄清（续）

误解 7：「KG2 的图就是所有源数据的大合并，损失了各源内部结构。」
恰恰相反——本体类的层级结构（GO 的 is_a、HPO 的继承、MONDO 的跨库映射）被完整保留为图的边。损失的是谓词细粒度（见 §15.2），不是结构。

误解 8：「月更版本用最新就行，不用管版本号。」
学术论文、基准对比、监管相关分析都必须锁定版本并记录指纹。月更意味着「最新」是一个移动靶，可复现性靠版本冻结。

误解 9：「KG2c 合并了同义词，所以不用做实体消歧了。」
合并覆盖 gene/protein、疾病同义词等典型场景，但化学品的多标识、疾病粒度差异等仍需消费侧处理（§14.2）。

误解 10：「下载量大 = 用不起。」
边文件 1.7 GB 是压缩后体积，流式处理内存占用可控制在几百 MB 内；DuckDB 路线甚至能在一台笔记本上完成多数分析（§13.6）。真正的门槛是自建全量构建，不是消费。

误解 11：「API 查询的结果和下载版可能不一致，所以要只信其中一个。」
两者出自同一构建流水线，内容一致；差异只在时点（API 可能已升级到新版本）。对齐方法：查 API 返回的版本元数据与你的下载版本指纹。

误解 12：「学术引用格式随便写写就行。」
CC BY 的署名是许可条件的一部分，不是学术礼节。正确的署名（RTX KG2 development team）+ 版本号 + 论文引用，三件套齐全才算合规引用。

§19 术语与缩写总表（速查）

缩写	全称	一句话说明
NCATS	National Center for Advancing Translational Sciences	美国国立卫生研究院下属转化科学促进中心，Translator 项目资助方
Translator	Biomedical Data Translator	NCATS 的联邦式生物医学推理项目
RTX	Reasoning Tool X	Translator 内的推理系统团队/代号
ARAX	RTX 的推理引擎	消费 KG2 的模块化推理系统
KG	Knowledge Graph	知识图谱
KP	Knowledge Provider	联邦架构中的知识提供者
TRAPI	Translator Reasoner API	Translator 标准查询协议
ETL	Extract-Transform-Load	抽取-转换-加载流水线
CURIE	Compact URI	紧凑统一资源标识符
CUI	Concept Unique Identifier	UMLS 概念唯一标识
UTS	UMLS Terminology Services	UMLS 许可签署与下载门户
KGX	Knowledge Graph Exchange	Translator 社区图谱交换格式
APOC	Awesome Procedures on Cypher	Neo4j 过程库，KG2 TSV 导入依赖
GNN	Graph Neural Network	图神经网络，KGML-xDTD 采用
OMIM	Online Mendelian Inheritance in Man	遗传病-基因关系权威库
MESH	Medical Subject Headings	NLM 医学主题词表
RxNorm	Rx Norm	NLM 药物规范化词表
HGNC	HUGO Gene Nomenclature Committee	基因命名委员会
GO	Gene Ontology	基因本体
HPO	Human Phenotype Ontology	人类表型本体
SNOMED CT	Systematized Nomenclature of Medicine - Clinical Terms	临床医学术语系统（许可特别条款）
FAIR	Findable, Accessible, Interoperable, Reusable	数据管理原则
PMID	PubMed Identifier	文献标识
DOI	Digital Object Identifier	数字对象标识符
ORCID	Open Researcher and Contributor ID	研究者身份标识
JSONL	JSON Lines	逐行 JSON 的流式存储格式
DAG	Directed Acyclic Graph	有向无环图（流水线任务依赖）
EC2	Elastic Compute Cloud	AWS 云主机（r5a.4xlarge 为参考机型）

§20 从 RTX-KG2 学到的图谱工程方法论（可迁移清单）

面向正要构建自己领域整合图谱的团队，KG2 提供了十条可直接抄作业的设计决策：

语义层外包给社区标准（Biolink Model），不要自造 schema——互操作性与工具链都来自标准。
建图逻辑数据化：谓词映射进 YAML、源清单进 inventory，让加源变成配置工作。
流水线交给通用引擎（Snakemake/Airflow），自己只写解析与映射任务。
验证做成强制闸门：不通过 schema 验证的构建不允许进入下游步骤。
边级溯源是一等公民：源、引文、原句、置信分四层信息逐边携带，下游的一切信任计算都靠它。
保留 pre-canonical 形态：同义词合并的图（KG2c）与原始图（KG2pre）都分发，覆盖研究与应用两类需求。
质检三层：机器验证 + 人工报告审查 + 下游消费方众测。
许可问题显式化：逐源枚举许可等级、FAQ 直说「很复杂」、把不可再分发写在最显眼处——沉默的许可是最大的法律风险。
构建成本透明化：公布参考硬件、时长与美元成本，让潜在复现者能做预算。
月更节奏 + 版本指纹三渠道：高频更新建立信任，多渠道指纹保障可核验性。

这十条中，第 5 条（边级溯源）与第 8 条（许可显式化）是 KG2 区别于多数同类项目的两个最大特色，也是本站把它收录为 AI-Ready 条目的核心原因：一个「每条证据都可回溯、每份许可都可核查」的知识基础设施，正是 AI 时代最稀缺的数据形态。

§21 与库内条目的协同学习路径（给站内读者）

按学习目标推荐的本库内阅读顺序：

路径 A：理解知识图谱整合工程
hetionet（rid=832）→ 本条目 → 参考 §5.4 与 §16.2 的对比分析。先读 Hetionet 了解「一次整合的经典范式」，再读 KG2 看工程化的下一步。

路径 B：药物重定位研究
drugbank（rid=89）→ dgidb（rid=419）→ 本条目 §6.4 与 §12.1 → reactome（rid=424）。从药物-靶点数据源读到整合图上的建模方法。

路径 C：医学文本挖掘证据链
semmeddb（rid=836）→ 本条目 §2.3 与 §15.2 → 回到 SemMedDB 条目细读抽取方法。理解「文献挖掘边」的价值与噪声结构。

路径 D：术语标准化与 ID 对齐
umls（rid=558）→ 本条目 §14 → MONDO/本体类源。建立从中文术语到国际 CURIE 的对齐能力。

四条路径殊途同归：KG2 是本库知识图谱类条目的「下游枢纽」，理解它等于同时理解了上游各源在整合体系中的分工。

§22 结语

RTX-KG2 的价值主张可以用一句话收束：它把「整合 70+ 个生物医学知识源」从一次性工程变成了可持续运营的基础设施。月度重建的流水线、强制验证的闸门、逐边携带的溯源、显式透明的许可，四个设计决策共同回答了整合图谱领域最难的问题——如何让一张大图在多年时间里保持可信。

对本站检索者，最后三点提醒：① 消费用 KG2c、锁定版本指纹；② 图内容不可再分发，上游许可（UMLS 优先）自己签；③ 置信与证据判断永远回到 primary_knowledge_source 与 publications 字段——这是 KG2 设计者留给每一位使用者的信任锚点。

§23 上游知识源全景表（选录与分类）

以下按内容类别列出 KG2 整合的代表性上游源。完整清单以仓库 README 源表与 ont-load-inventory.yaml 为准（口径差异见 §2.5 与存照）。

23.1 本体与受控词表类（节点主干）

源	内容	在 KG2 中的角色
UMLS Metathesaurus	医学概念集成（含数十子词表）	节点命名与同义词主干；许可红线所在
— RxNorm	规范化药物词表	药物节点标识来源之一
— MESH	医学主题词表	疾病/化学品节点补充标识
— GO	基因本体	基因功能节点与 is_a 层级
— HPO	人类表型本体	表型节点及继承结构
— MONDO	疾病本体	疾病节点跨库对齐
— ChEBI	化学实体本体	化学品节点分类
— NCI Thesaurus	癌症术语	肿瘤类概念补充
— Uberon	跨物种解剖学本体	解剖部位节点
— NCBITaxon	分类学	物种节点
— ICD10 / ICD9	疾病分类	临床编码桥接（ICD10 为 category 4 许可）
— LOINC	检验观测指标	检验类节点（需特别声明）
— MEDDRA / CPT / HCPT / HCPCS	药物警戒与操作编码	category 3 高限制子源
— HGNC / HL7 / NDDF / PDQ / PSY	基因命名与临床术语	补充节点与同义词
— OMIM	遗传病-基因关系	疾病-基因强证据边（再分发受限）

23.2 药物与化学类（药物侧承载）

源	内容	角色
ChEMBL	生物活性分子与活性预测	药物节点与配体-靶点预测边（含 subject/object score）
DrugBank	药物与靶点人工策展	药物-靶点边金标准（商业许可）
SMPDB	小分子通路图	代谢与药物通路边
HMDB	人类代谢物	代谢物节点
MED-RT	药物-疾病治疗关系	治疗关系边（category 0）

23.3 关联与相互作用类（桥接边）

源	内容	角色
SemMedDB	文献语义谓词	长尾边主力（唯一带原句）
DisGeNET	基因-疾病关联	疾病-基因边主力
DGIdb	药物-基因相互作用	药物-基因边
IntAct	分子相互作用	蛋白-蛋白边
UniProtKB	蛋白注释	蛋白节点属性
NCBIGene	基因记录	基因节点补充
KEGG	基因组百科	通路补充
ClinicalTrials KG	临床试验	试验-疾病/药物边
ATC	解剖治疗化学分类	药物分类边

23.4 六大核心源的证据链角色分工

论文特别强调的六核心源在推理中各司其职：UMLS 负责「说得清」（概念与同义词）、SemMedDB 负责「覆盖广」（文献长尾）、ChEMBL 负责「算得出」（活性预测分）、DrugBank 负责「策展准」（人工靶点）、Reactome 负责「连得通」（通路机制）、SMPDB 负责「代谢全」（小分子通路）。理解这个分工后，证据过滤策略的设计（§12.1 步骤三）就有了直观依据。

§24 边记录实例解剖（字段级导读）

以下用一个示意化的边记录展示 KGX JSONL edges 文件中一行数据的完整形态（字段值以官方文档描述为准做示意，实际值请以下载文件为准）：

{
  "id": "UMLS:C0006826-biolink:inhibitor-ChEMBL:COMPOUND_CHEMBL25",
  "subject": "ChEMBL:COMPOUND_CHEMBL25",
  "predicate": "biolink:inhibitor",
  "predicate_label": "inhibitor",
  "object": "UMLS:C0006826",
  "source_predicate": "ChEMBL:activity_relation",
  "primary_knowledge_source": ["infores:chembl"],
  "publications": ["PMID:32196849"],
  "publications_info": {
    "PMID:32196849": {
      "publication date": "2020-03-25 00:00:00",
      "sentence": null,
      "subject score": "8.9",
      "object score": null
    }
  },
  "qualified_predicate": null,
  "qualified_object_aspect": null,
  "qualified_object_direction": null,
  "update_date": "2024-11-02"
}

逐字段解读：

id：官方文档说明是由边属性拼接的唯一标识，同一条边组合在同源内不会重复出现。
subject/object：注意两个端点分属不同前缀空间（ChEMBL 化合物 vs UMLS 概念）——这是整合图的常态，ID 对齐能力（§14）因此成为消费前提。
source_predicate 与 predicate 的差异：上游的「活性关系」细节被归一到标准谓词。做精细分析时回溯 source_predicate。
publications_info 的键：与 publications 列表一一对应；sentence 为 null 说明这是非 SemMedDB 边（坑：不要期待策展边有原句）。
subject score 的含义：ChEMBL 边上这是配体-靶点结合预测的置信（坑 3：不可与 SemMedDB 分数混比）。
update_date：格式在此例中恰为 ISO，但跨源不保证（坑 5）。

再给一个 SemMedDB 边的对照示意（突出文本挖掘边的特点）：

{
  "subject": "MESH:D008545",
  "predicate": "biolink:treats",
  "object": "MESH:D001249",
  "source_predicate": "SemMedDB:TREATS",
  "primary_knowledge_source": ["infores:semmeddb"],
  "publications": ["PMID:27842144"],
  "publications_info": {
    "PMID:27842144": {
      "publication date": "2017-01-15 00:00:00",
      "sentence": "Asthma was treated with inhaled corticosteroids ...",
      "subject score": "0.782",
      "object score": "0.801"
    }
  }
}

两个实例并排看，三条消费纪律立刻具体化：分数只在同源内比（0.78 的 SemMedDB 分与 8.9 的 ChEMBL 分不可比）；原句只有 SemMedDB 有；谓词要回 source_predicate 看真实语义。

§25 扩展 FAQ（再答 12 问）

Q33：KG2 能直接回答「某药的适应症有哪些」吗？
能检索到候选边集合，但「适应症」没有单一专属谓词，需要组合 biolink:treats 等治疗类关系并按源过滤。它是关系候选器，不是适应症权威数据库。

Q34：图的节点类别有多少种？
Biolink 类别体系的实际使用子集，按节点 category 字段统计即可获得（§13.2 给了代码）。77 指关系类型数量，节点类别是另一套统计。

Q35：可以从 KG2 导出 RDF 吗？
官方分发形态是 KGX JSONL 与 Neo4j TSV，不提供 RDF。社区有第三方转换工具，但转换结果的 schema 兼容性需自行验证。

Q36：KG2 对药物相互作用（DDI）覆盖如何？
覆盖取决于上游源是否提供 DDI 边；DrugBank 含 DDI 数据，故图中有相当覆盖。做 DDI 分析前先统计该谓词的边数与源分布。

Q37：用 KG2 做网络药理学分析可行吗？
可行且是常见用法，但注意 §15.1 的度分布长尾问题——网络指标要带度保持随机化对照。

Q38：能查到中医/传统医学概念吗？
UMLS 含部分传统医学术语但覆盖有限；草药成分的化学实体若被 ChEMBL 收录则在图中有节点。整体不适合作为传统医学研究的主数据源。

Q39：KG2 的图规模适合放进图数据库做实时查询吗？
4000 万边量级对 Neo4j 是可承受的（配 64 GB+ 内存合理配置）；更大规模的实时图可考虑分布式图存储。自建时遵循官方版本配对（坑 7）。

Q40：图中药物节点的「药」如何界定？
由上游源定义与 Biolink 类别（biolink:Drug / biolink:SmallMolecule 等）共同决定；同一分子可能因来源不同被标为化学品或药物，分析时按 category 过滤。

Q41：有官方的 Python 客户端吗？
无官方统一客户端；消费主要靠 requests 调 SmartAPI 服务或直接解析 KGX JSONL（§13 给了模板）。

Q42：图的 license 能用于商业项目吗？
分层回答：代码 MIT 允许商业使用；图内容取决于上游源——UMLS 协议允许多数研究与一定商业场景，但 DrugBank 等需要商业许可谈判。商业项目建议先做逐源许可审计。

Q43：如何向团队报告图中疑似错误？
GitHub 提 issue。注意区分三类问题：KG2 流水线 bug（团队修）、上游源数据错误（需向上游报告）、Biolink 模式争议（社区讨论）。

Q44：本条目的信息够我启动项目了吗？
够启动消费型项目（下载、对齐、分析）；启动自建构建前请完整阅读官方 README 与 FAQ 原文——本文是导读与经验总结，不能替代官方文档。

§26 附录 E：消费侧代码片段补充集

26.1 统计某疾病的所有边及其来源分布

import json
from collections import Counter

TARGET = "MONDO:0005180"  # 替换目标疾病 CURIE
edge_count, src_counter = 0, Counter()
with open("kg2c-2.10.1-v1.0-edges.jsonl") as f:
    for line in f:
        e = json.loads(line)
        if TARGET in (e.get("subject"), e.get("object")):
            edge_count += 1
            srcs = e.get("primary_knowledge_source") or []
            for s in (srcs if isinstance(srcs, list) else [srcs]):
                src_counter[s] += 1
print(f"总边数: {edge_count}")
for s, n in src_counter.most_common():
    print(f"  {s}: {n}")

26.2 抽取某药物的完整邻域为子图 JSON

import json

DRUG = "ChEMBL:COMPOUND_CHEMBL25"
sub = {"nodes": [], "edges": []}
node_ids = set()
with open("kg2c-2.10.1-v1.0-edges.jsonl") as f:
    for line in f:
        e = json.loads(line)
        if e.get("subject") == DRUG or e.get("object") == DRUG:
            sub["edges"].append(e)
            node_ids.add(e["subject"]); node_ids.add(e["object"])
with open("kg2c-2.10.1-v1.0-nodes.jsonl") as f:
    for line in f:
        n = json.loads(line)
        if n.get("id") in node_ids:
            sub["nodes"].append(n)
json.dump(sub, open(f"neighborhood_{DRUG.replace(':','_')}.json", "w"), indent=1)
print(f"edges={len(sub['edges'])}, nodes={len(sub['nodes'])}")

26.3 版本指纹核验函数（发布前必跑）

import json

def check_fingerprint(nodes_path, expected_version):
    """核验三渠道版本指纹之一（build slot）。"""
    with open(nodes_path) as f:
        first = json.loads(f.readline())
    got = str(first.get("build") or first.get("name") or "")
    assert expected_version in got, f"版本不匹配: 期望 {expected_version}, 实得 {got}"
    print("指纹一致:", got)

# check_fingerprint("kg2c-2.10.1-v1.0-nodes.jsonl", "2.10.1")

26.4 度分布采样器（为 §15.1 的长尾分析准备）

import json
from collections import Counter
import math

deg = Counter()
with open("kg2c-2.10.1-v1.0-edges.jsonl") as f:
    for line in f:
        e = json.loads(line)
        deg[e["subject"]] += 1
        deg[e["object"]] += 1

buckets = Counter(int(math.log10(d)) if d else 0 for d in deg.values())
print("log10 度分桶:", dict(sorted(buckets.items())))
top10 = deg.most_common(10)
print("度 Top10:", [(k, v) for k, v in top10])

典型输出模式是 log10=0（度 1-9）桶占绝对多数、log10=4+ 桶只有少数明星节点——这就是长尾的定量形态。拿到这个分布后，你的采样策略、对照设计、指标选择都有了依据。

附录：DAIMS 评估全表

维度	评分（1-10）	依据
D 可发现性	8	论文开放获取（BMC）+ KG Hub 注册页 + SmartAPI 注册 + GitHub 仓库多入口；infores:rtx-kg2 提供标准信息资源标识
A 可获取性	6	预构建 dump 公开直链（translator-lfs-artifacts / S3 公开端点 / KG Hub）；但图内容使用受上游许可门槛（UMLS 签署、DrugBank 商业谈判），Neo4j 托管端点限成员
I 可互操作	9	Biolink Model 标准语义层 + KGX 交换格式 + TRAPI/SmartAPI 协议生态；CURIE 全图统一；为整合图谱互操作性的标杆水平
M 元数据质量	8	边级溯源四件套（源/引文/原句/置信分）远超同类；扣分项：update_date 格式不一致、置信分无统一量表、Biolink 具体版本未注明
S 可持续性	8	月度 Snakemake 重建 + 强制验证闸门 + 多渠道版本指纹 + 团队依托 NCATS 长期资助；构建文档公开（硬件/成本/时长透明）
综合评级	7.8/10（高）	工程化与互操作性为整合图谱领域第一梯队；唯一显著短板是图内容不可再分发带来的许可门槛——但这恰是对上游源合规的诚实处理

附录：数据获取决策树

你的需求是什么？
├── 只想偶尔查几条关系
│   └── arax.rtx.ai SmartAPI 接口（§13.5），无需下载
├── 想做药物重定位建模 / 图机器学习
│   ├── 1) 下载 KG2c（canonical）nodes+edges JSONL（KG Hub 直链）
│   ├── 2) 签署 UMLS UTS 协议（使用合法性）
│   ├── 3) 用 §13.3 流式脚本抽子图，锁版本指纹
│   └── 注意：别用 KG2pre 训练（坑 6）
├── 想要 Cypher 交互式图查询
│   ├── 1) 下载 Neo4j TSV 包
│   ├── 2) Neo4j 3.5.13 + APOC 3.5.0.4（坑 7，版本必须配对）
│   └── 3) 用 kg-simplified-report 核对导入完整性
├── 想复现/改造构建流水线
│   ├── 1) 评估硬件门槛：128 GiB 内存 / ~1 TB 磁盘 / 20 Gb/s（§3.1）
│   ├── 2) clone RTXteam/RTX-KG2，dry-run 确认 DAG（§3.2）
│   ├── 3) screen 会话全量构建 ~25h；中断先 --unlock（坑 8）
│   └── 4) KGX/Biolink 验证 PASSED 才算数
└── 想发布含 KG2 内容的衍生数据
    ├── 1) 逐源审计 source-licenses/README.md（UMLS category 分级）
    ├── 2) 签署 UTS；DrugBank/OMIM 类源单独评估
    └── 3) 结论大概率是不可公开再分发 → 改为发布「下载脚本+版本说明」

附录：关键数字证据链自证

关键数字	来源	位置
70 个知识源 / 六核心源	主论文摘要	BMC Bioinformatics 23:400（DOI 10.1186/s12859-022-04932-3）
6.4M 节点 / 39.3M 边 / 77 关系类型	主论文摘要（KG2.7.3）	同上
80+ 知识源	KG Hub 注册页描述	kghub.org/kg-registry/resource/rtx-kg2/rtx-kg2.html
节点 359.1 MB / 边 1.7 GB（KG2.10.1c）	KG Hub 产物表	同上 Products 节
代码 MIT / artifacts CC BY-4.0 / 内容不可再分发	官方 FAQ「Where can I download」「What licenses cover KG2」	GitHub README（RTXteam/RTX-KG2）
UMLS 子源 license category 0-4 与特别条款	source-licenses/README.md	仓库 commit 841cc5569a5c5b7f3c7f506777a52f3
构建 ~25h / r5a.4xlarge / ~$23 / 128 GiB / Python 3.13	README General Steps / build requirements	GitHub README
月更 / Snakemake / KGX 验证闸门 / translator-ingests	README build 流程节	GitHub README
Neo4j 3.5.13 + APOC 3.5.0.4	README 与 FAQ	GitHub README
ARAX 验证工作流（恢复已知药物-疾病关系）	Every Cure 知识源文档引用	docs.dev.everycure.org
KGML-xDTD 更高准确率/更低假阳性	Ma C. et al. 摘要（PMID 37602759）	Every Cure 文档引用
infores:rtx-kg2 / Stephen Ramsey ORCID	KG Hub 注册页元数据	kghub.org

事实清单（硬事实 36 条）

RTX-KG2 是 NCATS Biomedical Data Translator 项目内的开源知识图谱构建系统与图谱本体。
开发机构：Oregon State University；PI：Stephen Ramsey（ORCID 0000-0002-2168-5403）。
GitHub 组织/仓库：RTXteam/RTX-KG2；infores 标识：infores:rtx-kg2。
资助合同：OT2TR002520 与 3OT2TR003428-01S1（NIH NCATS）。
主论文：Wood E.C. et al., BMC Bioinformatics 2022;23:400，DOI 10.1186/s12859-022-04932-3，PMID 36175836，17 位作者，CC BY-4.0。
主论文报道整合 70 个知识源，含 UMLS、SemMedDB、ChEMBL、DrugBank、Reactome、SMPDB 六核心源。
KG Hub 注册页口径：整合 80+ 结构化知识源。
README 源表口径：50+ 条目（data 类与 ontology 类分列）。
KG2.7.3（论文时点 canonical 版）：6,400,000 节点、39,300,000 边、77 种 Biolink 关系类型。
KG2.10.1c（KG Hub 现行分发）：节点 KGX JSONL 359.1 MB、边 KGX JSONL 1.7 GB。
版本命名格式：KG2.{major}.{minor}；图结构版本恒为 2；形态后缀 pre（未合并）/ c（canonical）。
版本核实三渠道：构建 JSON 的 build slot、RTX:KG2 节点 name 字段、S3 kg2-version.txt。
构建流水线：Snakemake 管理 DAG，入口 build-kg2-snakemake.sh，dry-run 约 50 任务。
构建环境：Ubuntu 22.04、Python 3.13、AWS CLI（us-west-2 S3）。
硬件门槛：128 GiB 内存、约 1,023 GiB 磁盘、20 Gb/s 网络。
参考构建成本：EC2 r5a.4xlarge 全量约 25 小时、约 23 美元（±20%）；部分构建约 12 小时。
构建频率：约每月一次。
质量闸门：KGX/Biolink 验证（NCATSTranslator/translator-ingests 工具）必须 PASSED 才进入 conflation。
每次构建产出 kg-simplified-report JSON 与孤立边清单供人工审查。
谓词映射：predicate-remap.yaml 数千行，将 UMLS RB/RN/RO 等上游谓词归一到 Biolink 标准谓词。
Neo4j 配对版本：3.5.13 + APOC 3.5.0.4；TSV 导入脚本 tsv-to-neo4j.sh。
边级溯源字段：primary_knowledge_source、publications、publications_info、source_predicate、update_date。
publications_info 的 sentence 字段仅 SemMedDB 边非空。
subject/object score 无统一量表；SemMedDB 边与 ChEMBL 预测边含义不同。
update_date 字段格式跨源不一致，无法统一时间过滤。
许可：构建代码 MIT；文档与 GitHub/S3 构建产物 CC BY-4.0；图内容本体受上游许可约束不可再分发。
CC BY 署名要求：RTX KG2 development team, github.com/RTXteam。
UMLS 许可按 license category 0-4 分级管理；SNOMED CT 有附录 2 特别条款；LOINC 需特别声明；DrugBank 需商业许可；OMIM 限制再分发。
获取渠道：translator-lfs-artifacts（GitHub dump）、S3 rtx-kg2-public、KG Hub 注册页、SmartAPI API（arax.rtx.ai）、Neo4j 端点（限成员）。
源遴选五准则：扁平文件可下载、持续维护、内容互补、CURIE 可连接、优先人工策展。
ARAX 论文：Glen A.K. et al., Bioinformatics 2023;39(3):btad082，PMID 36752514。
KGML-xDTD 论文：Ma C. et al.，PMID 37602759，在 KG2c 上训练 GNN 做药物-疾病治疗预测，报告更高准确率与更低假阳性。
ARAX 的验证工作流：恢复已知药物-疾病关系。
Every Cure KGML 流水线采用 RTX-KG2c 为药物重定位基础图。
KG Hub 为 RTX-KG2 维护官方 evaluation 页面。
canonical 化包含 gene/protein conflation（HGNC 两侧合并），建模推荐用 KG2c。

术语表（30 条）

Biolink Model：Translator 社区的知识图谱语义模式标准，定义节点类别与关系类型的层级体系。
KGX：Translator 社区的图谱交换格式，JSON Lines 形态的 nodes/edges 文件对。
KG2c：RTX-KG2 的 canonical（同义词合并后）版本，建模推荐形态。
KG2pre：同义词合并前的原始形态版本。
Conflation：同义词/等价实体合并操作，如 gene 与 protein 节点合并。
CURIE：紧凑统一资源标识符，如 UMLS:C0006826，KG2 节点与边的标识形式。
UMLS：统一医学语言系统，美国 NLM 维护的医学术语集成系统，KG2 节点命名主干。
SemMedDB：从 MEDLINE 抽取语义谓词的数据库，KG2 文献挖掘边来源。
ChEMBL：生物活性药物样分子数据库，欧洲生物信息学研究所维护。
DrugBank：药物与药物靶点人工策展数据库，商业许可约束的典型代表。
Reactome：人工策展的生物反应通路数据库。
SMPDB：小分子通路数据库。
DisGeNET：基因-疾病关联数据库，整合文献挖掘与策展证据。
DGIdb：药物-基因相互作用数据库。
HMDB：人类代谢物数据库。
MONDO：疾病本体，跨库疾病定义对齐。
HPO：人类表型本体。
ChEBI：化学实体本体。
KP（Knowledge Provider）：Translator 联邦架构中的知识提供者服务角色。
Reasoning agent：Translator 联邦架构中接收问题并编排 KP 查询的推理代理。
TRAPI：Translator 标准查询 API 协议（Reasoner API）。
SmartAPI：API 元数据注册服务，KG2 的查询服务在此注册。
ARAX：RTXteam 的模块化生物医学推理系统，KG2 的首要消费方。
mediKanren：Translator 生态中基于 Scheme 的推理系统，从 KG2 导出图。
KGML-xDTD：基于 KG2c 的药物-疾病治疗预测图机器学习框架。
Snakemake：Python 生态的工作流管理器，KG2 构建流水线的 DAG 引擎。
infores：Biolink 的信息资源标识前缀体系，如 infores:rtx-kg2。
孤立边（orphan edge）：subject 或 object 节点缺失的边，整合图谱常见病灶。
drug repurposing（药物重定位）：为已知药物寻找新适应症的研究范式，KG2 的最大应用场景。
UMLS license category：UMLS 各子词表的许可分级（0 最松、4 最严），KG2 逐源标注。

附录

附录 A：与库内条目的上下游血缘速查

                  ┌── umls (558) ── 节点命名主干/许可红线
                  ├── semmeddb (836) ── 文献挖掘边（含原句+置信分）
RTX-KG2 (本条目) ─┼── drugbank (89) ── 药物-靶点策展边/商业许可代表
                  ├── reactome (424) ── 通路边
                  ├── dgidb (419) ── 药物-基因相互作用边
                  └── hetionet (832) ⇄ 同类整合图谱横向对照

附录 B：边记录字段全量速查（KGX JSONL edges）

字段	类型	说明
id	string	由边属性拼接的唯一标识
subject / object	CURIE	边两端节点标识
predicate	CURIE	简化后的 Biolink 标准谓词
predicate_label	string	标准谓词的 snake_case 标签
source_predicate	CURIE	上游原始谓词（如 UMLS:RB）
primary_knowledge_source	CURIE 列表	报告该边组合的上游源
publications	CURIE 列表	支撑引文（PMID/DOI/ISBN）
publications_info	object	按引文给出原句/置信分/出版日期
qualified_predicate / qualified_object_aspect / qualified_object_direction	—	Biolink 限定符组
update_date	string	上游更新时间（格式跨源不一致）

附录 C：构建自建检查单（给想复现的团队）

确认硬件：≥128 GiB 内存、≥1 TB 磁盘、20 Gb/s 网络（或接受更长传输时间）。
Ubuntu 22.04 + Python 3.13 + AWS CLI，配好 us-west-2 凭据。
clone RTXteam/RTX-KG2，运行 setup-kg2-build.sh。
dry-run：build-kg2-snakemake.sh 确认约 50 个任务 DAG 完整。
在 screen 会话中跑全量（约 25 小时）；中断后先 --unlock 再重跑（坑 8）。
KGX/Biolink 验证必须 PASSED 才继续；审查 kg-simplified-report 与孤立边清单。
conflation 产出 KG2c；导出 KGX JSONL 与 Neo4j TSV（配对 3.5.13 + APOC 3.5.0.4）。
上线前核对版本三渠道指纹一致。

附录 D：本条目未收录内容清单（许可原因）

图本体任何切片、镜像、再打包下载链接（UMLS 等上游许可禁止再分发）。
UMLS License 原文与 UTS 注册流程细节（以 UTS 官方页面为准）。
DrugBank/OMIM 许可条款全文（以各源官方条款为准）。
KG2 团队私有 Neo4j 端点凭据申请流程（需直接联系维护者）。

尾注

本条目由千方病案医数集编写，基于一手来源三源互证：KG Hub 注册页（kghub.org）、RTXteam/RTX-KG2 官方 README（GitHub）、Wood et al. 2022 主论文（BMC Bioinformatics，DOI 10.1186/s12859-022-04932-3）；辅以 Every Cure 技术文档与 RTX-KG2 仓库 commit 记录（source-licenses 清单）。
所有版本号、规模数字、许可表述以官方渠道现行发布为准；本条目写作时点为 2026-10-17。
双口径存照：知识源数量 70/80+/50+ 三口径差异详见正文 §2.5 与 FACTS.md §9；论文卷页以 README 口径 23:400 记录。
遗留疑点：KG2.10.x 现行版本节点/边总数未公布；Biolink Model 具体版本号官方未指明。
相关库内条目：umls（rid=558）、semmeddb（rid=836）、drugbank（rid=89）、reactome（rid=424）、dgidb（rid=419）、hetionet（rid=832）。