PDF管理半结构化数据
DANIELA FLORESCU，ORACLE
我清楚地记得我的第一堂大学课程，我被关系数据库深深吸引——它是一个信息绿洲，保证了我们可以随时获得正确、完整和一致的信息。在那堂课上，我学会了如何为我的信息构建模式，并且我了解到，为了获得准确的模式，必须预先了解要建模的信息的结构和属性。我还学习了 ER（实体-关系）模型，作为所有进一步数据建模的基本工具，以及需要在信息的一般结构和所有生产、处理或消费这些信息的社区使用的词汇表上达成预先协议。
几年后，我为一个组织工作，该组织的目标是创建一个大型食谱库。目的是收录来自世界各地的食谱及其营养信息，以及食物创作的历史和文化方面。
我参与了创建数据库模式来保存这些信息。突然，我在学校学到的公理崩溃了。我们根本不可能提前知道描述法国、中国、印度和埃塞俄比亚食谱需要什么样的模式。我们必须建模的信息实际上是无限且未知的。没有共同的词汇表。可用的信息主要包含在自然语言描述中；即使付出巨大的努力，使用实体和关系对其进行建模也是不可能的。要求厨师以表格、行、对象或 XML 元素的形式输入数据是不可思议的，并且为如此灵活和不可预测的信息结构构建输入表单是困难的，如果不是不可能的话。项目停止了。多年后，我相信我们仍然没有以我们设想的方式获得此类信息。
这类项目在我们周围比比皆是。虽然传统的数据建模和管理技术对于广泛的应用来说是有用且合适的——正如关系数据库的巨大成功所证明的那样——但在其他情况下，这些传统技术不起作用。大量信息仍然不可用且未被利用，因为现有的数据建模和管理工具不适用于此类信息的现实情况。
半结构化数据
在 20 世纪 90 年代，Web 改变了数字信息规则。HTML 的极端简洁性和 HTTP 的通用性降低了创作和交换信息的成本。我们突然接触到海量的信息；当然，这种信息并不是什么新鲜事，但数量是前所未有的。对我们日常生活的影响也是巨大的。很明显，这种丰富的信息无法存储在关系数据库中，也无法使用传统技术进行查询和处理；我们已经达到了使用传统规则可以处理的极限。我们需要新技术。
除了 Web 上纯粹（非结构化）的 HTML 数据之外，还有更多的数据以一种不符合纯粹结构化关系模型的形式存在，但信息具有明确的结构——它不仅仅是“文本”。信息的这个灰色地带被称为半结构化数据。数据库社区和其他地方已经投入了大量研究来研究这个主题。不幸的是，将近 10 年后，我们仍然没有好的解决方案、软件、工具或方法来处理这类信息。计算机科学专业的学生仍然没有学习如何处理它。我们甚至对问题的形态都没有达成一致——更不用说解决它的好方法了。
问题的第一个部分是半结构化数据这个术语的模糊定义。我将其归类为所有无法使用传统模式工具、软件或方法轻松有效地建模的数字信息。大多数此类问题都与我们需要建模的信息与当前工具对描述信息的先验简单模式的要求之间的不匹配有关。我们目前需要处理的信息与模式之间存在复杂而微妙的关系。
使用现有方法难以轻松有效地建模和处理信息的原因可能千差万别。处理每种半结构化数据的情况可能需要不同的技术和解决方案。
可能最常见的半结构化信息案例只是非结构化信息——即，嵌入在自然文本中的数据。此信息没有与之关联的简单结构——更不用说描述此类结构的模式了。世界上很大一部分信息包含在 Word、PDF、TIFF、HTML 和其他此类文件类型中。搜索引擎的不断发展和改进使得人类读者可以访问这些信息（在一定程度上，质量也各不相同）。然而，从其中自动提取信息是一个问题，因为自然语言理解和信息提取工具仍然很简单。电子邮件是一个典型的例子。尽管自然语言理解取得了进步，我们仍然没有高质量的工具来搜索、分类和自动处理电子邮件。
在很大程度上，我们无法有效处理埋藏在自然语言中的信息的原因是，大多数自动处理信息的工具都要求信息以某种实体-关系模式的变体进行建模。ER 模型不是建模自然文本的合适选择：人们用句子交流，而不是实体和关系。例如，考虑法律文件的内容。人们可以提取文档中包含的信息的子集，以 ER 形式呈现，但任何尝试这样做都会降低原始内容的大部分质量。
当今信息管理中另一个常见的问题是词汇表和模式缺乏一致性。现有的信息处理方法要求所有参与生成、处理或消费相同信息的社区都同意给定的模式和词汇表。不幸的是，不同的人、组织和社区天生就有不同的方式来建模相同的信息。这与要建模的领域或正在使用的目标抽象模型（例如，关系、Cobol 结构、对象类、XML 元素或 RDF [资源描述框架] 图）无关。在不同社区之间达成模式协议是软件设计中最昂贵的步骤之一。数据库视图旨在缓解这个问题，但视图并不能普遍解决模式异构性问题。我们需要能够在不需要参与者之间达成此类先验模式和词汇表协议的情况下处理信息。
传统工具要求在创建数据之前开发数据模式。不幸的是，有时数据模式仅在软件已在使用后才出现——并且模式通常随着信息的增长而变化。一个典型的例子是 eBay 上商品描述中包含的信息。eBay 开发人员似乎不可能为这些描述中包含的信息定义先验模式。今天，所有这些信息都以原始文本形式存储，并且仅使用关键字进行搜索，这大大限制了其可用性。问题在于，商品描述的内容只有在新商品描述输入到 eBay 数据库后才知道。EBay 有一些标准实体（例如，买家、日期、询价、出价...），但信息的重点——商品描述——具有丰富且不断发展的结构，而这种结构没有被捕获。
传统的软件设计方法在这种情况下不起作用。人们不能严格遵循以下步骤
- 收集有关软件组件要操作的数据的知识。
- 设计模式来建模此信息。
- 用数据填充模式。
我们需要软件和方法，允许更灵活的过程，其中步骤可以自由交错，同时允许我们自动处理这些信息。
通常，信息的结构会随着信息在各个处理阶段的进展而演变，并且该过程无法静态地预测。例如，想象一下一份医疗表格，其中包含实验室测试和医学检查的结果，由连续的医学调查填写。一些测试的结果会触发新的测试。在过程结束之前，不可能知道信息结构；随着过程的展开，信息被填写进去。我们需要能够捕获并有效利用模式和过程之间这些依赖关系的方法。
信息结构通常会随着时间的推移而演变和完善，随着信息的老化和被更好地理解。让我们以科学实验获得的数据为例。随着时间的推移，科学家对某些科学事实的理解会得到改进，因此描述此信息的模式也会演变。在处理此类迭代改进的信息时遇到的困难激发了关于半结构化数据库的原始工作，这仍然是数据库社区的一项重要努力。
流行的模式语言通常过于简单，无法建模日益复杂和动态的信息结构。由于这种不匹配，在某些情况下，即使模式存在，结果不幸地与之前的情况相同：“丰富的结构”在实践中通常转化为“没有结构”。例如，常用的关系和面向对象模式语言缺乏对描述替代结构（例如，书籍的作者或编辑）以及条件和相关结构的充分支持。在现有模式语言中难以建模的此类相关性的示例是共现约束（例如，如果属性 employer 存在，则属性 salary 也存在）和基于值的约束（例如，如果属性 married 的值为 yes，则该人也必须具有一个名为 spouse-name 的属性）。通常，这种情况使用所有已知属性的并集来表示，或者更糟糕的是，表示为全局缺乏结构。
这些只是我们在建模和处理非传统信息时面临的与模式相关的一些挑战。当然，还有更多。一个自然而然的问题出现了：这些难道不只是传统的模式演变案例吗？事实上，半结构化数据可以被看作并解释为模式演变的极端情况，其中数据与描述它的模式具有复杂的关系。数据可能存在或可能不存在模式或多个模式；模式可能是静态未知的；模式可能会随着时间的推移而改变，或者在数据处理时改变，或者只是改变得非常快。模式可能非常丰富，并且可能难以使用 ER 模型进行建模。模式可以从数据中派生出来，而不是驱动数据生成，或者模式可以是事后覆盖现有数据。
那么为什么要费心拥有模式呢？原因很简单：模式为数据赋予意义，从而允许自动数据搜索、比较和处理。虽然在传统意义上强加模式确实限制了数据和操作数据的代码的演变，但完全消除模式似乎也不是正确的解决方案。必须找到平衡；我们必须学会使用和利用模式作为助手，但不要依赖它们的存在，也不要让它们成为限制因素。
现实情况是，我们没有好的工具、软件和方法来处理半结构化信息。通常，这种情况根本无法解决——或者以复杂而昂贵的方式解决。在许多情况下，信息存储在平面文件中，然后使用代码提取和处理。在其他情况下，开发的数据库以最小的方式使用模式，将处理数据的智能隐藏在操作数据的应用程序中。将数据操作的智能隐藏在程序中会产生许多负面后果，主要是在构建和维护此类应用程序的成本以及结果代码的脆弱性方面。
我们应该从哪里开始？
学术数据库社区在过去十年中在半结构化信息方面做了大量工作。提案包括新的（基于图的）数据模型，以及与模式无关的查询语言和新的存储和索引方法——所有这些都完全与模式无关。还研究了自动从数据中派生模式的新方法，并产生了几个原型系统。
与半结构化数据管理相关的其他几个领域已经达到工业成熟度。随着互联网的增长，优秀搜索引擎的重要性也随之增加。如今，优秀的引擎可以为基于简单关键字的查询提供针对大数据量的高质量答案。搜索引擎可能被认为是半结构化数据问题的答案，因为它们在很大程度上忽略了底层信息的潜在结构。但搜索引擎是半结构化信息管理的答案吗？它们可能是一个答案，但它们不是唯一的答案。
不幸的是，在其当前形式中，搜索引擎有太多的局限性，无法成为这个问题的答案。为此类技术设计的数据和查询非常简单，并且在逐步增加数据中的结构程度、模式知识程度以及查询中的结构化搜索程度时，无法优雅地扩展。除了为人类提供对此信息的访问之外，它还必须可用于自动处理。程序必须能够更新数据，使用处理数据的复杂逻辑，并根据内容采取自动操作。现有搜索引擎的设计初衷并非如此。
作为 W3C 一部分开发的语义网技术集是自动处理世界半结构化和非结构化数据的良好起点。诸如 RDF 之类的数据模型，以及诸如 OWL（Web 本体语言）之类的声明性本体描述以及自动分类和推理机制，都是专门为解决此类问题而设计的。目标是为世界的结构化和非结构化内容添加元数据，并能够处理元数据以推断和提取必要的信息。语义网会成为管理世界半结构化信息的解决方案吗？我的答案和以前一样：虽然本体、分类和推理是管理半结构化信息的重要工具，但它们不是唯一的必要工具，并且还需要来自其他领域的技术。
一项较旧的技术是半结构化数据问题的另一种可能的解决方案。在 W3C 于 1998 年提出 XML 后，关于半结构化数据的学术工作几乎停止了，因为人们希望 XML 是答案。将近十年后，XML 因多种原因被各种社区普遍接受和拥抱，但现在很清楚，虽然 XML 解决了大量与模式相关的挑战，但它并没有解决半结构化信息的普遍问题。（在本文中，XML 指的是 W3C 开发的整个标准 XML 基础设施，包括以一致的方式设计的一组技术和语言：抽象数据模型，例如 Infoset、XQuery 1.0 和 XSLT 2.0；XML Schema；以及声明性处理语言，例如 XPath、XQuery 和 XSLT。）
XML 提供了一些主要优势。作为信息的一种标准语法，XML 能够建模整个范围的信息，从完全结构化的数据（例如，银行帐户信息）到自然文本。对于建模、存储、索引和自动处理此类信息，拥有用于整个信息频谱的单一模型具有巨大的好处。当我们增加或减少信息中的结构级别时，无需从一个系统切换到另一个系统，也无需使不一致的系统相互通信。
XML 的另一个主要优点是能够建模混合内容。拥有超越实体-关系模型的抽象信息模型为大量以前无法使用先前技术建模的信息打开了大门。XML 模式与数据分离的事实对于数据和模式演变也至关重要；数据可以存在于有或没有模式的情况下，或者具有多个模式。模式可以在数据生成后添加；数据和模式生成可以自由交错。
虽然 XML 技术为管理半结构化信息提供了显着的优势，但它们以目前的形式和孤立地来看，并非万能药。大多数信息仍然不是 XML 形式，其中一些信息永远不会是 XML 形式。XML 的优势（例如，复杂模式、混合上下文、与模式无关的数据）不出所料地带来了额外的复杂性和许多挑战。最后，当今与 XML 相关的技术并未提供完整的解决方案。例如，虽然 XSLT 和 XQuery 提供了良好的查询和转换（即，只读）语言，但仍然没有好的方法来表达对此类模式灵活数据的命令式逻辑，也没有语言来描述复杂的完整性约束和断言。这些限制最终将被消除，但不会立即消除。
解决半结构化信息的一般问题将需要借鉴许多领域的思想和技术，包括知识表示、XML 和标记文档、信息检索、语义网和传统数据管理技术。没有单一的方法可以提供解决此问题的答案。
接下来是什么？
解决半结构化数据管理问题还有很多工作要做。我们才刚刚开始漫长的旅程。以下是我们面前一些显而易见的任务。
首先，我们需要更好的信息创作工具。我们需要降低信息生成成本，同时提高数据的质量和结构程度，这反过来会增加此信息被自动处理的可能性。当前的信息创作工具包括文档生成器（例如，Word）、表单和 XML 编辑器（例如，XMeta）。它们要么过于简单，要么太难使用，只会加剧半结构化数据问题。下一代此类工具不仅必须能够以可以自动处理的形式（语义上有意义的 XML 可能是最合适的）生成信息，而且还必须易于使用。最后，它们不应限制可以建模的信息类型及其潜在的结构或内容。创作过程可以由底层模式驱动，也可以不驱动，和/或在现有词典和标准词汇表的帮助下进行。
即使使用最复杂的信息创作工具，许多信息仍将以纯文本形式存在。信息提取技术将始终很重要。在 90 年代，随着人们渴望从 HTML 页面自动提取信息并使用 Web 应用程序对其进行处理，对此主题的研究激增。这项工作变得不流行，因为许多人认为 XML 和 Web 服务使其变得无关紧要。这项工作不仅仍然相关，而且还是处理半结构化信息难题的重要组成部分。此类技术包括纯提取；提取和标记文本中引用某些实体的部分（例如，姓名、地址、公司、城市）；去重（例如，发现多个此类提取的实体引用同一真实世界实体的能力）；以及关联（例如，发现某些标记的实体通过某种关系相互关联的能力）。
应该投入更多精力来创建和重用标准模式和词汇表。社区创建的模式的作用正在急剧增加。RSS 是此类基于社区的模式的典型示例。最初由一个人提出，RSS 模式经过整个社区的改进和接受。当社区决定根据通用词汇表和通用模式创作其信息时，结果信息的价值将大大提高。
虽然基于社区的模式设计过程对于 RSS 来说效果很好，但对于其他社区和领域来说可能不起作用。我们可能需要组织和流程来创建、搜索和注册标准模式和词汇表。这是 UDDI（通用描述、发现和集成）注册表的最初目标之一；不幸的是，它们仍然没有实现。
即使基于社区的模式生成和重用过程到位，也总会有不同的人和社区使用不同的模式来建模相同信息领域的情况。我们将始终需要处理遗留的和独立设计的模式。我们需要了解如何自动将此类模式和词汇表相互映射，以及如何自动将为特定模式编写的代码重写为为描述同一领域的另一个模式编写的代码。正在该领域进行有趣的研究，但在问题得到理解并且我们拥有可用的工具之前，还需要付出更多的努力。
除了自动（或半自动）模式到模式的映射工具之外，我们还需要方法将现有数据自动链接到现有但独立设计的模式或本体。这将消除数据生成与模式和本体生成之间的依赖关系。我们还需要从现有数据中自动提取高质量的模式，并对生成的模式执行增量维护，以实现模式和数据独立性的目标。
搜索引擎将改进解决半结构化数据问题的一个方面：人类对信息的消费。可以利用上下文、语义和结构信息来提高简单文本查询结果的相关性。
将数据与模式分离也会对数据处理的所有方面产生重大影响：存储、索引、查询和更新、提供事务支持等等。大多数当前技术都依赖于静态模式信息来实现此类任务的性能。我们需要重新审视此类技术，以保证其正确性和性能，即使在没有模式信息或模式信息不断演变的情况下也是如此。
最后但并非最不重要的一点是，我们需要能够自动处理半结构化数据——换句话说，编写程序来操作它。目前，大多数流行的编程语言都将代码和模式紧密耦合，我们需要可以将它们分离的工具和方法。几十年前，关系数据库引入了将代码与数据的物理组织分离的想法，以便物理组织可以独立演变，而无需更改代码。
今天，我们需要更进一步——我们需要能够将代码与数据的逻辑结构分离。与将代码链接到物理数据组织的数据库优化器类似，我们需要一个新的组件，将针对逻辑数据表示编写的代码链接到数据的当前逻辑结构。这些结构将是部分的、非标准的和不断演变的。程序需要更高的数据独立性。
结论
半结构化信息无处不在，但我们常常无法处理和使用它。使用现有技术处理信息的成本很高——因为当前要求数据、模式和代码紧密（不灵活）耦合——为使用此信息设置了天然障碍。我们需要在拥有模式的优势（在更好地理解和自动处理数据方面）与模式带来的缺点（在不灵活性和缺乏演变方面）之间的张力中找到一个折衷方案。
实现灵活、廉价、简单且有效的半结构化信息处理是一个重要的目标。我们仍然处于起步阶段。
DANIELA FLORESCU 是 Oracle 公司的技术人员顾问成员。她曾是 BEA Systems 的高级软件工程师和 XQRL Inc. 的 CTO，XQRL Inc. 后来被 BEA 收购。她与 Jonathan Robie 和 Don Chamberlin 一起开发了 Quilt，Quilt 是用作 W3C XML 查询语言 (XQuery) 基础的核心语言。她目前是 XQuery 的编辑。
最初发表于 Queue 第 3 卷，第 8 期——
在 数字图书馆 中评论本文
更多相关文章
Andrew McCallum - 信息提取
2001 年，美国劳工部受命建立一个网站，以帮助人们在全国各地的社区学院、大学和组织中寻找继续教育机会。该部门希望其网站支持对地点、日期、时间、先决条件、讲师、主题领域和课程描述进行字段布尔搜索。最终，它还有兴趣挖掘其新的数据库以获取模式和教育趋势。这是一个主要的数据集成项目，旨在每三个月从数以万计的独立机构自动收集详细的结构化信息。
Alon Halevy - 为什么你的数据无法混合
当独立的各方为同一领域开发数据库模式时，它们几乎总是彼此大相径庭。这些差异被称为语义异构性，它也出现在多个 XML 文档、Web 服务和本体中——或者更广泛地说，只要存在不止一种方式来构建数据体。半结构化数据的存在加剧了语义异构性，因为半结构化模式从一开始就更加灵活。为了使多个数据系统彼此合作，它们必须理解彼此的模式。
Natalya Noy - 从混乱中理出秩序
过去十年在线信息量呈“大爆炸”式增长，可供人类和机器处理，这大概没有什么争议。它促成的两个趋势（还有许多其他趋势）是：首先，与以前存储大多数电子数据的传统集中式关系数据库相比，已经转向更灵活和流动的（半结构化）模型；其次，今天可供处理的信息实在太多了，人类无法处理，我们真的需要机器的帮助。
C. M. Sperberg-McQueen - XML <和半结构化数据>
词汇表设计者可以要求 XML 数据完全规则，或者他们可以允许少量变化，或者大量变化。在极端情况下，XML 词汇表可以有效地表示，除了所有格式良好的 XML 所需的规则之外，根本没有规则。由于 XML 语法仅记录存在的内容，而不是可能存在的所有内容，因此稀疏数据不会使 XML 表示显得笨拙；XML 存储系统通常旨在优雅地处理稀疏数据。
© 保留所有权利。