提供Deep Web访问的其他可选方案

访问deep-web内容有两种通用的方法。第一种方法是为特定领域（如汽车、书或者房地产）创建中间协调器(mdiator)，这种方法被垂直搜索引擎广泛采用。在这种方法中，我们先创建一个主(mster)表单（即作为中间协调器），然后在每个表单和该中间协调器之间创建语义映射。对于每个中间协调器上的查询，基于一些预计算的表单摘要信息选择相关的底层表单；通过语义映射在每个表单上构建查询；接着从每个选择的表单中返回内容，然后组合这些内容呈现给用户。从高层上看，该方法和现代提供购物对比的门户网站的实现思想很相似，这些门户网站通过使用Web服务，返回很多底层站点的供应信息。

由于垂直搜索专注于一个领域内的同类表单的收集，因此这种方法可以适合于垂直搜索，但它不适合于通用的搜索引擎。首先，构建和维护很多不同的中间协调器和映射的人工代价很高。其次，识别对搜索引擎关键字查询最相关的表单是非常具有挑战性的。只有小部分的表单需要识别，否则，底层表单接收到的用户流量可能超过了它们的处理能力。为了实现相关表单的识别，极端情况下，表单的摘要信息可能需要和底层内容几乎一样大。最后，即更基础的原因是，Web上的数据可以是方方面面，无法给领域的边界做出清晰的定义。因而，为Web创建一个中间协调器将是一项宏伟的挑战，而且该中间协调器需要支持100多种语言。因此，当目标是覆盖很多领域上的大量表单时，这种方法是不可行的。

第二种方法是探寻，为任何感兴趣的HTML表单预先计算最相关的表单提交。每个表单提交生成一个唯一的URL，该URL可以像任何其他的HTML页面一样被搜索引擎索引。这种方法能够充分利用现有的搜索引擎基础设施。此外，它可以将deep-web页面无缝地融合到Web搜索中，也就是说，这些deep-web页面可以被直接插入到结果页的排序列表中来响应搜索查询请求。此外，如果用户基于页面摘要(sippet)认为搜索结果是相关的，当点击该搜索结果时，就可以给deep-web内容带来用户流量。

实现探寻方法^[1]主要面临两个挑战。第一，HTML表单通常含有多个输入框，因此，对所有输入框的所有可能值的整个笛卡儿积进行枚举的简单策略，会导致生成海量的URL。Web爬虫需要抓取每个生成的URL，抓取太多的URL会耗尽Web爬虫的资源，而且很可能会对这些HTML表单的宿主Web服务器带来无法承受的负荷。此外，当笛卡儿积非常大时，很可能会有大量的结果页面是空的，因而从索引角度考虑，这些结果页是无用的。例如，在Cars.com上的某个查询表单有5个输入框，这些输入框的笛卡儿积生成的URL超过2.4亿个，而实际上该网站只有65辆车待售(htp：//www.cars.com)。毫不奇怪，对于这些URL，大量的表单提交将无法得到任何记录，因此对于搜索引擎是无用的。

第二，HTML表单通常包含文本输入框，而且可能需要输入合适的值才能够返回检索结果。文本输入框可以有两种类型：一是接受任意输入值的通用输入框，如关键字搜索框，二是只接受某个特定集合中的值键入的输入框，图9-1所示的是商店定位的邮政编码输入框。

本章的剩余部分所描述的解决方案采用如下策略来解决这些挑战。首先，我们设计了称之为“信息度测试”(iformativeness test)的测评方式，用来评估查询模板，即表单输入框的组合。对于任何模板，我们通过不同集合的值来探测表单中的模板里的输入框，并且检查我们得到的HTML页面之间是否有显著不同。生成的结果页面显著不同的模板被认为是作为探寻的好的候选模板。其次，为了识别适合于探寻的查询模板，我们设计了一个算法，它可以高效地遍历查询模板的空间。该算法权衡了生成更少的URL和达到网站内容的高覆盖率。最后，我们设计了算法来预测文本输入框的合适的输入值。该算法扩展了之前为通用文本输入选择关键字的算法(Brbosa 2004，Ntoulas 2005），采用富信息量测试方式来表示从通用的数据类型中识别键入的输入项的值，比如邮政编码、价格和日期。

HTML表单处理的基础

这里我们只是简要地概述了表单处理。更多的信息可以通过HTML表单规范来获取(htp：//www.w3.org/TR/html401/interact/forms.html)。

HTML表单是由form标签定义的（如例9-1）。参数action表示当表单提交时，需要执行查询处理的服务器。表单可以有若干个输入控件，每个控件通过input标签定义。输入控件可以有很多类型，其中最重要的是文本框(txt box)、下拉选择框(slect menu，通过分离的select标签定义）、复选框(ceckbox)、单选按钮(rdio button)和提交按钮(sbmit button)。每个输入项都有一个name，它通常不是用户可以直接在HTML页面上看到的名字。用户可以选择以下方式选择输入值：在文本框中输入任意的关键字，或在下拉选择框、复选框和单选按钮中选择预定义的选项。此外，存在隐藏输入框(hdden input)，它的值是固定的且对于和表单交互的用户是不可见的。隐藏输入框通常用于为表单提交提供一些额外的上下文信息（如该表单的来源站点）。在这一章中，我们集中研究表单中的选择按钮和文本输入框。复选框、单选框的处理方式和下拉选择框相同。

例9-1：包含让用户搜索工作的表单的HTML代码

当提交一个表单时，浏览器会通过get或者post方法，发送包含输入值的HTTP请求到服务器。如果采用get方法，参数会附加到action参数值后，在HTTP请求中，作为URL的一部分（如例9-1的http：//jobs.com/fnd?src=hp＆kw=chef＆st=Any＆sort=salary＆s=go)。如果采用post方法，参数会在HTTP请求体(bdy)中发送，URL仅仅包含action（如例9-1的http：//jobs.com/find)。因此，使用get方法从表单中得到的URL是唯一的（依赖于提交的参数值），但采用post方法得到的URL不是唯一的。

因为搜索引擎是基于Web页面的URL来识别它们，从post得到的结果页面无法区分URL，因此不能直接插入到搜索引擎的索引中。此外，按照HTML规范，当表单提交导致状态变化或者产生副作用(sde effect)（如购物车、旅行预定和登录），必须使用post表单。正如之前描述的，这样的站点通常本质上没有信息。由于这些原因，我们把注意力限制在get表单，这种表单可以生成更适合于Web搜索的内容。

任何需要输入个人信息的表单都必须去除，举个例子，通过过滤任何包含密码输入框以及任何如用户名、登录等通常都和个人信息相关的单词。同样，只是简单地记录用户反馈或者评论的表单也可以通过以下方式去除：忽略那些包含有文本区域输入框的表单。

最后一点，我们提出的方案无法处理Javascript事件（正如本章所描述的）。表单和输入控件可以包含onselect、onclick和onsubmit属性，这些属性可以包含任意的Javascript代码。处理这些事件意味着要模拟Javascript在所有可能事件下的执行。原则上，我们可以利用Javascript引擎如SpiderMonkey和V8（见本章的“参考文献”），通过利用Web浏览器为我们执行表单提交，从而扩展我们的算法来处理这些表单。但是这种模拟的处理代价很高，因而其挑战在于能够快速地识别那些很可能会生成deep-web内容的Javascript表单，而且可以把这些deep-web内容添加到搜索引擎索引中，也就是说，最后的那个Web页面有一个诸如get请求一样的“幂等URL”(iempotent URL)。

查询和查询模板

我们可以把表单理解为允许用户向后台数据库提交查询的接口。每个表单提交都是一个查询，这个查询的输入是表单的输入框中提供的值，返回的是数据库的记录子集。该查询属于由表单输入项和其值约束的限制性语言(rstricted language)。此外，表单站点的内容在查询之前是未知的。因此，为探寻选择表单提交的问题实质上是在内容未知的数据库中的限制性语言中选择一组查询。

选择正确的一组查询的挑战在于表单输入项的模糊性质。尤其是，输入项可以有两种类型。第一，选择输入项是在数据库记录上增加选择条件，如例9-1中的kw（在求职描述中的关键字(kyword)）和st（状态(sate)）。选择输入项的值可以从一个预定义的列表（通过选择菜单）中获取，或者在文本输入项中输入。文本输入项可能只接受特定类型的值，但其类型我们通常是无法知道的。选择输入项通常可以分配一个可以匹配数据库中所有记录的通配符值。对于选择菜单，该通配符必须是该菜单的一个选项，如输入状态有Any这个选项值；对于文本输入项，其通配符是空字符串。

第二，存在表示层输入项，它们不影响记录的选择，而只是控制表示方面，比如结果页面的排序或HTML页面布局，如例9-1中的排序。对选择输入项和表示层输入项进行区分是探寻算法需要解决的一个挑战。

形式上，假设我们需要使用SQL来提交查询。我们可以把表单站点的内容建模为只包含一个单表D的数据库，该表包含m个属性。每个表单提交可以看做一个如下查询：select*from D where P，其中P表示通过选择输入项来表示的选择谓词。

例如，假设例9-1的表单是用于在job表Jobs(position、city、state、desc)上提交查询，提交请求返回在美国加州的厨师岗位的检索，其对应的查询应该是：select*from Jobs where state='CA'and desc like'%chef%'。注意一点，我们这里假定在例9-1的其他输入项是表示层输入项。

探寻的问题本质上是选择一组较优的查询（表单提交）。但是，对每个表单提交的属性进行推测是不现实甚至不可行的。因为一个表单可能对应几百万种不同方式的表单提交，分别测试每个表单提交可能会耗尽底层站点的资源。为了推测表单提交的集合，我们定义了查询模板。查询模板指定表单中输入项的一个子集作为绑定输入项(bnding input)，其余的是自由输入项(fee input)。通过给绑定输入项赋以不同的值，可以生成多个表单提交。以SQL查询为例，查询模板可以简洁地表示表单中的所有查询：select*from D where P'，其中P'只包含表单中绑定输入项的选择谓词。绑定输入项的个数即模板的维度。表9-1显示了例9-1表单查询模板的三个实例。

注意，在实践中，为了生成有效的表单提交，必须给模板中的自由输入项分配值。理想情况下，我们希望不要为模板的SQL查询增加任何额外的选择条件。对于文本输入，我们可以分配空字符串；对于选择菜单，我们可以分配菜单的默认值，期望该值可以用通配符表示。我们注意到，为了减少用户交互操作的麻烦，绝大部分的表单都支持通配符表示。

探寻deep-web站点的问题现在可以划分为两个子问题：

·选择一组合适的查询模板；

·为绑定输入项选择合适的输入值，即采用实际值来初始化查询模板。对于一个选择框，可以使用该选择框的所有选项；但是对于文本输入框，必须预测输入值，而且我们不能假定对于需要考虑的那些值所在的领域存在先验知识。

为了在说明上尽可能简单，我们假设初始化输入项的一组值对于绑定输入项的所有模板都是一样的。但是，实际上有些输入可能是相关的。例如，一个输入项（如cityName)的值可能依赖于选定的另一个输入项（如state)的值，或者多个输入项（如salaryMax和salaryMin)可能会约束相同的底层属性。

选择输入项组合

我们首先描述如何判断表单中的输入项和输入项组合对于探寻是有用的。现在，我们假定表单中的每个输入项的值都是已知的，也就是说，把文本输入项和选择菜单都统一对待。对文本输入项中的值进行选择的问题将在第10章探讨。

正如所看到的，我们可以把探寻问题建模为选择一组合适的查询模板。在选择一组正确的模板中，从识别我们需要追求的一些目标开始。正如之前所述，简单地枚举所有可能的输入值的笛卡儿积的策略既浪费（给Web爬虫和表单的宿主服务器施加负载负担），又不必要（因为有大量的URL可能不包含数据记录）。

因为我们想尽可能多地发现deep-web内容，很自然地，其处理策略的一个目标是最大化底层数据库的覆盖率（即返回记录的所有数量），同时限制表单提交的总数量。但是，由于我们生成的页面需要添加到搜索引擎的索引中，因此我们也必须解决一些其他的问题。

首先，最佳的策略可能是确定一些能够包含大量结果的表单提交。但是，有大量结果的Web页面并不一定最适合添加到搜索引擎索引中。举个例子，对一个二手车网站，只有一个包含所有待售的Honda汽车的页面是没有用的；相反，如果它有多个页面，包含Honda的每个模型或者不同价格范围则更理想。因此，我们希望生成在每个页面中既不包含太少也不包含太多记录的URL。

其次，虽然一个搜索引擎的主索引很大，它还是远远不够存储从Deep Web抽取的所有页面。由于搜索引擎最重要的目标是根据用户的查询将用户引导到相关的Web站点，我们更希望拥有来自很多站点的丰富且重要的内容。从某种意义上说，生成的URL个数不需要是完整的，但必须足够好以便将流量引导到底层站点。

再次，对于Web站点探寻来说，实际上不需要追求百分百的覆盖率；为一个站点的那些内容丰富的页面建立Web索引就足够了。定期执行的Web爬虫最终会抓到通过探寻得到的页面的超链接（如对于相同的查询，链接到更多的结果，或者链接到相关查询的结果），因此，最终该网站的覆盖率会增长。

总之，为了实现只通过在每个站点提交少量的查询就能够达到较好的（可能是不完整的）覆盖率，我们的目标是为几百万个不同的表单选择查询，而且通过探寻将获取的页面作为搜索引擎索引的好的候选页面。

查询模板的质量

我们可以把以上列出的每个目标作为查询模板的标准。例如，我们绝对不想要一个包含表现层输入项作为绑定输入项的模板。这种模板返回的结果也可以简单地通过一个不包含表现层输入项的模板来提交查询，从而获得返回结果，而且这种处理方式，通常可以生成更少的URL。

包含很多维度的模板通常不是我们想要的，因为它们生成太多的URL，这些URL中有很多无法返回结果。然而，维度越多的模板能够保证返回越多的记录。

维度较小的模板通常是我们更想要的，因为它们生成较少的URL，但是也有可能这些查询每个都将返回太多的结果。正如之前所述，有太多记录的页面并不适合作为索引。此外，站点可能对在每个页面上显示的实际记录有限制，因此减少了返回的实际记录的数量。

因此，我们期望模板1）不包含任何绑定的表现层输入项；2）不包含维度太多或者太少的URL。从直观上说，模板的维度应该依赖于底层的数据库大小。

现在我们定义一个测试来进一步说明之前所述的标准。在我们描述之前，先举个例子来说明这个想法。如例9-1表单的两个模板，模板T1只有一个绑定输入项st(State)；模板T2只有一个绑定输入项sort(Sort by)，现在考虑这两个模板生成的表单提交集合（如表9-2所示）。

我们注意到模板T1的每个提交都返回不同状态下的job列表。因此，返回的记录不同，从而结果Web页面内容将会很不一样。我们称这种生成的Web页面内容很不同的模板为富信息量模板。反之，因为没有关键字，T2中的每个提交返回的记录都是相同的（所有job)我们称这种模板为非富信息量模板。从本质上讲，我们的目标是选择富信息量模板，去除非富信息量模板。

因此，我们可以基于从表单提交生成的Web页面的内容区分度(dstinctness)来评价模板。我们通过基于由模板生成的Web页面内容的相似性来对这些页面进行聚类，从而估计该模板生成的不同的Web页面的数量。

如果和表单提交的数量相比，不同的Web页面的数量很小，很可能是如下情况：1）该模板包含表现层输入项，因此多个页面的集合本质上有相同的记录；2）模板维度相对于底层数据库来说太多，因此产生大量的无记录页面，不同页面之间都很相似；3）模板（或者表单）有问题导致出现错误结果页面，这些错误结果页面也很相似。如果模板不存在这种情况，但是还是生成很相似的内容，那可能是搜索引擎索引的边界值，因此不可能对搜索引擎查询有任何影响。

富信息量测试

我们考虑对于给定模板生成的URL，并且下载这些Web页面的内容。我们计算从每个提交得到的Web页面内容的签名，当一个模板生成的Web页面内容计算得到的签名个数远远少于可能的提交个数时，则认为该模板是非富信息量的。

富信息量是根据阈值τ来定义的，该阈值可以通过实验确定。假设Sd是不同签名的集合，St是所有签名的集合。那么，当|Sd|/|St|＞τ时，表示T是富信息量模板。

相比之下，关于内容签名更具体的细节不是很重要，我们列举了该函数需要的一些重要属性。首先，该签名必须对HTML格式是透明的，因为表现层输入项通常只是改变Web页面的布局。其次，该签名必须和词项的排序无关，因为结果重排是很普通的表现层操作。再次，该签名必须能够忽略页面间的细微区别；因为区别的来源通常是广告，尤其是商业网站，更是如此。这些广告通常在页面边缘处展现。它们增加了页面的文本内容但是并不反映返回结果的内容，因此必须被过滤掉。这些签名不应该包含输入项的值本身。一个二手车搜索网站，如果在邮编为94107的区域没有红色的Honda Civic车出售，则很可能会有这样的错误信息“在94107区域没有红色Honda Civic汽车出售！”(N search results for Red Honda Civic in 94107！）。类似的，对于以{color make model zip}为查询项的结果页面，会有大量的“No search results for{color make model}in{zip}”的结果页。这些页面的唯一区别是搜索词不同，不排除搜索词的签名很可能会把这些页面当做不同的页面，因而认为相应的模板是富信息量的。

在实践中，可能不需要分析一个模板生成的所有提交的内容；而只是需要测试所有可能提交的一个足够大的样本集合就够了。

搜索富信息量查询模板

我们的目标是搜索表单中的富信息量查询模板。我们可以采取一个非常简单的策略来考虑表单中所有可能的模板，并对每个模板应用富信息量测试。但是，假设一个表单包含n个输入项，存在2ⁿ-1个可能的模板，那么对每个可能的模板进行测试的计算代价很高而且不必要，因此，可以采取增量式的策略而不是遍历所有模板空间，并且只测试那些可能是富信息量的模板。

我们的策略是从单一的绑定输入项模板开始，通过自下而上的方式搜索模板空间。这种策略的基本思路是认为模板的信息量很可能依赖于它扩展的模板，也就是说，它有额外的绑定输入项。如果模板T有维度k，而且其扩展的所有维度小于k（即维度为k-1）的模板都是非富信息量，那么T不可能是富信息量模板。

我们通过所有维度为1的模板开始，测试每个候选模板的信息量。如果有维度为1的模板被认为是富信息量模板，我们就给该模板维度加1，也就是说，构建包含绑定输入项超集的维度为2的模板。

因此，候选模板必须至少包含一个富信息量扩展模板（但该候选模板其本身并不一定是富信息量）。然后测试每个新的候选模板来确定该新模板是否为富信息量。从维度为2的富信息量模板，我们继续以相同的方式构建维度为3的候选模板，如此反复操作。如果某个维度不包含富信息量模板，程序就终止。

注意：当增加一个模板时，考虑到所有的候选输入项。我们可以选择更积极的策略，只考虑富信息量的输入项，即其相应的维度为1的模板是富信息量的。但是，我们相信，在实践上，这种策略会（错误地）忽略一些富信息量模板。也有很多表单，包含一个主要输入项用于返回结果，而其他的输入项实际上只是作为修饰。例如，一个包含make和color输入项的表单，如果对于make输入项选择默认值，而只选择color这一输入项时，则无法返回结果记录。因此，只有绑定输入项color的表单是非富信息量，而包含make和color的则是富信息量。

一旦搜索终止，我们可以把所有富信息量模板生成的URL增加到搜索引擎的索引中。对于搜索的调整有很多可以完善的地方。例如，我们发现永远都不需要考虑多于三个绑定输入项的模板，或者是生成很多提交的模板。它们不可能是富信息量模板，因此可以很容易地删除这些模板。不需要分析由一个模板生成的所有URL；通常来说，考虑一个足够大的样本就够了。

实验分析表明，我们的算法生成的URL远远少于其他更简单的可选策略。特别地，我们发现生成的URL数量比不采用富信息量测试的最佳的启发式算法少了两个数量级。我们还发现该方法可以高效地为表单确定富信息量模板——在分析过程中，无论测试的模板个数还是下载的模板提交总数在数量上都很小。重要的是，我们发现生成的URL依赖于底层数据库的大小，而不是表单中输入项的个数。

预测输入项值

大量的HTML表单包含文本输入项。此外，有些包含选择菜单的表单必须有文本输入项值才能够返回检索结果。

我们注意到文本输入项通常用于两种方式。第一，通用的输入项实际上可以接受任何合理的值，在输入项输入的查询词可以返回在后台数据库中包含该词的所有文档。这种情况的通常例子是通过标题或者作者搜索书籍。第二，存在一些键入的输入项(tped input)。这种输入项的值只能是一个定义良好的有限集或者数据类型（如邮政编码），或者属于一些连续的但定义良好的数据类型（如日期或价格）。在固定格式的文本框中输入无效的值通常会导致错误页面，因此识别正确的数据类型很重要。在通用的文本输入框中输入不好的关键字仍然可以返回一些结果，因此挑战在于可以识别关键字的一个有限集合，从该集合中可以抽取很多不同的结果页面。

文本输入项的两种类型可以分别对待。在接下来的部分，我们首先描述一个算法为通用的输入项生成关键字，然后考虑键入的输入项。

通用的文本输入项

在我们描述如何为通用的输入项识别好的候选关键字前，先来考虑（并驳回）一个可能的备选方案。可以想象，我们本可以在各种领域把涉及的查询词列表作为文本输入项值，并把每个文本输入项值和最适合的查询词列表进行匹配。但是，我们很快发现这种处理方式会有太多的概念和领域。而且，对于通用的输入项，即使我们在相同领域符合相同概念的两个分离的表单中识别输入项，相同集合的关键字也不一定在两个站点上都能正常工作。最佳的关键字通常是属于特定站点的(ste-specific)。由于我们的目标是扩展到几百万的表单和多种语言，我们需要一种简单、高效和完全自动化的技术。

我们采用迭代式探测的方法：从高层上，我们指定候选关键字的初始种子集合作为文本框的输入值，构建查询模板，把该文本框作为单一绑定输入框。生成相应的表单提交，下载相应的Web页面内容，从结果文档中抽取额外的关键字。然后，我们用这些抽取的关键字更新文本框的候选值；重复该过程直到无法进一步抽取关键字或者达到了某个候选的停止条件，如有足够多的候选关键字。在终止时，选择候选关键字子集作为文本框的输入值集合。

迭代式探测在过去作为从文本数据库中检索文档的方法而提出(Brbosa 2004，Callan 2001，Ipeirotis 2002，Ntoulas 2005）。但是，这些方法的目标是实现特定站点的最大覆盖。因此，它们采用了和站点相关的(ste-aware)技术，这些方法无法应用于所有的领域。

在高层上，我们定制了如下迭代式的探测方式：

为了确定文本输入框实际上是否是一个通用输入框，在第一次迭代时，使用初始候·选集合在模板上执行富信息量测试。结果表示，通用的文本输入框很可能会被认为是富信息量模板，而其他的输入框则是非富信息量。

·为了选择候选值的种子集合，我们分析了包含该表单的Web页面的内容。我们通过识别与页面内容最相关的单词来选择页面的单词。任何合理的查询词打分方法，如流行的TF-IDF方法(Slton 1983），都可用于选择表单页面的几个最佳查询词。

为了在每次迭代结束时选择新的候选值，我们考虑为模板分析的所有表单提交页面·上找到的所有选择词集合。排除在很多页面上都包含的选择词，因为这些选择词出现在每个页面上，很可能是HTML样本模板的一部分。我们还排除只出现在一个页面上的选择词，因为这些选择词很可能是没有意义的或者是具有特殊含义，不能代表该表单所表示的站点的内容。

为了对文本输入框选择最终输入值集合，考虑从表单页面或提交页面抽取的所有候·选值，根据这些值检索到最丰富的内容的能力来选择这些值（通过分析从表单提交得到的页面内容）。

我们注意到，为每个文本输入框设置单一的关键字个数的最大值的方式是不合理的，因为表单站点的结果内容的区别可能是几个、几十个到几百万个。我们采用back-off的策略来解决该问题。从每个表单一个小的最大值开始，在这过程中，我们评估了这些生成的URL对搜索引擎流量会带来的影响。如果受到影响的查询个数很高，那么我们就为该表单提高关键字个数限制，然后重启探测进程。

实验分析表明，这里概述的迭代式探测方法对于通用输入框选择输入项值是有效的。相应的表单提交可以展现底层数据库大量的记录个数。有趣的是，我们发现相同表单的文本输入项和选择菜单通常能够展现底层数据的不同部分。我们还可以构建Web爬虫，通过系统生成的URL，能够随时间展现更多的deep-web内容。

键入的文本输入项

实践表明，存在相对较少的类型，如果能够识别出来，可以用于索引很多领域，因此出现在很多表单中。例如，邮政编码在很多领域被作为输入项，包括店铺定位、二手车、公共记录和房地产。类似的，日期通常在很多领域作为输入项，如事件和文档档案。我们基于两个想法来利用以上的观察。首先，只有键入适当值，键入的文本输入框才可以生成合理的结果页面。通过这个想法，我们使用已知值为流行类型构建富信息量测试。我们考虑有限的和连续的类型。对于有限的类型（如美国的邮政编码和州的缩写），使用已知值的部分样本进行富信息量测试。对于连续的类型，可以根据不同规模次序，测试使用均匀分布值的集合。我们可以使用这样的输入项名称列表，通过手工提供或者随时间进行学习（参见[Doan 2001]），来选择候选输入项，应用于富信息量测试。

[1]即决定提交查询表单时，需要填写哪些输入框，并找到合适的值填写这些输入框。