是否可以并且应该使用本体来生成数据转换器的代码？

时间：2017-01-03 12:24:11

标签： architecture code-generation database-schema ontology data-exchange

鉴于三个主要竞争应用程序各自为同一问题域实现略有不同的数据模式，我面临着实施的任务：

  1. a＆＃34;规范＆＃34;数据模式足以表示类似于所有3个应用程序的交集特征以及其他详细信息（元数据）
  2. 用于在这3个应用程序和规范架构之间进行（双向）数据交换的转换器

    3. 我目前如何处理任务

    使用XSD定义规范模式，并且非常类似于3个应用程序之一的数据模式，我们将其称为A.这使得与A平凡的数据交换。为了允许与应用程序B和C进行双向数据交换（在A中创建一些状态，将其加载到B中，在B中更改它，将更改后的状态加载到A中），我尝试将A中的简单状态映射到更复杂的B / C中的状态，可以在反向映射中识别和解构。

      

    示例：在A中，对象可以简单地镜像＆＃34;作为内在的几何   在B和C中进行转换时，我们必须引入一个＆＃34;镜像   子空间＆＃34;其中嵌入了相应的对象。这＆＃34;镜像   子空间＆＃34;也可用于A.因此，在转换B-> A期间，我们有   决定一个＆＃34;镜像子空间＆＃34;发现数据必须   映射到＆＃34;镜像子空间＆＃34;在A或如果它将被替换   对象的内在几何变换。我现在这样做   这通过特别标记那些＆＃34;镜像子空间＆＃34;这只是   在转换A-> B期间引入。

    为什么我要改变我的方法

    • 大多数模式映射都非常简单（A中的对象名称只是映射到B中对象的名称），所以我想避免手工编写很多简单的代码。我想这个简单的代码可以在数据方案之间进行形式化映射的情况下生成。
    • 对于映射的重要部分（如上面所描述的部分），我预计未来会发生很多变化，因为它看起来很随意。在许多情况下，将A中的状态映射到B / C中更复杂状态的特定约定可能会在某个时刻陷入死胡同。例如，用户可能需要更改＆＃34;镜像子空间＆＃34;标签，因此可能需要另一种识别转换工件的方法。我认为形式化的映射可以成为透明地管理这些约定的工具。也许推理者甚至可以自动发现不连贯，不一致的映射。它还可以让我更轻松地与领域专家和用户讨论映射。

    问题

    • 从我读到的关于本体的内容来看，我的印象是我想要的是一个本体论。它是否正确？
    • 据我了解，使用本体描述映射还需要我在本体中表达数据方案本身（因此关系＆＃34;映射到＆＃34;可以引用A和类型中的类型来自B）。由于这些方案来自长期存在的应用程序，因此它们并不总是一致的。例如，＆＃34;功能＆＃34;在应用程序中可能会导致某些状态具有与其组成部分的语义相同的语义。现有工具可以帮助我管理这些复杂性吗？
    • 我希望我在本体中需要一些额外的机制来描述像上面例子中的-taken这样的东西 - ＆＃34;永久镜像子空间＆＃34;和＃34;消散镜像子空间＆＃34; （两种类型+重新连接它们的特殊关系？）。这需要做很多努力吗？可用的本体语言提供了开箱即用的表达方式吗？
    • 本体的这种应用是本体的常见应用还是一个极端的案例？您是否知道为此应用程序提供服务的公司？
    • 您建议使用哪些工具来创建本体？我假设没有现成的代码生成工具可供使用。那么你将如何处理代码生成任务？

1 个答案:

答案 0 :(得分：2)

抽象类型系统，一组接口和转换规则被定义为本体创建的子集，称为元模型。元对象工具（MOF）就是一个例子：

Meta-Object Facility (MOF) Diagram

  

MOF接口和MOF模型可用于定义特定的元模型   用于数据库，数据仓库，模型转换和仓库管理   域

     

MOF的IDL   转换功能将单个类映射到两个接口。有可能   定义转换到备用接口表示，例如Java接口。

     

行业领导者对于类，类型和接口概念的定义存在并且可能永远存在不同观点。作为一个领域特定的建模环境，只要MOF明确了MOF中Class的含义，它就应该不受这些关注的影响。

主题地图是另一个：

  

将知识提取到一个独立的层，并在该知识层启用处理，并将反馈循环返回到源，这似乎不是最直接和有效的方法。此过程可与作者坚持使用Word的发布工作流程相媲美，但发布者需要XML。往返两种格式之间的转换效率不高，但有时是必要的。此外，这种间接层正是为我们提供了以一种可以随时间保留的方式处理知识的能力和自由，无论源信息发生什么，更具体地说，用于处理的系统。为描述信息，键入主题，创建关系，管理多语言等效而完成的所有工作仍然有效。由于它是独立管理的，因此升级系统只是意味着与旧系统断开连接并重新连接到新系统。

     

与Topic Maps合作20多年来所汲取的经验教训是对比的：由于技术进步的快速发展，我们已经被信息技术的成功所淹没。寻找下一个重大事件已经掩盖了我们思考我们正在做的事情的基本性质的能力。信任，可靠性，高质量内容的概念仍然是我们企业长期成功的关键。我们需要适应我们所处理信息的方式不断变化的本质。这只是一个开始。当我们创建主题地图标准时，我们创建了一个没有问题的解决方案：跨组织合并知识网络的可能性。尽管在这个方向上有许多期望和许多努力，但这并没有证明可以满足用户的足够需求。但我们也开发了信息源和知识管理层之间的独立性概念。这可能会成为长期存在的问题，即使这个想法曾经以主题地图的名义出现这一事实可能会被遗忘。

<强>参考

相关问题
最新问题