📚 课程目录第4章药物核心本体与标准复用

4. 药物核心本体与标准复用

药物知识图谱的本体设计，很少从零开始。更现实的做法是：先识别哪些外部标准已经稳定覆盖了某类语义，再决定“直接复用、受限复用、仅做映射，还是自建”。本节围绕 RxNorm、DrugBank、ChEBI、SNOMED CT 与 OBO Foundry 五类资源，分析它们各自的本体定位、可复用边界，以及跨源映射时的工程策略。

一、五类资源的语义分工

这五类资源并非同一层级的标准，混用会导致本体结构混乱。理解它们的分工，是复用决策的前提。

RxNorm：由美国国家医学图书馆维护，核心是“临床药物”的规范化标识。它以 RxCUI 为唯一标识，通过 Ingredient（成分）、Clinical Drug（临床药物）、Branded Drug（品牌药）等术语类型（TTY）组织药物，并提供成分—剂量—剂型—包装的语义关系。它最适合承载“可开方、可调剂”的临床药物粒度。
DrugBank：偏药物化学与药理数据，覆盖靶点、酶、转运体、通路、相互作用与适应症。它的 DrugBank ID 与大量外部数据库交叉引用，适合作为“药物—靶点—机制”关系层的数据源，但其本体公理体系较弱，更多是结构化数据库而非严格本体。
ChEBI：欧洲生物信息研究所维护的化学实体本体，以 ChEBI ID 标识分子实体及其角色（role）。它严格区分“分子实体”与“生物学角色”，是药物活性成分化学结构的权威本体来源。
SNOMED CT：临床术语系统，覆盖疾病、操作、药物、解剖等。其药物层级与 RxNorm 有重叠但粒度不同，优势在于与临床记录、适应症、不良反应的语义衔接。
OBO Foundry：不是单一本体，而是一套本体协作原则与本体集合（如 ChEBI、GO、Uberon 等）。它提供命名规范、ID 策略、关系复用（RO）与上层本体（BFO）约束，是本体工程方法论的参照系。

二、复用边界：什么能直接拿，什么必须自建

复用不是“能引就引”。判断边界时，建议从三个维度评估：语义覆盖度（该资源是否覆盖你需要的概念）、粒度匹配度（其最小单位是否与你的业务粒度一致）、公理强度（是否提供可推理的类与关系约束）。

以“阿司匹林”为例：ChEBI 提供其分子实体（CHEBI:15365）与角色（如 COX 抑制剂、抗血小板药）；RxNorm 提供其临床药物形式（如阿司匹林 81mg 口服片，RxCUI 对应具体 TTY）；DrugBank 提供其靶点（COX-1、COX-2）与相互作用；SNOMED CT 提供其与“抗血小板治疗”等临床概念的关联。四者粒度不同，不能互相替代。

因此，合理的复用边界是：化学实体层复用 ChEBI，临床药物层复用 RxNorm，药理机制层引用 DrugBank，临床语义层对接 SNOMED CT，方法论层遵循 OBO Foundry 的 ID 与关系规范。而“药物—适应症—指南推荐”这类业务语义，通常需要自建，因为外部标准不覆盖你的具体决策逻辑。

复用边界的核心判断：如果外部标准的语义粒度与你的业务粒度一致，且其标识稳定、许可允许，则优先复用；若粒度不一致，则只做映射，不强行合并。

三、映射策略：从标识对齐到语义对齐

跨源映射通常分三层推进，难度递增。

第一层：标识映射。建立外部 ID 与本地 ID 的对应表。例如本地药物实体 drug:aspirin 映射到 RxNorm:1191、ChEBI:15365、DrugBank:DB00945。这一层可用 skos:exactMatch、skos:closeMatch 表达，并记录来源与置信度。

第二层：语义映射。处理“同名不同义”与“同义不同名”。例如 RxNorm 的“Aspirin”可能指成分，也可能指具体产品；ChEBI 的“aspirin”是分子实体。映射时必须指定映射的语义类型，不能只对字符串。

第三层：关系映射。将外部关系对齐到本地本体关系。例如 DrugBank 的“target”关系映射到本地的 hasTarget，SNOMED CT 的“has active ingredient”映射到本地的 hasActiveIngredient。这一层需要检查关系的定义域与值域是否兼容。

# 映射记录示例（YAML 片段）
mapping:
  local_id: drug:aspirin
  external:
    - source: RxNorm
      id: "1191"
      match_type: skos:closeMatch
      semantic_type: Ingredient
      confidence: 0.95
    - source: ChEBI
      id: "CHEBI:15365"
      match_type: skos:exactMatch
      semantic_type: molecular entity
      confidence: 0.99
    - source: DrugBank
      id: "DB00945"
      match_type: skos:closeMatch
      semantic_type: drug
      confidence: 0.90
  relation_mappings:
    - external: DrugBank:target
      local: hasTarget
      domain_check: passed

映射完成后，必须做一致性校验：同一本地实体映射到多个外部实体时，检查这些外部实体之间是否存在语义冲突；若冲突，需人工复核或降级为 skos:relatedMatch。

四、OBO Foundry 的方法论约束

OBO Foundry 对本节的价值，不在于提供药物概念，而在于提供一套可复用的工程规范：ID 必须唯一且持久；本体应使用 BFO 作为上层框架；关系应复用 RO（Relation Ontology）；术语应有定义与来源。遵循这些约束，能让你的药物本体在与其他 OBO 本体互操作时减少摩擦。

例如，在定义“药物—靶点”关系时，不要自造 drugTarget，而应优先检查 RO 或相关本体是否已有对应关系；若必须自建，则需给出与 RO 关系的映射说明。这样做的代价是前期设计更慢，收益是后期集成成本更低。

五、工程落地中的关键判断

在实际项目中，映射策略需要配合版本管理。RxNorm 每月更新，ChEBI 每季度发布，DrugBank 版本迭代频繁。若直接引用外部 ID 而不记录版本，后续追溯会出现“同一 ID 语义漂移”的问题。建议在映射表中增加 source_version 与 retrieved_at 字段。

另一个常见问题是“过度复用”。有些团队试图把 SNOMED CT 的全部药物层级直接导入本地本体，结果导致本体规模膨胀、推理变慢，且大量概念与业务无关。更务实的做法是：只抽取与当前业务路径相关的子集，用 owl:imports 或映射表按需引入。

注意：RxNorm 与 SNOMED CT 的药物概念存在重叠但不等价。RxNorm 的“Ingredient”与 SNOMED CT 的“substance”粒度不同，映射时不能简单做 owl:sameAs，否则会破坏本体的推理一致性。

最后，映射质量需要可度量。建议为每条映射记录置信度与审核状态，并定期抽样复核。对于置信度低于阈值的映射，标记为待人工确认，不参与自动推理。这样既保证了图谱的可用性，也保留了后续修正的空间。