根据关联数据的4个基本原则,在Web中发布的事物必须具有可参引的HTTP URI标识。统一资源标识符 (Uniform Resource Identifier,URI)是互联网中数字对象标识的基准,也是语义Web的基础,它能够唯一地标识Web上的任意一个资源,其思想是在需要的时候通过链接引用资源,因此不需要对资源进行备份或集中管理。“资源”是能够被标识的任何对象,包括信息资源(Information Resource),如邮件、Word或PDF文档;非信息资源(Non Information Resource),如一个客观事物、人、地点或概念。

HTTP URI是可参引的(Dereferencable),即通过这个URI在Web上可获得相应资源的信息。对于返回资源的表达和显示格式,根据内容协商(Content Negotiation)机制,如果URI参引时要求的媒体类型(MIME-type)为Accept: Application/RDF+XML,则数据源必须能返回被标识资源的RDF/XML描述;由于一般的浏览器不支持RDF显示(如直接显示RDF源码或仅提供下载不支持显示),当HTTP头的媒体类型请求为Accept: Text/HTML时,则需要提供基于HTML的、适合阅读的格式。

当参引的URI标识的是信息资源时,服务器成功响应返回给客户端的HTTP代码,即HTTP 200;对于非信息资源被参引时,服务器无法返回一个表达,而是根据内容协商机制,数据源会返回给客户端HTTP 303代码,即重定向到描述该非信息资源的信息资源地址,客户端再次请求,得到一个描述非信息资源的信息资源。除了内容协商和重定向之外,非信息资源的URI由相关信息资源和片断标识符(如#)组成,也能够实现参引。

关联数据以RDF模型来表达事物、特性及其关系。RDF对资源的表达通过一系列的三元组来实现,每个三元组由主语(Subject)、谓词(Predicate)和对象(Object)三个部分组成,构成一个声明。主语是URI所标识的资源;对象可以是一个字符串,如字母、时间、数字等,也可以是一个URI,是与主语有关的其他资源的标识符,即RDF链接(RDF Link);谓词表明了主语和对象之间的关系,谓词也可以是URI,比如来自某一词表或URI集合。RDF链接不仅可以链接同一数据源中的资源,还可以与其他数据源链接,使得用户能跟随RDF链接浏览整个数据Web。RDF链接是数据Web的基础,它将独立的资源编织成数据Web,通过数据Web,关联数据浏览器或网络爬虫能够遍历整个网络^{[ 4]}。

如何将已有的数据或新生成的数据发布为RDF三元组,是关联数据发布的核心。通常需考虑待发布数据的规模、更新频率和当前的存储方式。一般来说,RDF数据有以下4种生成方式。

(1)生成并发布静态RDF文件。这是一种最简单的关联数据发布方式,即将静态的RDF文件,通过Web服务直接进行发布。静态RDF文件可以手工创建,如发布个人的FOAF文件或RDF词表等,也可以通过软件将已有数据转换为RDF文件输出。这种方法适合数据规范不大或将较大的文件可拆分发布的情况,同时需要注意正确地配置MIME类型,并为非信息资源对象设置URI。

(2)通过关系型数据库的RDF转换实现。对于关系型数据库,关联数据可以看作是数据表的一种视图,可以使用某些工具来实现这种视图。如D2R(Database to RDF)服务模式基于数据库和目标RDF术语间声明的映射,能够对关系型数据库产生一个关联数据视图,并支持RDF浏览器和SPARQL端点对关系型数据库的访问,其核心是正确地实现和配置映射关系。D2R服务模式的具体应用系统有柏林DBLP书目服务器、汉诺威DBLP书目服务器、柏林自由大学Web系统小组服务器以及欧共体国家和地区服务器。

(3)通过其他类型信息的RDF转换实现。对于CSV、Excel、BibTeX格式的数据将其转换为RDF格式,可使用一些RDF化的工具,如ESW Wiki的ConverterToRdf ,SIMILE的RDFizers;将转换后的RDF存储在相应的RDF存储器中。理想的RDF存储器具有关联数据界面,即支持数据的Web获取。对于不支持关联数据界面的RDF存储器,可以选择支持SPARQL端点的存储,并将Pubby作为关联数据界面,置于SPARQL端点前。DBpedia采用的就是这种方式。

(4)通过对已有应用或Web API的封装来实现。越来越多的Web应用通过Web API提供自己的数据,如eBay, Amazon, Yahoo, Google and Google Base。各种不同的API提供了多样化的查询、检索接口以及多种格式的返回结果(如XML、JSON或Atom),造成了搜索引擎抓取和一般数据浏览器访问的困难。关联数据对Web API进行封装能够一定程度上克服这些问题,封装器可以将HTTP URI分配给由API提供的非信息资源,当被参引的URI请求为Application/RDF+XML时,封装器能够重写客户端的请求为相应的API,并将API请求的结果转换为RDF格式并发送回客户端^{[ 4]}。

基于关联数据发布的基本要求,Wikipedia的关联数据发布首要问题是结构化数据的抽取与RDF化的表达。Wikipedia的文章主要是自由文本,因此,要进行RDF化的表达和网络获取,首先要进行数据的结构化处理。实际上,Wikipedia包含多种类型的、具有结构化特征的数据。

MediaWiki是运行于Wikipedia后台的软件。它所提供的所有编辑、链接、元数据标注都是在文章的文本内、通过增加特殊的语法结构来完成的,也就是说,无论是结构化的还是非结构化的数据,都以一种WikiText格式来表示。因此,通过解析文章的文本语法,可以获得结构化的信息,WikiText的结构如下^{[ 5]}:

==heading ==

this is a paragraph

* this is a list item

* this is a another list itme

[[Wikipedia|link to article]]

MediaWiki通过描述模板生成了大量结构化数据,如图1所示的题名、分类信息、图像、地理坐标、与外部Web页面的链接、Wikipedia不同语言版本之间的链接、信息框(Infobox)等。

图1

	Figure Option ViewDownloadNew Window
	图1 Wikipedia页面的结构化数据

描述模板由模板名、字段名和字段值组成^{[ 5]},如下所示:

{{ TemplateName

| field1=value1

|field2=value2

|field3=value3 }}

描述模板分两种:

(1)信息框模板(Infobox Template),含有文章所讨论的主题和各种分面,通常这部分数据位于页面右侧的独立区域,是最重要的结构化数据来源,如图2所示。针对这部分信息,抽取算法可以检测所使用的模板,并利用模式匹配识别它们的结构,从而解析并转换为RDF三元组。由于信息框模板系统经过了一段时间的演变逐渐形成,因此缺少统一的规范,例如不同的模板对相同的属性可能使用不同的名称。信息框的早期抽取算法采用通用处理,将属性名称和值直接转换为三元组,对类似Birth Place和Place of Birth这样的相同属性是按不同名称处理的,而新的基于映射的抽取算法引入了DBpedia本体,基于模板与本体之间的映射来解决这个问题。

(2)非信息框模板,主要用于链接信息的描述,如链接到一个地图中的坐标、同主题的文章等。模板简化了抽取结构化数据和转化为其他格式的工作,因为数据是一致的,很容易解析为结构化的格式。在DBpedia中,所有从Wikipedia中抽取而来的实体都被分配了一个唯一的URI,形式为http://DBpedia.org/resource/Name,而这个Name是从原Wikipedia文章的URL中取得的,形如:http://en.wikipedia.org/wiki/Name^{[ 6]}。

图2

	Figure Option ViewDownloadNew Window
	图2 信息框的表现及编码[ 6]

从结构化数据抽取的工作流来看,主要包括几个部分:页面收集器(PageCollection)是本地或远程Wikipedia文章源的抽象;目标器(Destination)存储或设置是否连续抽取RDF三元组;抽取器(Extractor)将特定的Wiki标记转换为三元组;解析器(Parsers)通过识别数据类型、不同单元之间的转换值和将标记拆分为列表来支持抽取器。抽取业务将页面收集、抽取和目标器组成一个工作流。这个框架的核心是抽取管理器,用来管理将Wikipedia的文章传送给抽取器,并将输出提交给目标^{[ 7]}。结构化数据抽取与发布的系统框架如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 结构化数据抽取与发布的系统框架[ 7]

结构化数据经抽取并转化成RDF文件之后,存储于OpenLink Virtuoso存储器中,它能够提供SPARQL端点。为了获得关联数据视图,在SPARQL端点前面还部署了Pubby,能够为SPARQL端点提供一个关联数据界面。

在Web上获取关联数据,主要有以下三种方式^{[ 4]}:

(1)关联数据参引方式。关联数据要求以HTTP URI标识资源,通过Web可以参引并得到相应的资源RDF描述及相关资源的RDF链接。具体方式包括:关联数据浏览器,如Disco、Tabulator、OpenLink Data等;语义爬虫,如SWSE、Swoogle等;语义Web查询代理,如Semantic Web Client Library和SemWeb Client for SWI Prolog等。

(2)SPARQL端点方式。SPARQL是一种基于模式匹配的RDF数据查询语言,SPARQL端点支持SPARQL协议的语言处理服务,能够接收客户端的查询请求,并对RDF数据源进行模式匹配,将结果返回给客户端。用户可以通过SPARQL端点,像使用SQL语言查询关系型数据库一样,在Web上精确地获得所需要的数据。

(3)RDF转存文件方式。将数据集中的RDF数据以某种序列化方式,如RDF/XML, N-Triples等格式输出,并提供下载,实现关联数据的获取和使用。

DBpedia支持上述三种通用的关联数据获取方式,可以通过Pubby关联数据界面、关联数据浏览器和各种爬虫来获取,同时支持SPARQL服务(http://DBpedia.org/sparql)和RDF文件下载(http://wiki.DBpedia.org/Downloads),并提供了丰富的用户界面和功能来促进DBpedia数据的多样化使用^{[ 8]}。

(1) DBpedia与Web页面的简单整合

DBpedia是一种非常有价值的通用数据源,其数据可以内嵌入各种Web页面中实现简单的整合。例如,从DBpedia查询到一个数据表,包含有德国首都、非洲音乐家、计算机游戏等多种结构化数据,通过客户端的JavaScript或者服务器端的PHP语言将这些查询到的数据表嵌入到用户的页面中,并基于Wikipedia庞大的社区维护,通过DBpedia保持更新。

(2) 查询DBpedia.ORG

DBpedia.ORG提供多种形式的查询。它允许用户浏览DBpedia数据集,并且通过RDF链接到其他数据集如GeoNames、RDF Book Mashup或者是DBLP Bibliography而获得更多的信息。与基于关键词的Web常见的全文检索方式不同,结构化数据的查询提供了对数据关系的增值性使用,DBpedia利用数据关系,提供了从不同的维度和分面,逐步限定检索结果的功能。在查询的同时,DBpedia还结合了浏览功能。如检索关键词“Scorsese”,得到关于导演Martin Scorsese的介绍和其执导的电影,以及参与这些电影的演员。检索结果采用类似于PageRank的排序方法,引用的文章越多,则排序越靠前。

用户在得到排序的检索结果的同时还得到一个Tag云图。Tag云图来自于检索结果集所涉及的各个类,采用的分类标准是DBpedia分类和YAGO的分类。Tag云图可以帮助用户将检索结果缩小到特定的实体类型,比如演员是一个实体类型,即使一个用户输入的检索词没有包括任何关于演员的关键词,仍然可以通过Tag云图进行限定或精细化查询。

(3) 基于关系的查询构造

DBpedia提供了基于图模式的查询构造器。用户可以基于多个元组对知识库进行查询。对每一个三元组,有三个文本框分别针对主语、谓词和对象,用于变量、标识符或过滤器的输入。由于DBpedia中存在大量的数据模式,因此,用户在构建查询时必须要得到一些指引和建议。例如当用户在其中一个表格框中输入标识名称时,一个先期执行的查询会提供合适的选项。这就能确保所提出的标识符与图模式是真正关联使用的,并确保查询实际能够有结果产生。如图4所示,查询一名足球运动员,其球衣号码为11号,所效力的俱乐部拥有4万个以上坐位的主球场,并出生于人口大于一千万的国家;该查询需求采用多个三元组描述,并相应地输入查询构造器中,当以“?country”绑定国家变量,并限定其对象大于一千万时,系统会自动提供一系列谓词供选择。

图4

	Figure Option ViewDownloadNew Window
	图4 查询构造界面[ 8]

(4) 第三方用户支持

DBpedia的目标是支持各种针对Wikipedia的应用构建混搭平台。有大量的第三方应用使用DBpedia数据集,DBpedia经许可和授权,可提供数据集RDF文件的下载和转存。运行于Karlsruhe大学的Semantic MediaWiki,已经导入了DBpedia的数据集;WikiStory能够使用户对Wikipedia文章中的人物按时间线进行浏览;Object Sheet JavaScript可视化数据环境,允许基于DBpedia数据进行总表分析。