资源描述结构（Resource Description Framework，RDF）

资源描述框架（Resource Description Framework），一种用于描述Web资源的标记语言。RDF是一个处理元数据的XML（标准通用标记语言的子集）应用，所谓元数据，就是“描述数据的数据”或者“描述信息的信息”。也许这样解释元数据有些令人难以理解，举个简单的例子，书的内容是书的数据，而作者的名字、出版社的地址或版权信息就是书的元数据。数据和元数据的划分不是绝对的，有些数据既可以作为数据处理，也可以作为元数据处理，例如可以将作者的名字作为数据而不是元数据处理。

==================================

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

数据集成如何从面向资源的思维中获益

在这个介绍数据集成标准和技术的由五部分组成的系列文章的第一部分中，Brian Sletten 将介绍资源描述框架 (RDF)，RDF 是称为开放式生命周期协作服务 (OSLC) 的一套新标准的基础。作为万维网联盟 (W3C) 语义 Web 技术堆栈的一部分，RDF 旨在促进多个参与者之间的信息集成，无需大量的预先协调。

查看本系列更多内容 | 0评论

Brian Sletten, 总裁, Bosatsu Consulting, Inc.

2015 年 5 月 05 日

• 内容

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

开始您的试用

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

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

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

关于本系列

本系列将介绍、探讨和应用全球标准，解决开发人员、架构师和数据管理员所面临的大规模数据集成难题。本系列将介绍一些跨平台的、独立于语言和应用程序的技术，它们支持在数据库、文档、电子表格、服务 API 中进行信息集成。您将了解的数据模型和工具可以让您的工作变得更轻松，并对组织产生实质性的影响。

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

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

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

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

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

“尽管我们通常会看到附加到文档或 Web 应用程序中的 URL，但 REST 架构使得它们适用于任何信息资源。”

尽管我们通常会看到附加到文档或 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 系统都可以使用来自其他任何 RDF 系统的 RDF，无需进行任何类型的协调。 ”

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" .

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

后续内容

一些策略是为了在来源、信任级别、分类等基础上分离事实而存在，但目前您可以忽略这些问题。如果追踪包含来源元数据注释图的生成和修改方式很重要，那么该注释图有可能会使用 PROV 词汇。再次声明，我会将这些问题留在本系列后面的文章中进行讨论。

任何人都能够通过属性谈论关于任何主题的任何内容，这项功能非常强大，但是我们还希望能够根据资源所属的类型来组织资源。您可以从类集合成员关系方面思考这个问题。如果资源是指一个人，那么我们可以说，个人是 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 项目提供益处。

参考资料

学习

• RDF：探索 W3C Semantic Web 维基中的 RDF 页面。
• OSLC：访问 OSLC 项目的社区网站，该网站开发了一些标准，让使用软件生命周期工具与他人共享数据变得简单而又实用。OSLC 现在是 OASIS Open Standards Network 的一部分，由 IBM 及其合作伙伴共同建立。
• N-Triples：了解有关 N-Triples 的针对 RDF 图形的基于行的语法的更多信息。
• Turtle：查看针对 RDF 的 Turtle 语法。
• developerWorks Web development 专区：通过专门关于 Web 技术的文章和教程，扩展您在网站开发方面的技能。
• developerWorks Ajax 资源中心：这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。
• 查看 HTML5 专题，了解更多和 HTML5 相关的知识和动向。

获得产品和技术

• Apache Jena：您需要 Jena 来使用 rdfcat。

讨论

• Semantic Web Interest Group：加入一个支持开发人员和用户了解 Semantic Web 技术的论坛。
• 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区

==================================

资源描述架构在都柏林核心集的应用介绍

吴政睿(Cheng-Juei Wu)

辅仁大学图书资讯系专任副教授

E-mail: [e-mail]

中文摘要

元资料是将来用来描述（网路）资源的格式，由于资源的种类复杂，多种元资料共存共荣乃为未来必然的趋势，因此需要有一种适当的工具，来同时携带多种元资料来往于网路上，而「资源描述架构」（ RDF ）即为此种工具之一。 本文主要是介绍「资源描述架构」及其在「都柏林核心集」的可能应用，资源描述结构是由 W3C 主导和结合多个元资料团体（如都柏林核心集等）所发展而成的一个架构，可用来携带多种不同的元资料来往于网际网路和 WWW 上。 本文介绍了 RDF 的核心资料模式，以及「具体化」（ Reification ）和「声明」（ Assertion ）等的机制，最后是一个使用 XML 语法和 RDF 核心资料模式，来携带都柏林核心集记录的实例。

关键字：元资料，资源描述架构，都柏林核心集， Metadata ， RDF ， Dublin Core 。

一、前言

资源描述结构（Resource Description Framework，简称RDF）是一个用来携带多种不同的元资料来往于网路上的工具。 [注1] 元资料（Metadata）最常见的英文定义是"data about data"，可直译为描述资料的资料，主要是描述资料属性的资讯，用来支持如指示储存位置、资源寻找、文件纪录、评价、过滤等的功能。 以图书馆的角度来看，就其本义和功能而言，元资料可说是电子式目录，因为编制目录的目的，即在描述收藏资料的内容或特色，进而达成协助资料检索的目的。 [注2] 因此元资料是用来揭示各类型电子文件或档案的内容和其他特性，其典型的作业环境是电脑网路作业环境。 换言之，元资料是因应现代资料处理上的二大挑战而兴起的：一是电子档案成为资料的主流，另外一个是网路上大量文件的管理和检索需求。

至于元资料的种类，下面是一些常见的清单。 首先，国际图书馆协会联盟（International Federation of Library Association and Institutions，简称IFLA）在描述元资料资源的首页中[注3]，列举了以下的元资料种类： Dublin Core、EAD（Encoded Archival Description）、 FGDC's Content Standard for Digital Geospatial Metadata、DIF (Directory Interchange Format)、GILS (Government Information Locator Service)、IAFA/whois++ templates、MARC、PICS （Platform for Internet Content Selection）、RDM（Resource Description Messages）、SOIF（Summary Object Interchange Format）、SHOE（Simple HTML Ontology Extensions）、TEI、URC（Uniform Resource Characteristics）、X3L8 Proposed ANSI standard for data representation。

其次是在『Judy And Magda's List of Metadata Initiatives』的网页中，按类别提出一些经常被广泛使用或具有潜力的元资料如下︰ [注4]

(一) 通用描述型-- MARC、Dublin Core、Edinburgh Engineering Virtual Library (EEVL)、Semantic Header for Internet Documents、GILS、URC、X3L8 Proposed ANSI standard for data representation、IAFA Templates、NetFirst、Header for HTML documents、SOIF 、MCF（Meta content Format）、PICS。

(二) 文字档描述型-- TEI、BibTex、Gruber Ontology for Bibliographic Data、RFC 1807。

(三) 数据资料类-- ICPSR Data Documentation Initiative、SDSM（Standard for Survey Design and Statistical Methodology Metadata）。

(四) 音乐类-- SMDL（Standard Music Description Language）、

(五) 图像与物件类-- CDWA（Categories for the Description of Works of Art）、CIMI（Consortium for the Computer Interchange of Museum Information）、VRA Core Categories、MESL Data Dictionary。

(六) 地理资料类-- FGDC's Content Standards for Digital Geospatial Metadata。

(七) 档案保存类-- EAD、Z39.50 Profile for Access to Digital Collections、Fattahi Prototype Catalogue of Super Records。

由以上的列表和清单可知，因为网路资源的种类复杂，用途殊异，因此多种元资料共存共荣实为不可避免的趋势，因此需要有一种适当的工具，来同时携带多种元资料来往于网路上，而「资源描述架构」即为此种工具之一。

资源描述结构（Resource Description Framework，简称RDF）是由全球资讯网协会（W3C）主导和结合多个元资料团体（如都柏林核心集等）所发展而成的一个架构，可用来携带多种不同的元资料来往于网际网路和WWW上。 因为W3C先前曾致力发展一个元资料─PICS（Platform for Internet Content Selection） [注5]，因此RDF受到PICS很深的影响，在语法上则是遵循另一个W3C致力推广的架构-- XML（Extensible Markup Language）[注6]，由于目前XML已受到业界广泛的支持，如浏览器的两大霸主Netscape [注7] 和Internet Explorer [注8] 都已经各自制作使用XML格式的元资料规格，并且也已呈送W3C审核，因此XML与RDF的发展可说是备受瞩目。

二、 RDF 的核心资料模式与声明的机制

以下根据W3C 的RDF工作小组的草案[注9]，来对RDF模型做更进一步的介绍，基本上RDF是一个与任何特定（电脑）语法无关的抽象的资料（表达）模式，用来呈现一个特性与其值。 而所谓的「特性」（Property），可能是

资源的属性：如题名、著者等，都柏林核心集的题名（Title）栏位即可归属于这类。

资源间的关系：如都柏林核心集的关连（Relation）和来源（Source）两栏位即属于这类范畴。

RDF 的另外一个特点是语法独立性，因此两段看起来差异很大的 RDF 陈述，事实上可能是描述相同的一件事，这是因为 RDF 是一个抽象的资料模式。 由于这个抽象的特点，各种不同的元资料（如都柏林核心集）均可利用此种抽象的资料模式，来表达它们的内容。

RDF的核心资料模式（RDF Core）定义如下：

(一) N：一个点（Node）的集合（Set），此处的「集合」是一个数学的名词和概念，在此的意义和用法正如在数学中一般。 而「点」可以是一个资源（如网页）或是物件（Object），甚至可以是一个「特性」（Property）。 [作者注：「特性」的意义请参见前面的描述。 ]

(二) P（特性型态）：是一个N 的子集合（Subset）。

(三) T：一个含有三个元素的「有序对」（Tuple），其形式为（P, N, V），即有序对中的第一个元素来自前面的集合P，第二个元素来自前面的集合N，第三个元素V可以是来自集合N，或者是一个单纯的值（如字串” 吴政睿 ” ）。

例子：吴政睿是网页http://mes.lins.fju.edu.tw 的著者，可用RDF的有序对表示如下：

{著者，[http://mes.lins.fju.edu.tw]，[吴政睿]}

上述的有序对中，著者是一个「特性」，[吴政睿]是此特性的值，网页http://mes.lins.fju.edu.tw 是一个点（Node）。

从另外一个角度，可把RDF核心资料模式的三个元素有序对（P, N, V），以数学中的图学表示如下：

N -- P -- > V

即将N 和 V 视为点， P 是从 N 到 V 弧线的标示，因此上述的例子又可表示为

[http://mes.lins.fju.edu.tw] -- 著者-- > [吴政睿]

此外又可透过所谓的「具体化」（Reification）将「特性」（Property）变成一个新的点（假设为X），从而产生三个新的有序对如下：

(一) {PropName, X, P}。

(二) {PropObj, X, N}。

(三) {PropValue, X, V}。

以上面的例子来说，若将「特性」著者具体化为新的点X 后，将产生如下的三个新有序对

(一) {PropName, X, 著者}。

(二) { PropObj, X, [http://mes.lins.fju.edu.tw]}。

(三) { PropValue, X, [吴政睿]}。

若将描述同一个资源的众多特性的有序对集结起来，即成为RDF的「声明」（Assertion），例如描述网页http://mes.lins.fju.edu.tw 的两个有序对

(一) {著者，[http://mes.lins.fju.edu.tw]，[吴政睿]}

(二) {题名，[http://mes.lins.fju.edu.tw]，[吴政睿的首页]}

组合起来即构成RDF 的「声明」。

三、一个都柏林核心集记录的RDF 实例

都柏林核心集（Dublin Core）为备受瞩目的元资料之一，是1995 年3 月由国际图书馆电脑中心（Online Computer Library Center，简称OCLC）和National Center for Supercomputing Applications（NCSA）所联合赞助的研讨会，经过五十二位来自图书馆、电脑和网路方面的学者和专家，共同研讨下的产物。 目的是希望建立一套描述网路上电子文件特色的方法，来协助资讯检索。 研讨会的中心问题是--如何用一个简单的元资料记录来描述种类繁多的电子物件？ [注10] 主要的目标是发展一个简单有弹性，且非图书馆专业人员也可轻易了解和使用的资料描述格式，来描述网路上的电子文件。

都柏林核心集最近一次的研讨会为第五次研讨会，于1997年10月6-8日在芬兰的赫尔辛基举行，由于在写作本书时，第五次研讨会的正式报告尚未出版，只好先根据澳洲国家图书馆的一位与会者--Bemal Rajapatirana的报告先行介绍第五次研讨会的情况与成果[注11]，待第五次研讨会的正式报告出炉后，作者会另撰专文来加以介绍。

根据Bemal Rajapatirana的报告，与会者达成了如下的几项共识：

(一)加快标准化的脚步— 由于都柏林核心集的15个基本项目架构，自第四次研讨会以来已普遍获得认同，同时都柏林核心集也得到世界各国很多研究者的肯定，并且尝试建造系统，此时若无一定的标准来遵循，将使系统的建造者无所适从和系统的更改频繁。 因此基于都柏林核心集已趋成熟的共识，决定推派代表撰写RFC的草案，呈交给IETF进行标准化的过程。

(二)区分简单和复杂两种都柏林核心集格式— 简言之，所谓简单（simple）和复杂（complex）格式的区分，一般而言主要是以有无使用任何修饰词作为标准来划分的。 由于都柏林核心集的15个基本项目已有共识，因此简单都柏林核心集的标准化过程将会较早开始。

(三)语法上采用HTML和RDF格式为主— HTML的格式目前是使用4.0版本，写法请参见作者的另一篇文章[注12]。

(四)成立工作小组— 针对一些尚未有定论的议题，组成工作小组进行研讨，主要有

(1) 内容或格式尚未有定论的基本项目，如Date、Relation、Rights Management等项目。

(2) 修饰词。

(3) 特殊性议题，如都柏林核心集和Z39.50间的互换。

(五) 次项目（或类别修饰词）的制定原则

(1) 与基本项目一致，都是可省略的选择项。

(2) 次项目须能进一步协助诠释项目的内容。

(3) 只展开一层，免得结构过于复杂。

(4) 数目尽可能精简，有可能需要类别修饰词的基本项目，将限于Title、Creator、Contributor、Publisher、Date、Relation、Coverage等。

1997年10月公布的资料著录项目列表如下：[注13]

(一) 主题和关键词（Subject）：作品所属的学术领域，控制语汇用scheme 注明出处如LCSH，亦可包含分类号如杜威十进分类号（Dewey Decimal Number）。

例子：Subject = 都柏林核心集。

(二) 题名（Title）：作品名称。

例子：Title = 都柏林核心集与元资料实验系统。

(三) 著者（Creator）：作品的创作者或组织。

例子：Creator = 吴政睿。

(四) 简述（Description）：文件的摘要或影像资源的内容叙述。

(五) 出版者（Publisher）：负责发行作品的组织。

(六) 其他参与者（Contributors）：除了著者外，对作品创作有贡献的其他相关人士或组织。

〔注: 如书中插图的制作者。 〕

(七)出版日期（Date）：作品公开发表的日期，建议使用如下格式– YYYY-MM-DD和参考下列网址：http://www.w3.org/TR/NOTE-datetime。 在此网页*规范有六种格式，都是根据国际标准日期暨时间格式 – ISO（国际标准组织）8601制定而成，是ISO 8601的子集合（subset），现在列举和解说如下以供参考： [注14]

例子：1997-09-07（西元1997年9月7日）。

(八) 资源类型（Type）：作品的类型或所属的抽象范畴，例如网页、小说、诗、技术报告、字典等，建议参考下列网址：http://sunsite.berkeley.edu/Metadata/types. html。

例子：Type = Text.Dictionary。

例子：Type = 文字.技术报告。

(九) 资料格式（Format）：告知检索者在使用此作品时，所须的电脑软体和硬体设备，例如text/html（MIME格式）、ASCII、Postscript（一种印表机通用格式）、可执行程式、JPEG（一种通用图像格式）。 亦可扩展至非电子文件，例如book（书本）、丛书、期刊。

例子：Format = text/html。

(十) 资源识别代号（Identifier）：字串或号码可用来唯一标示此作品，例如URN、URL、ISSN、ISBN等。

(十一) 关连（Relation）：与其他作品（不同内容范畴）的关连，或所属的系列和档案库。

例子：Relation = http://mes.lins.fju.edu.tw/。

(十二) 来源（Source）：作品从何处衍生而来（同内容范畴），例如莎士比亚的某个电子书出自那个纸本。

(十三) 语言（Language）：作品所使用的语言，建议遵循RFC 1766 的规定，请参考下列网址：http://ds.internic.net/rfc/rfc1766.txt，RFC 1766 是使用ISO 639的二个字母的语言代码。 [注15]

例子：Language = en。 [注16]

(十四) 涵盖时空（Coverage）：作品所涵盖的时期和地理区域。

(十五) 版权规范（Rights）：作品版权声明和使用规范。

以下是使用XML语法和RDF核心资料模式来携带一个都柏林核心集记录的实例：

<xml::namespace href="http://purl.oclc.org/metadata/dublin_core_elements" as="DC">

< xml::namespace href="http://www.w3.org/schemas/rdf-schema" as="RDF">

<RDF:serialization>

<RDF:assertions href="http://mes.lins.fju.edu.tw/mes/">

<DC:creator> 吴政睿 </DC:creator>

<DC:title> 元资料实验系统 </DC:title>

<DC:subject> 都柏林核心集 </DC:subject>

<DC:subject> 元资料 </DC:subject>

<DC:description> 有鉴于元资料对资料著录和检索的重要性，作者建立了一个相关的实验系统 — 元资料实验系统 (Metadata Experimental System ，简称 MES ，网址 : http://140.136.85.194/mes 或 http://mes.lins.fju.edu.tw/mes) ，作者建立 MES 目的，除了是让读者透过这个系统，对元资料及其未来的可能运作方式，有更具体的认知外；也希望利用此一实验系统，来测试和验证元资料的功能和效用，例如都柏林核心集这种简易的资料描述格式，是否如制定者们所预期的，足以满足大部分网路文件著录和检索的需求。 MES 是一开放性的实验系统，欢迎任何人上站著录自己的网页或文件，以供他人查询和检索。

</DC:description>

<DC:date>

<ISO8601>1997-009</ISO8601>

</DC:date>

<DC:type>homepage</DC:type>

<DC:format >text/html</DC:format>

<DC:identifier><url>http://140.136.85.194/mes</url></DC:identifier>

<DC:rights> 所有版权属于吴政睿 </DC:rights>

</RDF:assertions>

</RDF:serialization>

下面的RDF文法是摘录自W3C 的RDF工作小组1997年10月2日公开的草案[注17]，此文法是以电脑界通用的BNF（Backus-Naur Form）[注18] 形式呈现，同时由于工作小组的草案是会随时增修的，请自行连上W3C 的网站（http://www.w3.org/Metadata/RDF/Group/WD-rdf-syntax）查看最新的发展。

(一) RDF ::= '<RDF:serialization> ' node* ' </RDF:serialization>'

(二) node ::= resource | assertions | aggregate

(三) resource ::= '<RDF:resource' idAttr? '>' property* '</RDF:resource>'

(四) assertions ::= '<RDF:assertions' idRefAttr* '>' property* '</RDF:assertions>'

(五) aggregate ::= sequence | bag | alternatives

(六) sequence ::= '<RDF:seq' idAttr? '>' aggnode* '</RDF:seq>'

(七) bag ::= '<RDF:bag' idAttr? '>' aggnode* '</RDF:bag>'

(八) alternatives ::= '<RDF:alternatives' idAttr? '>' aggnode* '</RDF:alternatives>'

(九) aggnode ::= node | '<RDF:li' hrefAttr '/>'

(十) idRefAttr ::= hrefAttr | idAttr

(十一) hrefAttr ::= 'href="' resourceURI '"'

(十二) idAttr ::= 'id="' IDsymbol '"'

(十三) resourceURI ::= (see RFC1738)

(十四) IDsymbol ::= (any legal XML name symbol)

(十五) property ::= '<' propName idAttr? '>' propValue '</' propName '>' | '<' propName idRefAttr '/>'

(十六) propName ::= name | namePrefix ':' name

(十七) propValue ::= node | string

(十八) name ::= (any legal XML name symbol)

(十九) namePrefix ::= (any legal XML namespace prefix)

(二十) string ::= (any XML text)

四、结语

元资料的兴起和WWW与搜寻引擎的盛行颇有关连，WWW盛行后，为因应检索网页内容的需要而有搜寻引擎的产生，搜寻引擎运作的方式，基本上是属于全文检索，主要是透过自动抓取程式在网际网路上抓取网页，然后以自动拆字（或词）作索引的方式来建立其资料库，做为检索的基础，这种操作方式的特点是高运作效率和一网打尽，因此有高回收率与低精确率的特性，这个低精确率的缺点，随着WWW网页数量的急遽膨胀，成为无法忍受的致命伤。

很明显的，我们需要更多的资讯，来从回覆的款目当中，挑选我们真正需要的资料，而这些资讯必须由资料提供者来提供，因此如何制定一套资料描述格式，来有效率的描述收藏的资料，成为一个重要的课题，这正是元资料日渐受到重视的原因。 这种对资料须加以适当描述的体会，正是图书馆制作目录的动机，于是这个古老的经验又得到再一次的肯定。

都柏林核心集（Dublin Core）是一个简单有弹性，且非图书馆专业人员也可轻易了解和使用的资料描述格式。 这种简单有弹性和适合各种专业人员的特性，正是它在国外越来越受到欢迎的主要因素，也是作者特别青睐都柏林核心集的原因，这是因为作者同时具有图书馆学和电脑的背景，了解到在现阶段，一种适合各专业人士的简易元资料的必要性；一方面传统的机读编目格式过于繁琐，也继承太多的传统包袱，同时传统图书馆的著录方式并不适合非图书馆专业的人。 另一方面以作者对目前人工智慧、类神经元网路、模糊逻辑等相关学科的了解，知道创造一个具有现今一般图书馆员智慧的自动化系统，在现阶段仍是一个遥不可及的梦想，因为至今我们连模仿一个三岁小孩说和听故事的智力都有困难，更别说是模仿一个成年的专业人士。 所以综合来说，在现阶段资料的描述仍需以人工作业为主，同时以今日网际网路上资料膨胀的速度来看，光靠图书馆员来处理是不够的，由（众多专业的）文件或资料的创造者本身来自行加以描述，已是必然的趋势，这正是类似都柏林核心集这种元资料受重视的原因。

以都柏林核心集在国外的发展现况来看，1997年10月的第五次研讨会已有专门的议程来针对都柏林核心集的实作系统进行展示和讨论，这是以前四次研讨会所没有的，也说明都柏林核心集已渐趋成熟和受到肯定。 除了已开发系统的介绍外，也有一些正在筹建中的都柏林核心集相关系统的宣布，以下是它们的简介：

(一) 丹麦*决定自西元1997年起将所有*的出版物上网，系统的主要规格之一，是采用都柏林核心集来描述文件和协助查询。

(二) 荷兰国家图书馆将发展一种新的全球资讯网服务，系统的主要做法是要在所有已搜集的网页中，加入都柏林核心集的资料，新的网页将要求提供者先自行加入都柏林核心集的资料后再送呈，将来荷兰国家图书馆的搜寻引擎会利用这些元资料来协助检索。

(三) 英国的UKOLN正在推行一个名为BIBLINK的计划，在出版社和国家书目中心间建立一条网路通讯管道，来直接交换书籍纪录和资讯，这套系统是使用都柏林核心集作为其基本的格式。

(四) 在商业的应用上，一个称为STARTS的协定正在发展中，它可以辨识网页中的元资料，来协助使用者过滤和排比查询的结果，STARTS已决定包含都柏林核心集。

综观以上的发展，显示都柏林核心集已渐成熟和广受肯定，以系统的实作而言，欧洲和澳洲（请参见下面第四章中关于DSTC的介绍）可说是居于领先的地位，欧洲较注重都柏林核心集在图书馆相关服务上的应用，澳洲的DSTC则较偏重都柏林核心集在WWW相关服务上的应用。

由于类似都柏林核心集这类的元资料正逐渐获得肯定和使用，因此相关的携带工具也成为研究者注目的焦点。 这是因为元资料的种类复杂且用途殊异，将来多种元资料共存共荣的局面已成为共识，因此一种可同时携带多种元资料来往于网际网路和WWW上的架构，成为不可或缺的工具。 基于此种认知，W3C乃主导和结合多个元资料团体发展出「资源描述架构」（RDF）。 虽然在第二次都柏林核心集的研讨会中，也提出一个类似的多个元资料的携带工具─「瓦立克架构」[注19]，但是由于W3C在网际网路和WWW界的影响力甚巨，作者预期RDF终将获得采用而取代「瓦立克架构」，成为携带都柏林核心集的主要工具，因此撰写本文来介绍资源描述架构在都柏林核心集的可能应用方式。

注释：

注1：E. Miller and B. Schloss, ” Resource Description Framework (RDF) Model and Syntax, ” 2 Oct. 1997, <http://www.w3.org/TR/WD-rdf-syntax-971002>, p. 2.

注2：吴政睿，「元资料实验系统和都柏林核心集的发展趋势」， 国立*图书馆*分馆馆刊 4卷2期（民86年12月），页12。

注3：IFLA, “ DIGITAL LIBRARIES: Metadata Resources, ” 24 March 1997, <http://www.nlc-bnc.ca/ifla/II/metadata.htm>。

注4：J. Ahronheim, “ Judy and Magda's List of Metadata Initiatives, ” 2 Nov. 1997, <http://www-personal.umich.edu/~jaheim/alcts/bibacces.htm>.

注5：P. DesAutels, ” Platform for Internet Content Selection, ” 18 July 1997, < http://www.w3.org/PICS/index.htm>.

注6：D. Connolly, ” Extensible Markup Language (XML), ” 1 Dec. 1997, < http://www.w3.org/XML/index.htm>.

注7：A. Hopmann, ” Web Collections using XML, ” 9 March 1997, < http://www.w3.org/TR/NOTE-XMLsubmit.html>.

注8：RV Guha and T. Bray, ” Meta Content Framework Using XML, ” 24 June 1997, < http://www.w3.org/TR/NOTE-MCF-XML/index.htm>.

注9：同注1，页2-6。

注10：吴政睿，「三个元资料格式的比较分析」， 中国图书馆学会会报 57期（民85年12月），页39。

注11：B. Rajapatirana, ” The 5th Dublin Core Metadata Workshop: a report and observations, ” 2 Dec. 1997, <http://www.nla.gov.au/nla/staffpaper/helsinki.html>.

注12：同注2，页18。

注13：S. Weibel and E. Miller, “ Dublin Core Metadata Element Set: Reference Description, ” 2 Oct. 1997, <http://purl.oclc.org/metadata/dublin_core_elements>.

注14：M. Wolf and C. Wicksteed, “ Date and Time Formats, ” 15 Sept. 1997, < http://www.w3.org/TR/NOTE-datetime>。

注15：HT Alvestrand, “ Tags for the Identification of language, ” March 1995, < http://ds.internic.net/rfc/rfc1766.txt> , p. 2.

注16： “ Guide to Creating Core Descriptive Metadata, ” 13 April 1996, < http://www.ckm.ucsf.edu/people/jak/meta/mguide3.html> , p. 7.

注17：同注1，页6-7。

注18：AV Aho, R. Sethi, and JD Ullman, Compilers: Principles, Techniques, and Tools , (Addison-Wesley : Reading, Massachusetts) 1988, p. 159.

注19：同注2，页14-15。

=================================