从表格中提取信息三元组答案

【问题标题】：Extracting information triples form Tables从表格中提取信息三元组
【发布时间】：2012-12-15 16:07:22
【问题描述】：

我有一个非常大的 HTML 表格数据集（最初从 Wikipedia 中提取）。我想从这些表中提取有意义的tripleSet（这不会与从维基百科信息框中提取三元组相冲突，这是相对容易得多的任务）。

对于人类来说，三元组必须在语义上有意义，而不是像 DBpedia 那样将三元组提取为 URI 和其他格式。所以我可以只提取表格文本值。

请记住桌子方向和形状的多样性。我看到的主要任务是提取表记录的主要实体（例如学校记录中的学生姓名），以便它可以用作三元组的“主题”。

示例

对于这样的表，我们应该知道主要实体是“服务器”，其他只是对象，所以关系应该是这样的：

<AOLserver> <Developed by> <NaviSoft>.
<AOLserver> <Open Source> <Yes>.
<AOLserver> <Software license> <Mozilla>.
<AOLserver> <Last stable version> <4.5.1>.
<AOLserver> <Release date> <2009-02-02>.

另外，请记住，主实体并不总是位于表格的第一列，甚至有一些表格根本不会谈论同一主题。

这是一个主实体是最后一列而不是第一列的表：

此表应生成如下关系：

<Arsène Wenger> <Position> <Manager>.
<Steve Bould> <Position> <Assistant manager>

问题

我的第一个问题是这是否可以使用基于规则的方法来完成，围绕示例制定一些规则并尝试概括，以便我可以检测到正确的实体？你能建议示例规则吗？

第二个问题是关于评估的，我该如何评估这样的系统？我如何衡量我的表现，以便提高它？

【问题讨论】：

标签： relationship semantics ontology wikipedia

【解决方案1】：

所以，我终于能够实现我的项目的目标，它需要大量的工作和测试，但它实现了。

这个想法主要停留在如下管道中：

1-一个提取表并将它们导入内存对象的组件

2-排除坏表的组件，这些是在表格标签中使用的东西，但它们并不是真正的表格（有时页面的编写者想要组织数据外观，所以他们将它们放在表格中）

3- 一个组件，用于剥离表格的样式，并通过按跨度数重复数据来解决列/行跨度

4-一个基于机器学习的分类器，用于对表格的方向（水平/垂直）和该表格的标题行/列进行分类。

5-一个基于机器学习的分类器，用于对应该是关系三元组的“主题”的行/列进行分类

第一个分类器是支持向量机分类器，它采用字符计数、表/行单元格计数比率、数字与文本比率、大写等特征。我们在准确率和召回率上都达到了大约 80~85%

第二个分类器是随机森林分类器，它采用与一行/列内的单元格相关性更相关的特征。我们在准确率和召回率方面也达到了大约 85%。

过程中还涉及一些其他细化组件和启发式方法，以使输出更加清晰并与表格的上下文相关

一般来说，维基百科没有使用额外的数据来使该工具更适用于网络上的任何 html 表格。但分类器的训练数据主要偏向于维基百科内容！

一旦完成，我将使用源代码更新问题代码。

【讨论】：

太棒了 - 做得很好！很高兴看到你让它工作了——一些表格的 html 语义（尤其是阿森纳页面上的内容被明确地混淆了！）

【解决方案2】：

了不起的项目！！如果您让它工作，请尝试将其合并到 dbpedias 爬虫/提取器中 - http://wiki.dbpedia.org/Documentation。

供参考 - http://en.wikipedia.org/wiki/Comparison_of_web_server_software

如果你看一下 HTML，列标题在一个 thead 元素中，而行都包含在 tbody 元素内的 tr 元素中，实体的标题 (/rdfs:label) 在一个 th 元素中 - 这个应该有很长的路要解决你的问题，而不会变得太脏和不精确。

我认为检查 html 结构以查看有多少行元素是值得评估这种方法的。

在第二个示例中 (http://en.wikipedia.org/wiki/Arsenal_F.C.) 确实没有thead 元素帮助，即。 - 允许我们假设页面本身即。阿森纳是表中数据的主体。

还有一些微格式，例如关于维基百科的 vcard scatter，可能无法阐明这些关系

我不确定它在维基百科的所有表格中的通用性如何，但应该是一个好的开始。我想尽可能地坚持 html 结构和微格式而不是陷入任何太棘手的事情是非常优越的

另外 - 每个链接都有一个 dbpedia uri 来识别它，这在这些情况下非常有用。例如。 http://example.com/resource/AOLserver http://example.com/property/Server http://dbpedia.org/resource/AOLserver。 http://example.com/resource/AOLserver http://example.com/property/Developed_by http://dbpedia.org/resource/NaviSoft。 http://example.com/property/Developed_by rdf: 属性。 http://example.com/property/Developed_byrdfs:label "开发者"@en

你见过吗 - http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/ - 可能值得生成映射

【讨论】：