大规模数据集成: 使用 RDF 创建数据网络

在现代世界，软件的基本用途之一就是生产和使用数据。以下是一项简单的任务：创建数据模型或模式，将其映射到一个对象模型，并以外部化格式序列化数据，将它发送给共享您的上下文的某个接收方。但是在协调多个合作伙伴和环境时，这样做会让软件生产商面临更困难的任务。因此，显而易见，我们倾向于只是为了投资回报而提交集成项目。错失机会和系统效率低下可能会增加没有正确连接数据源而导致的机会成本。

大规模数据集成并不只是一个技术问题，它还是一个社会问题。要交换信息，我们必须在交换信息意味着什么方面达成共识——再次声明，小型的点对点交互很容易实现，请想象一下更高层次的复杂交换。我们遇到了文化、语言学、心理学、认知和政治方面的障碍。不断更改的需求会让优先考虑事项也发生变化，在动态领域，希望与更多的合作伙伴进行协作会让局势变得更加不稳定。在一个脆弱的世界里，实时快照技术（比如关系数据库模式、XML 模式和现有的代码库）让这种不稳定放大到了几乎无法控制。我们需要长时间维护域元素名称、域元素形状和各种关系方面的协议，在发生任何变化之前交付软件。

我们需要在现代商业的混乱漩涡中达成共识的主要原因是由于 软件问题 造成这的，或者是为了认清在可预测的时间很难生产高质量的软件的事实。这些需求很少得到应有的重视。借助关系表模式中隐式和显式表达的域模型、对象关系映射 (ORM) 文件、代码库和服务描述，我们能够推出新的功能或修复缺陷，而这些又因为过分依赖生命周期而受到了阻碍。所以我们使用了规模越来越庞大的团队，预算也在不断增加，这需要政治影响力，而政治影响力很难改变或重新调整。我们制定了主数据管理 (MDM) 计划并创建了企业数据仓库 (EDW)，试图统一、标准化和控制对域的集体认识，以便促进信息交流。

。我们需要使用来自数十个合作伙伴的组合工具和本地实现来管理需求、软件工件、缺陷跟踪和系统变更。域的某些方面可能会跨越这些领域，但每个方面也是更大问题的一个单独的垂直部分。在所有利益相关者之间达成关于如何指定所有域元素的所有细节的共识是永远不可能的。

本系列文章解释了如何以有用的新方法解决大规模数据集成问题。本系列文章将逐步关注软件生命周期域中的一个令人兴奋的方法： 开放式生命周期协作服务 (OSLC) 计划。OSLC 基于 Representational State Transfer (REST) 体系结构样式和语义 Web 技术，比如 资源描述框架 (RDF) 和 关联数据平台 (LDP)。本文章系列的前三部分将介绍 OSLC 的技术基础。在最后的两个部分中，我将向您介绍 OSLC 项目和演示它的应用。

Web：相互关联文档的一个可扩展平台

Web 基于一些众所周知的技术，这些技术是在一个文档相互关联、灵活可伸缩的平台上一起协同工作的。从头开始设计 Web 已经几乎不可能。但我们设计了一组标准，旨在解决 Web 上的具体问题，让这个神奇的生态系统不断进化和发展。

我们要介绍的第一项技术是统一资源定位符 (URL)。这个命名方案（目前基于统一资源标识符 (URI) 规范）有两项任务：识别全球信息空间中的任意内容；充当句柄，我们可以通过该句柄来请求此内容。我们通过在电子邮件、微博、维基、电视广告、公交车广告、甚至是餐巾上共享这些标识符，与世界共享文档和内容。因为标识符基于我们控制的域名，所以我们能够很好地把握中央调解和边缘自由之间的平衡。由于标识符是全球范围的，但通常被绑定到特定的域，所以可以共享它们而不必担心发生冲突。我不能在您控制的域中创建标识符，反之亦然，但我可以在我自己的域中创建我希望的任意数量的标识符。尽管我们鼓励用良好的 URL 设计提供稳定性、较长的使用寿命和灵活性，但我仍然可以选择任何名称，和大家一起共享即席协作。

尽管我们通常会看到附加到文档或 Web 应用程序中的 URL，但 REST 架构使得它们也适用于任意的信息资源。我们可以通过标识符 http://example.com/account/id/12345 或某个产品（比如 http://example.com/product/id/sku/9823423）来提到某个帐户。实际上，我们正在表示几乎无限的信息空间中的任意信息。

为了访问资源的状态，或者以某种方式与之交互，我们可以采用下一个有用的 Web 技术：HTTP。HTTP 为任何人以任何方式产生的任何资源提供了一个统一接口。作为信息客户，我不知道资源实现方式的细节，也不关心这一点。如果我向资源发出一个 GET 请求，就会返回一个默认的表示。如果我想获得不同形式的资源，那么我可以试着问问服务器是否能够为我提供这种形式。

使 Web 正常运作的最后一项主要技术是 HTML，这通常是 Web 资源返回到浏览器客户端所采用的形式。HTML 提供了所请求资源的表示，以及我可以在资源的当前状态下执行的所有操作。我可以跟随某个链接到达另一个文档，建立一个经过验证的会话：进行登录，并通过表单提供适当的证书，等等。此系统中的耦合关系是发生在浏览器与返回的表示之间，而不是在浏览器与服务器之间。服务器可以重新定位资源，更改实现技术，而浏览器客户端在下次请求一个资源时将会愉快地继续工作。客户端了解在哪里可以找到内容，还了解用户可以用这些内容来做什么，从表示中了解这些内容——而不是因为它知道某些关于服务器的信息。

Web 已被大部分人广泛理解，甚至是非技术人员。稍微有点不同的想法只是少数，相同的想法可应用于更广泛的信息。在这个过程中，组织可以降低数据集成成本，增加重用的机会。他们可以采用各种方式灵活地连接到数据源，创造获得更大金融利益的新机会。

回页首

信息互联网络的 RDF

一旦我们采用跳跃式思维考虑将可解析的标识符分配给任意信息，我们就可以开始想象互联的信息网络。我们想介绍一篇文章，该文章的主题是日本国家，作者是 Bob。我们可以想象所有资源的所有相关性，用它们来表达相关的事实和内容。人们前往学校学习，为某些企业工作，他们出生在世界的某个地方，有着家人、宠物、各种兴趣和朋友。我们希望能够 “混合（intertwingle）”（ Ted Nelson 的术语）所有这些东西。我们需要的是一个灵活的数据结构，并且让所有这些事情不会发生冲突。

URI 标准已经使我们能够将任意全局标识符分配给任何东西。现在我们想对 概念 而不是文档或服务应用标准。在前一段的示例中，我们要为文档、日本国家和 Bob 提供标识符；这些都是系统的 实体 。这里将要介绍的新的与众不同的内容是，我们还希望为 主题 和 作者 关系提供标识符。文档的标识符将会是主题节点。用于 Japan 和 Bob 的标识符将会是对象节点。关系标识符将这些主题连接到某些值，作为指定的、定向的圆弧。图形具有灵活的结构，可用于此用途。在使用图形时（与数据库表或 XML 文档树不同），我们可以在任何时候添加单个关联，而不影响其他结构。

在试图将整个图形都存储在一个存储系统中时，大多数图形系统都失败了。如果数据超过了一定的规模，这样的尝试通常不起作用。但是，通过使用可解析的 Web 标识符 (URL)，我们可以让 Web 成为我们的图形。现在我们可以扩大到任意大小的信息空间。我们没有考虑将 Web 让入容器中，而是将东西放入 Web 中。

RDF 是一个具有这些属性的 W3C 标准数据模型。这些实体使用了 URI（最好是可解析的 URL），并通过直接关系进行关联（而且也以这种方式进行标识）。实体和关系都可以通过全球标识符进行引用，可以通过解析标示符来了解它们。如果我们将图形序列化成某种标准格式，那么我们将拥有完全便携的数据。任何 RDF 系统都可以使用来自其他任何 RDF 系统的 RDF，无需进行任何类型的协调。应用程序或用户可能不知道如何处理数据，但他们至少可以使用这些数据，然后查看摄入了哪些数据。

我将使用一个看似愚蠢的示例来展示 RDF 的工作原理。如果我请求您修改您的系统来接受某项声明，比如我的生日是 5 月 26 日，您可能不愿意这样做。如果您的表格没有被设置为接受某些人的概念和他们的生日，那么您可能不愿意理会这些事情。它将花费您太多的精力来更改您的表格和类结构。采用我的生日并不是一个值得高度重视的考虑事项，但这个问题仍然存在于少数荒谬的场景中。产生这个问题的部分原因是，我们认为实体是独立的事物，我们将它们存储在单独的地方。我们并不认为概念性实体是我们所了解的来自多个数据源的实体。它们之间的区别是：一个是 封闭世界 模型，一个是 RDF 的 开放世界 模式。在开放世界模型中，我们接受任何人都可以分享任何东西的事实。我们可能永远不会知道关于实体或主题的一切。这种假设可能使得 IT 经理想要拥有和控制一切，但这种假设使得系统能够保持灵活，捕获来自所有来源的任意事实。

我们需要确定我，确定生日关系，还需要知道如何表示我的生日的日期。我选择通过 URL https://w3id.org/people/bsletten 来找到我自己。该 URL 已在一个 社区 内注册，该社区承诺帮助维持已注册标识符的稳定性，这些标示符目前在一个 GitHub 库内，您可以复制、修改和发布请求来添加自己的标识符。

我通过一个 HTTP 303 See Also 重定向，将这个标识符重定向到一个描述我的文件。该重定向是目前 W3C 技术架构组（TAG）建议用于非信息资源的重定向。我的序列化做的不是特别好，所以您无法拥有当前状态的表示（通过请求获得该状态）。对我的引用与对关于我的一个文档的引用（该引用可以解除引用并进行解析）之间的区别是：303 会警告客户端，该请求是有效的，但它不能直接实现。相反，响应中包含一个称为 Location 的标头，它指向描述我的文档。（我会在下一篇文章中再次介绍这个过程。）

所以，现在我们知道了如何引用我（语句的主题），我需要一个术语来引用生日（被定义为某人的出生日）。没有任何东西可以阻止我选择自己的术语。类似 http://bosatsu.net/ns/birthday 的 URL 也可以使用，特别是在我将术语的描述放在这个位置上的时候，这样所有人都可以解析属性标识符，弄明白它的含义。不过，幸运的是，我不需要这样做。一个称为 Friend of a Friend (FOAF) 的社区已经同意一系列有关 Web 上的分布式网络和社区的术语。该规范包括一个被广泛采用的用于生日的术语： http://xmlns.com/foaf/0.1/birthday ，这个术语想表达的正是我想要表达的。如果您 通过 HTTP 请求它 ，那么您会被带到一个描述术语集合的文档。该文档还会通知您应该采用什么样的格式： mm-dd 。我们现在还要了解一个事实，该事实涉及一个主题（我）、一个谓词（ http://xmlns.com/foaf/0.1/birthday ）和一个值（ 05-26 ）。当三个相结合时，我们想象了一个有向图，用该图来反映这种说法，如图 1 所示。主题是节点，谓词是圆弧，值在圆弧的另一边。

图 1. 表示为一个定向图的一个事实

现在，我需要做的就是将我的生日发布为一个机器可以处理的事实。我将使用一个称为 N-Triples 的简单的 RDF 序列化，将语句存储到一个文件中。采用这种格式时，每行都有一个用句点终止的事实：

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" .

这个文件可以存储在一个文件系统上，或者发布在网上。然后，任何 RDF 系统都应该能够使用这个事实。如果其他系统的用户不知道我是谁，他们可以解析主题标识符，了解有关我的更多信息。如果他们不知道 FOAF 生日意味着什么，他们可以做同样的事情。

或许我想发表我的全名。再次声明，我可以编造我自己的姓名来提供术语 名称 ，但这不是必需的，因为 FOAF 已经成为了用于此目的的广泛使用术语：

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

图 2 中的图形反映了有关我的新事实。

图 2. 表示为一个定向图的另一个单个事实

事情开始变得有趣起来。不管这两个事实是存储在同一个文件中，还是存储在两个不同的文件中，如果它们被读入相同的模型中，那么属性和值将会针对主题进行累积（如图 3 所示），因为这两个语句引用了使用相同标示符的同一个主题。

图 3. 表示为一个定下图的两个事实

以下展示了我如何使用 N-Triples 来存储两个关于相同主题的 RDF 事实：

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" . <https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

您越了解某个主题，节点外的圆弧就会越多。您能够了解的关于事物的信息是没有真正限制的，任何额外的事实并不影响图形的其余部分。事实来自哪里并不重要，但它们可以是有关联的。

任何人都能够通过属性谈论关于任何主题的任何内容，这项功能非常强大，但是我们还希望能够根据资源所属的类型来组织资源。您可以从类集合成员关系方面思考这个问题。如果资源是指一个人，那么我们可以说，个人是 Person 类的一个成员（按照惯例，类名称的首字母应该使用大写形式）。相同的人，如果他或她是一位工程师，那么他或她可能是 Engineer 类的成员。在您可以是多少类集合的成员方面，并没有来自任何数量的词汇表的任何限制。

混合模式的工作非常简单，但我现在坚持使用可靠的 FOAF 词汇表。因为它的主要目标之一就是谈论人，该词汇表包含一个我可以使用的 Person 类。我需要一个特殊的谓词来表明资源是某个类的一个实例。这是一个要表达的基础性的重要谓词，所以 RDF 为这种类型的关系提供了一个术语： http://www.w3.org/1999/02/22-rdf-syntax-ns#type 。这种类型的语句具有与您目前为止看到的属性关系不同的语义，但表达方式是相同的：

<https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>     <http://xmlns.com/foaf/0.1/Person> .

图 4 中的额外的圆弧看起来类似于我们已经看到的圆弧。

图 4. 定向图中的实例所属关系

最后，正如您可以想象到的那样，N-Triples 中表达的所有三种语句的组合在不断累积，形成了以下结果：

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" . <https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" . <https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>                  <http://xmlns.com/foaf/0.1/Person> .

图 5 显示了表示为一个图形的三个事实。

图 5. 表示为一个定向图的三个事实

这个故事中的关键点是：数据模型支持添加信息的观点。在任何时候，您都可以学一些新东西。通过使用标准的全球标识符、标准的数据模型和标准序列化，不兼容的数据会变得不适用，整合更多的数据应该几乎不需要花费什么力气。

回页首

RDF 格式之间的转换

N-Triples 格式不是非常人性化。在以某种易于解析的方式转储事实时，这种格式非常合理，但所有的重复会让您很难了解与某个特定主题相关的内容。现在，我将向您展示一种更好的格式，该格式称为 Turtle，它支持 Terse RDF Triple 语言。（其他格式也可以使用，其中包括一种称为 RDF/XML 的基于 XML 的丑陋格式。）

格式之间的转换很简单。一种方法是使用来自 Apache Jena 项目的一个称为 rdfcat 的工具。在这里，我请求 rdfcat 将 triples 格式转换为 Turtle 格式：

> rdfcat -out ttl basic.nt <https://w3id.org/people/bsletten>   a <http://xmlns.com/foaf/0.1/Person> ;   <http://xmlns.com/foaf/0.1/birthday> "05-26" ;   <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

您可以在 Turtle 中看到这种转换，每个主题都只被作为一个主题提到一次（相同的标识符可能位于另一个关系的对象位置上）。分号分隔开了关于主题的每一个事实。一个句点终止了我们所知的这个文件中的关于该主题的事实。当然，您可以了解来自其他来源的其他事实。

假设我已经在 Web 上发布了另一个 Turtle 文件，该文件夹包含一个关于我的额外事实。此文件使用了 http://xmlns.com/foaf/0.1/depiction 属性来表明，我的图像可以在 Web 上获得。该属性也有类似的格式，但只有一个事实：

> http get http://bosatsu.net/turtle/brian.ttl HTTP/1.1 200 OK Accept-Ranges: bytes Access-Control-Allow-Origin: * Content-Length: 124 Content-Type: text/turtle Date: Mon, 10 Mar 2015 04:56:39 GMT ETag: "1049e7-7c-50fd9f13a4140" Last-Modified: Tue, 24 Feb 2015 18:46:53 GMT Server: Apache/2.2.16 (Debian)  <https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/depiction>                <http://bosatsu.net/images/briansletten.jpg> .

如您所料，本地文件中的数据和远程文件中的数据很容易合并到一个通用模型中。因为我在这两个地方使用了相同的标识符，所以数据集变得非常容易：

> rdfcat -out ttl basic.nt http://bosatsu.net/turtle/brian.ttl <https://w3id.org/people/bsletten>         a       <http://xmlns.com/foaf/0.1/Person> ;         <http://xmlns.com/foaf/0.1/birthday> "05-26" ;         <http://xmlns.com/foaf/0.1/depiction>                 <http://bosatsu.net/images/briansletten.jpg> ;         <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

rdfcat 是了解如何在数据源之间操作标准和合并数据的众多工具和库之一。通过使用这些标准，数据集成的成本下降到几乎为零。例如，您可以想象一下将销售表内容连接到第三方数据源的好处，包括已销售产品的评级。结合使用这些数据源，可以明显快速加强对部门需要的支持，因为您正在销售许多差评产品。

回页首

结束语

RDF 是一个强大得令人难以置信的数据模型，在本系列的后续文章中，我们将继续扩展该模型的各种可能性。现在，您应该足以认识到使用任意数据源的简单性和灵活性。您应该能够理解为什么 OSLC 计划希望能够联系来自各种产品和参与者的信息，形成一个集成的、有关联的整体。通过精心规划，可以将资源表示需求连接到满足它们的代码。代码的测试可以连接到运行测试结果。源代码的某些特定更改可以连接到特定的事件，甚至连接到对此负责的个人。

使用 URI 和图形模型会导致一些开发人员关注更熟悉的 JSON 键/值对格式的简单性。额外的复杂性并不是毫无根据的，我们谈论的相互关联的数据图形就不是一个或多个对象的简单序列化，但不要让复杂性成为一个问题。类似 JSON-LD 的标准使您能够非常简单地连接 JSON 和 RDF，同时获得这二者的长处。

请继续关注我们，以便获得一些有趣的、令人惊讶的、强大的启示，本系列将继续探索面向资源的思维方式如何为 Web 上的数据集成和 OSLC 项目提供益处。