继续沿用前面的任务。我们要做一个科技史知识服务系统，并希望它能回答：
go
詹姆斯·瓦特（James Watt）是谁？James Watt 与蒸汽机（steam engine）是什么关系？James Watt 属于哪一类人物？为什么系统还能根据已有知识推出新结论？前面已经说明，知识图谱需要合适的知识表示方法。
但在真正落地时，还要进一步回答一个问题：这些知识具体应该用什么模型来表示。
不同模型的重点并不相同：有的强调事实表达，有的强调类别结构，有的强调本体约束，有的强调工程实现，有的强调计算与学习。
一、知识图谱表示模型的必要性
如果系统只把知识写成普通文本，那么"James Watt improved the steam engine"这样的内容虽然人能看懂，机器却不容易稳定处理。
它很难直接知道：
James Watt 是一个实体；
improved 是一个关系；
steam engine 是另一个实体；
这条知识还能与其他知识继续连接。
因此，知识图谱不能只依赖自然语言描述，而需要更清楚的表示模型，把实体、关系、类别、属性和约束写成结构化形式。
只有这样，系统才能更稳定地组织知识、执行查询，并在已有知识基础上支持进一步推断。
二、RDF：事实表示层
如果先从最基础的问题入手："怎样把知识写成统一结构？"
常见答案就是 RDF（Resource Description Framework，资源描述框架）。
RDF 的核心思想很简单：把知识写成三元组（triple），也就是"主体---谓词---客体"的结构。
例如，在当前任务里，可以写成：
javascript
James Watt --- improved --- steam engineJames Watt --- connected with --- University of GlasgowJames Watt --- associated with --- Industrial RevolutionRDF 解决的是知识图谱最基础的一层：怎样把事实写出来。
它把原本分散在文本中的知识，转化为统一、可连接的结构化表达。
延伸阅读：
三、RDFS：模式表示层
如果只有 RDF，系统虽然能写出事实，但还不够清楚这些事实属于什么结构。
例如，系统也许知道"James Watt --- improved --- steam engine"，但还不知道：
nginx
James Watt 属于 engineer；engineer 是 person 的子类；University of Glasgow 属于 university；improved 通常连接某类人物与某类技术对象。这时，就需要 RDFS（RDF Schema，RDF 架构描述语言）。
RDFS 解决的是：怎样把事实放进类、属性及其层级结构中。
它在 RDF 基础上进一步引入类（class）、属性（property）、子类关系、定义域（domain）和值域（range）等内容，使知识图谱从"事实记录"进一步上升到"模式表达"。
延伸阅读：
四、OWL：本体表示层
RDFS 已经能表示类别和属性结构，但如果系统还要进一步知道：
哪些类之间存在更强的语义关系；
某个属性具有什么逻辑特性；
某些知识在什么条件下可以自动推出；
那么仅有 RDFS 还不够。这时，就需要 OWL（Web Ontology Language，网络本体语言）。
OWL 更接近知识图谱中的本体层。
它的重点不再只是"有哪些类和属性"，而是"这些类和属性还遵守哪些更强的语义规则"。
例如，在更强的语义建模中，系统可以进一步表达：
某两个类别互不重叠；
某个属性具有对称性或传递性；
某个实体只要满足一组条件，就可以归入某一类别。
因此，OWL 的价值不只是"再多写一些类别关系"，而是让知识图谱具有更明确的语义约束和更丰富的推理能力。
延伸阅读：
五、属性图模型
如果前面的 RDF / RDFS / OWL 更偏语义表达和形式化建模，那么属性图（Property Graph）则更偏工程实现。
属性图的基本思想也很直观：
（1）用节点表示实体；
（2）用边表示关系；
（3）让节点和边都可以直接携带属性。
在我们的任务里，属性图可以这样理解：
• 节点：James Watt、steam engine、University of Glasgow、Industrial Revolution
• 边：improved、connected with、associated with
• 属性：birth year、type、period 等
属性图的优势在于建模灵活、遍历方便，很适合图数据库和关系分析任务。它不像 RDF 那样以三元组为统一单位，而是更强调"节点---边---属性"的整体工程结构。
因此，属性图通常更适合图数据库中的查询、遍历和工程开发，而 RDF 更强调语义互操作与形式化表达。
延伸阅读：
六、向量空间表示
前面几种模型主要都属于显式符号表示。但如果系统还要进一步完成：
相似性计算；
链接预测；
知识补全；
与机器学习模型结合；
那么还需要另一种表示方式：向量空间表示（Embedding）。
向量表示的基本思想，是把实体和关系映射到向量空间中。
例如：
nginx
James Watt 可以表示为一个向量；steam engine 可以表示为一个向量；improved 也可以表示为一个向量。这样，知识图谱中的实体和关系就不再只是符号，还变成了一组可计算的数字表示。
这类表示的重点不是直接给人阅读，而是让机器更高效地学习、比较和预测。
需要注意的是，向量表示并不是对前面符号模型的简单替代，而更像是一种面向计算学习的补充表示方式。
在很多实际系统中，显式符号表示与向量表示往往会结合使用。
延伸阅读：
七、表示模型的层次与比较
到这里，可以把这几种模型放在一起看：
RDF 解决：怎样把事实写出来；
RDFS 解决：怎样把事实放入类别和属性结构；
OWL 解决：怎样加入更强语义约束和推理；
属性图解决：怎样以更灵活的方式进行工程建模；
向量表示解决：怎样把知识转成可学习、可计算的形式。
下面这张图可以概括这些表示模型的大致分工：
不同模型解决的是不同层面的问题。
真正的系统往往不是只依赖其中之一，而是根据任务目标，在语义表达、工程实现和计算学习之间做出选择和组合。
延伸阅读：
📘 小结
知识图谱的表示模型各有分工。RDF 负责事实表达，RDFS 负责模式结构，OWL 负责本体约束与推理，属性图偏向工程建模，向量表示偏向计算与学习。真正的知识图谱系统，通常需要根据任务要求，对这些模型进行选择、组合与配合。
"点赞有美意，赞赏是鼓励"