网站上有哪些可用数据？
UniProt网站提供了对表中所示数据集的访问1.
网站是如何构建的？
表中显示的URL模板模式2不仅用于主要数据集，还用于各种“本体”、文档甚至运行或完成的作业。
没有特殊的搜索页面。可以通过出现在每个页面顶部的工具栏直接访问搜索功能和其他工具。根据当前上下文，一些工具表单是预先填写的。例如，当查看UniProtKB条目时，序列搜索表单将预先填充条目的序列，对齐表单将预先填写条目的所有替代产品（如果有）。
如何让人们开始？
在包含大量内容的主页上，重要信息往往被忽略。新的UniProt主页（见图1)有一个突出的工具栏，它出现在每一个页面上，作为一个基本的站点地图，带有指向公共入口点的链接。该网站包含许多在线帮助中记录的小而有用的功能；然而，一般来说，人们似乎不愿意花大量时间阅读文档。为了解决这个问题，我们录制了一个“现场参观”[3]可以从主页访问。
如何正确使用文本搜索功能？
文本搜索功能是网站上最常用的功能。因此，我们投入了大量精力，使所有常见和不太常见的搜索不仅成为可能，而且对于不了解UniProt数据的人来说，使用起来简单方便。旧网站最明显的问题之一是搜索结果缺乏良好的相关性评分。评分对于旨在定位特定条目但包含大量条目中出现的术语的查询至关重要（例如，上面引用的“人类胰岛素”示例）。影响新网站上给定查询条目得分的主要因素有：
-
条目中搜索词出现的频率（不按文档大小进行规范化，因为这将有利于注释不良的文档）。
-
术语出现在条目中的哪些字段中（例如，蛋白质名称中的匹配比引用出版物的标题中的匹配更相关）。
-
条目是否经过审查（审查后的条目更有可能包含正确的相关信息）。
-
一个条目的注释有多全面（在其他条件相同的情况下，我们希望对注释良好的条目有偏见）。
每个数据集的准确评分方案不同，需要不断进行微调。
为了让人们能够快速查看最长或最短序列的条目，或者一次翻阅一个有机体的结果，某些字段被设置为可排序的。事实证明，实现这一点并非易事，因为底层搜索引擎库不支持对结果进行有效排序，而只支持对其分数进行排序。因此，现在在加载数据时构建特殊的排序索引，代价是减慢增量更新。图2显示UniProtKB中的查询结果，按长度降序排序。
对于“基本”和“高级”查询，使用两种不同形式的传统方法存在几个问题：根据我们的观察，很少有人开始打算使用“高级”形式。即使他们对数据和搜索功能有很好的理解，他们也常常首先尝试通过简单的搜索形式获得结果，如果基本搜索没有产生预期的结果，或者结果太多，则必须在高级搜索表单中重新执行查询，以便应用进一步的约束。
“高级”搜索表单的另一个问题是，它们通常没有考虑到大多数重要的查询似乎是以迭代方式构建的：人们从一个或两个术语开始，然后添加或修改（例如约束）术语，直到看到所需的结果或放弃。如果一次指定了多个复杂约束，而查询没有产生任何结果，那么找出哪些约束（如果有）使用得不正确可能会很耗时。因此，我们选择了“及早失败”的方法：简单的全文搜索是确定某个术语是否出现在数据库中的最快、最有效的方法，因为您可以跳过滚动选择字段的步骤，然后不得不怀疑该术语是否已出现在其他字段中。
出于这些原因，我们选择了单个搜索表单（参见图3). 人们从搜索一两个词开始。结果页面显示了这些术语的匹配项，对于不熟悉我们搜索字段的人，可以单击以下建议：
-
“你的意思是”拼写建议（如果没有结果或结果很少，并且索引中包含类似单词）。
-
将术语限制为字段（仅列出出现术语的字段）。
-
引用术语（如果它们经常出现在索引中）。
-
筛选出未审阅或过时的条目（如果结果包含此类条目）。
-
用更严格的字段替换字段（如果这有助于减少结果数）。
-
限制字段中值的范围（如果结果在此字段中排序）。
-
……和其他，取决于上下文。
这种方法允许人们无缝地从基本查询转移到高级查询，而无需事先了解UniProt中用于存储数据的字段。与在“高级”搜索表单中选择字段相比，单击建议所需的鼠标单击次数更少。它也更有效，因为只列出了出现术语的字段–使用传统的“高级”查询表单很难实现这样的筛选。
图4显示简单查询的建议，http://www.uniprot.org/uniprot/？query=insulin.
查询构建过程中的每个步骤都会更新查询字符串并反映在URL中，因此可以为其添加书签，也可以通过单击后退按钮撤消。循序渐进的过程并不排除专家用户直接输入复杂的查询，与使用“高级”查询表单相比，这可能更快、更强大（例如布尔运算符）。表3提供了查询语法的概述。
在过去的实现中，查询失败的一个常见原因是一些细微的差异，例如在名称中使用破折号（例如“CapZ-Beta”与“CapZ-Beta”）或罗马数字与阿拉伯数字（例如“protein IV”与“protein-4”）。这种情况现在被视为同等情况。许多搜索引擎都会搜索单词，例如，它们会将搜索词“禁止”、“禁止”和“禁止”视为等价词。然而，考虑到大多数查询都是由名称组成的，如蛋白质、基因或生物体名称，这些名称的词干是危险的，而且无法知道输入的术语是否应该词干，这一点被排除在外。
“高级”搜索表单的一个优点是，如果字段包含中型到大型本体的值，它们允许将可能值数量有限的字段显示为下拉列表或提供自动补全。然而，此功能也可以集成到“简单”搜索表单中：我们选择通过一次添加一个字段搜索约束来提供在数据集特定字段中搜索的可能性。用户单击“字段>>”，选择所需字段并输入值，然后单击“添加和搜索”执行查询。可以添加进一步的搜索约束来迭代地优化查询，直到获得所需的结果（参见图5).
某些数据集相互引用：这可用于进行子查询，例如，在搜索UniRef时，可以添加约束“uniprot:（keyword:antigen organic:9606）”，以仅显示引用具有指定关键字和organic:9606的uniprot条目的UniRef条目。有时也可以从搜索结果访问此功能，例如，在搜索UniProtKB时，可能会有一个“减少序列冗余”链接，将当前查询转换为UniRef中的子查询。
大多数数据集的搜索结果表可以通过两种方式进行自定义：可以更改每页显示的行数，也可以选择不同的列。
请注意，在以制表符分隔格式下载结果时，保留了列的选择。
图6显示了UniProtKB搜索结果的“自定义显示”选项的屏幕截图。
如何支持自定义数据集的下载？
我们经常需要提供各种可下载的条目集，例如FASTA格式的所有已审核人工条目。虽然一些最频繁请求的文件可以通过我们的FTP服务器分发，但对于许多请求来说，这样做显然是不可行的（尤其是对于增量更新，例如自今年年初以来以FASTA格式添加或更新的所有已审核的人工条目）。这样的设置现在可以从网站上获得，不再有任何下载限制。然而，为了确保不会干扰交互式查询，大量下载的优先级较低，因此与UniProt FTP服务器上的下载相比，下载速度较慢。
如何支持浏览？
查找数据的两种主要模式是1。直接搜索和2。通过浏览，即通过层次结构组织跟踪链接。新网站利用各种本体（分类学、关键词、亚细胞位置、酶、基因本体、UniPathway）允许用户浏览数据或将搜索与浏览结合起来（例如搜索关键词：Antigen，然后按分类法浏览，见图7).
如何允许选择多个项目？
使用结果列表通常意味着执行进一步的操作，例如下载所有或选定的项目，或对齐相应的序列。最简单的解决方案是在项目旁边添加复选框，并将其封装在一个表单中，该表单还包含可提交项目的工具列表。这种方法的问题是，它可能会导致用户界面中出现一些冗余：当添加工具时，需要在可以选择项的任何位置添加它。此外，这种方法不允许跨多个页面（例如，在搜索结果中分页时）或跨不同的查询或数据集选择项目。实现的解决方案是提供一种通用的选择机制，将项目存储在“购物车”中。购物车的内容在web浏览器中存储为cookie（因此不需要在服务器端存储任何状态）。购物车本身附加了某些操作，如“检索”或“对齐”，只需单击即可清除。如图所示8购物车还允许跨多个数据集选择项目。
如何显示复杂条目？
此网站上最重要的数据可以在UniProtKB中找到，特别是在审查过的UniProtKB/Swiss-Prot条目中。这些条目通常包含大量信息，需要以便于扫描和阅读的方式显示：
-
名称和来源
-
蛋白质属性
-
一般注释（注释）
-
本体论（关键词和基因本体论）
-
二进制相互作用
-
替代产品
-
序列注释（特征）
-
序列
-
工具书类
-
网络资源（维基百科和其他在线资源的链接）
-
交叉引用
-
条目信息（元数据，包括发布日期和版本号）
-
相关文件（引用条目的文件列表）
描述UniProtKB/Swiss-Prot中的信息[4]超出了本文的范围。以下是与之前显示此数据的尝试相比所做的一些改进：
-
对特征和交互参考进行了分类。
-
要素具有简单的图形表示，以便于比较其位置和范围。
-
次要结构特征折叠为单个图形。
-
替代产品在“序列”部分中明确列出。
-
节可以重新排序或隐藏（并记住这些更改）。
图中显示了人类组织型纤溶酶原激活物（P00750）UniProtKB条目视图的两个部分9.
如何集成序列相似性搜索？
除了文本搜索之外，序列相似性搜索是UniProt中常用的搜索方式。它们可以通过以工具栏的“爆炸”形式提交FASTA格式的序列或UniProt标识符来启动。请注意，在查看UniProtKB、UniRef或UniParc条目时，此表单预先填写了当前序列。图10显示了序列相似性搜索形式和结果。
如何集成多序列比对？
集成的“对齐”工具的目的是允许简单方便的序列对齐。使用ClustalW是因为它仍然是使用最广泛的工具，尽管它可能不再是所有情况下性能最好的工具。表单可以与FASTA格式的一组序列或UniProt标识符列表一起提交，也可以通过内置的“购物车”提交。在查看带有替代产品或UniRef集群的UniProtKB条目时，表单预先填写了序列列表。对于需要特定选项或特定工具的复杂路线，可以轻松将序列导出为FASTA格式，以便与外部路线工具一起使用。图11显示了多序列比对形式和结果。
如何集成标识符映射功能？
有一个标识符映射工具，它将UniProt标识符列表作为输入，并将其映射到UniProt引用的数据库中的标识符，反之亦然。可以映射的另一个受支持的数据集是NCBI GI编号。图12显示了RefSeq标识符如何映射到UniProtKB。
如何批量检索UniProt条目？
批检索工具允许指定或上传UniProt标识符列表，以检索相应的条目（参见图13). 可用的下载格式是最大的公分母：例如，如果批检索请求同时包含UniProtKB和UniParc标识符，则纯文本（仅适用于UniProtKB）和XML（适用于两者，但具有不同的模式）都将不可用，只有FASTA和RDF可用。然后，可以使用前面描述的搜索引擎选择性地进一步查询由其标识符检索的条目集。
如何处理作业提交？
该网站是一个只读、无状态的应用程序，但作业处理系统除外。例如，当提交数据库映射作业时，将创建一个新的“作业”资源，并将用户重定向到此作业页面（最初只显示作业状态，稍后显示结果）。这样做的结果是，如果web服务器收到一个对它没有的作业的请求，它需要询问所有其他镜像是否有此作业（如果有，则传输它）。作业具有唯一标识符，可以在查询中使用（取决于作业类型）（例如，获取两个序列相似性搜索的交集）。可以使用URL列出当前用户最近运行的作业http://www.uniprot.org/jobs/（见图14).
如何处理网络爬虫？
搜索引擎是一个重要的流量来源，可能是因为人们现在倾向于在尝试更专业的网站之前“谷歌”搜索词。因此，重要的是要确保搜索引擎能够索引（并保持最新）尽可能多的网站内容。然而，网络爬虫很难找到属于大型集合的一部分并且没有与主导航页面链接的页面，例如数据库条目，当他们这样做时，这可能会给站点带来很大的负载。为了确保网络爬虫能够找到所有需要索引的内容，这些内容被链接到多个来源，包括概述文档和机器可读的站点地图[5]. 为了让网络爬虫远离那些不值得索引或过于昂贵而无法大规模检索的内容，robots.txt文件[6]使用，并且不应遵循的链接被标记为“nofollow”“rel”属性[7]. 大型集合中文档的检索性能得到了优化，直到我们确信即使是快速爬行也不会对网站的总体响应性产生太大影响。此类文档还应要求返回“上次修改”日期标题。某些网络爬虫（例如Googlebot）将在下次访问时发出有条件的“If-Modified-Since”请求，因此无需重新发送未更改的文档。由于现在只能通过一个URL访问每个资源，因此不再需要对资源进行冗余爬网（与过去具有不同地址的多个镜像的情况一样）。请求日志和“谷歌网站管理员工具”网站[8]用于监视此网站上web爬虫的行为。截至2008年7月，新网站的400多万页被谷歌编入索引。
如何避免断开链接？
该网站在Web上发布了大量资源（数百万）。这些资源链接自许多其他生命科学数据库以及科学论文。由于跟踪并更新所有此类链接是不现实的，并且长时间保持旧的URL重定向方案可能很乏味，因此值得投入一些精力来降低将来必须更改大型URL集的可能性[9]. URL中避免了“/cgi-bin/”或“.do”等技术工件[10]. 如果不使用官方和稳定的URL，那么它们就不好了。从以前的站点中吸取的教训是，最终使用的URL是浏览器中显示的URL（即特定于镜像的URL）。新站点通过为每个资源精确设置一个URL来避免此问题。另一个问题是如何处理被删除的单个资源。主数据集（UniProtKB）中过时的条目或与其他条目合并的条目不再从web界面中消失，而是保留自己的网页（例如。http://www.uniprot.org/uniprot/P00001)，带有指向（可检索的）早期版本列表的链接（例如。http://www.uniprot.org/uniprot/P00001？版本=*). 也可以直接引用特定版本（例如。http://www.uniprot.org/uniprot/P00001.txt？版本=48)，并用于工具形式（例如P00001.48）。
如何支持用户定义的自定义？
一些简单的自定义设置，例如可以选择搜索结果中显示的列，使网站使用起来更加方便。然而，我们不想让每个请求都依赖于集中的用户配置文件数据，从而损害应用程序的无状态性（这对于保持应用程序的可分发性和可伸缩性很重要）。这可以通过在客户端cookie中存储基本设置来实现。此解决方案的缺点是，当浏览器中清除Cookie或用户切换到另一台机器时，这些设置会丢失。以这种方式存储的数据量也很有限。另一方面，自定义操作简单且易于重做。这个解决方案也不要求人们注册，有些人可能不愿意这样做，因为这会带来一些隐私问题。
如何让人们根据自己的需要定制网站？
理想的网站应该是一个“一站式商店”，可以解决所有用户的需求。然而，生命科学界有着非常多样化的需求，而我们的数据往往只是这些需求的一小部分。我们能做的最好的事情是尽可能容易地以编程方式从该站点检索数据，以便在我们的数据基础上开发应用程序。
如何启用对站点的编程访问？
人们需要能够检索各种格式的单个条目或条目集，并在基本脚本或复杂应用程序中简单高效地使用我们的工具。我们希望鼓励人们在我们的数据基础上构建针对特定用户社区定制的应用程序——我们网站上的定制选项只能做到这一点，我们构建的任何东西都将始终以我们的数据为重点。
新站点的早期版本有一个完整的SOAP[11]使用Apache Axis构建的接口[12]. 不幸的是，该接口的性能较差（这就需要引入一些限制，例如一次性检索的最大条目数），而以FASTA格式检索条目数等简单操作最终变得更加复杂。例如，为了从Perl脚本中检索数据，必须安装并修补一个特殊模块（SOAP:：Lite），因为它支持SOAP附件。同时，有更好的SOAP库，但它们仍然比直接HTTP请求更复杂，使用效率更低。
确保这种“RESTful”[13]访问尽可能简单和健壮，站点具有简单和一致的URL模式（在前一节中进行了解释），并返回适当的内容类型标头（例如，xml资源的application/xml）和响应代码。对所有请求返回适当的HTTP状态代码，而不是返回200 OK，即使请求失败，也有几个好处：
表4列出了站点可能返回的所有响应代码。最重要的区别是4xx响应代码，这表示请求本身有问题，再次发送相同的请求可能会再次失败，而5xx响应码则表示服务器有问题。
除了依赖于数据集的格式外，所有搜索结果都可以作为OpenSearch检索[14]RSS提要与外部工具（如新闻提要阅读器或Yahoo Pipes）集成[15].
如何处理复杂数据？
虽然能够以FASTA、制表符分隔甚至纯文本格式获取数据可以满足大多数人的需求，但有些人需要获取并使用完整的数据结构。由于数据模型复杂且变化很大，这一点变得更加复杂。RDF（W3C语义Web计划的一部分[16])提供了一个通用的类似图形的数据模型，可以帮助解决这些问题[17]. 所有UniProt数据都可以在我们的FTP服务器（用于批量下载）和站点上以RDF和XML格式提供。
RDF中的资源用URI标识。UniProt使用PURL[18]. 例如，http://purl.uniprot.org/taxonomy/9606用于引用和识别人类分类单元的概念。此URL可以解析为http://www.uniprot.org/taxonomy/9606（人类可读的表示；例如在浏览器中输入时返回）或http://www.uniprot.org/taxonomy/9606.rdf（机器可读表示；如果请求包含“Accept:application/rdf+xml”头，则返回）。
网站的架构是什么？
该网站被实现为一个纯Java web应用程序，可以使用嵌入式web服务器Jetty独立运行[19]，或部署在任何兼容Servlet 2.4的平台上[20]web应用服务器。应用程序中的组件是使用Spring应用程序框架配置和连接在一起的[21]. 支柱[22]协调请求处理，页面使用JSP（2.0）模板呈现为XHTML。数据库条目存储在Berkeley DB JE中[23]用于快速检索。搜索是在Lucene文本搜索库的帮助下实现的[24].
引入Spring是为了从代码中删除硬编码依赖项（或硬编码服务查找），因为这妨碍了我们对代码进行单元测试的能力。Struts是在众多可用web应用程序框架中选择的，因为它提供了一些便利，例如从请求参数中自动填充对象，但没有试图抽象太多（例如，我们需要访问HTTP请求和响应对象，以便读取和设置某些HTTP头）。Struts也是（或曾经是）一个事实上的标准，学习起来很简单。使用Berkeley DB JE使用自定义序列化代码存储序列化的Java对象是迄今为止我们测试的检索数据最有效的解决方案。使用存储的偏移量从未压缩的文本文件中提取数据可能会更快地返回特定格式的数据。然而，由于未压缩文件的大小以及不同数据库和格式的数量，这种方法不如动态生成各种表示法实用。将存储在磁盘上的数据量降至最低还可以确保应用程序能够从增加磁盘缓存大小中获得更多好处。
网站应用程序是自包含的，可以在零配置的情况下开箱即用，用于开发和测试目的。非Java和计算密集型工具（如序列相似性搜索（BLAST）、多序列比对（ClustalW）和数据库标识符映射）在外部服务器上运行。为了进一步减少应用程序的占用空间，历史数据（如UniSave中的条目版本）[25]也可以按需远程检索。即使如此，包括索引在内的数据仍占用了将近140 GB（截至14.5版）。对于开发和测试，通过向加载了完整数据的站点发出查询，可以生成较小的、内部一致的数据集（~2 GB）。
如何在分布式镜像上部署站点？
在之前的设置中，每个“镜像”站点都有自己的公共地址。请求网址：http://www.uniprot.org被重定向到http://www.ebi.uniprot.org（EBI），http://www.pir.uniprot.org（PIR）或http://www.expasy.uniprot.org（SIB）。重定向是通过客户端HTTP重定向完成的，并且基于发起请求的IP地址的反向DNS查找所揭示的顶级域（TLD）。此设置的一个主要问题是，用户和网络爬虫会添加书签并链接到他们重定向到的镜像，而不是主站点。追踪这些链接并纠正它们是一项艰巨的任务。一个后果是，人们往往不会出现在最近的镜像上，也不会从故障切换中受益。新的设置利用了这样一个事实，即您可以将多个IP地址（A记录）附加到一个域名。客户端将或多或少随机连接到一个可访问的地址。我们还测试了是否可以通过让不同的名称服务器返回不同的IP地址来实现地理相似性，这取决于哪个镜像更近。这是可行的，因为客户端必须用于解析地址的“缓存”名称服务器通常会跟踪解析名称服务器对给定域的响应速度更快（因此最可能是最近的）。测试表明，这在一定程度上起到了作用，至少对最频繁的用户是如此。此解决方案的缺点是，只有两个镜像，当其中一个站点碰巧无法访问时，无法进行故障切换。考虑到美国和欧洲之间的网络延迟并不太糟糕，可靠性被认为更重要。如果在更偏远的地方设置了一个或多个其他镜像，则可能会发生变化。
当前镜像站点在Tomcat上部署web应用程序[26]并使用Apache[27]作为反向代理[28]以及请求日志记录、缓存和压缩响应（后者会对低速连接上的客户端的页面加载时间产生巨大影响）。如果应用程序在一个站点不可用（例如，在更新时），Apache会自动向另一个可用的镜像发送请求。web应用程序有一个特殊的健康检查页面，可以通过本地脚本（如果出现问题，会通知本地站点管理员）以及商业监控服务进行监控。此服务还可以检测网络问题并统计每个镜像的总体可靠性和响应性。应用程序级警告和错误由Log4j处理[29]. 错误会触发通知消息，这些消息会直接发送到由开发人员监控的电子邮件帐户（除非错误是由严重的操作问题触发的，否则通常表明代码中存在错误）。最后，还有一个JMX接口，它用应用程序信息（例如特定对象缓存的命中率）补充JVM级别的信息（例如内存使用）和Tomcat提供的信息（如打开的HTTP连接数）。
如何管理数据和应用程序更新？
只需将RDF格式的数据集或用于增量更新的部分数据集拖放到一个特殊目录中，等待应用程序拾取并加载数据，就可以将数据加载到web应用程序中。然而，为了节省资源，我们将所有数据加载到单个登台服务器上，然后将压缩后的数据分发到镜像站点，通常与最新版本的web应用程序一起分发。每三周更新一次，与UniProt版本同步。
如何降低代码中引入错误的风险？
所有代码更改都有可能引入错误，修复这些错误可能非常耗时，尤其是在没有立即检测到的情况下。为了将此风险降至最低，需要设置自动化测试。最低级别的测试以“单元”测试的形式进行。单元测试的目标是使用不同的输入覆盖代码中的每个执行路径。单独测试单个类。这些测试是使用JUnit测试框架编写的[30]. 最初的测试覆盖率很低，因为没有简单的方法来为独立测试解开类之间的关系。通过引入“依赖注入”框架，这一点得到了改进[21]删除硬编码依赖项。单元测试由“功能”测试补充。我们使用开源工具Selenium创建了一组测试脚本[31]. 这些测试可以在任何最近的浏览器中回放，并模拟用户与站点的典型交互。降低回放速度可以实现半自动测试，在这种测试中，一个人可以观察测试的执行情况，以捕捉布局问题，而这些问题在全自动测试中很难捕捉到。除了在发布之前对网站进行测试外，这些测试还可以用于浏览器兼容性测试。我们试图确保该网站与最流行的浏览器和操作系统组合（例如，Windows上的Internet Explorer 6和7，Linux上的Firefox 2）以及其他最新的浏览器（例如，Mac OS X上的Safari）配合使用。另一个主要的“功能”测试是将所有数据加载到站点中。考虑到这是一个很长的过程，通常使用较小的测试数据集来验证导入过程是否有效。其他一次性测试包括设置和使用工具来比较新网站和旧网站返回的搜索结果。
如何确保站点具有足够的性能？
基本性能目标是根据从以前站点的请求日志中获得的数字确定的。尽管应用程序是无状态的（即服务器上没有存储任何状态），因此可以横向扩展（即通过购买更多机器），但声明的目标是能够支持单个功能强大但“现成”的机器上的全部负载。以下是一些负载测试，用于识别潜在问题并帮助建立对应用程序的信心：
-
检索随机数据库条目
-
执行随机查询
-
下载大型结果集
-
模拟对主页的初始请求，包括所有必需的静态资源
测试是使用shell脚本和httperf工具的组合进行的[32]. 使用R分析性能数字，如响应时间[33]. 一旦发现性能问题，就可以借助商业分析工具跟踪有问题的代码[34]. 发现生产服务器上的性能问题1。通过外部监控工具记录对一般健康检查页面的请求的响应时间，以及2。通过分析每个月底的请求日志（包括每个请求的持续时间）。虽然前者允许立即采取行动，但后者可以帮助检测更微妙的性能问题。
如何确保人们知道如何使用网站？
除了最琐碎的函数外，很难预测人们是否能够理解如何使用它们。回答这些问题的最有效方法是进行“可用性”测试[35]. 我们设法招募了十几名左右的志愿者，让我们观看他们使用网站完成某些任务。他们中的大多数人都有某种生命科学背景，但并非所有人都定期使用我们的数据。测试采用以下形式：两个人，一个提问，另一个做笔记，去志愿者的工作场所（如果可能的话；这样可以确保人们有他们习惯的设置，并且感觉很舒服）。我们询问了一些简短的背景问题，以确定此人对我们的数据的熟悉程度，他们过去使用过哪些服务和工具等。根据这些信息，他们将被要求在网站上完成某些任务。我们尽可能避免给用户带来压力。另一个困难是避免根据我们使用的概念来表达任务。例如，当被要求填写“联系人表单”时，人们会立即找到“联系人”链接。但如果我们用不同的措辞来表达这个问题，比如“发送反馈”，那么成功就不那么有保障了。测试时间在半小时到一小时之间，有助于解决和开启不少“设计”讨论。
如何跟踪正在使用的内容？
为了了解站点的使用情况，以及站点的哪些部分工作正常，哪些部分工作不正常，必须收集站点使用情况的数据。可用性测试是非常宝贵的，可以帮助确定某些问题，但它很耗时，因此不适合收集大样本。幸运的是，可以通过web服务器日志文件记录用户与站点交互的一些基本信息。除了为每个请求记录的标准信息（例如请求的准确时间和路径、响应代码、IP地址、推荐人和用户代理）之外，web服务器还配置为记录请求的持续时间、返回的搜索结果数（如果请求是查询）以及响应的内容类型（这通常可以从请求资源的扩展中推断出来，但并不总是如此）。每个月从所有镜像站点收集一次请求日志，进行一些清理并加载到关系数据库中的简单星型模式中。这不仅使我们能够获得一般的使用统计数据（例如，不同资源的请求总数，显示自动请求的百分比），还可以查找问题（例如，没有产生任何结果或失败的查询）甚至有助于设置注释优先级（例如，查看哪些条目是最频繁请求但尚未被审阅或长时间未更新的条目）。
另一个用于收集统计数据的补充工具是谷歌分析[36]，它通过嵌入在网页中的JavaScript记录数据。这种方法的优点和缺点是，它不会记录自动请求，例如网络爬虫发出的请求或对非HTML资源的请求。虽然Google Analytics在整个测试阶段都处于启用状态，但现在只是偶尔启用。我们使用它来检查通过请求日志分析过程报告的非robot请求的数量（不太准确），该过程依赖于用户代理字符串匹配以及需要不时更新的模式。它还帮助我们了解人们使用的浏览器和屏幕分辨率，以及不太准确或无法通过web服务器请求日志获得的信息。Google Analytics可以就某些更改的影响提供快速便捷的反馈，因为数据至少每天更新一次，但它也可以减缓感知的页面加载时间，并加剧某些隐私问题。
如何以最小的人员伤亡“上线”？
尽管进行了所有的负载和可用性测试，但无法保证一次性将所有旧站点切换到新站点不会给我们带来更多技术问题，也不会激怒用户。长期的“测试”期使我们能够从许多用户那里获得反馈，并通过采取以下步骤逐步增加使用新网站的人数（以及网络爬虫等）（只要我们觉得足够舒服，就可以进入下一步）：
-
1
向某些人和组发出使用新网站的邀请。
-
2
在Google中获取站点索引。
-
三。
将旧站点链接到新站点。
-
4
逐个切换旧站点。
