从零开始，她如何为客户创建语义知识图谱？

在这篇文章中，Capgemini 的知识图谱负责人 Veronika Heimsbakk 分享了她为客户创建语义知识模型的方法。阅读本指南，了解她如何与客户合作，从头开始构建语义知识模型，并发现可以应用于您自己的语义建模项目的实践。

如何为客户构建语义知识模型

在参加 2024 年知识图谱大会时，我与 metaphacts 的创始人兼首席科学官 Peter Haase 一起参加了一个关于本体及其建模的讨论小组。之后，metaphacts 邀请我为他们的博客撰稿，详细阐述我的语义建模方法。在这里，我将重点介绍我与客户合作创建语义知识图谱时通常遵循的步骤。

值得一提的是，我没有遵循某一种特定的本体建模方法，而是基于不同的方法，因为客户的成熟度和需求各不相同。这篇博客文章将描述我日常工作的基本步骤和构建模块，不过，我在 Capgemini 的同事可能会有不同的方法。

先决条件：在开始语义建模之前

在开始实际的信息建模之前，有几件事需要先搞清楚。这些步骤可以与客户一起完成，也可以由客户自行提供这些信息。在此，我假设用例和/或用户故事已经确定。

1. 确定范围
1. 确定信息来源
1. 时间框架和里程碑

确定范围

您的客户需要确定知识图谱将服务的范围。发现一个足够小且具有足够高价值的范围，以展示知识图谱能够为其用例带来的奇迹，这是一门科学。然而，由于知识图谱是一个动态模型，具有易于扩展的特性，开始的范围可以非常小。

假设用例是为咨询公司创建一个简历和项目的门户，那么一个起始范围可以是来自某个特定部门的所有员工和项目，之后可以逐步添加更多部门。在此阶段，您还需要开始考虑粒度问题。知识图谱是数据的原子分解，但对于您的特定项目，您真正需要的粒度级别是多少？保持简单。在本体开发过程中，这个粒度问题会多次出现。

确定信息来源

接下来，您需要了解有哪些信息来源，以及它们的形式。我们是否可以访问这些信息？是否需要考虑第三方来源？信息来源差异很大。它们可以是 Word 文件、Excel 表格、SQL 数据库、数据流、PDF 文件、JSON API，几乎任何类型的文件都可以。作为知识工程师，您必须为处理非结构化数据、混乱数据、低质量数据做好准备。我们的工作是解析、转换，并在客户的数据中创建秩序和完整性。

时间框架和里程碑

与您的客户一起，规划所需的里程碑，并将它们绘制在项目的时间线上。本体建模是一个迭代的工作，需要与客户领域专家密切合作，以建立语义知识层，即本体所服务的层。在确定范围时，必须考虑到可用的时间。一个为期 8-20 周的最小可行产品（MVP）或概念验证（PoC）将有不同的里程碑和阶段，与一个全面的项目相比。

与客户的初步活动

在您独自一人，沉浸在您最喜欢的建模工具中并映射所有那些混乱的数据之前，您需要与客户一起完成一些活动。这些活动将帮助并在整个过程中为您提供指导。

核心问题

在先决条件就位后，您可以开始定义一系列核心问题。这些是您希望通过本体回答的自然语言问题。它们通常可以很好地转换为 SPARQL 查询，以便稍后测试知识图谱。核心问题列表将作为建模过程中的有用指南，并在测试知识图谱时非常有帮助。

回到我们之前的例子，一些核心问题可能是：“Lisa 在过去三年中参与了多少个 Azure 项目？”、“我们有多少 PRINCE2 认证的高级架构师？”、“我们需要所有与 AWS 相关项目的 KPI 统计数据。”，等等。问题越多越好！

找到这些问题是与客户一起进行的活动。

绘制初步概念

这是我在这份工作中最喜欢的活动之一——从客户的头脑中挖掘知识，并一起将其绘制在纸上！我通常将这个活动安排为一个 2-4 小时的研讨会，所用的工具是 A3 纸和一盒彩色铅笔。

我们从用例开始。它包含什么？有哪些概念，它们的含义是什么？这个概念是否与其他概念有关系？它是否包含“子概念”？

您的工作是提出那些看似愚蠢的问题，以便将客户的知识从他们的脑海中挖掘出来并记录在纸上。如果一开始有些困难，您可以让客户将相关词语写在便利贴上，按类别分组，然后开始绘制。

开始自己的建模过程

现在是时候开始实际的建模工作了。此时，您手中已经有了几种有用的工具：绘图、核心问题和信息来源。

接下来，您可以选择不同的方法来开始这阶段的工作。

• 可能某些信息来源包含机器可读的模式或类似的内容，您可以将其解析为 RDF 以获取一个初始框架。
• 可能您的客户已经熟悉 RDF，并希望参与工作。在这种情况下，建立一个协作基础设施非常重要。作为知识工程师，您需要了解供应商的生态系统，以便为客户做出最佳的工具和数据库推荐，以满足他们的需求。
• 也可能您几乎没有任何可参考的材料，除了通过先决条件和绘图研讨会收集到的线索。

无论哪种情况，本体都会逐渐成形。

考虑已建立的本体

网上有很多可用且维护良好的本体，等待您为客户用例复用它们的知识。是否有任何外部本体或词汇表可以为您的客户用例使用？

我与公共部门的客户合作较多。在挪威，我们有自己的国家数据目录，它基于 DCAT-AP-NO、SKOS-AP-NO 以及相关的 RDF 规范。在大多数项目中，我会重用这些 RDF 资源来描述客户的知识。

发现对公理和/或约束的需求

在某些情况下，可能需要推理功能。我最常遇到的是实体分类推理，但在少数情况下，我也遇到过基于各种指标的实体排列或组合推理。如果确实需要为推理目的描述公理和限制，请确保您有一个允许您这样做的工具。尽管我并不总是在本体中需要公理，但我倾向于为所有本体利用 RDFS 推理。这是为了确保本体的语义与实例数据的预期相符，并避免模型构建方式带来的意外结果。

然而，SHACL 形状的约束需求在当今更为常见。我认为，在封闭世界假设下验证数据通常比开放世界假设更接近现实情况。但我仍然会分别建模本体和形状，通常先建模本体，然后将这些 RDF 资源复用到 SHACL 形状描述中。