OntoMate：一个帮助大鼠基因组数据库管理的文本工具

摘要

大鼠基因组数据库（RGD）是大鼠基因组、遗传和生理数据的首要存储库。将科学文献中的自由文本数据转换为结构化格式是所有生物模型数据库的主要任务之一。RGD花费了大量的精力手动管理基因、数量性状位点（QTL）和菌株信息。生物医学文献的快速增长和生物自然语言处理（bioNLP）社区的积极研究推动了RGD采用文本管理工具来提高管理效率。最近，RGD启动了一个项目，使用OntoMate，一个由RGD开发的本体论驱动、基于概念的文献搜索引擎，作为PubMed的替代品(http://www.ncbi.nlm.nih.gov/pubmed)基因管理工作流中的搜索引擎。OntoMate标签包含基因名称、基因突变、生物体名称和RGD使用的16个本体/词汇中的大多数。所有标记为摘要的术语/实体都与摘要一起列在搜索结果中。所有列出的术语都链接到数据输入框和管理工具中的术语浏览器。OntoMate还为物种、日期和其他与文献搜索相关的参数提供了用户激活的过滤器。与使用PubMed相比，使用该系统进行文献检索和导入简化了过程。该系统构建了可扩展的开放式体系结构，包括专门设计用于加速RGD基因管理过程的功能。随着bioNLP工具的使用，RGD为其管理工作流程增加了更多自动化。

数据库URL:http://rgd.mcw.edu

介绍

大鼠基因组数据库（RGD，http://rgd.mcw.edu)一直在寻找通过使用软件工具来提高管理效率的方法。2006年至2009年，RGD的生物信息学开发人员创建了一个工具套件(1)协助RGD的策划过程。这些工具改进了最初基于电子表格数据输入的流程。本体注释创建和编辑工具用作策展数据库的数据输入接口。直到最近，RGD生物化学家还依赖PubMed界面上的文献检索(2)查找用于管理的文章。为了改进工作流程，策展人想要一个能够与基因策展工具交互的搜索引擎。

生物创意：生物信息提取的关键评估是一项社区范围的工作，旨在通过组织共同的评估任务，促进创建和改进用于生物化的文本管理工具和解决方案。2012年生物创意展(3–5)和2013年(6,7)研讨会几位RGD策展人测试了各种文本挖掘工具。其中，RGD馆长发现了PubTator(http://www.ncbi.nlm.nih.gov/CBBresearch/Lu/Demo/PubTator/index.cgi？user=User422218159)与他们的基因管理工作流程最为相似，因为RGD基因管理者从生物医学文献中注释疾病、表型、通路和基因本体（GO）数据。所有这些不同的数据类型都需要同时通过相同的界面进行管理。

PubTator出版社(8)是一个基于web的抗管理生物医学搜索引擎。它利用生物自然语言处理（bioNLP）工具来注释和索引对生物形成有用的信息，如基因、疾病术语和物种。PubTator比PubMed更友好，它缺乏RGD管理所需的一些功能。例如，查询结果中的文章只能按发布日期排序，而不能按相关性排序。最重要的是，PubTator不够灵活，无法直接集成到RGD的策展工作流程中。在研究了不同的解决方案后，RGD决定创建OntoMate并将其集成到其基因管理工作流程中。

OntoMate软件

OntoMate是一个本体论驱动的、基于概念的文献搜索引擎。该项目的最初目标是利用文本管理工具部分自动化PhenoMiner中使用的本体开发(9–12). PhenoMiner是大鼠表型数据的存储库。它利用了RGD开发的四个本体：大鼠应变本体、临床测量本体、测量方法本体和实验条件本体。OntoMate的基本要求是能够标记自由文本文章（MEDLINE摘要）中的本体术语，并生成术语文章统计信息。第一个需求是典型的信息提取工具，第二个需求是信息检索应用程序。在比较了不同的解决方案后，我们决定建立一个内部系统。尽管有大量的信息提取和信息检索工具，但很少有工具能够同时满足RGD的两个需求：

1. 本体论在不断变化。这与大多数标记系统的假设非常不同：执行一次并保存结果。我们的计划是在每个新版本的本体上应用标记系统。为了标记这些本体的术语，需要一个非常可定制的标记系统。

2. 我们需要使用标记系统处理所有MEDLINE摘要。国家生物医学本体中心（NCBO）注解器等工具的性能(13)不允许我们根据需要经常注释整个文档集。除了标签的基本要求外，我们还希望扩展该系统，以帮助策展人完成基因策展和其他文本管理任务。

在设计系统时，我们还设定了一些要求：

1. 系统应具有高性能，允许在相对较短的时间内处理大量文本文件。

2. 系统应具有可扩展性。在需要时，向系统添加更多服务器以扩展处理和存储容量应该不难。

3. 该系统应该是健壮的。单服务器故障不应导致数据丢失或系统故障。

4. 系统应打开。将第三方工具集成到系统中应该不会很麻烦。

5. 系统应尽可能多地使用开源软件，以保持低成本。

这些要求不仅适用于标记任务，而且还适用于随着时间的推移进行的更多文本提示任务。由于Java是大多数bioNLP开发人员的首选，因此它在整个系统开发过程中都被使用。随着项目的进展，我们不仅满足了最初的要求，还成功地将OntoMate集成到RGD的基因管理工作流中。

系统架构和实施

OntoMate由四个主要组件组成：数据收集、文章数据库、信息提取和信息检索(图1).

数据收集

由于几乎所有RGD的基因管理都依赖PubMed的生物医学文献搜索引擎，OntoMate目前使用PubMed.作为唯一的数据源。目前，OntoMate处理每篇文章的标题、摘要和医学主题词。未来计划进行全文处理。使用NCBI的E-utilities Web Service（SOAP-Simple Object Access Protocol）构建了一条管道(http://www.ncbi.nlm.nih.gov/books/NBK25500/)从PubMed数据库检索数据。该管道使用Apache Axis2 for Java编程接口，因为它包含一个可扩展标记语言（XML）解析器，可以访问从PubMed检索到的XML文件中的任何字段。最初，该管道检索到PubMed数据库中的所有记录。这个过程最初花了几个星期才完成。初始下载完成后，管道每天晚上都在运行，只添加前一天可用的新文章。最后，管道解析所有下载的XML文件并将文章加载到文章数据库中。

文章数据库

这是关于系统性能的一个关键组件，因为在创建文章索引之前，它涉及到每个操作。我们评估了几个用于存储文章、注释和其他相关信息的数据库系统。MySQL数据库(http://www.mysql.com/)对于存储几百万篇附加了数十亿条标签注释的文章来说，它的速度太慢，可扩展性不够，成本太高。

无SQL(http://nosql-database.org/)是下一代数据库，它解决了我们在SQL方面的一些问题。NoSQL是非关系、分布式、开放资源和水平可扩展的。根据定义，NoSQL应该比MySQL数据库更好地服务于我们的应用程序。我们测试了两个NoSQL解决方案：Apache CouchDB(http://couchdb.apache.org/)和Apache Hadoop/HBase(http://hadoop.apache.org/) (14). 我们选择Hadoop/HBase，因为它提供了比CouchDB更好的性能和灵活性。

Apache HBase是一个开源、分布式、版本化和面向列的数据库。HBase在Hadoop分布式文件系统（HDFS）上运行(http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html). 这将启用Hadoop Map/Reduce(15)从本地服务器读取数据库记录的作业；因此，系统吞吐量不受网络带宽的限制。表中的记录存储为键值对。我们使用反向（用于负载平衡）PubMed标识号（PMID）作为密钥。每个记录可以有数百万列，可以单独写入或读取。HBase中的列被分组到列族中。我们决定将文章以XML格式存储在一个列中。每次我们需要访问文章中的属性时，都会从数据库中读取并解析完整的XML数据。在我们当前的设置中，读取和解析XML中的所有文章需要34分钟，而解析需要不到2分钟的时间。

HBase记录的列通过在每个存储值上具有时间戳来进行版本控制。用户可以定义要保留的版本数。当收到新值时，数据库将自动将其时间戳与现有值进行比较，并只保留最新的值。此功能对我们来说非常有吸引力，因为在重新运行标记器时，我们不必删除现有注释。时间戳也有助于跟踪PubMed中的文章更改。我们使用八台Dell服务器构建了一个小型Hadoop集群。将所有2300万篇文章加载到HBase只需要1.5个小时，而单个MySQL服务器只需要71个小时。浏览所有文章只需24分钟。

信息提取

为了充分利用NLP社区开发的现有工具，我们决定使用流行的NLP框架GATE（文本工程通用架构）(16). 我们使用GATE插件构建了一个基于词典的本体术语标记管道。该管道由两个ANNIE（一个新的信息提取系统）地名录插件组成：一个用于区分大小写的术语，另一个用于对大小写敏感的术语。ANNIE是一套基本信息提取库。

我们从RGD数据库中导出了本体术语，并使用Snowball Stemmer构建术语词典对其进行词根分析。文章文本在通过管道之前也会进行词干分析。词干是将单词缩减为词根形式的过程。例如，“biatures”在词干之后变成“creatur”。来自管道的文章的所有注释都作为一列存储在HBase中。在我们的测试中，我们的管道生成的结果与NCBO注解器的结果非常接近。我们的本体标记管道标记不仅来自PhenoMiner使用的五个本体，还来自RGD使用的其他11个本体中的大多数。除了本体标记管道外，我们还使用GATE插件构建了基因标记管道、组织标记管道、变异标记管道和部分语音标记管道。

与大多数用于生物化的信息提取系统不同，OntoMate中的基因注释没有标准化。其中一个原因是，很难精确地将提及的基因映射到用于注释的有机体特定基因标识符。不正确的映射可能会导致信息检索步骤中的召回丢失。另一个原因是因为RGD的基因疾病管理过程总是从给定的基因标识符开始。从基因标识符到基因提及的映射相对简单。如果忽略有机体约束，则不太可能发生不匹配。ABNER（生物医学命名实体识别器）(17)基因注释器只标记更有可能是基因相关文本的文本片段。在文章中搜索基因仍然是基于关键字的，这依赖于下面“查询提交和分析”部分中讨论的query-expansion功能。

信息检索

HBase是我们应用程序中用作文章/注释存储的一个很好的解决方案，但它缺少查询数据的方便方法。我们决定在HBase中索引数据，以便使用Apache Solr进行查询(http://lucene.apache.org/solr/). Solr基于Apache Lucene项目(http://lucene.apache.org/core/index.html)，是一个高性能、功能齐全的文本搜索引擎库。Solr通过提供点击突出显示、分面搜索、丰富文档处理和分布式索引等功能，使Lucene易于使用。分面搜索可以生成给定字段的值分布，这是获取术语文档统计信息的理想方法。高性能的全文搜索也使我们有可能为RGD的策展建立我们自己的文献搜索引擎。Solr还提供了类似于HTTP/XML和JavaScript Object Notation（JSON）应用程序编程接口（API）的REST（REpresentational State Transfer），作为提交查询和检索结果的方便编程接口。使用分布式索引功能，为Hadoop集群中的所有2300万篇文章及其注释编制索引只需不到5个小时。

将OntoMate集成到RGD基因管理工作流中

RGD的基因管理由疾病相关、路径相关和QTL相关项目推动。这涉及到对相关基因的疾病术语、通路术语和GO术语的管理。OntoMate与RGD基因管理工作流的集成解决了这一范围的注释。RGD旧的和当前的基因管理工作流程如所示图2OntoMate将PubMed以前提供的搜索功能与RGD策展工具合并，从而将文献搜索、标题/摘要策展和注释的整个过程整合为一个界面，而不是两个界面。

表1列出了PubMed中基因诊断搜索的查询字符串，与OntoMate/curation工具界面中的基因诊断搜索进行了比较。通过使用基因ID和本体术语ID，OntoMate允许管理员最小化手动搜索输入，同时获得与PubMed搜索几乎完全相同的结果。OntoMate依靠一个基因及其同源基因，根据管理工具中提供的基因RGD ID提供名称、符号和同义词。对于基因疾病管理，RGD管理者只对与大鼠、人类或小鼠相关的论文感兴趣，因此这三个物种的默认搜索参数会自动附加到查询字符串中。通过使用本体层次结构的强度（同时搜索搜索框中输入的任何父项的子项），OntoMate减轻了输入许多搜索词以获得复杂搜索结果的负担。

用于管理的OntoMate用户界面

OntoMate为RGD管理专门设计的查询结果用户界面如所示图3用户界面包括三个区域：查询条件区域、筛选区域和文章列表区域。查询条件区域显示概念查询条件。在呈现之前，来自管理工具发送的实际查询条件的RGD基因ID和术语加入ID分别转换为基因符号和本体术语。概念由实际Solr查询字符串中使用的布尔运算符连接。

在过滤器区域单击过滤器列表中的超链接将对查询结果应用过滤器，以仅包括具有该概念或在发布日期范围内的文章。可以组合多个过滤器。“过滤器路径”显示了已应用于结果集的过滤器(图3). 用户可以通过单击路径中的上部节点来删除筛选器。每个过滤器超链接后面的数字表示如果应用过滤器，将显示多少文章。概念按这些数字降序排序。

这个物品列表区域默认情况下，文章按相关性排序。给定一个查询，Lucene使用相似度评分公式计算与查询匹配的每个文章的相关性(18). 用户可以从“排序依据”下拉文本框更改为其他两种排序条件，即按出版日期或按PMID。每个参考条目都有到RGD策展界面和外部来源的各种链接，以获得完整的论文访问[PubMed Central(网址：http://www.ncbi.nlm.nih.gov/pmc/)或出版商网站]。如果参考文献已经在RGD中，单击标题上方的RGD徽标将在RGD打开文章的参考报告页面。对于疾病注释和GO注释，用户界面将在文章条目的右上角显示相应方面的字母。将鼠标移到方面字母上可显示注释细节(图3). 如果文章摘要已在OntoMate中打开，该工具将显示一个带有馆长姓名和时间戳的“Read by”指示器(图4). 此功能以及前面的注释指示符可以防止文章被不必要地重新阅读，这在PubMed结果界面中是不可能的。如果文章在RGD中没有注释，并且标题显示为可管理，馆长可以单击“摘要和其他字段”按钮，以显示摘要、引文详细信息以及自动注释/标记摘要的任何本体/词汇术语的列表(图4).

将立即记录抽象打开操作，以便“Read by”指示器可以使用信息。文章摘要显示在同一页面上，这样管理员就不需要像PubMed中那样在文章列表页面和摘要页面之间来回切换。管理员可以通过再次单击按钮来隐藏详细信息。匹配的基因名称/符号在标题和摘要中自动突出显示。馆长可以将鼠标悬停在一个本体术语上，在摘要正文中手动突出显示它。每个带注释的术语都是指向管理工具界面中本体浏览器中术语的链接。术语后接出现次数，并按此数字降序排序。当策展人决定对文章进行注释时，他/她可以通过单击查询结果页面上PMID左侧的bucket图标直接将文章导入策展工具。这一次点击取代了策展人从PubMed策展时使用的“复制/粘贴/点击导入”程序。策展人还可以直接从摘要下的列表向策展工具添加本体/词汇表术语。这也可以通过点击任何术语左侧的bucket图标来实现。一旦疾病或GO术语关联输入RGD数据库，OntoMate查询结果页面将自动显示新的注释。导入文章、为策展添加术语和访问全文文章的操作都会被记录下来，以分析策展工作。访问全文文章日志可用于指示摘要是否不足以进行注释。

总结

作为将文本管理工具集成到RGD策展工作流程中的最初努力，我们在OntoMate和RGD的策展工具之间创建了一个接口，以便OntoMate可以取代PubMed作为基因策展的文献搜索引擎。切换到OntoMate后，每位策展人每小时策展的平均论文数量从2.10篇增加到2.83篇。策展人不需要花费时间构建基因和疾病的查询字符串。这相当于每个基因/本体术语搜索节省大约5分钟的时间。现在可以很容易地防止重读以前策划的论文。OntoMate中的超链接PMID、基因名称和本体论/词汇术语创建了RGD策展工具的快捷方式，该工具消除了以前在策展PubMed文献时所需的大量复制/粘贴、键入和术语搜索。这为每个本体论术语注释节省了约10-15秒的时间，并节省了5-10秒的时间每个PMID加载到管理工具/数据库中。关于查询结果的准确性和召回率，馆长没有发现OntoMate和PubMed结果之间存在任何差异。

在RGD管理中使用OntoMate最具吸引力的潜力是它是开放的，并且可以完全定制。将添加句子级用户交互的日志记录。我们将使用机器学习技术构建模型，以确定哪些文章更适合管理，甚至自动生成基因关联。我们收集的用户操作日志数据在构建此类模型时非常有用。我们将添加更多管道来提取对管理或机器学习有用的信息，例如语法信息、依赖关系、关键字/句子和事件。使用OntoMate的系统基础设施，我们将注释所有可用的全文文章，并使信息可以在OntoMate管理用户界面中直接访问。未来将添加更多用户交互功能。

基金

这项工作得到了国家心脏、肺和血液研究所代表国家卫生研究院（HL064541和HL094271）的支持。开放获取费用的资金来源：代表国家卫生研究院的国家心脏、肺和血液研究所（HL64541）。

利益冲突。未声明。

工具书类

作者注释