modENCODE数据协调中心：获取全面实验细节的经验教训

使用wiki收集实验元数据

以受控的方式收集大量描述性数据需要一个用户界面来输入这些信息，该界面知道不同字段的相关CV。此外，由于项目的地理分布性质，基于浏览器的界面对用户来说最方便。考虑到这些限制，我们可以使用的唯一实用方法是HTML表单或wiki。考虑到时间安排和快速部署的需要，我们选择使用wiki来加快实施速度，假定熟悉度和联盟的易用性，处理自由文本和相关图像的能力，以及支持扩展，从而允许我们为结构化数据添加表单。

modENCODE wiki(http://wiki.modencode.org)使用MediaWiki软件，以及DCC开发的附加插件。我们的DBFields扩展允许wiki编辑器（通常是DCC员工）使用类似HTML的语法在任何wiki页面上创建表单，其中的字段可以是自由输入、选择框或在输入CV术语时自动完成的文本字段。除了强制执行CV之外，这些字段中的任何一个都可以标记为“必需”，例如，在提供分析类型之前，协议将被标记为不完整。对MediaWiki页面的每次更改都会为该版本生成一个新的唯一URL，DBFields扩展与MediaWiki's版本控制系统集成，以便跟踪表单内容的更改。DBFields模板化wiki页面的示例如所示图3.

在单独的窗口中打开

图3。

使用DBFields模板的modENCODE wiki组织页面的屏幕截图。在这个例子中，WormBase细胞和解剖本体(24)选择术语来描述L3期表达unc-4的神经元。组织的DBFields模板配置为包括口语名称、物种、性别、组织、贡献实验室和相关外部URL的字段。组织字段允许从配置的本体中进行多种选择；当用户开始键入短语（如AVF）时，会显示部分匹配项供选择，相应的定义显示在右侧。用户“更新”表单以接受更改后，将显示一个更新的URL，供用户专门引用此版本的wiki页面。该URL用于BIR-TAB元数据文档中描述样本，审查软件在处理过程中检索字段值。

维基分为三个基本类别，用于以可控的方式收集实验元数据：实验描述、协议和试剂。这些wiki类别中的每一个都使用DBFields扩展模板来记录所需的特定属性。当实验室向DCC提交数据时，我们的自动化管道会引用适当的wiki页面来检查每个类别中的各个字段，并根据管道的不同软件模块的要求检索其值。DCC发布提交内容后，所有引用的wiki页面都将公开并可供社区使用。在迄今为止发布的1112份提交文件中，有54份实验描述、399份协议描述和600份试剂描述，总共1049个独特的wiki页面(图4A） ●●●●。

在单独的窗口中打开

图4。

modENCODE数据提交统计信息。(A类)wiki页面类型的分布。在已发布的提交中使用的wiki页面数（深灰色）（已在wiki中输入）。未使用的wiki页面集可能会在将来的提交中使用。数据仅来自已发布的数据集，而不是那些被取代、弃用或拒绝的数据集。(B类)提交文件包大小的分布。在项目过程中，单个包大小的散点图（以GB为单位，左侧为刻度）与所有modENCODE数据的累积大小（以TB为单位，右侧为刻度）重叠。黑色表示数据提供商上传到系统中的文件的大小，是备份所需的最小集；红色表示已处理提交的总大小，包括gbrowse轨迹、chadoxml和上传数据的所有版本，是维护完整历史记录所需的最大大小。(C类)modENCODE数据类型的组成。这些数据基于每个类别中的累计提交文件大小，包括已被取代、替换和拒绝的数据集。(D类)一段时间内提交的数量。图中显示了数据提交的峰值。虚线表示最初创建提交文件的时间；实线表示提交文件在管道中发布的时间。红线表示累计计数；黑线表示每周的计数数。科学会议或数据冻结等事件用蓝色圆圈表示。显示项目季度（第1年第4季度缩写为Y1Q4）。显示了所有数据，包括被取代、被取代和被拒绝的提交文件。(E类)按数据类型分组的管道处理时间。针对发布的数据集中的每种类型的数据，显示了三个管道步骤（验证、数据库加载和跟踪查找）的平均处理时间（以分钟为单位）。

这个实验描述wiki页面记录了各个实验室进行的每组实验的高级描述。该描述包括一个“数据类型”标签，用于对所识别的基因组特征或行为进行大致分类，一个“化验类型”标签用于对所应用的实验技术进行分类，以及一小段描述属于这一总括分类的一组实验。这些分类标签用于下游应用程序的报告。在中的示例中图2，该提交物属于一组使用TF抗体的ChIP-seq实验，并将标记数据类型“TF结合位点”和分析类型“ChIP-seq”。迄今为止，我们已经遇到了23种不同的提交类型，包括：ChIP-seq和ChIP-ChIP对TF或其他结合位点的研究、复制时间、组蛋白修饰和染色质结构、基因注释、5′-和3′-RACE、靶向RTPCR、RNA拼接阵列和RNA-seq以确定转录水平。

协议描述是modENCODE提交的基础，提供了每个实验复制的详细信息和关键实验变量的框架。协议描述页面尽可能基本，以确保正确使用，只需要协议类型、使用和生成的数据和试剂的输入和输出以及散文描述。尽管一个协议可以足够全面地描述整个实验，但我们鼓励数据提交者要精细。例如，生物体生长方案应与随后的染色质纯化方案分开（如图2). 一个典型的实验将有关于生物体生长和分离、样品制备、文库制备、测序/排列、比对/标准化和峰值调用的协议。这种粒度使数据提供者能够在不同的实验中引用相同的协议；例如，无论采用何种检测方法，都可以重复使用相同的生物体生长方案。

这个试剂wiki页面的类别由几个子类别组成。试剂代表不同于相关提交文件的实验因素。子类别包括抗体,菌株,细胞系，发育阶段,组织,RNAi试剂,微阵列芯片组和重组构建物/载体。每种类型的试剂都使用自己的表单模板，其中包含DCC管理员与数据提交者合作指定的字段。最大的亚类是由该联盟指定的具有500多个抗体的抗体（尽管迄今为止只有大约180个抗体在已发布的提交文件中被引用）。

所有提交给DCC的文件都是从DCC管理员和提交数据的实验室之间的对话开始的，以确定适用于给定实验类别的协议、试剂、元数据和数据格式。馆长充当最终用户的代言人，确保提供足够的信息细节。由于modENCODE项目中的实验类别差异很大，这需要在每个实验室的基础上进行元数据和数据设计，尽管一旦生成原始模板，随后可以为类似的实验类别遵循这些模板。根据与实验室人员的讨论，DCC管理员建立了一个wiki页面“存根”集合，供实验室填写。公开发布后，此元数据将并入我们的公共数据库，并支持modMINE中的查询，是生成基于矩阵的下载界面的基础，并为基于web的基因组查看器GBrowse提供了轨迹描述。

提交和跟踪界面

提交界面是使用Ruby on Rails实现的，这是一个专为快速开发设计的web应用程序框架。我们从ENCODE DCC继承了Rails和提交管道的框架。事实证明，它非常适合我们的需求；特别是，新功能的开发速度非常快，包括从添加到数据模型到开发管道状态的新视图的所有内容。

我们最初计划与ENCODE-DCC一起继续开发管道软件，但进一步的探索表明，我们各自的需求差异太大。虽然两个DCC都跟踪和管理传入数据，但我们实现了更多依赖CV的自动处理，这需要更复杂的作业管理系统。在项目的早期阶段，制定一个工作解决方案比维护一个共同共享的通用解决方案更为关键，这导致两个DCC的提交管道只有表面上的相似之处(图5). 这种经验强调了即使项目与ENCODE和modENCODE类似，跨项目共享软件仍然是多么困难。

在单独的窗口中打开

图5。

modENCODE提交接口。(A类)显示了个人提交示例的主页。(B类)通过输入提交文件的名称并选择适当的实验室和PI来创建新提交文件。(C类)创建提交后，当前详细信息将列在页面的左上角。(D类)可以实时监控管道正在执行的一系列分步任务，并可以查看每个模块的相应输出。(E类)当提交文件经过自动化QC处理的每个步骤时，会显示进度。在本例中，剩下的工作就是为浏览器、最终手册清单和公开发布配置曲目。(F类)本页列出了构成提交包的所有主要文件：IDF、SDRF、wig和GFF3。如果需要，提交实验室可以替换单个文件。(克)活动提交的列表可以单独显示，为用户提供其提交的审查状态的快照。

自动化质量控制

为了在所有提交给modENCODE DCC的文件中实现一致性，我们开发了一个用Perl编写的模块化自动审查工具。为了审查提交内容，该工具首先扫描BIR-TAB文档。假设没有语法错误或技术不一致，平面元数据将转换为表示实验的图形结构。接下来，获取提交引用的所有wiki页面，从中收集所有字段值并用于填充元数据。由于wiki中的协议包含描述其输入和输出“类型”的CV，因此每个协议输入的一致性与前面的协议输出一致，以确认由SDRF构建的实验图组成的一系列协议与wiki中相匹配。如果这一点得到确认，那么基于对实验图的自省，将选择要执行的检查模块。

审查模块包括简单的检查，如确保提交数据集中确实存在指定的“结果文件”，以及更广泛的检查，例如确保抗体在实验应用之前有足够的质量控制。有一些模块用于确保外部基因、转录物、蛋白质和EST标识符的存在，以及SRA和GEO材料。我们还允许并检查对远程托管的原始数据文件的引用。该组模块还支持审查GFF3、WIG、BED和SAM数据格式。尽管GFF3、BED和WIG被许多其他数据存储库使用，并且已经存在一些审查脚本，但我们的格式要求更严格（尤其是GFF3），并且我们已经为这些格式开发了增强模块（有关格式要求，请参阅“方法”一节）。在审查每一条数据时，实验图都会更新。例如，当审查包在描述GFF3文件的图中的节点上运行时（例如图2)，它处理GFF3文件并将新的基因组特征节点附加到代表GFF3的文件节点。

审查提交文件的时间从30秒到5天不等，平均时间约为一小时(图4E） 。这种差异是由于基础数据的复杂性和不同数据大小的差异造成的。大约三分之一的提交文件最初包含某种类型的错误，这些错误可以通过两种基本方法基本解决：首先，许多错误可以通过更仔细、更批判性地查看提交文件来修复；其次，如果错误不明显，则使用截断的数据文件重新运行提交；这使我们能够优化和更正元数据，而不会像从GFF文件加载一百万个特性那样缓慢（例如）。最坏的情况（6/3043）是当数据文件的末尾只出现一到两个错误时（例如，GFF文件中靠近文件底部的两个特征在起始点之前有一个端点，这是无效的）。在这几种情况下，除了继续测试数据文件外，没有其他事情可做；这种情况通常表明数据提供程序在生成文件时存在问题，我们会与他们一起解决这些问题。通常，运行时间最长的是全基因组基因模型的验证，而运行时间最短的是基于阵列的提交（ChIP-ChIP或平铺阵列）。

数据存储和轨迹生成

有几种现有的数据库模式用于存储基因组特征数据，通常与不同的基因组浏览器相关联。部分列表包括AceDB、UCSC注释DB、Ensembl和Chado(12–15). 我们选择Chado数据库来存储modENCODE实验元数据和基因组特征，这是因为我们熟悉、工具可用、与FB和WB的标称兼容性以及浏览器中立性。此外，它是高度规范化的，这减少了冗余和内部不一致的可能性。

Chado的结构允许以新表的形式轻松添加扩展，允许我们扩展模式以适应通用提交详细信息、协议和数据引用(补充图S1). 新的扩展利用了CV和外部数据库引用的现有表，并在适当的地方将协议输入和输出链接到基因组特征表。由于这些表是一个扩展，因此它们不会干扰为使用Chado数据库而开发的现有工具。

在自动审查之后，提交的文件被加载到数据库中。通过生成ChadoXML作为自动审查过程的输出，简化了数据库加载。在数据不适合关系模式的情况下，例如ChIP信号数据，我们将数据保存在文件系统中，并将这些外部文件的链接记录在数据库中。加载时间因提交文件而异，从7秒到2天不等，平均时间为30分钟(图4E） ●●●●。

自动化过程的最后一步是从我们的数据库直接生成GFF3、WIG和SAM文件，以便在公共浏览器中显示和供社区成员下载，从而确保整个modENCODE项目的内部一致性。这增加了1秒到12天的数据处理时间，平均大约一个小时。对于装载和航迹生成，变化主要还是由于数据的复杂性。基因特征具有多层次的子特征（转录本、外显子等），加载时间最长（数据未显示）。

手动批准检查表

数据集通过自动审查并加载到数据库后，负责的DCC管理员对只能通过人工审查才能检测到的错误进行最终检查。虽然最初是临时执行的，但随着时间的推移，这些步骤已正式形成清单，并纳入管道中。常见的错误包括列出与给定实验标题相比不正确的抗体、引用失效的wiki协议、包含的重复次数不足以及引用代表错误数据集的GEO ID。例如，即使提交的文件在语法上是正确的，区分提交的生物复制数据和重新提交的数据对于确保提交文件包的完整性至关重要。除了这些数据完整性交叉检查外，馆长还审查了实验的散文描述，以供社区成员理解（完整的检查表可以在补充数据S2). 如果提交文件未通过这些检查，数据提交人和/或策展人必须编辑提交文件并解决问题。然后上传元数据和/或数据的修订，提交管道跟踪修订历史。

如果我们收到秀丽线虫坐标中的数据集不是modENCODE商定的标准（目前为WS190）。虽然原始数据文件仍然可供公众下载，但所有文件都已发布秀丽线虫数据已处理为WS190坐标。我们的liftover工具是WormBase工具的Java重新实现(http://wiki.wormbase.org/index.php/Converting_Coordinates_between_releases网站)，扩展以适应GFF3、WIG、BED和SAM（参见“方法”部分）。发布之前，馆长需要执行的其他手动步骤包括编辑生成的曲目散文描述以及在浏览器中配置曲目外观。

一旦DCC批准提交，数据提交者将被要求批准发布。在提交获得批准之前，只有数据提交者提供的原始提交文件可供公众使用。

维基

维基界面用于跟踪实验元数据的灵活性被证明是足够的；除了支持格式化文本和图像之外，对扩展的支持还允许我们开发DBFields扩展并以结构化的方式收集重要属性。此外，使用MediaWiki软件，我们可以访问大量现有扩展，包括所见即所得编辑器和发布后将私有页面标记为公共的界面。

另一方面，wiki和提交管道的松散集成是一个弱点。例如，wiki和提交管道上的帐户是独立的，因此用户名和密码可能不同。此外，由于许多单个实验室使用的内部wiki与我们的系统没有链接，数据提交者两次输入了一些元数据（一次是在他们自己的私有wiki中，第二次是在DCC的wiki中）。单个财团范围的wiki可能会使这一点变得更容易，但这需要所有数据提供商之间达成协议，DCC需要更多的资源，DCC和生产实验室之间需要更紧密的连接来收集和实施需求。然而，回想起来，我们觉得提交管道接口和wiki之间的紧密集成将使我们能够避免几个耗时的障碍。尽管有这些缺点，维基范式使DCC能够成功捕获我们设定的元数据；它支持捕获我们想要的所有实验元数据，并为社区提供了一个熟悉的类似Wikipedia的界面来查看元数据。

审查

DCC审查软件最初是一个Perl脚本，用于从BIR-TAB/GFF提交中生成ChadoXML文件，这需要基本的语法有效性。我们很快扩展了它的职责，以检测提交中的逻辑不一致、添加的基本检查以及其他计算机比人类更容易执行的重复任务，并详细报告所有错误和警告。

审查工具设计为动态、模块化系统。动态的，这样就可以只使用基于CV类型的适当模块来审查提交内容，这些字段是该提交内容所特有的。模块化允许我们轻松快速地添加新模块以响应新的数据类型。在编写ChadoXML之前，审查工具构建了一个完整的实验模型，包括所有元数据和基因组特征，以便能够交叉检查跨字段和特征的依赖引用。这种方法的一个缺点是内存利用率高；跟踪完整的实验模型需要一些磁盘缓存（尽管有12G的可用内存），这大大降低了处理较大提交的速度。这在基因模型提交中尤其明显，该提交具有多层次特征（基因、转录本、外显子），并且处理速度比其他类型提交的平均速度慢30倍。

然而，对于大多数数据集，这种方法是令人满意的。特别是，新模块通常可以在一两天内开发出来。由于所提供的数据类型和验证要求在项目过程中发生了变化，因此这种短的响应时间非常关键。对于希望进行基于元数据的验证的未来项目，我们建议采用模块化方法，并检查允许分布式处理不同组件的新方法，避免需要检查整个提交文件。

查多

在实践中，我们发现Chado足以完成其存储基因组特征的主要任务，并通过我们的扩展将特征链接到实验元数据，通过过滤与特定提交相关的数据，可以轻松构建浏览器轨迹、填充modMine和打包GEO提交。我们发现有必要通过为每次提交创建单独的名称空间来对我们的主Chado数据库进行分区。这使得有可能从数据库中删除或重新加载未发布的提交，这些任务需要作为审查的一部分定期执行。不幸的是，这种方法使所有提交的查询更难编写，执行起来也更费时。modMine组通过生成一个只读Chado数据库来缓解这一问题，该数据库中的提交是按PI而不是按单个提交进行分区的，他们使用该数据库来构建modMine查询数据库。

Chado的一大局限性，实际上，任何专为基因组特征设计的模式，都是缺乏对连续数据（如信号强度）的支持。当然，极高密度的基因组特征数据不适合于一般的基因组特征数据库。相反，我们以最初提交的格式（例如WIG和SAM）保留这些类型的数据，并从数据库中引用它们。这使得很难找到某些问题的答案，例如，在多个提交中查找区域的读取覆盖率需要查找这些提交的SAM文件，然后使用专门用于分析SAM数据的工具提取区域的读取涵盖率，而不是针对数据库编写单个查询。另一方面，将这些数据提供给基因组浏览器并不重要，因为它们已经是支持的格式。

DCC从扩展Chado而不是构建新模式中受益匪浅。我们不仅避免了从头定义新模式的潜在巨大努力，还能够采用现有的Chado基础设施。ChadoXML加载程序为我们提供了一种在DCC组件之间传递数据的可移植方法；我们使用现有的工具在数据库中填充CV。我们还发现很容易将WB和FB提供的公开Chado数据库与我们的数据库合并。

为了解决对收集与短读测序技术相关的基因组特征的支持，我们建议未来的项目研究支持分片/分区的架构的开发，使负载能够跨多个服务器分布。我们还建议在数据处理管道的核心中构建对查询外部二进制格式的支持，以便查询不适合关系数据库的优化数据格式。当然，建议任何想要存储离散基因组注释的群体以及收集基于本体论的元数据时使用Chado，因为它针对这两种类型的数据都进行了优化。