Mining Data Records in Web Pages ——挖掘网页中的数据记录

这篇论文的引用频度比较高，应该说是基于ＤＯＭ的全自动抽取算法中比较经典的。ＭＤＲ算法的程序在作者的官网提供下载。限于篇幅，所有图表请参照原文。

作者后来又发表了一篇论文，Web Data Extraction Based on Partial Tree Alignment ，将ＭＤＲ中的字符串编辑距离算法替换为树的简单匹配算法，新系统命名为ＤＥＰＴＡ。

Mining Data Records in Web Pages

挖掘网页中的数据记录

译／Ｍａｔｒｏｘ

摘 要

Web中的大量信息包含在规则地结构对象中，我们称之为数据记录。数据记录的重要性在于其通常用于呈现页面中的重要信息，比如，产品或服务的列表。挖掘数据记录的目的是从中抽取信息并以此提供增值服务。由于准确率较低，目前的全自动技术不能令人满意。本文提出了一种能更有效地解决此类任务的方法。此方法主要基于一种字符串匹配算法和观察网页中数据记录得到的两条结论。它能够挖掘相邻的或不相邻的数据记录。我们的实验结果显示，此方法总体上优于现存的其他技术。

关键词：Web数据记录，Web挖掘，Web信息集成

目 录

1. 绪论 1

2. 提出的方法 3

2.1 建立HTML标签树 3

2.2 挖掘数据区 3

2.2.1 比较泛化节点 4

2.2.2 用编辑距离比较字符串 6

2.2.3 挖掘数据区 6

2.3 确定数据记录 7

3. 实验结果 9

4. 结论 11

5. 参考文献 12

1. 绪论

Web中的大量信息以有规律的结构对象的形式呈现。网页中的此类对象列表通常描述了一组相似的项，比如，一组产品或服务。本文称之为一组数据记录。挖掘数据记录很有意义，因为这使我们可以将多个数据源中的信息集成在一起，并以此提供增值服务。图1给出了一个数据记录列表的例子，其中的网页片段给出了两个苹果笔记本电脑的信息。每个笔记本电脑的完整描述就是一个数据记录。本文的研究目标是自动挖掘给定网页中的所有数据记录。

相关文献中已经给出了几种半自动或全自动的从网页中挖掘数据记录列表的方法，例如，文献[2][3][4][6][8][9][10][12]。文献[4][8][9][12]使用机器学习技术，这需要人工对网页中有价值的数据区域进行标注，因此它是半自动的。文献[6]提出了一种全自动的方法，其利用一组启发式规则和域本体来完成抽取任务。文献[2]对该方法进行了改进，设计了新的启发式规则同时没有利用任何任务域知识。我们将在实验部分中展示，实际上此方法的准确率较低。文献[3]提出了另一种全自动方法，此方法使用Patricia树和近似序列对齐算法来发现网页中的模式（模式代表一组数据记录的集合）。由于Patricia树的固有缺陷和序列匹配的不准确性，此算法通常产生大量的模式，而且这些模式并不完全准确。此外，此算法性能比较差。文献[10]提出了一种基于聚类和语法归纳的方法，然而其实验结果不能令人满意[10]。

除准确率低外，现存的方法也假定数据记录中的相关信息包含在相邻的HTML代码中。这个模型并不完备，因为在某些网页中，一个对象（一个数据记录）的描述可能和其他对象的描述混杂在一起。例如，HTML源代码中对两个对象的描述可能以如下方式排列，对象1的第1部分，对象2的第1部分，对象1的第2部分，对象2的第2部分。这样，对象1与对象2的描述就不是毗邻的。然而在浏览器中，它们对于浏览者来说却是相邻的。

本文提出了一种新颖，有效的方法来自动地挖掘网页中的数据记录。此算法称为MDR（Mining Data Records in Web pages）。它通常能够发现所有由表格或表单相关标签（例如，table，form，tr，td等）生成的数据记录列表。网络中的大多数数据记录由这些标签生成。我们的方法基于以下两条观察结论：

1.一组包含相似对象描述的数据记录通常呈现在页面中的某个特定区域，并且用相似的HTML标签格式化。此区域称为数据区。例如，图1中的两台笔记本电脑处于同一个区域。它们的格式也由几乎完全相同的HTML标签序列描述。如果我们将页面中的HTML标签视为一个字符串，我们就可以用字符串匹配算法比较不同的子串来找出相似的子串，这些子串可能代表相似的对象或数据记录。

此方法的问题在于数据记录可以从任何位置开始或结束。一组典型数据记录的标签字符串的长度并不相同，因为它们可能含有不同的信息片段（见图1）。

2.网页中的HTML标签的嵌套结果自然地形成了一个标签树。我们的第二个观察结论是，置于某个特定区域的一组相似数据记录在标签树中通常有公共的父节点，尽管暂时不能确定哪个是父节点（我们的算法将找出这个节点）。举例来说，图1所示区域对应的标签树在图2中给出（忽略了一些细节）。图1中的每个笔记本电脑的信息（一个数据记录）包装在5个TR节点中，它们的子树位于同一个父节点TBODY之下（见图2）。这两个数据记录由虚线框标出。换而言之，一组相似的数据记录由一些同一父节点下的子树组成。

进一步观察可以得出，一个数据记录不大可能从一棵子树的内部起始，在另一个棵子树的内部结束，而是从一个子树的起始点开始，在同一棵子树或后面邻近的子树终结。例如，数据记录不可能从TD*开始，而在TD#结束（见图2）。利用此结论可以得到一个挖掘数据记录列的有效算法。

我们的实验显示这些观察结果真实可靠。值得注意的是，我们并不假定网页中仅有一个数据区域。实际上，一个网页中可能有多个数据区域。我们的方法仅需要一个数据区域包含至少两个数据记录。

给定一个页面后，算法按下面三个步骤工作：

步骤1：建立一个HTML标签树

步骤2：利用标签树与字符串比较算法挖掘数据区。需要注意的是，直接挖掘数据记录列表是很困难的，我们的方法首先挖掘数据区，再从中找出数据记录列。例如，在图2中，我们首先找出节点TBODY下的单个数据区。

步骤3：从每一个数据区中发现数据记录。例如，在图2中，这一步将找出TBODY下数据区中的数据记录1和数据记录2。

2. 提出的方法

下面依次介绍所提出的方法的三个步骤。

2.1 建立HTML标签树

在本文中，我们仅使用标签来进行字符串比较，以发现数据记录。大多数HTML标签成对出现。每一对包括一个起始标签和一个结束标签。在一对标签内部可能存在其他标签对，这构成了嵌套的HTML代码块。用网页的HTML代码构建标签树是非常自然的。在我们的标签树中，每一对标签视为一个节点。图2是标签树的一个示例。

2.2 挖掘数据区

这个过程将找出网页中包含相似数据记录的数据区。直接挖掘数据记录比较困难，我们首先挖掘网页中的泛化节点。一个相邻泛化节点的序列形成一个数据区。我们将从每个数据区中分辨出实际的数据记录。

定义：一个长度为r的泛化节点（或一个节点联合）由HTML标签树中的r（r ≥ 1）个节点组成，这些节点遵循以下两条规则：

1）所有节点有公共的父节点。

2）节点间是相邻的。

我们归纳泛化节点的原因是，一个对象（或一个数据记录）可能包含在多个兄弟节点中，而不是一个。例如，在图1和图2中可以看到，每个笔记本电脑的内容包含在5个表格行（或5个TR节点）中。注意到我们称标签树中的每个节点为“标签节点”，以此与泛化节点区分开来。

定义：一个数据区是两个或多个具有以下属性的泛化节点的集合：

1）所有泛化节点有共同的父节点。

2）所有泛化节点长度相同。

3）泛化节点都是相邻的。

4）相邻的泛化节点间的编辑距离（字符串比较）小于一个固定的阈值。

举例来说，在图2中，我们可以塑造两个泛化节点。第一个由TBODY的前5个TR节点组成，第二个由余下的5个TR节点组成。值得注意的是，尽管一个数据区中的泛化节点有相同的长度（相同数量的子节点数），它们的子树中的内部节点可能差别迥异。因此，这些泛化节点能匹配不同种类的有规律的结构化对象。

为了进一步解释不同种类的泛化节点与数据区，我们使用图3中的人工标签树。为了便于标记，我们不用真实的HTML标签名表示标签树中的标签节点，而是用ID号。阴影区域就是泛化节点。节点5和节点6是长度1的泛化节点，当条件4中的编辑距离满足时，它们共同定义了标记号为1的数据区。节点8，9和10也是长度为1的泛化节点，当条件4满足时，它们共同定义了标记号为2的数据区。节点对（14，15）和（16，17）是长度为2的泛化节点。当条件4满足时，它们共同定义了标记号为3的数据区。

我们以两条比较重要的注释结束这一部分：

1.在实际应用中，由实验结果可以看出我们上面给出的定义是十分健壮的。这里的关键假设是，一个数据区在同一个父节点下。这一点非常合理，例如，一个数据区不可能从节点7开始，在节点14结束（参见图2）。

2.一个泛化节点可能不代表实际的数据记录（见节2.3）。它将被用于寻找最终的数据记录列表。

2.2.1 比较泛化节点
为了找出网页中的所有数据区，挖掘算法需要确定以下问题。（1）数据区的第一个泛化节点从何处开始？例如，图3中的数据区2从节点8开始。（2）每个数据区的一个泛化节点有多少个标签节点或组件？例如，在图3的数据区2中，每个泛化节点中仅含有一个标签节点（或一个组件）。

K表示一个泛化节点的最大标签节点数。为了解决问题（1），我们可以试着从每个节点开始找出连续的节点序列。为了处理问题（2），我们可以分别用以下的形式进行比较：1个节点，2个节点的联合，...，K个节点的联合。也就是说，我们从每个节点开始，执行1个节点的字符串比较，所有2个节点的字符串比较，等等。然后从比较结果中找出所有数据区。

实际上需要比较的次数并不多，因为：

·根据假设，我们仅需比较同一个父节点下的子节点。

·前几个节点的比较和后面节点的比较有重复的部分（见下面的例子）。

我们用图4来阐述完整的比较过程。图4中的父节点p下有10个子节点。我们从每个节点开始，对所有可能的节点联合的字符串进行比较。此例中一个泛化节点内的最大节点数为3。

从节点1开始：对以下字符串进行比较。

·（1，2），（2，3），（3，4），（4，5），（5，6），（6，7），（7，8），（8，9），（9，10）

·（1-2，3-4），（3-4，5-6），（5-6，7-8），（7-8，9-10）

·（1-2-3，4-5-6），（4-5-6，7-8-9）

（1，2）的意思是节点1的标签字符串将与节点2的作匹配。一个节点的标签字符串包括它所有子树的标签。例如，在图2中，TBODY下的第二个TR节点的标签字符串是，其中“...”表示第二个TD节点的子树的字符串。TBODY下第三个TR节点的标签字符串是。

（1-2，3-4）的意思是节点1与节点2的联合标签字符串将与节点3和4的联合标签字符串进行比较。

从节点2开始：我们只需计算：

·（2-3，4-5），（4-5，6-7），（6-7，8-9）

·（2-3-4，5-6-7），（5-6-7，8-9-10）

我们不需要作单节点的节点联合的比较，因为在从节点1开始比较的过程中已经完成。

从节点3开始：我们只需计算：

·（3-4-5，6-7-8）

这里，我们不需要作单节点和双节点的节点联合的比较，因为在从节点1开始比较的过程中已经完成。

比较标签树中每个节点的节点联合的算法（MDR）的全貌在图5中给出。它以深度优先的方式（第3-4行）从根节点开始遍历整个标签树。对于每个内节点，过程CombComp（图6）对子树中不同形式的节点联合作字符串比较。第1行声明，如果节点Node的子树的深度是2或1，算法将不对其进行挖掘，因为数据区不可能仅由单层标签构成（数据区由Node的子节点组成）。

过程CombComp的主要思想在前面已经讨论过。第三行检查是否至少由一对节点联合。如果不是就不需要作匹配。第4-8行通过编辑距离计算函数EditDist来比较不同的节点联合。

N是标签树中的节点总数，在不考虑字符串比较的情况下，MDR的时间复杂度为O（NK）（详情见文献[11]）。

2.2.2 用编辑距离比较字符串
我们使用的字符串比较方法基于标准的编辑距离。对于两个字符串S1和S2，算法的时间复杂度为O（|S1||S2|）[1]。在我们的程序中仅需要对非常相似的字符串进行比较，这实际上减少了计算量。只有字符串较长时计算量才较大。如果我们仅需要相似度超过50%的字符串，可以用如下方法降低计算量：如果|S1|>2|S2|或|S2|>2|S1|，则不需要进行比较，因为它们的差异明显过大。

2.2.3 挖掘数据区
现在我们可以通过找出泛化节点来发现所有数据区。下面结合图7来具体阐述。此页面有8个数据记录。算法将每一行视为一个泛化节点，并将虚线框作为一个数据区。

算法大体上通过每个父节点的字符串比较结果来找出相似的子节点联合，进而得到候选的泛化节点与数据区。为了做出最终的选择，必须考虑下面三个问题：

1. 如果高层的数据区覆盖了低层的数据区，算法返回高层数据区及相应的泛化节点。这里的覆盖指低层数据区在高层数据区的内部。例如，在图7中，在低层数据区中单元1与单元2是候选的泛化节点，它们组成了一个候选数据区行1。然而，它们被含有4个行的高层数据区覆盖了。在这种情况下，我们仅认为每一行是一个泛化节点。

2. 相似字符串的一个重要属性是，如果一个字符串集合s1，s2，s3，...，sn两两相似，那么上述集合中任何等量的子字符串集合的联合也彼此相似。这样，我们仅需将数据区中长度最小的泛化节点视为候选泛化节点。在图7中，我们仅需将每一行作为一个泛化节点，而不是两行的联合（行1-2，和行3-4）。

3. 为了判断两个字符串是否相似，必须先确定编辑距离阈值。这需要由一组训练页得出。

这一步的算法在图8中给出。算法找出一个页面中的每个数据区和相应的泛化节点。编辑距离阈值为T，任一节点为Node，泛化节点的最大标签节点树为K，Node.DRs是Node下的数据区的集合，tempDRs是存储每个Node的子节点放弃的数据区的临时变量。行1与图5中的行1相同。算法的思想是以深度优先的方式自上而下遍历整个标签树。对遍历到的每个节点执行函数IdentDRs，并在结束对其子树的遍历时执行另一个函数（行6）。

1. 在遍历时，算法通过函数IdentDRs（行2）找到每个节点的候选数据区。

2. 当结束对某一节点的遍历时，算法检查Node.DRs中的父级数据区是否覆盖了子级数据区。那些被覆盖了的子级数据区将被丢弃，因为我们认为父级数据区更可能是实际上的数据区。函数返回Child.DRs中没有被覆盖的数据区，并将其存储在tempDRs中（行6）。在所有Node的子节点都被处理后，Node.DRs∪tempDRs给出了Node的子树中所有没有被覆盖的数据区（行7）。

现在我们讨论过程IdentDRs。注意到先前的步骤中已经计算出所有可能的子节点联合的编辑距离。这一步中使用这些编辑距离值与阈值T来发现Node节点的数据区。也就是说，需要确定哪个联合代表了泛化节点，每个数据区从何处开始，在何处结束。

过程IdentDRs在图9中给出，此过程分辨出最小泛化节点。IdentDRs过程是递归的（行15）。在每一次递归中，抽取出下一个覆盖了最大子节点树的数据区maxDR。maxDR由以下三个成员（行1）描述，（1）联合中的节点数，（2）数据区中起始子节点的位置，（3）过程涉及的或数据区中覆盖的节点数。curDR是当前需要考虑的候选数据区。字符串比较结果存储在一个与每个节点相连的数据结构中。值可以通过过程Distance（Node，i，j）（此过程仅是一个查找表格的过程，并未在此列出）获得，其中i代表i-联合，j代表Node的第j个子节点。IdentDRs主要检查每个联合（行2）和每个起始点（行3）。对每种可能的情况，算法找出第一个含有一组泛化节点的连续区域（第5-10行）。第11-12行更新最大数据区maxDR。第11行中的条件确保只返回的是较小的泛化节点，除非较大的泛化节点覆盖了更多的节点并且起始点在较小的泛化节点之前。

最后，过程UnCoveredDRs在图10中给出。tempDiffDRs将那些没有被覆盖的数据区存储在Child.DRs中。

设标签树中节点总数为N，过程FindDRs的复杂度即为O（NK2）。由于K通常很小，算法的计算量较低。

2.3 确定数据记录

在找出页面中所有数据区与相应的泛化节点后，我们可以确定每个数据区中的数据记录。正如前面提及的，泛化节点可能并不是包含了单个对象的数据记录，因为过程UnCoveredDR返回的是高层数据区。实际的数据记录可能在低一级的数据区中，例如，泛化节点可能包含一个或多个数据记录。

图11显示了包含两个表格行（1和2）的数据区。行1和行2已经被识别为泛化节点。然而，他们并不是单独的数据记录。每一行实际上包含了两个数据记录（对象）。

为了从数据区的每个泛化节点中找出数据记录，可以利用下面的约束条件：如果泛化节点包含了两个或多个数据记录，这些数据记录的标签字符串必须是相似的。这条约束是很明显的，因为我们假定数据区包含的是相似的对象。

从泛化节点中找出数据记录的过程比较简单，因为它们组成了同一层的泛化节点（包括子树）或是标签树中低一级的节点。实验表明，我们只需向下遍历一层节点，检查其是否存在数据记录。如果不存在，则将同一层的泛化节点作为数据记录。这基于上面提及的约束条件，即所有的字符串比较工作都已完成。然而，这一步的算法依赖于关于如何显示数据对象的启发式规则（详见文献[11]）。识别不相邻数据对象的算法也在文献[11]给出。

3. 实验结果

我们测试了基于本文算法（MDR）的系统，并与其他两个比较先进的系统，OMINI[2]和IEPAD[3]，进行比较。实验结果如表1所示。下面首先介绍实验配置。

实验网页：我们从OMINI的官网选取了18个页面。由于大多数网页变化频繁，OMINI的三个页面没有包含本实验所需的规则数据记录。所以这3个页面没有包含在内。我们也选取了大量其他主题的网页，例如书籍、旅行、软件、拍卖、工作、电子产品、购物、和搜索引擎返回页。

编辑距离阈值：我们在系统中通过大量的训练页（不包含在测试页中）来选择编辑距离阈值，最终确定为0.3。

评测方法：用标准的召回率与准确率来评估不同系统的实验结果。

实验结果：下面讨论表1中的结果。

列1与列2：列1给出了每个实验或网页的id。前15个网页来自OMINI。列2给出了每个页面的URL。

列3：列3给出了每个页面中数据记录的数量。这里指的是比较明显的数据记录。虽然导航条也存在一定的模式，但它不能作为数据记录。由于OMINI试图找出页面中的主题内容，所以它不能抽取导航条或其他小区域。然而，IEPAD和MDR能够发现这些区域。尽管可以用一些启发式规则删除这类区域，但是考虑到它们对某些用户可能有用，我们保留了此类数据区。

列4：列4显示了MDR抽取的数据记录数。除了页面44外，所有的页面都可以完美抽取。MDR在页面44中丢失了一个数据记录。

列5，6，7：列5给出了OMINI正确抽取的记录数。列6给出OMINI发现的数据记录（可能不正确）的总数。列7给出了OMINI的一些错误的注释。

列8，9，10：这几列给出了IEPAD相应的三个实验结果。IEPAD通常产生大量的规则来从数据记录中抽取信息。我们试验了所有规则，并将最好的结果展示在列8中。

表格的最后两行给出了每列中数据记录的总数，各个系统的召回率和准确率。

在进一步讨论实验结果前，我们首先解释表格中的错误注释。

all-in-n（m-in-n）with noise：全部的（或m个）数据记录被识别为n个记录（m>n）。“with noise”表明数据记录中的一些项是噪音信息。

n-err：找到了n个（额外的）错误的数据记录。

miss n objects：丢失了n个正确的数据记录。

split into n：正确的数据记录被切分为n个较小的。例如，丢失了一个数据记录，而发现了一些其他的。

none-found：没有发现任何正确的数据记录。

all-miss-infor（n-miss-infor）：系统找到了所有（或n个）数据记录，但丢失了某些部分。

下面概述表1中的实验结果。

1.我们的系统MDR能够完美抽取除页面44外的所有其他页面。页面44中有一个数据记录丢失，原因是它和邻近的记录过于不同。从末两行中可以看出，MDR召回率达到99.8%，准确率为100%。而OMINI和IEPAD的召回率仅为39%。

2.在列7和列10中，不包含注释的单元表示此系统正确抽取了所有记录。OMINI完美抽取了46个页面中的6个，而IEPAD也仅正确抽取了14个页面。我们的系统MDR能正确抽取除页面44外的所有页面。

3.在列7中可以看出，OMINI将近20个页面的许多数据记录分别识别为一个记录，并包含了一些噪音项。很显然，OMINI基于标签的启发式方法有严重的缺陷。

4.OMINI和IEPAD均不能识别非相邻的结构。例如页面1，4和36。

运行时间：实验PC的CPU为奔腾4 1.4GHz，内存为512MB。处理单个页面的时间小于0.5秒。

4. 结论

本文提出了一种新颖而有效的方法来挖掘网页中的数据记录。此算法也能发现不相邻的数据记录，而现存的其他系统均不能处理这一情况。实验结果表明这个新方法明显优于其他两个现存的系统。

5. 参考文献

[1] Baeza-Yates, R. "Algorithms for string matching: A survey." ACM SIGIR Forum, 23(3-4):34--58, 1989

[2] Buttler, D., Liu, L., Pu, C. "A fully automated extraction system for the World Wide Web." IEEE ICDCS-21, 2001.

[3] Chang, C-H., Lui, S-L. "IEPAD: Information extraction based on pattern discovery." W W W-10, 2001.

[4] Cohen, W., Hurst, M., and Jensen, L. "A flexible learning system for wrapping tables and lists in HTML documents." W W W-2002, 2002.

[5] Doorenbos, R., Etzioni, O., Weld, D. "A scalable comparison shopping agent for the World Wide Web." Agents-97, 1997.

[6] Embley, D., Jiang, Y and Ng, Y. "Record-boundary discovery in Web documents." SIGMOD-99, 1999.

[7] Gusfield, D. Algorithms on strings, tree, and sequence. 1997.

[8] Hsu, C.-N., and Dung, M.-T. "Generating finite-state transducers for senu-structured data extraction from the Web." Information Systems. 23(8): 521-538, 1998.

[9] Kushmerick, N."Wrapper induction: efficiency and expressiveness." Artificial Intelligence, 1 18: 15-68, 2000.

[10] Lerman, K. Knoblock, C., and Minton, S. "Automatic data extraction from lists and tables in web sources." IJCAI-01 Workshop on Adaptive Text Extraction and Mining, 2001.

[11] Liu, B., Grossman, R. and Zhai, Y. "Mining data records in Web pages." UIC Technical Report, 2003.

[12]Muslea, I., Minton, S.and Knoblock, C. "A hierarchical approach to wrapper induction." Agents-99, 1999.