Biperpedia: An Ontology for Search Applications/ 应用于搜索应用的本体!

摘要

搜索引擎在识别可以由结构化数据回答的查询上做出了重大努力，同时在创建和维护高精度数据库方面进行了大量投入。虽然这些数据库具有相对较宽的实体覆盖，但是它们建模属性的数量（例如，GDP，CAPITAL，ANTHEM）相对较小。扩展搜索引擎已知的属性数量可以使它更准确地回答非频繁查询，从Web中提取更广泛的事实，以及恢复Web上表的语义。

Biperpedia，一个具有1.6M（类，属性）对和67K不同属性名称的本体。Biperpedia从查询流中提取属性，然后使用最佳提取来从文本中提取属性。对于每个属性，Biperpedia保存它出现的一组同义词和文本模式，从而使其能够在更多上下文中识别属性。除了对Biperpedia质量的详细分析，本文还证明其可以增加Web表的数量，相比于Freebase，我们可以恢复超过4个因素。

1. 介绍

在网络历史上，结构化数据一开始便是搜索结果的首选。主要搜索引擎在识别何时可以使用结构化数据来回答用户的查询上做出了重大努力。与此同时，他们正在投入大量资源来建立一个数据库以扩展知识库，如Freebase [3]。这些数据库包含如（法国，CAPITAL，巴黎）的三个成分，其模拟了广泛的感兴趣的主题。来自结构化数据的搜索结果显示在常规搜索结果的顶部或右侧。

虽然在搜索结果中结构化数据库具有相对较宽的实体覆盖（例如，瑞典，Gerhard Weikum，Ghostbusters），但是它们建模的属性（例如CAPITAL，PUBLICATIONS，RELEASE DATE）的数量相对较小。例如，对于类COUNTRIES，Freebase只有少于200个属性，而感兴趣的属性的数目是数以千计的。

 

从以下几方面考虑，扩展搜索引擎属性的数量是十分必要的。首先，附加属性将使得搜索引擎能够更精确地回答非频繁查询（如巴西咖啡生产）。其次，附加属性可以方便使用开放信息提取技术从网络文本中提取事实[9]。最后，广泛的属性库也可以让我们可以恢复Web上表的语义[24]，因为它使得列标题和周围文本中的属性名称能够更容易被识别。

我们将Biperpedia描述为一个二元属性的本体，包含比Freebase多两个数量级的属性。Biperpedia中的属性（参见图1）可以是一对实体（如CAPITAL of COUNTRY），实体和值（如COFFEE PRODUCTION）或实体与叙述（如CULTURE）之间的关系。Biperpedia关注模式级别的属性，而提取这些属性的实际值是未来要努力的一个方向。Biperpedia是一个尽力而为的本体，它并不是所有的属性都是有意义的。然而，我们证明了其具有相当高的准确性（如前100个属性为0.91，前5000个属性为0.52）。

除了范围，Biperpedia与普通本体的第二个区别特征是它立足于支持搜索应用。特别地，Biperpedia应该支持诸如解析用户查询，恢复Web表的列的语义以及识别文本中的句子是否是指实体的属性等任务。传统的本体已经被应用在以前的搜索（如[15,23]）。然而，传统的本体往往是脆的，因为它们包含对世界建模的单一方式，包括任何类，实体或属性的单个名称。然而，传统的本体往往是脆弱的，因为它们仅能通过唯一方式对世界建模，包括任何类，实体或属性的单个名称。因此，用本体支持搜索应用并不容易，因为将查询或文本片段映射到本体可能会非常困难。

Biperpedia包括一组便于查询和文本理解的结构。特别地，Biperpedia将属性的一组常见拼写错误，同义词（一些可能相近的词），其他相关属性（即使特定关系未知）以及提及属性的常见文本短语（[20]）附加到每个属性上。

除了从Freebase本身引导外，Biperpedia还从两个来源提取新属性：查询流和Web上的文本。查询流是频繁属性的来源，但是在所有查询中识别属性便成了一个挑战。Web文本的覆盖范围甚至比查询流更广，但是如以前的开放信息提取工作结果所示[9]，Web文本中存在很多无意义的属性。本文贡献如下：

l 我们描述一种新的本体结构，通过解释Web查询和文本适配搜索应用；

l 我们开发了一种用于从查询流和Web文本中提取本体属性的算法。特别是，我们开发了一种从文本中高精度提取属性的方法，通过使用远程监控来学习文本提取，这些提取器是从查询流和Freebase中提取的种子属性；

l 我们描述了一种新颖的算法，它使用属性被提及的动词来将属性分类为数字（如GDP），原子（如CAPITAL）和叙述（如HISTORY）等类别。同时将属性限制在现有模式中，用于进一步过滤Biperpedia中的属性，以及用于诸如事实提取和问题回答的下游应用。如此分类是非常有价值的；

l 我们描述了一种将属性附加到给定类层次结构中最合适的类的算法。该算法对于从Biperpedia贡献属性到其他本体是十分必要的；

l 我们通过证明Biperpedia可以帮助解释Web表的语义来显示其实用性。我们利用Biperpedia描述了一个模式匹配算法，相比于仅使用Freebase，我们可以解释的表的数量超过4倍；

l 实验验证Biperpedia的高精度和对感兴趣属性的召回。特别地，对于前5000个属性，我们获得了超过0.5的精度。 在这些属性中，只有1％存在于Freebase和1％在DBpedia [2]。

本文的结构如下。 第2节提出问题，第3节描述了Biperpedia的架构。第4节描述如何从查询流提取属性，第5节描述如何从文本提取其他属性。第6节描述了我们如何合并属性提取和用同义词增强本体。第7节评估属性质量。第8节描述了用于在层次结构中放置属性的算法。第9节描述了我们如何使用Biperpedia来改进我们对Web表的解释。第10节描述相关工作，第11节总结。

2. 问题定义

Biperpedia的目标是找到可以与实体类相关联的模式级属性。例如，我们想要发现CAPITAL，GDP，LANGUAGES SPOKEN和HISTORY作为COUNTRIES的属性。Biperpedia不关心属性的值。也就是说，我们不是试图找到某个国家的具体GDP。

类层次结构：我们假设一组给定的实体类，例如COUNTRIES或US PRESIDENTS（注意类名总是以较大的字体字母开头）。这些类包括Freebase中的类型和标识Freebase类型子集的附加类。为了达到我们的目的，我们假设（1）类是高质量的（即它们与世界中自然实体集相对应），（2）对于每个类，我们都有一组实例（如法国是一个国家）。我们在类集合上还有一个子类层次结构（如美国PRESIDENTS是POLITICIAN的子类），但子类层次结构可能是不完整的。此外，同一层属性重要性并不都是相同的（例如，在LOCATIONS类下，我们可以有一个重要的子类，如TOURIST ATTRACTIONS和一个不感兴趣的子类，如SPORTS TEAMS LOCATIONS）。

名称，域类和范围：Biperpedia中属性的名称是具有一个或多个字母的字符串，如POPULATION或LIFE EXPECTANCY FOR WOMEN。每个属性都有一个域类，即定义属性的实体集合。一个属性可以对应多个类。如POPULATION是类LOCATIONS和类BIOLOGICAL BREEDS的属性。因此，类名和属性名的组合唯一地定义了一个属性。属性的域仅仅指定该属性适用于该类的实例。但是，属性通常附加在许多类中。例如，属性POPULATION适用于超过2500个类（包括LOCATIONS的所有子类）。因此，Biperpedia会尝试识别要附加属性的最佳类（第8节）。Biperpedia附加一个范围与每个属性。范围指定属性值应属于的类或数据类型。例如，CAPITAL的范围是CITIES，而LIFE EXPECTANCY的范围是实数。我们只在简单的情形下提出了解决计算范围的问题。

同义词和拼写错误：Biperpedia的主要目标是能够识别用户生成的内容（例如查询和文本）中的属性。用户显然没必要与Biperpedia中的属性完全一致，他们也已经习惯于能自动修复常见拼写错误的搜索引擎。为了支持尽可能多的召回，Biperpedia为每个属性附加一组常见的拼写错误和Biperpedia认为涉及相同的属性（第6节）的一组同义词。重要的是要注意，拼写错误和同义词取决于类。 例如，MOTER是PERSON类的MOTHER的拼写错误，同时却是CARS类中的MOTOR的错误拼写。

相关属性和提示：Biperpedia可以识别密切相关的属性也很重要。 例如，Biperpedia应该知道MOTHER是PARENT的子集，FIRSTNAME是FULL NAME的一部分，RURAL POPULATION是POPULATION的一个组成部分。这样的知识可以帮助搜索引擎回答更广泛的查询，并且当它们包含更详细的数据时能够检索相关的Web表。例如，一个用户查询抽象地指定属性（如POPULATION），同时存在包含诸如RURAL POPULATION和URBAN POPULATION组件属性的高质量表。Biperpedia当前不识别所有可能的关系，并将所有这些关系折叠到子/超级属性。

同样，为了便于在文本和查询中识别提及的属性，Biperpedia还将一组提及该属性值的句子和查询模式附加到每个属性上（参见图1）。在这方面，Biperpedia非常类似于Patty系统[20]。 我们在本文中不讨论检测相关属性的问题。

出处：由于Biperpedia的属性是从多个源提取的，因此我们附加了发现属性的数据源集合（Freebase，QueryStream，Text）和一些源特定的源信息（在第4节和第5节描述）。当合并两个属性时认为它们是同义词，便会保留每个同义词的来源。

与传统本体的差异：Biperpedia和手动创建的本体之间的核心区别是Biperpedia尝试找到在查询和文本中人们认为与实体相关的属性。相反，从设计上考虑手动策略会以更复杂的方式对属性建模。例如，ARCHITECTURAL STYLE是Biperpedia认为与MUSEUMS类相关的属性。然而，在Freebase中将相同的属性作为路径建模：MUSEUMS具有包含一组建筑物的属性BUILDINGS OCCUPIED，同时类BUILDINGS具有属性ARCHITECTURAL STYLE。Freebase设计更加模块化，但在查询和文本中，人们却指的是博物馆的建筑风格，我们的目标是识别这样的情况。当然，Biperpedia仍然可以使得MUSEUMS具有BUILDINGS OCCUPIED属性，BUILDINGS具有ARCHITECTURAL STYLE的属性。为了支持涉及遍历本体中路径的更复杂的推理，Biperpedia将需要识别其包含的冗余路径。 一般来说，将Biperpedia这样尽最大努力本体的优点和手工创建的本体相结合，为未来研究提供了更具有潜力的方向。

评估：鉴于我们的目标，我们以两种方式评估Biperpedia的质量。 首先，给定Biperpedia对类C提出的属性A，A是否是C的实例的合理属性？第二，评估Biperpedia是否在应用程序中起作用。在本文中，我们证明了Biperpedia是理解Web表语义的不可或缺的工具。

3. BIPERPEDIA系统

Biperpedia提取途径如图2所示。在最上层有两个阶段。第一阶段从多个数据源提取属性候选项，第二阶段则合并所提取的属性，并通过查找同义词，相关属性以及属性的最佳类来增强本体。以FlumeJava管道[6]方式实现。

 

属性提取：流水线通过从多个源（包括Freebase，查询流和Web文本）提取属性候选项开始。

从Freebase中提取的过程如下（注意，在Freebase中classes被称为types，attributes被称为properties）。首先遍历所有类型，并检索附加属性作为Biperpedia的属性。对于每个属性存储名称，范围类型和英语描述（如果存在）。另外还将Freebase属性附加到它们的子类型上。例如，POPULATION是Freebase中LOCATIONS的属性，但我们也将它附加到COUNTRIES和CITIES上。涉及查询流和Web文本的提取分别会在第4和第5节中加以描述。

我们还尝试从Web表中提取属性[4]。然而，我们发现Web表中的绝大多数属性是上下文敏感的。在第9节中，我们可以使用Biperpedia来更好地解释Web表中的属性。

本体增强：一旦提取完成，即合并属性候选集合，并通过域类对它们进行索引（例如，我们收集COUNTRIES的所有属性）。 因此，以下步骤在单个域类中完成。

拼写错误：从识别哪些属性是正确属性名称的常见拼写错误开始。我们的实验表明，拼写错误占了4％的属性，但有些却频繁发生并最终是排名靠前的属性（如FALG是COUNTRIES查询的顶级属性之一）。自然，相比于其他来源，拼写错误在查询流中出现得更加频繁。

同义词：接下来，Biperpedia识别属性名称中的同义词（见第6节）。实验表明，32％的（拼写无误）属性可以被认为是其他词的同义词。注意，原则上，当本体用于解释查询时，我们可以尝试在查询时检测拼写错误和同义词。然而，在Biperpedia中存储的拼写错误和同义词为分析许多之前的查询大有裨益。此外，拼写错误和同义词不会经常改变，因此实时分析查询并不能带来明显的益处。

子属性：我们目前使用两种启发式方法来识别子属性：（1）如果我们在Web上（使用诸如[14]的技术）找到足够的证据证明“A IS AB”，其中A和B都是属性，我们就认为属性A是B的子属性（例如，MOTHER IS PARENT）。（2）如果我们找到一对属性，其中一个属性包含一个修饰符作用在另一个属性上（如RURAL POPULATION and POPULATION），我们认为第一个是第二个的子属性。虽然存在噪声，这些启发式算法在实践中产生的结果却十分有用。

最佳类：Biperpedia轮流处理每个属性，并尝试找到层次结构中的最佳类以附加之。

以数字/文本/非原子分类：Biperpedia将每个属性分为数字（如COFFEE生产），原子-文本（如POLICE-CHIEF），非原子（如HISTORY）或无四类。这些标签对于诸如手动策划或仅提取原子属性的事实，又或者推断数字属性的测量单位和范围是大有裨益的。

4. 查询流提取

查询流是反映用户兴趣属性的绝佳源。挖掘查询流的主要挑战是涉及实体属性的查询与其他查询混合在一起，并且难以将它们分开。Biperpedia从一组360亿个匿名不重复查询中提取属性，步骤如下：

 

查找候选属性：最初，我们考虑所有形式如“what is the A of E ”的查询来查找候选属性名A.例如，我们可以在查询流中找到查询“what is the population of france”。 我们用A表示A的所有值。

接下来，我们考虑形式“A E”或“E A”存在的所有查询，其中A∈A，E已经被实体识别器标记为实体[12]。请注意，由于此简短形式在查询中更常见，因此该步骤所匹配的查询数量将远多于第一步。特别地，我们会发现属性A应用于更多的实体，这对于我们管道的其余部分是至关重要的。

结果以（A，E，f）的三元组集合形式输出，其中A∈A是候选属性名称，E是实体字符串，f是查询“A E”或“E A”在查询流中出现的次数。

协调到Freebase：此步骤的目标是将实例中的属性提示提升到类，以便我们可以汇总它们。 具体来说，对于每对（C，A），其中C是类，A是候选属性名称，我们计算两个值：

l InstanceCount（C，A）：在查询流中提及形式为“A E”或“E A”的查询的C中不同实体E的数量；

l QueryCount（C，A）：“A E”或“E A”形式出现的流中查询的总数，其中E表示C的实例。

InstanceCount（C，A）指示属性A在C的实例中出现的频率，而QueryCount（C，A）指示属性A在查询流中出现的频率。这些值指示特定A是否是属性 - 具有低计数的候选属性A通常是噪声。对于每个三元组，（A，E，f），我们进行如下处理（见图3）。

l 在Freebase中协调E与实体E。这个步骤本质上是启发式的：有时我们会将e匹配到错误的实体，更有甚者找不到匹配项。识别器返回候选实体的排名列表后，我们会保守地选择第一个。有些情况下，我们会错过有效的映射（如对于苹果，识别器将返回公司和水果，但我们只选择公司）。然而，我们可以保守，因为即使我们错过了一些实体，它也不会降低模式级提取。仍有大量公司名不会与水果混淆，因此能够以较高的可靠性发现公司的财产。

l 通过给定E的值查找Freebase中的所有类C 1...C n，其中E已知隶属其中。对于每对（C I，A），InstanceCount（C，A）的值加1，并将C添加至QueryCount（C，A）。

删除共同引用：搜索查询中通常的模式是通过限定符跟踪实体。例如，许多用户查询barack obama总统（美国的每个总统亦如此），于是我们可以提取PRESIDENT作为美国总统的顶级属性，而这并不是理想做法。为了过滤这样的提取，我们在网络文本中查找表明BARACK OBAMA是总统的证据。通过运行一个标准的参数解析算法[13]来查找字符串“barack obama”和“president”在文本语料库中指向同一个实体的次数是否足够多。对于共同引用字符串对，我们不增加计数器InstanceCount（C，A）和QueryCount（C，A）。而是维持一个计数器CoReferences（C，A）来跟踪共同参考事件的数量。

输出候选属性：Biperpedia保留InstanceCount（C，A）高于设定阈值的任意对（C，A）。 属性的来源包括计数器InstanceCount（C，A）和QueryCount（C，A）。

5. 从网页文本中提取

Web上的文本为Biperpedia提供了更丰富的属性来源，并在很多方面与从查询提取的属性互补。虽然查询能够反应人们所希望的属性，但文本能够提供更多实体的百科全貌概览（如维基百科，新闻文章，新闻稿，产品手册等）。例如，虽然许多人查询一个城镇当前的MAYOR（市长），但对其FIRE-CHIEF（消防队长）的查询却相对较少。此外，从文本中提取属性还可以用来确认该属性的来源是查询还是从其他来源提取。在本节中，我们将介绍如何从文本中提取Biperpedia的属性。所面临的主要技术挑战是从文本中提取属性可能有很多无关信息。在本节中我们的主要技术贡献是展示通过使用查询流和Freebase的提取来训练高质量的文本提取器。

但在描述提取过程之前，我们先回顾并讨论两个广泛存在的问题：（1）我们是否可以像查询一样手动定义一小部分模式来取代提取器？ （2）我们的提取目标是开放域，那么是否简单地利用现有的开放信息提取系统，而不是设计一个新的提取器？

第一个问题的答案是否定的，我们将在本节稍后提供实证证据证明在实践中需要大量的提取模式。直观的原因是，在文本中，属性可能与实体以各种方式共同表达，而不像简短的查询文本，仅允许几种可能的属性表达。

第二个问题的答案也是没有，下面将详细讨论之。

我们可以利用现有的开放域系统吗？如前所述，Biperpedia的目标是模式级的属性提取，而大多数现有的开放域提取系统则输出事实。原则上，可以使用常规开放域提取器的输出来获得属性而不是属性值。例如，可以提取（PERSON，STARRED IN，MOVIE）的许多实例，并假定STARRED IN是适用于PERSON的属性。然而，该方法存在一些限制，这在各种现有的开放域提取器的上下文中被最好地表现出来。

ReVerb系统[9,10]在实体之间提取类似“加星标”和“被选为”地二进制关系。每个关系被限定为动词短语或满足词性标签上以动词为中心的正则表达式。由于许多属性如CULTURE或POLICE-CHIEF通过动词短语表示显得不自然，因此存在局限性。其次，对于删除重复动词短语并规范化到一个名词短语的形式是不平凡的。例如，我们需要能够将STARRED IN，IS THE STAR OF和HAS ACTED IN归一化为名词短语形式LEAD ACTOR，同时排除附带表达反向属性的紧凑短语，如STARRED。

OLLIE系统[18]是对ReVerb的改进，因为它也引入名词短语模式，所以可以提取诸如POLICE-CHIEF的属性值。虽然有所改进，但仍然不能正确处理像“巴西的咖啡生产增加5％”的情况。在这句话中，提取的关系将会是“巴西咖啡生产”和“5％”之间的“升”，而不是巴西和咖啡生产之间的理想关系。直接学习连接巴西和咖啡生产的模式显得更为简单。

最后，NELL系统[5]有一组限制在≈600的关系（包括反转），所以不能得到一个巨大的属性集。

鉴于以上所述问题，我们采取直接学习将实体连接到属性的模式的方法。实体和属性都假定为名词短语，这就避免了删除属性的动词重复形式到规范名词短语的问题。值得注意的是，即使在名词短语属性的情况下也需要删除重复数据（如LEAD ACTOR和STAR ACTOR应该相同），但是在这里我们使用第6节所描述的同义词检测系统。

由于我们已经从Freebase和查询流中提取了高质量的属性，因此应用远程监控从文本中提取属性就显得很自然了。

5.1. 通过远程监控提取

Biperpedia通过诱导一组（实体，属性）的提取模式并将它们应用于文本语料库来从文本中提取属性。这些模式利用一组标准自然语言处理（NLP）原语。例如，一旦我们在文本中识别出名词短语，我们就可以应用词汇模式“ A of E ”，其中A和E与名词短语匹配，并分别表示属性和实体。类似地，一旦文本被依赖解析器处理（这里，依赖关系标签所指的是“possessive（占有）”），解析模式“E poss> A”就会将第二名词短语标识为属性。我们注意到，诱导模式需要扩展以提取属性的值。

我们使用远程监控[19]和从Freebase提取的高质量属性以及查询流来从文本中诱导提取模式。远程监控已经成功地用于各种大规模提取任务，如[19,27]。在远程监控中，不提供监控语料库（获取代价高），而是提供包含了我们希望提取的类型样本事实的知识库（KB）。在我们的例子中，KB是从已经由Biperpedia提取的顶部属性创建的。之后，我们假设如果在一个句子中看到该KB中的一对相关实体，则该事实表示对应关系。例如，考虑图4的左半部分。假设我们知道COFFEE PRODUCTION是巴西的一个属性。如果我们看到文本“巴西的咖啡生产增长了5％”，我们可以断定词汇模式“The A of E”和解析模式“A prep> of pobj> E'是连接属性和实体的候选模式。

我们已经获得按频率排序的候选模式的聚集列表，以及它们覆盖的已知属性的数量。表1展示了由此诱导的一些顶部词法和解析模式。我们选择由至少10个不重复的（实体，属性）对得出的所有模式，并且在文本语料库的子集中至少访问10次。

 

使用诱导模式的属性提取：我们对所有文本应用以下自然语言预处理器：词性标记器，依赖性解析器，名词短语分割器，命名实体识别器，参数解析器和实体解析器。这些步骤是必要的，因此我们可以定义如前所述的特定提取模式。参数解析器将代词和名词解析为实体，从而增加覆盖。例如在文本“约翰·史密斯住在伦敦。 [他的]（妻子）...“，参数解析器会告诉我们”他的“和”约翰·史密斯“是同一个实体，所以”妻子“实际上是”约翰·史密斯“的一个属性。 实体解析器将所提到的实体映射到Freebase，使我们可以像对查询流一样实现从单个提取到类的推广。

 

诱导模式随后通过使用词法和解析模式匹配器在大量NLP处理的网络爬虫语料库（图4的右半部分）上加以应用。非名词性（即名词）匹配的属性将被丢弃。该步骤输出形如（A，E，E-ID，f）的一组提取元组。除了E-ID是E的Freebase id外，这些元组与来自查询流的提取具有相同的形式。这些元组以与查询流完全相同的方式进行处理。

图5展示了顶部诱导提取模式的产量。虽然我们诱导了超过2500个模式，但前200个模式占比却达到提取的99％以上。同时有超过6％的提取没有模式覆盖，这意味着我们确实需要一个模式感应管道来学习大量的模式，而不能简单地使用一小组手写模式。

 

5.2. 属性分类

我们已经可以从Web文本中提取的大量属性仍然需要一个方法对添加到Biperpedia的属性加以选择。鉴于Biperpedia的预期用途（例如，添加到Freebase，问题回答和表解释），Biperpedia将关注于具有清晰定义的值的原子属性。特别地，我们的目标是区分原子数值（如COFFEE PRODUCTION）以及来自非原子属性（诸如CULTURE和HISTORY）的原子文本属性（如POLICE-CHIEF）。将属性分类为原子与非原子还为未来检测元数据（如范围和单位）以及最终提取属性值提供了可能。

技术挑战是对属性在不提取值的情况下进行分类（这是一个更难的问题）。下面描述的算法演示了自然语言处理的另一个好处。具体来说，因为我们的文本语料库已经做过预处理，所以语料库中每个句子的依赖性语法分析信息都已经掌握了。由于每个属性是一个名词短语，我们知道句子中的动词是一个语法主题（由nsubj依赖性标签指定）。我们发现，一个属性的最频繁的动词列表可为分类任务提供很多信息。例如，通过查看文本“巴西的咖啡产量增加5％”，我们可以推断咖啡生产是一个数字属性，因为动词'增加'与数字属性正相关。同样，通过查看“纽约警察局长今天辞职...”这一文字，我们可以推断出POLICE-CHIEF不是一个数字属性，因为动词'辞职'与数字属性负相关。

注意我们的分类并不详尽，因为存在其他种类的属性在我们的三个类别（如电话号码，日期，拼写错误，离散值属性等）中未完全覆盖。他们将被分到第四类其他，这是一个相对非结构化的“背景”类别。接下来将描述如何为这三个更结构化的兴趣类别学习三个独立的二元分类器。

特征。原始特征列表只是top-k动词的集合，是文本语料库中属性的nsubj父节点，其中k是通过交叉验证设置的。其与属性一同从文本中提取而来（参见图4）。可以通过添加额外的语言提示（如形容词，修饰符和附加到属性的特殊子句）来丰富此特性空间，这是我们未来工作中需要探索的方向。

表2展示了一些样本属性的前几个动词。如前所述，像COFFEE PRODUCTION和ENROLLMENT这样的数字属性与诸如增加，下降等动词词义具有很强的相关性。经常出现的动词如have, say, become等存在于每个类别中，最终在训练期间将给予低权值。

 

然而因为我们只有有限的训练语料库，使用原始词汇作为特征会因为巨大的词汇量以及测试时未知的特征导致过度拟合。因此，我们采用相对标准的特征散列技巧将动词向量减少到具有预设维度d的标准空间内。更具体地，每个动词v i都被Hash到维度h（v i）mod d的标准空间中，其中h是散列函数。散列具有额外的优点，即不需要绕过特征词典，仅需存储散列函数h和d。

分类器。使用逻辑回归模型组合获得的最终散列特征，其权重由小型手动标记属性语料库学习得到。使用L1和L2来对模型进行正则化，即优化以下训练目标：

 

其中W是待训练的权重向量，F（xi，yi）是用于训练属性xi的哈希特征向量，标记为yi∈{-1,1}，λ1，λ2是使用交叉验证的L1 /L2超参数集合。该目标使用现成的标准二阶解算器进行优化。我们着重为三个感兴趣的类别学习单独的模型（即W向量），并且通过网格搜索和交叉验证为每个分类器分别调整超参数λ1，λ2，d，k。

实验。我们使用5层折叠的交叉验证手动标记的1212个属性的语料库训练和评估三个分类器。这些属性属于16个不同的类，以避免在训练期间的任何偏差。我们将我们的分类器与一个简单的基准进行比较，给每个属性赋予多数标签（正或负）。我们的目标是发现动词签名在该基线上有多少有助于对属性的分类。

表3列出了三个任务的分类结果，使用超参数的最佳设置。感兴趣的两个指标是：仅通过正标签确定精确度/召回/ F1（即在三个任务中分别将属性标记为数字，原子文本或非原子），以及在正和负标签上两者的总体精度。我们发现我们的分类器可以识别具有相当高的正F1分数和总体准确性的原子属性（数字和文本）。数字属性特别容易识别动词签名，总体精度为93.9％。而非原子属性则显得相对较难，即使有动词签名帮助我们在基线上提高了近10个绝对点，其仍具有较低的F1分数。

 

我们观察到三个任务需要不同长度的动词签名（即k）。只有50个动词足以识别数字属性，其他属性需要更多的动词凭证来做出决定。图6绘制了不同k值，三个分类器的正标签F1以及总体精确度。我们发现，对于所有的分类器，性能提高到一个点后（特定k）就开始逐渐减少/平坦化。这是可预料的，因为系统最初受益于逐渐增多的信息动词，随着动词数量的增多辨别力便会下降，性能也便随之下降。总体而言，我们观察到50-200个动词足以以相当好的精度对属性进行分类。

 

6. 同义词检测

一般人们会在查询和网络文本中以不同的方式引用相同的属性。例如，TOURIST ATTRACTIONS和TOURIST SPOTS是同义词。此外，查询流包含许多拼写错误，而用户会认为搜索引擎将自动修复它们。Biperpedia的质量在很大程度上取决于其识别同义词和拼写错误的能力。我们注意到，拼写错误和同义词都取决于属性附加的类。

检测同义词和拼写错误是值得自己详细的处理，并不是本文的主要贡献。 为了完整性，我们会描述Biperpedia如何解决这些问题。在这两种情况下，我们使用内部的技术处理查询扩展[7]和拼写校正。

我们依靠搜索引擎实现拼写校正。给定类C的属性A，搜索引擎将为查询“C A”提出的拼写校正。如果一个校正是C的属性A'，则我们认为A是A'的拼写错误。例如，给定类BOOKS的属性WRITTER，搜索引擎将建议books writer是books writter的拼写校正。

为了检测同义词，我们训练SVM分类器，该分类器在一对属性A 1和A 2上使用以下特征：（1）Jaro-Winkler文本属性之间的相似性，（2）一个属性是否是另一个的子属性，（3）这两个属性是否已知为WordNet中的反义词[11]，以及（4）查询扩展的相似度。具体来说，我们比较“C A 1”和“C A 2”的查询扩展结果。扩展集合高度重叠说明A 1和A 2可能是同义词。基于我们在本文中没有报告的实验，我们估计基于SVM的同义词精度高达0.87。

7. 属性质量

在本节中，我们评估Biperpedia属性的质量，并将其与DBpedia [2]进行比较，DBpedia是一个自动从维基百科的InfoBoxes中提取的本体。

7.1. 实验设置

Biperpedia的当前版本使用略微超过10,000个类的层次结构构建。提取之后，合并同义词并仅将属性附加到最好的类上，最终得到了1.6M类-属性对，其中有67,000个不同属性名。（我们注意到，将属性附加到最佳类的步骤将类-属性对的数量减少了近50％。）如表4所示，Biperpedia大约是DBpedia的30倍。我们从Freebase中提取所有属性，但每个类仅从查询流中提取8000个属性，剩余从查询流中未提取的文本中添加4000个属性。我们注意到，从Freebase中提取的属性数量少于属性总数的6％。

 

我们实验了10个代表性类别（表5），所选择的一些宽泛，另一些狭隘。依旧显示相应的DBpedia类中的属性数量（如果存在）。

 

7.2. 总体质量

为了测量精度，我们设定一些k值，从top-k中手动标记100个随机选择的属性（当k≤100时标记为所有）。然后从3份评估中使用投票方式来确定属性对于该类是好还是坏。在表6中，我们使用两个不同的属性排名来测量精度：按查询排序 - 通过查询流中出现属性的类的实例数对类的属性排序，按文本排序 - 在文本中进行同样操作。 “精度”列指示标记为“好”的属性的分数。随着k的增加精度会下降，直到5000仍然超过0.5。注意到之前的工作[16,21]在k = 50时精度略低于本文k = 1000的情况。结果还表明除了此5000个以外还有许多的属性可以添加到Biperpedia，但是我们需要更集中的技术来识别它们。Freebase列显示良好属性也出现在Freebase中，其下降迅速。值得注意的是当k = 5000时99％的属性是Freebase的新属性，这显示了Biperpedia模式扩充的重要性。类似地，DBpedia列显示良好属性也存在DBpedia中（使用表5中存在于DBpedia的5个类别），其也随着k的增加而下降。

 

当按文本排序时，属性的精度比由查询流排序时属性的精度稍低。可以解释为：从查询流中提取可以比一般文本更精确。然而，在较低的等级下精度是类似的。虽然我们未在表中列出，但有趣的当k值较小时，查询流和文本中出现的属性的精度是相似的，但当k = 5000时精度差却高达8％。这是因为当一个属性在一个源中非常频繁地出现时，它不需要任何佐证，但是随着频率降低，佐证成为一个因素。

表7显示了属性的等级（k）与其同义词数量之间的有趣关系。 随着k增加，每个属性的同义词减少。例如，UNIVERSITIES类每top-10属性有2.8个同义词，但每top-1000属性只有0.75个同义词。因此排名较高的属性倾向于以多种形式表示。

 

7.3. 讨论

Biperpedia的分析揭示了几个重要的发现。首先，精度损失的最重要原因是由于映射字符串到Freebase中的实体的错误。例如，对于诸如COUNTRIES或US PRESIDENTS之类的实体链接相对比较容易，当k=5000时精度高达20-30％，而如FILMS和HOTELS等存在更高频率将字符串错误地链接到实体的，精度就会低于该数量。幸运的是，改进实体链接正在持续进行中。同样，Biperpedia不会提取其实例不足以在Freebase中存在的对象类的属性，如SPOONS。为了提取这些类的属性，Biperpedia仍然可以使用相同的提取模式，但不应该尝试将模式中的实体映射到Freebase，而是假定每一项是适当类的匿名实体。

其次，我们注意到许多高频查询的属性并不具体（如CULTURE，HISTORY）。这可以通过用户开始对这样的查询主题的探索来解释。我们还注意到，存在可以与其他属性相关联的更多属性的类。例如，地理位置往往具有许多属性，因为数量通常是相对于地理测量的。

最后，我们意识到Biperpedia的优势之一是提取多标记属性。这些属性往往更丰富，并且经常在Web表中出现。为了提取额外的这样的属性，我们以示例解释下面所实现的规则。如果POPULATION或RURAL POPULATION是来自查询流的高度排名的属性，那么我们推断诸如URBAN POPULATION一类的共享相同句法根（即“population”）的其他属性也是良好的，即使他们支持度并不高。对于表5中的每个类，我们从Web文本的前5000属性之外的属性中抽样了100个多标记属性，对其随机子集进行评估，得到平均精度为0.67。这比Web文本的前500个属性的精度（0.64）要好（表6）。使用这种方法，我们能够在维持平均精度的前提下使Biperpedia的大小翻倍。我们认为Biperpedia表明前5000以外属性中有很多良好属性待挖掘，但我们需要更集中的技术来获取。

8. 发现最佳类

如前所述，Biperpedia会将一个属性附加到它相关层次结构中的每个类。当我们想要验证一个属性是否与一个特定类相关时该做法是行之有效的，但是如果我们希望创建一个更模块化的本体或找到可以适配Freebase的属性，就需要找到最佳类供属性附加。

举例说明找到最佳类的技术挑战。假设我们要将属性BATTERY LIFE分配给图7所示的层次结构中的类。最顶层的CONSUMER_PRODUCTS太宽泛，因为并不是所有的消费产品（例如SHOES）都有电池。 相对的叶节点SLR_DIGITAL_CAMERAS和COMPACT_DIGITAL_CAMERAS太具体，因为任何数码相机都有电池。因此，DIGTIAL CAMERAS可以被认为是BATTERY LIFE的最佳类。使用类似的参数，COMPUTER_PERIPHERALS（DIGITAL_CAMERAS的兄弟类）也可以被视为BATTERY LIFE的最佳类。或者，如果BATTERY_LIFE适用于消费产品的绝大多数子类，我们就可以将其附加到CONSUMER_PRODUCTS。因此，寻找最佳类的挑战就是找到不太一般又不太具体的类，且能简化本体。

 

下面描述的算法的关键思想是为一个类中每个属性计算支持。然后将属性在该类中的支持度与其在父类和同级类中的支持进行比较，以确定属性的最佳位置。重要的是，支持度的概念使我们能够考虑多种方式做出安置决策。

我们的算法使每个属性的放置决定独立于其他属性。一个有趣的未来研究方向是使用先前的属性放置决定来驱动后续的放置。

8.1. 放置算法

算法1计算属性A的最佳类OA。非正式地，对于每个属性A，算法以自底向上的方式遍历A被标记为相关的类的每棵树（即包含（C，A）的类C的每棵树）。对于每对类和属性（C，A），我们计算C中A的支持度S（C，A），支持度从来源计算。例如，对于从查询流中提取的属性，支持度是包含A的C的实例数和C中属性的实例数最大值之间的比

 

文本提取的支持度也以同样的方式计算，且来自Freebase的属性的支持是1。我们将S（C，A）定义为从任何源获得的最大支持度。

算法需要做的关键决定如下。当有几个兄弟节点有足够的支持度时，他们都应该在OA中，或者我们应该继续类层次结构。 为了解决这个问题，算法计算兄弟节点的多样性测量。 如果兄弟节点之间几乎没有多样性，我们继续遍历树。如果有显着的多样性，即只有少数兄弟节点有足够的支持度，即输出这些兄弟节点。多样性定义如下。

 

其中C 1 ...C n是兄弟类。当多样性高于阈值θ（算法1中的第9行）时，我们将所有兄弟节点中支持度最高的节点添加到OA中。在我们的例子中，对于属性BATTERY LIFE，CONSUMER_PRODUCTS下的同级类的多样性将很高，因为一些消费产品具有电池，而另外一些没有。因此拥有高支持的兄弟类将被添加到OBATTERY LIFE。我们在实验中单独调整θ值。

8.2. 评估

我们对Biperpedia的属性应用算法1，评估分配50个属性到1100个类的结果。对于每个分配评估其是否满足（1）正确，（2）应该是直接父节点，（3）其中一个直接子节点，（4） 除同一层次的直接父子节点的类，或（5）完全错误。 如果属性被分配给其最佳类之一就被称为精确的，若被分配给最佳类的直接父节点或子节点则称为近似的。我们的结果考虑了几个精度度量：

 

l M exact：精确分配占所有分配的比率。

l M approx：近似分配占所有分配的比率。注意，近似赋值仍然是有价值的，因为人们只需要考虑类的小邻域以找到完全匹配。

与等同，但仅在第七节应用良好。

为了演示多样性指数的好处，我们还与一个strawman算法进行比较，当考虑具有足够支持度的节点n时，使用以下规则自下而上遍历树。当n的父节点的支持度等于n，或者有5个（调整以在实验中最好表现）及更多具有与n支持度相同的孩子节点时，算法沿着树继续遍历。否则，该属性将分配给n及其任何有足够支持度的兄弟节点。

表8所示的评估结果表明当θ为0.9（我们只选择实验中的几个值列在表中）时结果最佳，不管是未过滤还是过滤的属性算法都比strawman优越超过50％。即使是未过滤的属性，我们的算法也以72％的精度近似匹配，这为导入Biperpedia属性到另一个本体提供了一个良好的起点。与在θ = 1.0不被计算，因为在这种极端情况下，属性A将仅被分配给每个无直接父节点的相关根节点。实验中，α的值设置为0.1，但是我们注意到α（算法1中的第10行）主要影响返回类的数量，而不是结果的精度。

 

分析算法的错误是未来工作的一个有趣的挑战。我们的多样性措施高度依赖于人们对特定实体的兴趣。例如，用户经常查询总统的兄弟，但不是查询其他政府职称的人。结果，类GOVERNMENT_TITLES的多样性变得很大，并且算法会将属性BROTHER分配给类PRESIDENTS而不是GOVERNMENT_TITLES。但是，GOVERNMENT_TITLES是PRESIDENTS的父类，显然对BROTHER更加适合（但不是最终赋值）。一种可行的解决方案是在多样性指数的计算考虑出现的频率。

9. 解释WEB表

最后，如果Biperpedia可以改善搜索应用，其将是有用的。在本节中，我们展示了Biperpedia极大地提高了我们恢复Web表语义的能力。

在网络上有数以百万计的高质量HTML表格，内容非常多样化。除了回答在搜索引擎上许多用户的查询，通过有趣的方式对这些表进行组合可以产生新的数据集和发现。最近的几项研究主要集中在利用这些表[1,4,17,25,26]。Web表的一个主要挑战是了解表中表示的属性。例如，图8中的表格显示了SHIPS的GROSS TONNAGE和LOAD CAPACITY。在本节中，我们将介绍如何使用Biperpedia解释Web表。解释Web表是指使用Biperpedia属性附加的过程。我们可以将一个Biperpedia属性附加到一个特定的列（我们称为列映射），或者如果不能定位精确的列或属性名称不是由单列，就将属性附加到整个表（表映射）。如果我们可以将Biperpedia属性附加到表上，则当关键字查询包含这些属性时，搜索引擎可以给包含该表的页面赋予更高的权重，因为该属性在页面上比在其他地方的随意出现具有更重要的作用。因此，可以更准确地检索关键字查询的表。

 

翻译网页表也是Biperpedia召回的标志。特别是，使用Biperpedia解释的表的数量是Freebase的4倍。

9.1. 映射算法

我们描述了我们计算列和表映射的算法，原则上，它是一个关于模式匹配问题的变体，其中有大量的文献[8]。区别就是我们不给定一对模式及其对应表。相反，表的最佳描述属性可能在周围文本或页面的标题中。周围文本对于解释没有模式的Web表特别重要。 因此，我们算法的任务是将Biperpedia属性匹配到周围文本和页面标题中的列标题或标记n-gram。主要分两步。

（1）预处理：给定具有表头H 1...H n的表，其中H∈H1...H n，我们创建一组匹配的字符串集合SH。该集合包括H以及：

l 如果H超过3个标记，则我们将所有2-grams和3-grams添加到SH中。

l 如果H包含标记or或and，我们将该标记之前和之后的文本添加到SH中。

l 如果H列中的值都是C类的成员，则我们将C的名称添加到SH中。

我们还将以下字符串添加到SH中，但是只有当以上匹配项都找不到时，才会考虑以下情况：

l 如果H有多个标记，则通过连接单词首字母来添加缩略词。

l 我们添加属性的句法解析的根（例如POPULATION是RURAL POPULATION的根）。

我们还从页面标题的文本或紧邻表格的文本中所有的2-grams和3-grams中创建一个表级别的字符串集合T.

（2）匹配：我们假设每个表与描述其主题列中实体层次结构中的类C相关联。 如果我们没有主题列，或者类的预测是低置信度的，便忽略该表。

考虑Biperpedia对于C类的所有属性，尝试将它们的名称与T和SH1...SHn中的元素相匹配。我们使用Jaro-Winkler字符串相似性来查找近似匹配。若在SH中找到一项匹配，就将它们输出为列匹配，若在T中找到匹配，则将它们输出为表匹配。

示例：在图8中，主题列的类为SHIPS。列“Beam”直接映射到属性BEAM，列“GT”作为首字母缩略词映射到GROSS TONNAGE。在预处理期间，第四列将标记为COUNTRY，并将映射到属性COUNTRY。LOAD CAPACITY属性将作为表映射输出。事实上，列“Beam”，“Max TEU“和”GT“确实描述了船舶的负载能力。图9所示为Biperpedia为没有模式的表找到有用映射的示例。

 

9.2. 评估

我们评估了映射算法对从Web提取的大约200个表的精度。我们选择了质量相对较高的表格，而不是呈现非表格内容的HTML表格。同事使用了WebTables的主题列注释器以及与其相关的类[24]。除了所有表集合，我们还做了如下实验：（1）一组具有更高质量和更多列的维基百科表，（2）没有模式的表的集合（即传统的模式匹配算法不会返回任何内容）。

为了评估列匹配，我们测量了精度（正确匹配的百分比）和召回率（正确映射列的占比）。 然而，并非所有列都具有相同的重要性，并且表映射具有很多优势。为了测量这一点，我们假设每个表都具有一个或多个代表性属性。直观地，这些属性应该能使表从查询中检索，因为它们保存了表的本质。例如，属性LOAD_CAPACITY可以被认为是代表图8中的表，而LIFE SPAN代表了图9中的表。代表性属性不需要对应于表中的单个列。我们请求我们的评估者判断映射是否捕获他们认为的表的代表属性。

9.2.1. 解析质量

表9展示了基于3个评估器的质量评价结果。Representative列显示至少找到一个正确的代表属性的表的数量。Overall (P/R)列为所有映射的平均精度/召回率。Avg. P/R per table计算每个表的精度/召回率，然后计算所有表的平均值。对于完整数据集，有46％是正确的（每个表51％），所有列的75％由一个属性（每个表78％）覆盖。我们能够在82％的时间内使用代表属性来捕获表的本质。

 

仅考虑维基百科表，精度和召回率略低的两个原因有：首先，维基百科表往往有更复杂的周围文本，会导致一些错误的映射。这一点可以通过使用IR技术，通过基于周围文本的重要性计算单词的权重来解决这个缺陷。第二，维基百科表往往有更多的列，因此更难正确地映射。

最后，我们考虑了一组没有模式行或WebTables不能识别模式行的表。对于这些表，没有常规模式匹配技术可以提供任何解释。在某种意义上，这些是在语料库中最难解释的表。 然而，通过生成表映射，我们仍然能够找到78％的表的代表性属性，并获得重要的精度和召回率值，虽然略低于维基百科表。这个实验证明，通过使用一个大的属性本体，即使他们没有模式，我们依旧能够找到描述Web表的方法。

9.2.2. 与Freebase的比较

下一个问题是这些映射中有多少是由于Biperpedia与已经存在于Freebase中的属性。 表10中的结果表明绝大多数是由于Biperpedia的额外属性。第一组列显示了到Biperpedia属性的映射数量，映射到Freebase属性的数量以及它们之间的比率。例如，当映射完整数据集时，807正确映射中的142个是Freebase属性，因此 Biperpedia与Freebase相比，覆盖率提高了5.7倍。 第二组列显示了用于映射到代表性属性的各个量。对于代表性属性，改进因子甚至更高，因为代表性属性更复杂，因此不太可能在Freebase中找到。对于没有模式的表，相对覆盖率甚至更高。

 

9.2.3. 错误分析

表11的顶部显示了我们的算法的两个最常见的错误，原因是周围文本和页面标题中的噪声标记n-gram被映射到与HTML表无关的属性。我们可以通过使用更好的IR / NLP技术来优化与表格更“相关”的n-gram来减少此错误。 最后一个原因是使用查询扩展对列标题的各种不正确的字符串匹配。这里，更明智地使用查询扩展可以减少错误。

 

表11的下半部分考虑检测代表性属性中的错误。 最大的错误原因是当表描述涉及另一个常数时（例如，不同年份的Ballon D'Or奖的获奖者）。可以想象，我们的类层次结构应该包含类BALLON D'O R W INNERS，但无论多么详细，类层次结构总是有空隙。第二个原因是当列标题或上下文中没有足够的信息与属性进行比较时。这里，到页面的外部链接可以提供额外的证据。第三个原因是三个评估器同时否决任何代表性属性，但一些属性确实是代表性的。第四个原因是Biperpedia的覆盖不足，仅适用于9％的情形。最后的原因是当属性名称不是2-gram或3-gram，并且需要更复杂的名词短语识别。

10. 相关工作

我们已经在整篇文章中谈到了几个相关的作品。 我们在这里关注其他属性提取的工作。 Pasca等人[21，22]是第一个探索使用查询流数据生成实体的属性，他们的主要成果是查询流比文本的属性提取准确率高出45%。虽然我们的结果与观察结果一致，然而我们更进一步显示查询流可以用于从文本中提取种子。此外，我们解决了从查询流和其他来源提取出现的拼写错误和同义词的问题。Biperpedia的规模比以前的工作大得多。特别是，他们报告的前50个（这是他们考虑的最大排名）的精度略低于我们在排名1000的精度。最后，我们证明了广泛的属性集合有利于解释HTML表。

Lee et al[16]解决了确定类C如何被赋予属性A或者属性A被赋予类C的典型相关问题。相反，我们集中于通过识别同义词，拼写错误，以及属性对之间的关系构建具有属性的本体。它们还具有从查询和Web文本中提取属性的管道，但是存在几个关键的区别。首先，他们以两种模式从文本中提取属性，而我们已经表明，要获得一个相当大和高质量的本体，需要使用数百个模式。第二，它们独立于源提取属性，而我们使用来自查询流的高质量提取来对我们的文本提取种子。它们还执行概念水平提取，我们没有进行，例如使用诸如葡萄酒酸度的模式来提取WINES类的属性。他们在50级报告的精度与我们在1000级报告的水平相同。Lee et al.提及将Web表作为其工作的动机，但未提及将其属性应用于此任务。

11. 结论

我们描述了Biperpedia，一个二元属性的本体，它扩展了Freebase，并从查询流和Web文本中提取属性。我们提取的关键思想是使用来自Freebase的高质量属性和查询流来从文本中进行种子提取。我们演示了Biperpedia的实用程序，它可以解释超过Freebase4倍的Web表。我们目前正在将高质量的属性从Biperpedia添加到Freebase中。

除了改进和扩展我们的类层次结构和用于将字符串解析为立即对Biperpedia有益的实体的算法之外，我们还在追求两个主要方向。首先，我们正在开发用于分类对和属性之间的不同关系并从Web文本中发现它们的方法。第二，我们有意挖掘复杂属性名的语法。例如，我们希望能够识别，INCREASE IN TOTAL ASIAN POPULATION描述了属性ASIAN POPULATION的改变。这种解释对于理解大量高质量Web数据至关重要。

最后，从搜索应用程序的角度来看，我们的算法可以应用于可能具有不同结果的任何查询流。例如，将我们的方法应用于来自移动设备的查询流将不同于一般查询流的属性，并且需要适配于流量需求搜索的本体。

12. 引用

[1] M. D. Adelfio and H. Samet. Schema extraction for tabular data on the web. PVLDB, 2013.

[2] S. Auer, C. Bizer, G. Kobilarov, J. Lehmann, R. Cyganiak, and Z. G. Ives. Dbpedia: A nucleus for a web of open data.In ISWC/ASWC, pages 722–735, 2007.

[3] K. D. Bollacker, C. Evans, P. Paritosh, T. Sturge, and J. Taylor. Freebase: a collaboratively created graph database for structuring human knowledge. In SIGMOD Conference,pages 1247–1250, 2008.

[4] M. J. Cafarella, A. Y. Halevy, D. Z. Wang, E. Wu, and Y. Zhang. Webtables: exploring the power of tables on the web. PVLDB, 1(1):538–549, 2008.

[5] A. Carlson, J. Betteridge, B. Kisiel, B. Settles, E. R.Hruschka, and T. M. Mitchell. Toward an architecture for never-ending language learning. In AAAI, 2010.

[6] C. Chambers, A. Raniwala, F. Perry, S. Adams, R. R. Henry, R. Bradshaw, and N. Weizenbaum. Flumejava: easy, efficient data-parallel pipelines. In PLDI, pages 363–375, 2010.

[7] H. Cui, J.-R. Wen, J.-Y. Nie, and W.-Y. Ma. Probabilistic query expansion using query logs. In WWW, pages 325–332, 2002.

[8] A. Doan, A. Y. Halevy, and Z. G. Ives. Principles of Data Integration. Morgan Kaufmann, 2012.

[9] O. Etzioni, A. Fader, J. Christensen, S. Soderland, and Mausam. Open information extraction: The second generation. In IJCAI, pages 3–10, 2011.

[10] A. Fader, S. Soderland, and O. Etzioni. Identifying relations for open information extraction. In EMNLP, pages 1535–1545, 2011.

[11] C. Fellbaum. WordNet: An Electronic Lexical Database. Bradford Books, 1998.

[12] J. R. Finkel, T. Grenager, and C. D. Manning. Incorporating non-local information into information extraction systems by gibbs sampling. In ACL, 2005.

[13] A. Haghighi and D. Klein. Simple coreference resolution with rich syntactic and semantic features. In EMNLP, pages 1152–1161, 2009.

[14] M. A. Hearst. Automatic acquisition of hyponyms from large text corpora. In COLING, pages 539–545, 1992.

[15] J. Lee, J.-K. Min, and C.-W. Chung. An effective semantic search technique using ontology. In WWW, pages 1057–1058, 2009.

[16] T. Lee, Z. Wang, H. Wang, and S.-W. Hwang. Attribute extraction and scoring: A probabilistic approach. In ICDE, pages 194–205, 2013.

[17] G. Limaye, S. Sarawagi, and S. Chakrabarti. Annotating andsearching web tables using entities, types and relationships. PVLDB, 3(1):1338–1347, 2010.

[18] Mausam, M. Schmitz, S. Soderland, R. Bart, and O. Etzioni. Open language learning for information extraction. In EMNLP-CoNLL, pages 523–534, 2012.

[19] M. Mintz, S. Bills, R. Snow, and D. Jurafsky. Distant supervision for relation extraction without labeled data. In ACL, pages 1003–1011, 2009.

[20] N. Nakashole, G. Weikum, and F. M. Suchanek. Patty: A taxonomy of relational patterns with semantic types. In EMNLP-CoNLL, pages 1135–1145, 2012.

[21] M. Pasca and B. V. Durme. What you seek is what you get: Extraction of class attributes from query logs. In IJCAI, pages 2832–2837, 2007.

[22] M. Pasca, B. V. Durme, and N. Garera. The role of documents vs. queries in extracting class attributes from text. In CIKM, pages 485–494, 2007.

[23] T. Tran, P. Cimiano, S. Rudolph, and R. Studer. Ontology-based interpretation of keywords for semantic search. In ISWC/ASWC, pages 523–536, 2007.

[24] P. Venetis, A. Y. Halevy, J. Madhavan, M. Pasca, W. Shen, F. Wu, G. Miao, and C. Wu. Recovering semantics of tables on the web. PVLDB, 4(9):528–538, 2011.

[25] J. Wang, H. Wang, Z. Wang, and K. Q. Zhu. Understanding tables on the web. In ER, pages 141–155, 2012.

[26] M. Yakout, K. Ganjam, K. Chakrabarti, and S. Chaudhuri. Infogather: entity augmentation and attribute discovery by holistic matching with web tables. In SIGMOD Conference, pages 97–108, 2012.

[27] L. Yao, S. Riedel, and A. McCallum. Collective cross-document relation extraction without labelled data. In EMNLP, pages 1013–1023, 2010.