在这篇文章中，Capgemini 的知识图谱负责人 Veronika Heimsbakk 分享了她为客户创建语义知识模型的方法。阅读本指南，了解她如何与客户合作，从头开始构建语义知识模型，并发现可以应用于您自己的语义建模项目的实践。
如何为客户构建语义知识模型
在参加 2024 年知识图谱大会时，我与 metaphacts 的创始人兼首席科学官 Peter Haase 一起参加了一个关于本体及其建模的讨论小组。之后，metaphacts 邀请我为他们的博客撰稿，详细阐述我的语义建模方法。在这里，我将重点介绍我与客户合作创建语义知识图谱时通常遵循的步骤。
值得一提的是，我没有遵循某一种特定的本体建模方法，而是基于不同的方法，因为客户的成熟度和需求各不相同。这篇博客文章将描述我日常工作的基本步骤和构建模块，不过，我在 Capgemini 的同事可能会有不同的方法。
目录
• 先决条件：在开始语义建模之前
• 与客户的初步活动
• 绘制初步概念
• 开始自己的建模过程
• 发现对公理和/或约束的需求
• 使用实例填充
• 回到起点
先决条件：在开始语义建模之前
在开始实际的信息建模之前，有几件事需要先搞清楚。这些步骤可以与客户一起完成，也可以由客户自行提供这些信息。在此，我假设用例和/或用户故事已经确定。
1. 确定范围
2. 确定信息来源
3. 时间框架和里程碑
确定范围
您的客户需要确定知识图谱将服务的范围。发现一个足够小且具有足够高价值的范围，以展示知识图谱能够为其用例带来的奇迹，这是一门科学。然而，由于知识图谱是一个动态模型，具有易于扩展的特性，开始的范围可以非常小。
假设用例是为咨询公司创建一个简历和项目的门户，那么一个起始范围可以是来自某个特定部门的所有员工和项目，之后可以逐步添加更多部门。在此阶段，您还需要开始考虑粒度问题。知识图谱是数据的原子分解，但对于您的特定项目，您真正需要的粒度级别是多少？保持简单。在本体开发过程中，这个粒度问题会多次出现。
确定信息来源
接下来，您需要了解有哪些信息来源，以及它们的形式。我们是否可以访问这些信息？是否需要考虑第三方来源？信息来源差异很大。它们可以是 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 形状描述中。
[图片：水电站的分类公理示例，然后根据最大输出将个体分类到其适当的组。]
使用实例填充
对于大多数用例，客户希望使用本体来推动数据驱动的决策、分析和洞察。在这些情况下，填充实例数据（个体）到知识图谱中的需求变得明显。
在这种情况下，您不会想手动添加这些实例。市场上有许多映射工具可供选择，或者您可以使用 RDF 编程框架根据本体映射个体。
回到起点
一旦图谱包含了个体及其属性和关系，再加上知识层（即本体），您就拥有了一个 知识图谱。您可以根据已建立的核心问题开始测试和评估。
如前所述，大多数核心问题都可以轻松转换为 SPARQL 查询，这使得回答它们变得容易。将您的答案（最好通过知识图谱可视化工具可视化）带回客户，与他们一起评估质量和准确性。我们找到了我们想要的东西吗？是否获得了新的洞察？我们是否遗漏了什么？客户数据中是否存在不一致？
