知识图谱基础：概念、RDF/OWL 与图数据库
好，我们正式开始第2章。上一章我简单聊了聊药物KN的整体框架，现在咱们得把地基打牢——知识图谱到底是什么？
很多同学一听到“知识图谱”就觉得很玄乎，好像是什么高深莫测的东西。其实说白了，它就是一张有语义的网，用来描述真实世界里的实体和它们之间的关系。
2.1 知识图谱的核心概念
我刚开始接触这个领域时，也走过弯路。以为知识图谱就是画几张圆圈和箭头。后来在项目中踩过坑才明白，它的核心是三元组。
什么是三元组？很简单，三个要素：
- 头实体：比如“阿司匹林”
- 关系：比如“用于治疗”
- 尾实体：比如“头痛”
把这三样串起来，就是一条知识：“阿司匹林 - 用于治疗 - 头痛”。所有复杂的知识图谱，本质上就是成千上万个这种三元组拼起来的。
你想想看，药物KN里的知识多复杂。一个药物有靶点、有适应症、有副作用、有相互作用……如果不按三元组来组织，数据会乱成一锅粥。
知识点小结：
- 实体：药物、基因、疾病、蛋白等
- 关系：治疗、抑制、激活、副作用等
- 三元组：(头实体, 关系, 尾实体)
我曾经接手过一个项目，同事把药物和副作用直接塞进一个文本字段里，结果后面做推理时根本没法用。嗯，从那以后我再也不敢忽视三元组的设计了。
2.2 RDF/OWL：让机器也能读懂的知识表示
三元组是好东西，但怎么让它被计算机高效处理？这就引出了RDF和OWL。
2.4.1 RDF——资源描述框架
RDF是W3C推的一个标准。它的作用就是告诉机器：嘿，这部分是实体，那部分是关系，别给我搞混了。
举个简单的例子，用RDF表示“阿司匹林用于治疗头痛”：
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:drug="http://example.org/drug/">
<rdf:Description rdf:about="http://example.org/drug/aspirin">
<drug:treats rdf:resource="http://example.org/disease/headache"/>
</rdf:Description>
</rdf:RDF>你看，每个资源都有一个URI。这样全世界的知识就能连起来了。我习惯在项目中用Turtle格式写RDF，更简洁，但基本原理是一样的。
个人小技巧：
如果你刚开始搭建KN的RDF数据，别急着用复杂的工具。先用文本文件把三元组整理成CSV或Turtle格式，后面再批量导入。我早期一个项目就是因为直接在数据库里建，结果逻辑一乱改起来特麻烦。
2.4.2 OWL——本体语言
RDF只解决了“怎么存”，没解决“怎么推理”。比如：如果“伊布替尼”属于“BTK抑制剂”，而“BTK抑制剂”是“靶向药物”的子类，那“伊布替尼”是不是也算“靶向药物”？
这种推理，RDF处理不了，得靠OWL。
OWL是在RDF基础上加了逻辑层。它定义了类、属性、约束和公理。最常用的是OWL 2 DL，虽然推理复杂度高，但表达能力特别强。
打个比方：
- RDF像一张白纸，你能在上面写字
- OWL像在纸上画了格子，还规定了哪一栏该写什么、不能写什么
我在药物KN中，用OWL定义过一些关键约束。比如：
类: 靶向药物
等价于: (作用于 一些 靶点)
且 (是 药物 的 子类)
属性: 靶点
定义域: 药物
值域: 蛋白这样一来，程序就能自动推断：一个实体如果标注了“作用于EGFR”，它就会自动归为“靶向药物”。推理机的威力就在这里。
避坑：
OWL有两种类型：隐式定义和显式定义。我刚开始做时，明明数据里没写“伊布替尼是靶向药”，推理机却推断出来了。这不算错，但如果你后续要导出数据给别人用，对方可能不知道这个实体是推理出来的，容易出bug。所以我建议定义OWL时，在导出或共享前把推理结果显式补全一遍。
2.3 图数据库：知识图谱的存储与查询
好了，知识有了标准表示（RDF/OWL），接下来就是用啥存、咋查。纯SQL在多跳关系查询上特别慢。
举个例子，你想查“所有与某个药物有相同靶点的其他药物”，用关系数据库得写一堆JOIN，性能差得离谱。而用图数据库，一条查询语句就搞定了。
2.3.1 主流图数据库
| 图数据库 | 查询语言 | 特点 | 适用场景 |
|---|---|---|---|
| Neo4j | Cypher | 社区活跃，文档完善，支持事务 | 药物知识图谱、社交网络、推荐系统 |
| Amazon Neptune | SPARQL / Gremlin | 托管服务，支持RDF和属性图双模型 | 云端大规模KN、需要多模型混合的场景 |
| JanusGraph | Gremlin | 开源，可扩展，支持HBase/Cassandra | 超大规模图、需要定制存储的企业场景 |
我个人偏向Neo4j。5.0版本开始支持分片和更细粒度的索引，处理千万级节点不在话下。而且Cypher语言对开发者很友好。
2.3.2 Cypher查询示例
假设我们有一个药物KN图，里面包含药物、靶点、疾病节点。想查询“跟阿司匹林共用同一靶点的所有药物”，Cypher这么写：
MATCH (aspirin:Drug {name: '阿司匹林'})-[:targets]->(t:Target)<-[:targets]-(other:Drug)
WHERE other <> aspirin
RETURN other.name, t.name就这么几行，不需要JOIN，不需要子查询。图数据库天生适合这种多跳关联分析。我曾经用Neo4j搭过一个药物重定位的推理模型，就靠几条Cypher语句挖出了十几个候选药物，后来验证发现其中4个有文献支持。效率确实比手写SQL高很多。
小心图数据库的陷阱：
图数据库虽然直观，但索引别忘了建。一开始我没建索引，查询一个节点就全图扫描，慢得受不了。后来在节点属性上加索引，速度瞬间提升了两个数量级。所以记住了：建好索引再开工。
2.4 知识图谱的完整技术栈
我把从原始数据到最终知识图谱的转化路径总结成下面这张图。嗯，这张SVG花了我不少心思，你可以配合看下：
从图上你也能看出来，从原始数据到最终的知识图谱落地，每一步都环环相扣。我每次做类似的项目，都会先从第三层（RDF/OWL表示）开始设计，因为这一层决定了后面所有的存储和查询逻辑。
我的一个核心建议：
不要一上来就想着把数据全塞进图数据库里。先做一个小规模的语义模型（RDF+OWL），验证关系是否正确，再慢慢扩。我见过太多团队一开始就莽，最后发现关系定义错了，返工成本高得吓人。
好了，这一章的内容就到这。知识图谱的概念、RDF/OWL的表示方法、图数据库的选型和基本查询，这些是后续所有实体特征处理的基础。