给定三个主要的竞争应用程序，每个应用程序都为同一个问题域实现了稍微不同的数据模式，我面临着实现的任务：
- 一个“规范”的数据模式，其表达能力足以表示所有 3 个应用程序的特征的交集以及其他细节（元数据）
- 用于在这 3 个应用程序和规范模式之间进行（双向）数据交换的转换器
我目前如何处理任务
规范模式是使用 XSD 定义的，并且非常类似于 3 个应用程序之一的数据模式，我们称之为 A。这使得与 A 的数据交换变得微不足道。为了允许与应用程序 B 和 C 进行双向数据交换（在 A 中创建一些状态，将其加载到 B，在 B 中更改它，将更改后的状态加载到 A），我尝试将 A 中的简单状态映射到更复杂的状态B / C中的状态可以在反向映射中识别和解构。
示例：在 A 中，对象可以简单地“镜像”为固有的几何变换，而在 B 和 C 中，我们必须引入一个“镜像子空间”，其中嵌入了相应的对象。这个“镜像子空间”在 A 中也可用。因此在转换 B->A 期间，我们必须决定是否必须将在数据中找到的“镜像子空间”映射到 A 中的“镜像子空间”，或者是否应该映射到 A 中的“镜像子空间”。由对象的固有几何变换代替。我目前通过专门标记那些仅在转换 A->B 期间引入的“镜像子空间”来做到这一点。
为什么我想改变我的方法
- 大多数模式映射都很琐碎（A 中的对象名称简单地映射到 B 中的对象名称），所以我想避免手动编写大量琐碎的代码。我想这个简单的代码可以在给定数据方案之间的正式映射的情况下生成。
- 对于映射的重要部分（如上面描述的部分），我预计未来会有很多变化，仅仅是因为它看起来很随意。在许多情况下，将 A 中的状态映射到 B/C 中更复杂的状态的特定约定可能会在某些时候陷入死胡同。例如，用户可能需要更改“镜像子空间”标签，因此可能需要另一种识别转换工件的方法。我想，形式化的映射可以成为透明地管理这些约定的工具。也许推理者甚至可以自动发现不连贯、不一致的映射。它还可以让我更轻松地与领域专家和用户讨论映射。
问题
- 从我读到的关于本体的内容中，我的印象是我想要的是一个本体。这个对吗？
- 据我了解，使用本体来描述映射还需要我在本体中表达数据方案本身（因此“映射到”的关系可以引用 A 中的类型和 B 中的类型）。由于这些方案取自长期应用程序，因此它们并不总是连贯的。例如，应用程序中的“特性”可能会导致某些状态具有不同的语义，这与您期望从其组成部分的语义不同。现有工具可以帮助我管理这些复杂性吗？
- 我希望在本体内部需要一些额外的机制来描述类似的东西——从上面的例子中得到——“永久镜像子空间”和“消散镜像子空间”之间的区别（两种类型 + 重新连接它们的特殊关系？） . 这样做会很费劲吗？可用的本体语言是否提供了一些开箱即用的东西来表达这一点？
- 本体的这种应用是本体的常见应用还是一个极端案例？你知道为这个应用程序提供服务的公司吗？
- 您建议使用哪些工具来创建本体？我假设没有可用于上述代码生成的现成工具。那么您将如何处理代码生成任务呢？
