Uche Ogbuji 花了些时间回顾了他所展示的 XML/RDF 技术在更广阔的环境下的相关性。他讨论了 XML/RDF 交换的重要性、专门的 RDF 查询的重要性以及将 RDF 建模中获得的经验教训应用到整个应用程序开发的重要性。他还显示了 Thinking XML 专栏的这条线索与有关语义透明性方面的开发的类似线索之间是如何关联的。
在这一系列文章中，我演示了应用程序中 XML 和 RDF 设施之间用于互操作性的常规技术，侧重于 RDF 交换如何将特性添加到 XML 应用程序以符合语义或者只是为了取得信息建模中更大的灵活性。当总结本系列文章时，我将回顾已经介绍的各种技术，并给出如何将它们应用于其它应用程序开发任务的示例和指南。
跟着我重复：“没有语法”
最初的 RDF 1.0 规范把 RDF 的抽象模型和用于可互操作的表示和交换的 XML 语法结合在一起。我和其他人一样认为这种组合是错误的。除规范设计问题以外，这一绑定让许多人相信 RDF 确实是规范中的语法，例如，要利用 RDF，您必须按那个语法使用 rdf:RDF 作为所有文档中的根元素来编制 XML 文件。这完全错了，我要重申的一个重点就是：为了使用 RDF 并从中获益，您不必使用任何特殊语法 ? 甚至不必使用在 RDF 1.0 规范中指定的语法。
诀窍是从 XML 文档中抽取关键元数据 ? 甚至非标记格式（例如，RDBMS）? 然后将它同步成为 RDF 模型。然后您可以将这些模型视为本地化的语义 Web。例如，您可以将下列内容结合在一起：一个数据源中的个人联系信息 来自另一个来源的待办事项和日程安排 要建立信任的公钥基础结构元数据 字典列表和其它语义数据
这种信息的高度集成会造成其它不实用的特性并创建附加值填补 XML 和 RDF 模型之间流量的工作。
我所演示的将 XML 转换成 RDF 语法的 XSLT 转换（唯一目的是可互操作导入到 RDF 模型）是完成 XML/RDF 交换的一种方法。某些 RDF 工具可以为您管理这种交换。例如，您可以使用 4Suite 工具定义映射规则，而不必处理 RDF 语法。
在我的样本问题跟踪器应用程序中，虽然可以毫不费力地使用 RDF 将象语意搜索这样的高级特性结合进来，我仍使用 XML/RDF 映射以最自然的形式产生和交换应用数据。在本专栏的另一条线索（请参阅 参考资料）中，我介绍了几个电子商务字典资源；在利用这些资源的应用程序中，您可以使用 XML/RDF 映射导入如下资源：RosettaNet 字典 ISO 基本语义注册表（RDF 形式的注册表已经可用） DISA 格式的美国政府模式库
在统一的 RDF 模型中，这些资源可以与各种本地或其它全球数据集进行丰富的链接以用于统一的查询和自主代理处理。
Software AG 的 William Ruh 在最近的一次 XML Web Services One 会议上所作的会议主题演讲中指出，目前在创建 XML 格式的实体方法（ontologies）上人们花费了巨大的努力。实体方法是以结构化格式定义术语和概念的文档，并因此提供了语义数据库。Ruh 先生指出这种原始 XML 资料与 RDF 技术的结合将导致可实用的语义 Web。
查询的艺术
我还演示了查询 RDF 模型的一种很低级的方法。作为常规图的 RDF 模式需要专门的查询工具，这些工具可以逐个或以整体方式遍历图和弧。这与旧的层次型数据库的散列法和搜索树技术、关系数据库的表扫描以及对象数据库的属性汇总和关系遍历都是不同的。事实上，RDF 查询与后者最类似：对象关系被构造成抽象图，但区别是对象理论已经提供了支撑其弧和接点的许多语义。RDF 不提供任何这样的语义（RDF Schema 和 DAML+OIL 是位于 RDF 上的系统示例，这些系统确实提供某些结构和语义，但即使这样也比对象理论更加通用）。
我还介绍了 RDF 的一种比较高级的查询语言：Versa。这种语言通过可以集成到其它语言（例如，XML 处理语言）的特性处理图遍历以及属性聚集。诸如 Squish 和 CWM（请参阅 参考资料）之类的其它比较高级的 RDF 查询语言侧重于类似 SQL 的习惯用法和逻辑推断。某些 XQuery 拥护者建议：可以根据 XML/RDF 序列化或者从原始 XML（如果使用 XML/RDF 映射）将 XQuery 用于元数据查询。这一思想的主要问题是最通用的 XQuery 实现也不太可能为 RDF 中需要的查询模式种类而进行优化。如果您想使用一种专门的查询引擎，则还可能要使用适合于这种专门性的语法和语义（例如，RDF）。
选择 RDF 查询机制时要考虑的另一个问题是数据是如何分布的。到目前为止，本系列文章中的许多讨论都是适合封闭模型和单一类型数据库的，但 RDF 的某些能力在分布式系统中最为明显。例如，RDF 可以成为汇总多个内部网页面元数据的一种非常有用的工具，或者用于开销不大的应用程序集成。在这些情况下，您需要一种查询系统，该系统可以存储和转发部分结果、有效地形成子查询并处理冲突和矛盾。这些工具对于许多代理技术（例如搜索引擎 Web 搜寻器 (crawler)）已经很常见，而且可以被覆盖到基本 RDF 查询系统上。
下一代分析和设计
信息建模的教训甚至可能比我已经提到的 XML 映射或查询实现的详细信息更加重要。包括与实体有关的建模和统一建模过程（Unified Modeling Process）在内的用于应用程序开发的所有公共方法所期望的是实现，而不是退回到构成近似于实现的问题空间的基本概念。在许多情况下，这构成了软件的维护和集成巨大代价的很大部分。两个不同的软件包 ? 例如，人力资源数据库和内容管理包 ? 可能有相同的 雇员含义，但事实上在两个包中，如何对雇员数据的结构处理进行建模和实现几乎总是不同。约束和规则不同。表示和包含的数据也不同。如果您需要连接这两个应用程序，则这些差别可能阻挠您的努力，并且在许多情况下使它在经济上不可行。
对象管理组织（Object Management Group (OMG)）是负责许多对象（Object）设计规范（包括 CORBA 和 UML）的组织，它已经表示对这个问题有所理解。OMG 正在进行一场根本的转变，即，从根据平台无关性在系统中开展开发实践（CORBA 和 UML）到基于完全抽象的模型（这些模型代表组织内、行业内甚或全球的概念）开展开发。这种模型可能很象那种实体方法，但由于某些原因（可能期望强化其工作产品的吸引力），OMG 选择了推动 UML 作为抽象模型的语言和表示。这里的问题是 UML 偏重于实现。如 OMG 自己在其对 UML 介绍中所说的：
您可以使用 UML 对几乎任何类型的应用程序建模，这些应用程序可以在任何类型的硬件、操作系统、编程语言和网络及其组合上运行。它的灵活性让您能对几乎使用市场上的任何中间件的分布式应用程序建模。因为 UML 建立在将类和操作定义成基本概念的 MOF [Meta-Object Facility] 元模型基础上，所以它很自然地适合面向对象的语言和环境（例如 C++、Java [语言]和最新的 C#），但您也可以使用它对非面向对象的应用程序（例如，Fortran、VB 或 COBOL）建模。
最后，这个 OMG 描述否认其专门用于面向对象的设计，其本身也是有争议的免责声明。但即使有人同意这一点，也正是这个能配合应用程序开发的 UML 的宣传强调了余留问题。XML 的一个胜利是其扩展能力使开发人员的世界观超越应用程序开发的狭窄界限。最初，这种扩展能力表现为集成从 SGML 继承的传统面向文档处理的思路和模式的形式。最近 ? 尤其随着 XML 以 Web 服务方式闯入分布式编程领域 ? 更多开发人员对无状态信息处理模型的工作原理有了基本了解。
为了确定如何从 OMG 和 RDF 这两个领域最大程度地获益来为应用程序开发提供更利于可维护性的基础，从事 OMG 的人们和从事 RDF／实体方法研究的人们之间的相互联系正在增长。以 RDF 建模将您的视野扩展到诸如类和类型这种规范化概念的更广的联系上来。这是通向下一代建模之途上的一个重要里程碑。现在，实体方法与传统分析与设计的集成已经给了早期采用者明显的回报，即，更短的开发周期、改进的维护和集成以及推动所得到的应用程序的知识库中的新价值。遗憾的是，这类先驱者同样经历了许多不足：编程工具还不支持实体方法，实体方法工具（就象现在这样）还不支持传统的编程。要成功使用这种混合方法需要经验丰富的开发人员和良好的企业氛围。遗憾的是在大多数 IT 组织中，这两种资产都非常缺乏。
重点是：如果项目将信息建模放在首位，则它们有更好的机会使应用程序与现实世界保持同步。将信息建模放在首位意味着使用要建模的关键概念的正式描述和期望行为，并在开发周期开始初期使用一般数据表示工具（例如 XML 和 RDF 模式）来开展项目。并且只有当您很好地定义了抽象模型时，它才能被用来生成构成应用程序设计编程方面的结果构件。
下一步，技术更新
在软件建模和实体方法社区中有许多幕后工作。这种交换似乎必然导致我们开发应用程序方式的根本改变。现在要做的是以现有良好建立的工具的扩展形式连接这两个领域。我已经以称为 清洁建模方法（Clean Modeling Methodology）的形式使用这类工具开始实验了。清洁建模方法一开始就使用清除了所有实现考虑的模型，然后帮助开发人员生成接口和其它设计构件。还有许多人研究连接 UML 和 RDF 技术的工具，并建立了 XMI，虽然它是连接 UML 和 XML 的不太好用的工具。
下一篇文章将总结“知识管理的基本 XML 和 RDF 技术”系列文章，其中，我将展示问题跟踪器应用程序的统一实现，包括查询方法和模式的更新。
