译自:ParsCit: An open-source CRF reference string parsing package (部分)

0 摘要

我们这样描述ParsCit:一个自由,开源的参考文献解析包。ParsCit的核心是一个被训练完成的CRF模型,它被用来标记参考文献字符串的序列。这个启发式的模型对一个纯文本文件进行分割和识别。这个包可以直接运行,或者作为一个web服务器使用。

我们用3个不同的数据集来比较ParsCit,并用它和之前已出版的作品比较。

1 介绍

在学术著作中,我们通过参考文献的方式让别人知道前人的贡献。在论文的最后一节通常用参考列表或者书目的形式列出引用的作品。这种形式的确认是帮助读者和审阅者联系当前工作和前后研究论述的确认的关键。

一个正在被书目研究界内重点进行的项目是从底层的源文件自动创建引用网络。一个先决条件是用程序的方式还原指向和被指向的文件的联系,这需要一台机器理解参考文献字符串之间的关系。每个参考字符串都可以被看成是一组字段(比如,作者,标题,年份,期刊),作为被表明的字符串,用标点符号等来还原内容。然而,在解析这些参考文献的结尾的字符串的时候,往往由于人为的,或者不同社区的不同标准,外加部分作者的疏忽错误,使得这项工作难以被自动进行。

现在已经有很多处理这种序列标记的方法(Peng和McCallum, 2004; Giles等, 1998),在本文中,我们描述了我们在实现的这个使用的机器学习和启发式处理框架和系统ParsCit。

虽然已经有很多方法被提出来解决这个具体的问题(Huang等, 2004; Cortez等, 2007),我们的贡献在于:1)为解决这个问题制定了新的特征2)自动抽取引用文献的上下文3)把我们的的成果打包为一个软件模块,可以被作为一个基础服务,或者作为一个web服务器4) 为了社会的利益,我们的代码是开源的。

在本文的下面部分,我们讨论这个机器模型的核心,和按照顺序为一个能使用的服务做出的详细的预处理和后处理步骤。然后,我们描述实施的细节和使用的工具包,并总结和比较相关的工作。

2 学习模型

首先,我们正式定义要解决的问题。我们定义参考字符串R为首先被分解的标记序列,它被分解为{r1,r2,...rn}.每个标记被分配到一组正确的类令牌下C={c1,c2,...cn}下。显然可以被使用为任意的由文献引用字符串获取到的数据,也可以是一些之前分配的r1 ... rn之间的分类。

这个序列标注问题是自然语言处理中的常见任务,包括部分词性标注,上堆下切法,语义角色标注。同时它也预示了可以参考这类问题的解决来通过本问题。即,将这些元数据标注为一系列类的数据,比如作者,标题,期刊等。在我们的实现中,总共有13个类被标注,对应于通常使用的参考文件管理软件(比如EndNote, BibTeX ).

我们使用条件概率域(Lafferty等, 2001)形式学习一个模型,它可以应用到未知数据。这个学习模型易于测量,处理大数据。我们列出ParsCit系统使用的功能的一般,在括号内给出的数目表示各个类别的模块数量。

  1. 令牌确定(3) : 我们有三个模块是对如下三种不同形式的特征进行编码:1) as-is 2)小写3)无标点的小写。
  2. N-gram的前缀/后缀(9) : 我们有四个特征是对令牌的前四个字符进行编码,同样的,对后四个字符也进行编码。一个单独的特征还检查令牌最后一个字符,看它是大写,小写或者是数字。
  3. 拼写形式(1) : 我们分析令牌的情况,将其分配为四个值之一: 首字母大写, 混合大小写字格式, 全部小写或者其他。
  4. 标点符号(1) : 同样的,我们给出对令牌中标点符号给出详细的区分,比如: 引号开始,引号结束,多个连字符(页面中偶尔发现),继续标点符号(比如,逗号,分号),停止标点符号(比如,句号,双引号),配对的括号,可能的卷标(比如"3(4)"),或者其他。
  5. 数值(1) : 我们分析数值可能所在的令牌。这个模块的价值是具体的,比如,年份(19xx到20xx中的一个值),可能的页面范围(包括的[0-9]([0-9]*)),可能的卷标(包括[0-9]([0-9]*)),序号(包括那些后缀为"th"字样的),或者一般的类别: 4位,3位,2位,1位,有数字,没有数字。
  6. 字典(6) : 独立分析检查令牌是否符合某个关键的出版商名称,地名,姓氏,女性和男性的名字,这些值被存储在一个哈希表中。
  7. 地点(1) : 我们编码使得相关的地点放在,离散的放在n个均匀的箱中(通过实验,我们设置n这个值为12)。在大多数情况下,比较重要的数值,比如作者,标题,年份一般是在比较靠前的位置,这个特征试图通过CRF学习捕捉到令牌的序列
  8. 可能的编辑(1) :这个特征表示前面是否有个关键词,比如"eds."

注意,我们的的许多特征(比如,拼写形式,数值,标点符号)使得区别变得更加细粒,这些使得性能大大超过以前的工作。同时,我们可以观察到,在以往的工作中,作者和编辑经常被错误的分离,为了纠正这点,我们明确的增加编辑这个特征,使得两者区别更大,而更容易被分清。

3 预处理阶段

在参考文献字符串被正确的抽取之前,我们首先需要找到一篇文章的引用。虽然格式(比如,字体的变化)可以被用在帮助区分,但是依赖于特定的格式会导致一般性的损失。为了这个原因,ParsCit假定文件被首先转换纯文本格式,编码为UTF-8。那么某些类型(比如PDF)的被高度格式的文件的抽取是非常困难的。但是,进行适当的抽取是有必要的。

得到一个UTF-8的纯文本文件,ParsCit通过一组特征寻找参考文献字符串。它首先寻找文本的令牌,令牌可能包括如下字符串:"References","Bibliography","References and Notes",或者一些类似的普遍变化,比如参考文献部分字符串被分割的更加厉害。如果令牌被发现的过早(默认配置为40%),则开始继续搜索。最后选定的那个位置确定为参考文献的开始部分。然后开始寻找令牌,寻找后面的令牌,比如"appendices","figures","tables","acknowledgments","autobiographies"等等,或者文件的结束。

一旦完成参考文献的抽取,下一阶段是把参考文献字符串分割。一般情况下有如下三种方式作为参考: 1)有方括号括起来的数字或者字符串,(比如“[1]”,“(1)”,“[Heckerman02]”等) 2) 字符串有纯数字,(比如"1","1.") 3)字符串无标记(比如在APA格式下)。因此,第一步是找到标记不同的引文列表,对于1和2的情况,通过构造一些常见的标记样式和正则表达式匹配,然后计算每个表达式的匹配情况。如果这两种情况不能匹配文中数量的1/6,就使用匹配最大的来表示。这两种情况下,被用来查找标记类型相同的正则表达式可以被用来指示文献引用的起点,并以此来分割参考文献。如果没有发现引用字符串,一些启发式的方法被用来确定字符串的开始和结束,比如:根据之前行(短长的表示可能是参考字符串的最后一行),看似是作者姓名列表的(通常是在没有标记的引用字符串前面),结束标点之前(通常引用最后一段将结束一段距离)。

这个列表被独立的写入之前讲过的CRF++模型,并应用于数据。

4 后处理步骤

基于运行CRF++的输出,一些步骤是必要的。比如每个标签字段转换为标准的表示。作者姓名中可能发生的各种变化,比如 “M.-Y. Kan and I. G. Councill”和“Kan, M.-Y. & Councill, I. G.”。名称字符串首先必须要被分割成分和位置(比如通过逗号,分号区分),然后归类到“M-Y Kan”和“I G Councill”形式。标号字段,比如刊物的卷标和数量,要标准化,使得只有数字保留(比如"vol.5"被标准化为"5")。同样的,只有日期字段的年份被保留。最后,页码被标准化为"开始-结束"形式,比如字段"pp. 584-589"变成了"584-589".

5 抽取引用上下文

基于在后处理的过程中产生的参考文献标记的基础上,一个或者多个正则表达式生成,被用来扫描文本的正文内容。这个表达式基于三种类型的标记(对应于引用字符串分割上述三种情况)。对于明确的标记,用方括号或者括号括起来的字符串,标记直接转换为正则表达式,直接的数字标记(比如"1"或者"1.")括号以及括号表达式转换为优先考虑放括号表示,如果已有方括号表示,则括号表达式不再放在正文中考虑。标记有足够的灵活性来处理参考文献列表中发生的各种状况,比如(比如,"[12,2,5]")和参考文献上下文内容(比如,"see Figure(2)")不匹配的情况。

最后,字符串无标记(比如在APA格式下),将在产生的基础上,将作者和出版年份的姓氏,创建各种形式的标记。很多标记格式会被创建,比如Poljak,Rendl和Wolkowicz在1994年可能会被标记为如下的样式: 1) “Poljak, Rendl, Wolkowicz, 1994”, 2) “Poljak, Rendl, and Wolkowicz, 1994”, 3) “Poljak, Rendl, & Wolkowicz, 1994”, 和4) “Poljak et al., 1994”。一些额外的为了增加灵活性,省略掉标点符号,内置的表达式就不在此一一列举。每个正则表达式应用到正文内容中,然后生成一个所有的上下文匹配列表。这个上下文字符串的大小是可以配置的,但默认情况下,是在匹配位置任一侧上延伸到第200个字符。对于长文档,可以设定匹配次数。

8 相关工作

引用解析问题是由之前的一些研究的开始被关注的(Cameron, 1997; Lawrence 等,1999)。我们测试现有的分析器,一般可以分为两类,模式匹配和机器学习为基础的方法。

模式匹配的方法需要输入引用,匹配已知的模板。使用最匹配的模板,然后使用令牌作为引用字段标签。基于模板的方法的典型例子是ParaTools (Jewell, 2000),一组perl模块执行参考字符串的解析。ParaTools包含400个模板,用来比对引用字符串,但是即便如此浩大的数量,也有着大量的问题。即便用户可以选择手动的在ParaTools中添加新的模板,过程也是繁琐和不可扩展的。事实上,作者可能不会严格的坚持引用样式或者文本提取或者OCR参考字符串可能会产生不严格的模板也会削弱这个程序的有效性。一个进一步使得ParaTools效用降低的特征是它将模糊不清的领域定为"任何",这相当于没有进行任何标注。(Huang等,2004)报告ParaTool的精确度为约30%。这种级别的性能和缺乏可移植性的方法不适用于大数据的处理。

基于模板的方法的局限性,激励着研究者们尝试使用机器学习模型。给定足够的训练数据,可以生成一个基于机器学习的无论是什么类型的文献引用都有比较高的准确率的高性能解析器。我们回顾一下这几年在发表的四种处理这个工作的系统。

Seymore等在1999年的领导工作Cora数据集。他们使用隐马尔可夫模型(HMM)建立了一个参考文献字符串序列标注器。不同于标准HMM,他们使用内部状态作为处理不同区域,来实现并验证性能(类似于其他标注任务的IOB编码)。这个小组在之后的工作中,Peng和McCallum(2004)使用参考文献解析任务作为测试条件随机域(CRF)的基准。他们的工作使得CRFs学习模型成为这项工作的优先选择。这项工作促使我们同样选择CRF作为ParsCit的模型的基础。

第一个版本的ParsCit使用最大熵(ME)的训练来训练一个模型(Ng,2004)。除了使用ME外,这可以看作是迈出隐马尔可夫模型一步的另外一种判别模型,这项工作是对特征进行了两轮预测:第一轮预测标注出了参考文献,第二轮是标注全局,参考了附近其他参考字符串(比如参考文献或者参考书目部分)在第一轮是如何标记的。这是唯一一个试图利用这些信息的方法--这可能被证明是保持一个特定的参考书目风格的有用的方法。

FLUX-CiM (Cortez 等, 2007)提供了一种使用词频调节的无监督学习方法来解决这个问题,这个方法需要四个阶段:截断,比对,绑定和加入。最后一阶段相当于ParsCit的最后一步,截断延伸字段(比如作者)变为这个标签的成分。如前文所述,FLUX-CIM的表现在期刊,文章方面的表现明显好于在"卷标","作者"。

检索引用上下文一直是CiteSeer和nascent数字图书馆的重要特征。启发式驱动的方法由这两个系统和Powley和Dale,2007的那个不断提升。利用辨别上下文的引用来抽取摘要或者由他人论述影响着社会上这方面的工作继续进展。(Teufel等, 2006; Wu等, 2006; Schwartz等,2007).

 


Yu

Ideals are like the stars: we never reach them, but like the mariners of the sea, we chart our course by them.

6 Comments

Leniy · May 15, 2013 at 09:58

Google Chrome 26.0.1410.64 Google Chrome 26.0.1410.64 Windows 7 Windows 7

对了,你的设计做怎么样了?

    yu · May 15, 2013 at 11:51

    Google Chrome 26.0.1410.63 Google Chrome 26.0.1410.63 GNU/Linux x64 GNU/Linux x64

    代码还在提升中,翻译就是文中这个,paper在做,还有1个月了。。。

      Leniy · May 15, 2013 at 12:19

      Google Chrome 26.0.1410.64 Google Chrome 26.0.1410.64 Windows 7 Windows 7

      只有四星期了,加油

Leniy · May 11, 2013 at 16:01

Google Chrome 26.0.1410.64 Google Chrome 26.0.1410.64 Windows 7 Windows 7

评论不见了?

    yu · May 12, 2013 at 07:53

    Google Chrome 26.0.1410.63 Google Chrome 26.0.1410.63 GNU/Linux x64 GNU/Linux x64

    找错文了吧….

      Leniy · May 12, 2013 at 08:11

      Google Chrome 28.0.1485.0 Google Chrome 28.0.1485.0 Windows 7 Windows 7

      恩,一开始在手机上看到这篇,然后用电脑就以为是在这儿留的言

Leave a Reply to Leniy Cancel reply

Your email address will not be published. Required fields are marked *