翻译论文第一、二节,The DBpedia Konwledge Base,见下图

译文:

DBpedia项目为Web of Data的发展做了如下贡献:

  • 我们提出了一个信息抽取框架,这个框架可以Wikipedia的内容转化成一个丰富的多领域知识库。通过访问Wikipedia中实时文章更新feed【1】,DBpedia知识库实时反映Wikipedia的实际状态。从Wikipedia的infobox【2】模板向本体的映射提高了数据的质量。
  • 我们为每个DBpeida的实体定义了Web-dereferenceable identifier。它帮助我们克服了目前由于缺失实体identifier而阻碍了Web of Data的发展的问题,并且为Web上数据源的互相链接提供了基础。
  • 我们发布了RDF链接,这些链接从DBpedia指向Web数据源,而且支持数据发布者设置从他们的数据源指向DBpedia的链接。这已经促使围绕DBpedia的Web of Data的产生。

这篇文章列举了DBpedia最近的进展。它以两篇早一些的文章为基础。这篇文章的结构如下:在第2节总体先看一下DBpedia的结构和知识抽取技术;第3节是产生的DBpedia知识库;第4节讨论了用于服务在Web上的DBpedia的不同的访问机制;第5节概略地介绍围绕DBpedia的Web of Data;第6节展示了有利于DBpedia发展的应用程序;第7节回顾了相关工作;第8节总结列举未来的工作。

译者按:
【1】是一种给用户提供频繁更新内容的数据格式。https://en.wikipedia.org/wiki/Web_feed
【2】Wiki里面的信息列表,是一种结构化的信息。https://en.wikipedia.org/wiki/Category:Infobox_templates

2 The DBpedia Knowledge Extraction Framework

2 DBpedia 知识抽取框架
Wikipedia的文章中大多是自由文本,但是也包括了各种各样的wiki式的结构化信息【3】。这些信息包括infobox模板、分类信息、图片、地理坐标、指向外部界面的链接、消歧界面【4】、界面间的重定向和不同语言版本界面的链接。DBpedia项目从wikipedia中抽取了结构化的信息,,并且把它变成了又给丰富的知识库。本章,我们概括的学习一下DBpedia知识抽取框架,然后讨论DBpedia从infobox中抽取信息的方法的更多细节。

2.1 Architecture of the Extraction Framework

2.1 抽取框架的结构

图 1给了DBpedia知识抽取框架的概览。框架的主要部分是:PageCollections,它将Wikipedia文章中本地或者外部的资源【5】进行提取;Destinations,它存储并且序列化提取出的RDF三元组;Extractors将一个特定类型的wiki markup转化成三元组;Parsers通过确定数据类型、统一单位和分割wiki markup成列表形式。

ExtractionJobs把页面收集、extractors和destination放入一个工作流。框架的核心式Extraction Manager,它负责将把wikipedia的文章传入extractors并且将extractors的输出结果送入destination中。Extraction Managers还操作URI的管理和解析文章间的重定向。

图1. DBpedia的各个部分概览

这个框架现在包括了11种extractors,这些extractors处理下面的Wikipedia的内容:

  • Labels,所有的Wikipedia文章都有一个title,它用来作为wikipedia文章对应在DBpedia资源中的rdfs:label。
  • Abstracts,我们从每篇文章中提取了一个短的abstract(第一段,用rdfs:comment表示),还提取了一个长的abstract(目录表前的文本,大约500词,用dbpedia:abstract表示)。
  • Interlanguage links,我们抽取了一些链接,这些链接连接了wikipedia中主题相同语言不同的文章们,并且用这些链接为不同语言版本的DBpedia资源分配label和abstract。
  • Images,提取指向Wikimedia Commons(维基共享中心)图像的链接,这些图像可以用来描述资源,并且用foaf:depiction属性表示这些链接。
  • Redirects,为了识别同义词,Wikipedia的文章可以重定向到其他文章。我们提取出这些重定向,并使用它们来解析DBpedia资源之间的引用。
  • Disambiguation,维基百科的Disambiguation页面解释了同音异义。我们将Disambiguation链接提取出来,并且使用谓词dbpedia:disambiguates表示歧义消除链接。
  • External links,文章【6】包含对外部Web资源的引用,这些资源我们使用DBpedia属性dbpedia:reference表示。
  • Pagelinks,我们提取Wikipedia每个文章页面上的所有链接,并使用dbpedia: wikileaks属性表示它们。
  • Homepages,该提取器获得指向实体主页的链接,例如:在Wikipedia文章的链接中,通过查找关键词“主页”或“网站” ,可以得到公司或组织机构的主页链接。用foaf:homepage表示。
  • Categories,Wikipedia的文章是有分类的,它使用 SKOS词汇【7】表示。分类类别用skos:concepts表示,类别之间关系用skos:boader表示。
  • Geo-coordinates,地理提取器使用基本地理(WGS84纬度/经度)词汇表【8】和W3C地理空间词汇的GeoRSS简单编码【9】表达坐标。前者将纬度和经度分量表示为单独的事实,这样的操作允许在SPARQL查询中进行简单的区域过滤。

译者按:
【3】Wikitext, also known as Wiki markup or Wikicode, consists of the syntax and keywords used by the MediaWiki software to format a page.
【4】Wikipedia中有些page会有相同的标题,disambiguation界面就是wikipedia中消除歧义的方法。 https://en.wikipedia.org/wiki/Category:Disambiguation_pages
【5】这里的“sources”,译者理解为一篇Wikipedia文章中的“链接”,即指向Wiki中一些名词的链接或者指向外部网站、page的链接。
【6】这里指的是Wikipedia中的文章。
【7】原文引用:http://www.w3.org/2004/02/skos/
【8】原文引用:http://www.w3.org/2003/01/geo/
【9】原文引用:http://www.w3.org/2005/Incubator/geo/XGR-geo/

当前已建立DBpedia提取框架目的是实现两个工作流:常规的,基于转储(dump-based)的提取和实时提取。【10】

  • 基于转储的提取(Dump-based extraction)。:
    Wikimedia Foundation每月发布一次所有Wikipedia版本的SQL转储。我们定期使用30个Wikipedia版本的转储来更新DBpedia知识库。基于转储的工作流使用Database Wikipedia page collection作为文章文本的来源,并将N-Triples序列化器作为输出目标。生成的知识库可以作为链接数据,通过DBpedia的主要SPARQL端点下载(请参见第4节)。

  • 实时提取(live extraction):
    Wikimedia Foundation已授予DBpedia项目对Wikipedia OAI-PMH live feed的访问权限,该feed可即时报告所有Wikipedia的更改。每当更改Wikipedia文章时,实时提取工作流就会使用此更新流来提取新的RDF。这些文章的文本可通过*Live Wikipedia page collection *进行访问,该page collection获得根据OAI-PMH协议编码的当前文章版本。SPARQL-update destination会删除现有的三元组,并将新的三元组插入单独的三元组存储中。根据我们的测量,Wikipedia每秒大约更新1.4条文章页面。该框架在2.4 GHz双核计算机上每秒可处理多达8.8页(这包括整个工作流的时间消耗,从提取,挖掘并将三元组加载到Virtuoso【11】三元组存储中)。DBpedia反映Wikipedia更改的时滞介于一到两分钟之间。这里的瓶颈是更新流,因为从Wikipedia上的更改通常需要一分钟以上才能到达DBpedia。有关实时提取的更多信息,请参见http://en.wikipedia.org/wiki/User:DBpedia。

【10】译者认为这样表述更简单:将已经存储的Wikipedia的文章转换成DBpedia中,和实时将Wikipedia的文章转换到DBpedia。

2.2 Generic versus Mapping-based Infobox Extraction

2.2 通用infobox抽取方法对比Mapping-based infobox抽取方法

对于DBpedia提取最有价值的Wiki内容类型是Wikipedia infobox。信息框在Wikipedia页面右上角以属性-值对表的形式显示文章的最相关事实。图2和图3显示了在描述Tom Hanks和Andre Agassi的信息框后面的Wiki标记摘录。维基百科的信息框模板系统长期以来演变但是并没有统一协调。不同的社区使用不同的模板来描述同一类型的事物(例如infobox_city_japan,infobox_swiss_town和infobox_town_de)。不同的模板为同一属性使用不同的名称(例如birthplace和placeofbirth)。由于许多Wikipedia编辑者并不严格遵循描述模板的页面上给出的建议,因此使用各种不同的格式和度量单位来表示属性值。DBpedia项目决定通过同时使用两种不同的提取方法来处理这种情况:针对广泛覆盖的通用方法和为得到高质量数据的mapping-based的方法。

  • Generic Infobox Extraction.通用信息框提取。
    通用信息框提取算法(在[2]【12】中进行了详细描述)处理Wikipedia文章中的所有infobox。它以下列方式从infobox数据创建三元组:Wikipedia文章的相应DBpedia URI用作subject。谓词URI是通过将名称空间片段http://dbpedia.org/property/和infobox属性的名称连接起来创建的。根据属性值创建对象。对属性值进行后处理,以生成合适的URI引用或文字值。这包括识别MediaWiki链接,检测列表以及将单位用作数据类型。MediaWiki模板可以是嵌套的,我们通过blanknode创建算法进行处理它们。通用提取的优点是可以完全覆盖所有infobox和infobox 属性(attributes)。主要缺点是无法解析同义词属性名称,这使得针对通用信息框数据编写查询变得很麻烦。由于Wikipedia属性没有明确定义的数据类型,因此另一个问题是用于确定属性值的数据类型的而采用的启发式方法的错误率较高。
  • Mapping-based Infobox Extraction. 基于映射的信息框提取办法。
    为了解决同义属性名称和多个模板用于相同类型的事物的问题,我们将Wikipedia模板映射到一个本体(ontology)上。通过手动将Wikipedia英文版中的350个最常用的信息框模板分配到包含170个类的层次结构中,然后将这些模板中的2350个属性映射到720个本体属性来创建此本体。属性映射定义了有关如何解析信息框值和目标数据类型的细粒度规则,这样可帮助解析器处理属性值。例如,如果映射将目标数据类型定义为一些链接的列表,则解析器将忽略属性值中可能存在的其他文本内容。我们的本体目前使用55种不同的数据类型。异常的度量单位被规范化为这些数据类型之一。因此,infobox ontology中的实例数据比使用通用提取算法生成的数据更整洁,结构更好。基于映射的方法的缺点是当前仅覆盖350个Wikipedia模板;因此,它仅提供约843,000个实体的数据,而通用方法涵盖的数据为1,462,000个。虽然本体目前相对简单,但我们计划进一步扩展本体,例如,具有类不相交公理和逆性质。此类扩展的主要目的是允许DBpedia中进行一致性检查(consistency check),并在回答SPARQL查询时使用推断。由于任务的规模和从其它领域映射模板所需的(专业)知识,DBpedia团队的成员将无法为了覆盖所有Wikipedia信息框而扩展本体、映射和解析器规则。因此,我们正在研究众包(crowded-source)这项任务的方法。我们目前正在开发一种将DBpedia本体本身重新集成到Wikipedia中的方法。与某些信息框模板相关的本体定义将在相对应的模板定义页面上以信息框的形式表示。结合实时提取,更大的Wikipedia社区将拥有一个强大的工具来扩展和修订本体映射和信息框映射。

【12】原文引用文献:S. Auer, J. Lehmann, What have innsbruck and leipzig in common? Extracting semantics from wiki content, in: Proceedings of the 4th European Semantic Web Conference, 2007

3 The DBpedia Knowledge Base

DBpedia知识库目前包含大约2.74亿个RDF三元组,这些三元组是从英语,德语,法语,西班牙语,意大利语,葡萄牙语,波兰语,瑞典语,荷兰语,日语,中文,俄语,芬兰语,挪威语,加泰罗尼亚语,乌克兰语中提取的,土耳其文,捷克文,匈牙利文,罗马尼亚文,沃拉普克语,世界语,丹麦文,斯洛伐克文,印度尼西亚文,阿拉伯文,韩文,希伯来文,立陶宛文,越南文,斯洛文尼亚文,塞尔维亚文,保加利亚文,爱沙尼亚文和威尔士文版本。知识库描述了超过260万个实体。它具有30种不同语言的标签和简短摘要;609,000个图像链接;到外部网页的3,150,000链接;415,000个Wikipedia类别和286,000个YAGO类别。

表1 概述了常见的DBpedia类,并显示了每个类的实例数和一些示例属性。在下文中,我们描述了DBpedia知识库的结构,解释了标识符的构建方式,并比较了DBpedia所提供的四个分类schemata【13】。

【13】译者认为这个类似schema,译为“模式”。

3.1 Identifying Entities

3.1识别实体
DBpedia使用英文文章名称来创建标识符。通过双向评估Wikipedia文章的不同语言版本的链接,可以将来自其他Wikipedia语言版本的信息映射到这些标识符。根据模式http://dbpedia.org/ resource / Name为资源分配了一个URI,其中“Name”来自原始Wikipedia文章的URL,其形式为http://en.wikipedia.org/wiki/name。这样的好处如下:

  • DBpedia URI涵盖大范围的百科全书性质的话题。
  • 它们由社区共识来定义。
  • 制定了明确的管理政策。
  • 可以在知名的Web站点(Wikipedia页面)获得该实体的详细的文本定义。

3.2 Classifying Entities

3.2 分类实体
为了满足不同的应用程序需求,DBpedia实体分为四个分类模式。我们在下面比较这些schemata:

Wikipedia Categories:
DBpedia包含Wikipedia分类系统的SKOS表示形式。该分类系统包含415,000个类别。该分类系统的主要优点是它被数千名Wikipedia编辑人员协作扩展并保持最新状态。缺点是类别无法形成适当的主题层次结构,因为类别系统中存在循环,并且类别通常仅表示文章之间的非常松的相关性【14】。

YAGO:
YAGO分类方案由286,000个类组成,这些类构成了一个深层次的包含层级关系。该架构是通过将Wikipedia叶类别(即那些没有子类别的类别)映射到WordNet同义词集而创建的。
映射算法的细节在[19]【15】中描述。 YAGO层次结构的特征在于其深度和对一个类别中大量信息进行编码(例如,MultinationalCompaniesHeadquarteredInTheNetherlands类【16】)。虽然YAGO通常具有较高的准确性,但由于它是自动生成的,仍存在一些错误和遗漏(例如,之前提到的的类不是“MultinationalCompanies”的子类)。我们共同开发了一个脚本,该脚本将YAGO的类别分给DBpedia实体中【17】。该脚本可从YAGO下载页面5【18】获得。

UMBEL:
上层映射和绑定交换层(UMBEL)是一种轻量级的本体,它的建立是用于互连Web内容和数据。 UMBEL源自OpenCyc,包含20,000个类。反过来,OpenCyc类又部分衍生自基于WordNet同义词集的Cyc集合。由于YAGO也使用WordNet同义词集并且基于Wikipedia,因此可以通过UMBEL【19】导出从OpenCyc类到DBpedia的映射。分类法由UMBEL项目本身维护,关于其生成过程的细节可以在UMBEL的官网【20】上找到。

DBpedia ontology:
DBpedia本体由170个类组成,这些类形成一个浅层次的包含层次。它包含720个具有域和范围定义的属性。本体是根据英文版的Wikipedia中最常用的信息框模板手动创建的。 2.2节中描述的基于映射的infobox提取将本体用作目标架构。表1的左列显示了DBpedia本体的部分层次结构。

【14】a rather loose relatedness
【15】原文引用文章:F. M. Suchanek, G. Kasneci, G.Weikum, Yago: A large ontology from wikipediaand wordnet, Journal of Web Semantics 6 (3) (2008) 203{217.
【16】译为:Netherlands跨国公司的总部
【17】在DBpedia的实体中添加YAGO的类别。
【18】原文注释:http://www.mpi-inf.mpg.de/yago-naga/yago/downloads.html
【19】原文注释:http://fgiasson.com/blog/index.php/2008/09/04/exploding-dbpedias-domain-using-umbel/
【20】原文注释:http://www.umbel.org/

3.3 Describing Entities

3.3 描述实体
如果相应的英文Wikipedia文章包含一个信息框,则每个DBpedia实体都由一组常规属性和一组infobox-specific属性描述。常规属性包括label,长的和短的的英文 abstract,指向相应的Wikipedia文章的链接,(如果有的话,还需要)地理坐标,指向表示实体的图像的链接,指向外部Web网页的链接以及指向DBpedia相关实体的链接。如果一个实体存在于多种语言版本的Wikipedia中,则这些语言中的简短摘要和长期摘要以及指向不同语言的Wikipedia文章的链接将添加到描述中。

在http://dbpedia.org/property/命名空间下定义了由通用提取方法产生的Infobox-specific属性。基于映射的信息框提取所产生的属性在http://dbpedia.org/ontology/命名空间下定义。

Table 2比较了从常规的infobox extraction中、mapping-based infobox extraction中和从Wikipeida pages链接抽取中产生的数据库(所有数字来源DBpedia release 3.2,英文版)。DBpedia包含1,462,000个资源的通用infobox数据,而基于映射的方法包含的843,000个资源。2,853,315个Wikipedia页面之间存在链接。该页面数高于

DBpedia中的实体数(260万),因为还有额外的Wikipedia中的列表和模板页面。与通用数据集中使用的38659个不同属性相比,基于映射的数据集包含720个不同属性(包括许多同义属性)。页面链接数据集使用一个属性来表示Wikipedia页面之间的无类型链接。

在下一步中,我们测量了连接DBpedia实体的RDF图的特征。为此,我们从不指向DBpedia实体的数据集中删除了所有三元组,包括所有文字三元组,所有外部链接和所有无效链接。

表3中列出了这些精简数据集中“链接”属性的大小和数量。除去显示的三元组,与基于映射的数据集相比,指向其他DBpedia实体的属性百分比要高得多(53%)。通用数据集(25.6%)。我们用所有入站边的总和除以对象数计算平均节点入度,该对象从数据集中至少有一个入站边。这样可以独立于数据集的覆盖范围或大小来分析度数。在所有三个数据集中,度数最高的实体是美国。如图4所示,节点度数在所有数据集中均遵循幂律分布,这是小型世界网络的典型特征[18]。表3的最后一列给出的聚类系数计算为节点邻居之间现有连接的数量除以有向图中的可能连接数(k ∗(k − 1),k =节点邻居数量),并且在所有节点上平均。基于映射的方法由于覆盖范围较小,因此聚类系数略低。

【论文翻译】DBpedia - A Crystallization Point for the Web of Data-2009相关推荐

  1. 经典论文翻译导读之《A Bloat-Aware Design for Big Data Applications》

    [译者预读] 世界上最窝囊的莫过于运维说可以给你8核16G内存的高配机器你却只能说虚成4份再给我吧...为何,因为怕Java程序驾驭不了这么大的内存.实践发现JVM堆内存调到2G以上就要非常小心GC带 ...

  2. 【转】经典论文翻译导读之《A Bloat-Aware Design for Big Data Applications》

    [译者预读] 世界上最窝囊的莫过于运维说可以给你8核16G内存的高配机器你却只能说虚成4份再给我吧...为何,因为怕Java程序驾驭不了这么大的内存.实践发现JVM堆内存调到2G以上就要非常小心GC带 ...

  3. 论文翻译《Object-Level Ranking: Bringing Order to Web Objects》

    Object-Level Ranking: Bringing Order to Web Objects Zaiqing Nie Yuanzhi Zhang Jirong Wen Weiying Ma ...

  4. 【论文翻译】CN-DBpedia: A Never-Ending Chinese Knowledge Extraction System

    [论文翻译]CN-DBpedia: A Never-Ending Chinese Knowledge Extraction System 摘要 1 引言 2 系统架构 3 降低人力成本 3.1 跨语言 ...

  5. Deep Face Recognition论文翻译

    Deep Face Recognition论文翻译 作者: Omkar M. Parkhi ····································· Visual Geometry ...

  6. Spatial As Deep: Spatial CNN for Traffic Scene Understanding论文翻译

    Spatial As Deep: Spatial CNN for Traffic Scene Understanding论文翻译 Abstract摘要 Convolutional neural net ...

  7. 论文翻译_论文翻译的注意事项有什么?

    针对不同题材的文稿有不同的翻译标准,论文翻译是比较严谨的一种翻译类型,下面小编给大家分享论文翻译的注意事项有什么? 注意"从一而终" 所有的论文,在权威平台上发布的时候都必须译为英 ...

  8. 转:经典论文翻译导读之《Google File System》

    首页 所有文章 资讯 Web 架构 基础技术 书籍 教程 Java小组 工具资源 - 导航条 -首页所有文章资讯Web架构基础技术书籍教程Java小组工具资源 经典论文翻译导读之<Google ...

  9. 论文翻译_做论文翻译需要知道哪些翻译技巧?知行翻译:这3个技巧

    论文,在古代是指交谈辞章或交流思想.而现代常用来指进行各个学术领域的研究和描述学术研究成果的文章.论文不仅是探讨问题进行学术研究的一种手段,也是描述学术研究成果进行学术交流的一种工具.常见的种类包括学 ...

最新文章

  1. jqgrid的实用方法集合
  2. linux命令--VI命令详解(二)
  3. 最新PHP秒赞,快乐秒赞 php版
  4. azure 使用_如何使用JavaScript在Azure上开始使用SignalR
  5. C# log4net纯代码设置参数
  6. calendar.getinstance()获取的是什么时间_时间管理技能培训.ppt
  7. android 3d侧拉抽屉,iOS动画指南 - 4.右拉的3D抽屉效果
  8. Bootstrap滚动监控器
  9. [leetcode] 554. 砖墙
  10. 如何将iTunes资料安全地备份到外部硬盘驱动器?
  11. 阿里最新分享Redis全套学习笔记PDF版,图文并茂,太详细了
  12. RBF神经网络参数的参数优化(进化算法)+Matlab源码
  13. 关于Redis在windows上运行及fork函数问题
  14. Java字符串排序比较。
  15. 无法阻止的电竞热潮-用电竞连接世界
  16. Windows下运行Makefile
  17. 显卡内存足够但是torch报错RuntimeError: CUDA out of memory
  18. SSM整合(搭建一个Web脚手架)
  19. 网站ui设计是什么意思【萧蕊冰】
  20. DBlink 入门案例

热门文章

  1. Windows10禁用驱动程序强制签名方法
  2. 小白必看!您知道如何判断两台机器是否能正常通信吗?详解IP地址组成,网络地址和主机地址的区分!...
  3. 微服务调用链日志追踪分析
  4. 漫画云计算Serverless:一支穿云箭,千军万马来相见
  5. HTML5期末大作业:管理系统网站设计——蓝色OA企业员工管理系统(10页) HTML+CSS+JavaScript 学生DW网页设计作业成品 web课程设计网页规划与设计 计算机毕设网页设计源
  6. 微信收藏的html文件在哪里,微信如何收藏文件?微信收藏的文件在手机哪个文件夹?...
  7. 你的态度决定你的未来
  8. JBuilder快捷键 不全的请指教!
  9. PhoneGap安装和使用教程
  10. 武大计算机考研拟录取名单,2021武汉大学考研拟录取名单已公布