连接知识图谱与人工智能开发：将本体与领域对象连接的5个策略

导言：两个世界的挑战

在现代软件开发中实现图数据库时，我们经常面临一个重大挑战：弥合以本体为中心的知识表示与面向对象编程范式之间的概念差距。知识工程师和领域专家从语义关系和灵活的属性图的角度思考，而软件开发人员则在面向对象模型和固定数据结构的约束下运作。

当本体论者向工程团队展示图模型时，这种脱节会产生摩擦。图数据丰富的、灵活的特性——无论是表示为 RDF 三元组还是标记属性图——都需要解释和转换，才能在传统的软件架构中得到正确实现。

本体论与关系数据模型

传统的软件工程严重依赖具有固定模式的关系数据库，其中：

• 表具有预定义的列
• 外键建立严格的关系
• 数据的形状是“刻在石头上”的，灵活性有限

这种固定特性使得关系数据库与对象关系映射 (ORM) 系统自然兼容，ORM 系统将数据库表映射到代码中的数据传输对象。

相比之下，图数据库提供：

• 灵活的属性结构
• 实体之间的动态关系
• 对复杂、互连的数据模式进行建模的能力
• 丰富的语义表达能力

这种灵活性虽然对知识表示很有用，但在过渡到面向对象的代码库时会带来实现挑战。

灵活性的挑战

图数据库提供了强大的建模能力，但这种灵活性在与传统软件模式集成时可能会变得有问题。一个图可以用多种方式表示相同的概念或事件，具有不同的形状、属性和关系模式。

例如，在图中对复杂事件进行建模时，您可能具有：

• 各种类型的参与者实体
• 多个时间关系
• 不同的因果关系
• 分布在节点上的上下文属性

这种灵活性使得在子图和代码中的具体对象类型之间创建一致的映射变得困难。问题变成：我们如何将这些灵活的、语义丰富的子图转换为开发人员可以有效使用的结构化域对象？

图到对象映射 (GOM)

类似于关系数据库中的对象关系映射 (ORM)，图到对象映射 (GOM) 旨在弥合图数据和面向对象编程之间的差距。该领域已经出现了一些项目，包括 Loop，它专门解决了这一映射挑战。

GOM 过程包括：

1. 节点映射：将具有其属性的各个节点转换为相应的对象结构——相对直接。
2. 关系映射：将图关系表示为对象引用、集合或嵌套结构的更复杂的挑战。
3. 子图模式化：识别图中代表连贯域概念的常见模式，并将这些模式映射到聚合对象结构。

对于具有有限关系类型的简单本体，映射可以更直接。但是，在处理丰富的本体关系时——例如事件之间的时间连接、因果关系或上下文关联——映射变得越来越复杂，并且通常无法完全自动化。

Neo4J 为此提供了一些库

https://neo4j.com/docs/ogm-manual/current/tutorial/

同样对于 RDF，我们有

[## KOMMA: RDF Object Mapper

#### IEntityManager em; Person john = em.createNamed(URIs.create(), Person.class); Person jane = em.find(URIs.create()…

komma.enilink.net](https://komma.enilink.net/docs/)

图对象集成的实用方法

框架

框架和面向框架的本体的旧概念比经典的 OWL 本体功能要有限得多，但与面向对象设计和对象配合得很好。因此，如果您真的可以遵循更多基于框架的方法，那么您已经成功了一半，可以更好地进行对象映射，但它可能对您的任务和本体论目标来说过于有限

属性图

LPG 的概念更接近于对象和域驱动设计，并且可以与可嵌入的框架很好地结合，就像我们之前提到的那样。我们应该意识到，LPG 通常在本体论工具方面面临挑战。我仍在寻找一种语言和标准，它允许我以与 OWL 对 RDF 相同的方式处理 LPG 和本体论

将本体构建与映射分开

一个关键的建议是将本体开发和对象映射视为不同的过程：

1. 首先，专注于构建语义丰富且准确的本体模型
2. 然后，根据特定的用例设计到域对象的映射

这种分离提供了更大的灵活性，并防止损害本体论的清晰度或软件设计。

JSON-LD 作为桥梁

对于 TypeScript 和 JavaScript 环境，JSON-LD（用于链接数据的 JavaScript 对象表示法）提供了一个引人注目的折衷方案。 JSON-LD 允许开发人员：

• 将整个子图表示为 JSON 框架
• 将语义三元组嵌入到熟悉​​的文档结构中
• 保持语义含义，同时提供开发人员可以直观使用的对象

这种方法使得可以将复杂的图模式实例化为文档，这些文档保留了它们的语义关系，同时符合开发人员熟悉的对象模式。

https://www.baeldung.com/json-linked-data

我们也可以将复杂的子图映射为 JSON-LD 框架和框架数据

[## JSON-LD Framing - Triply Documentation

#### The official documentation for the Triply products: TriplyDB, TriplyDB.js, and TriplyETL.

docs.triply.cc](https://docs.triply.cc/generics/JSON-LD-frames/)

固定类型的危险

习惯于使用现代 ORM 的应用程序开发人员倾向于创建固定的 DTO 和直接映射。它与关系数据库配合得很好，但可能导致图数据库中出现严重问题，因为图数据库具有更丰富的功能来对关系进行建模。固定类型可能会强制固定子图模式，并将图简化为更类似关系型的存储。因此，最好更多地关注用例和可能的变量

用例驱动的映射

与其试图在所有图组件和对象之间创建通用映射，不如专注于特定的用例：

1. 确定特定应用程序功能所需的常见子图模式
2. 创建代表这些模式的目标域对象
3. 为这些特定场景开发自定义映射逻辑

这种方法承认您的应用程序的不同部分可能需要对相同的底层图数据使用不同的表示形式。

结论：寻求平衡

从本体到领域对象的旅程需要在语义丰富性和实现实用性之间找到平衡。通过：

• 首先关注本体设计
• 确定特定的用例及其数据需求
• 在图模式和领域对象之间创建有针对性的映射

我们可以弥合知识图谱和应用程序开发之间的差距，使团队能够从本体的丰富表现力中受益，同时保持高效软件开发所需的结构和可预测性。

这种方法使组织能够维护语义丰富的知识表示，同时为软件工程师提供构建有效应用程序所需的具体、结构化的领域对象。