1. 药物知识图谱本体设计工程导论

药物研发是一条高度依赖知识整合的长链条：从靶点发现、化合物筛选、药代动力学评价，到临床试验、上市后监测，每个环节都会产生大量结构化与非结构化数据。这些数据分散在文献、专利、数据库、实验记录和监管文件中，字段命名、实体粒度和语义约定各不相同。知识图谱的价值，正是把这些异构知识组织成机器可推理的网络；而本体，则是这张网络的“骨架”和“语法规则”。本课程讨论的不是如何调用某个图数据库，而是如何以工程化方式设计、构建、验证并维护药物领域的本体，使知识图谱在真实研发场景中可复用、可扩展、可审计。

课程目标与定位

学完本课程，你应当能够独立完成一套面向药物研发场景的本体设计：明确领域边界与竞争性问题，抽取核心类与关系，定义数据属性与约束，编写可被推理机处理的公理，并让本体与下游知识图谱实例、查询接口和质控流程衔接。课程强调“工程化”，意味着本体不是一次性文档，而是有版本、有测试、有评审、有迁移策略的软件资产。

知识图谱与本体在药物研发中的定位可以这样理解：知识图谱是实例层，回答“阿司匹林抑制 COX-1 这个事实是否存在”；本体是模式层，回答“药物、靶点、酶、疾病之间允许存在哪些关系，这些关系的定义域和值域是什么，能否传递”。没有本体的图谱容易退化为一张大表，查询结果依赖字段拼写；没有图谱的本体则停留在纸面，无法验证其表达力。二者必须协同迭代。

工程化视角下的核心挑战

药物领域的本体设计面临几类典型困难。第一是术语歧义：同一个缩写在不同语境下可能指不同实体，例如“ACE”既可能是血管紧张素转化酶，也可能是别的缩写；同一个药物在不同数据库中有不同标识符，盐型、母核、活性代谢物之间的层级关系需要明确。第二是粒度选择：把“阿司匹林”作为一个类，还是把“乙酰水杨酸”作为分子实体、把“阿司匹林片”作为药品？粒度太粗无法支持剂量推理，太细则实例数量爆炸。第三是关系语义漂移：不同来源对“inhibits”的定义不同，有的指酶活性抑制，有的指细胞增殖抑制，必须在本体中用子属性或限定条件区分。第四是版本兼容：本体一旦被下游图谱使用，修改类名或删除属性就会破坏已有实例，需要命名空间、弃用标记和迁移脚本。

这些挑战决定了本体设计不能只靠领域专家拍脑袋，也不能只靠工程师套模板。合理的做法是：先划定最小可用本体范围，用真实查询问题驱动类与关系的取舍，再通过实例化测试暴露问题，最后固化为带版本号的发布物。

整体路线图

本课程按“需求—设计—实现—验证—维护”的工程闭环组织，但每一章的具体产出不同。第 1 章建立整体认知；后续章节依次覆盖领域边界与竞争性问题、类与层级设计、对象属性与数据属性、约束与公理、命名与版本策略、实例化与实体链接、查询与推理验证、质量评估与迭代维护。每个阶段都要求留下可检查的交付物，例如术语表、类图、属性表、SHACL 约束文件、测试查询集和变更日志。

一个可执行的最小示例

假设我们要支持这样一个查询：“找出所有以 EGFR 为靶点、且已进入临床试验阶段的肺癌治疗药物”。这个需求直接决定了本体中至少需要以下元素：类 Drug、Target、Disease、ClinicalTrial；对象属性 hasTarget、treats、testedIn；数据属性 trialPhase、approvalStatus。其中 treats 的定义域是 Drug，值域是 Disease；hasTarget 的定义域是 Drug，值域是 Target。如果缺少 trialPhase 的取值约束，查询就会把临床前数据也混进来。

在工程实现上，可以用 OWL 定义类与属性，用 SHACL 补充闭合约束和基数约束，用 SPARQL 编写验证查询。例如，检查是否存在“药物没有靶点却声称治疗某疾病”的实例，这类查询就是本体验证的一部分。示例参数如 trialPhase 取值为 PhaseI 到 PhaseIV，属于合理假设，用于说明约束设计，不代表任何真实试验结果。