关联链接维护的机制、技术与案例分析，本文主要内容关键词为：案例分析论文,机制论文,链接论文,技术论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 概述
随着关联数据浪潮的不断推进与广泛实践，大量资源以关联数据的形式发布到语义万维网中，仅仅从CKAN项目对关联开放数据LOD运动的成果统计来看，目前已有338个数据集涵盖其中[1]。当然，这些发布的数据集并不是孤立的存在，它们之间通过诸如owl：sameAs、seeAlso、foaf：known等谓词联系起来，构建了大量的关联链接。关联链接是指主体与客体分属不同数据集的三元组[2]，它表示主体是通过另外数据集中的内容进行说明。图1给出了一个由谓词owl：sameAs联系起来的关联链接，它的主体就是通过DBPedia中的数据资源来进行的说明。
图1 关联链接示意
RDF链接是体现关联数据价值的根本所在，能进一步反映关联数据的质量。随着发布数据集的不断增加，建立的RDF链接也会越来越多，链接的类型也会越来越复杂。由于数据集本身固有的动态性和万维网日益变更的资源，这些数据集无时无刻不在经历着变化，任何一个资源的移除、修改或更新都可能带来连锁性的访问问题，导致资源无法实现自动、正确的获取。
关联数据质量的另一个重要方面就是关联链接的完整性，即一个资源被参引到的可靠性。由于数据集的链接动态性，产生了大量的断链问题和无缝访问故障，影响了资源的导航，使得目标资源不可达。尤其在语义网环境下，机器进行数据网络处理时，会产生远远比文档网络中断链问题更严重的情况。文档网络里人们还可以用替换的路径获得信息[3]：比如直接手动操作HTTP URI来进入Web浏览器或使用搜索引擎找到单独的信息。但在复杂的关联数据环境中，文档网络的方法往往显得苍白无力。因此，在这样一个语义网大数据时代，有必要关注关联链接的动态变化与维护问题。作为链接维护的基础，本文首先概述了数据集动态性研究的一些进展，重点介绍了关联链接维护的一些技术机制与流程，然后结合DBPeida Live等三个案例具体说明不同的关联链接维护方法。
2 数据集动态性研究
国外很早就有学者开始关注数据集动态性领域，并称为“Dataset Dynamics”，随着Web数据的快速增长以及关联数据技术的冲击，该研究领域也显得非常活跃，涌现出了诸多有名的动态性描述词表[4]。此外，Jurgen Umbrich，Boris Villallon-Terrazas等还基于对数据集动态性的研究提出了抽象数据集动态堆栈(Abstract Dataset Dynamics Stack)[5]，如图2所示。
图2 Abstract Dataset Dynamics Stack
为了对数据集动态性进行深入研究，W3C还专门成立了兴趣小组(Dataset Dynamics Interest Group)，并基于已有的一些理论研究成果和应用实践，总结出动态性研究应该包含四个核心部分[6]，即：Dataset dynamics vocabulary、Change description vocabulary、Change notification protocol和Applications。其中，“数据集动态性词汇”需要能够表达数据集变动的频率、维度等元信息，能提供更新通知资源的链接；“变动描述词汇”则重点在于表达不同层次(triple、resource、event)的语义变化，提供额外的变动信息(时间、变动原因等)；“变动通知协议”用于在链接数据集间进行变动信息交流，实现变动信息的沟通传播，值得注意的是这里的协议尽量要基于标准(如Atom、OAI-PMH)并被广泛支持；最后的“应用”主要指监测或处理变动的客户端应用，如用于链接维护中实现动态性监测的典例DSNotify。
我们发现，在语义网和关联数据技术环境下，动态性领域的研究成果可以帮助我们更好地认识万维网，更好地把握数据链接的变动特点，从而更好地帮助我们进行数据集的链接维护，如可以实现Link maintenance、Dataset synchronization、Data caching等应用场景，需要被通知远程数据集的具体变动情况需求等。
3 关联链接维护的机制与技术流程
关联链接维护作为数据链接动态性研究下的应用场景，是动态性研究的一个重要组成部分。关联链接维护的技术机制与流程包括：关联变动监测、关联变动描述、关联变动通知以及数据源端同步(如图3所示)，其中，第三个环节——关联变动通知，更是集中体现了链接维护的核心机制与交互模式。
3.1 关联变动监测
顾名思义，这个环节的主要研究内容就是如何有效、准确地获取数据集内容的变化，重点在于发现本地数据集的变化，监测捕捉到变动的原始动作。在已有的系统原型中，大都会有一个叫做Monitor的模块，这个模块的作用就是监测并获取变动内容。关联变动监测可能从源端和目标端两个方面进行，目标端监测自己内容的变化较为方便，而源端则可以通过SPARQL、RSS等方式获取。另外，不同的系统由于需求不同，对数据集内容变化的监测周期、层次和粒度都会有所不同，变动频率高的可以适当采取较高的监测频率，对变动需求比较细的也可以适当细化监测的对象level。
3.2 关联变动描述
监测到数据集的变动情况后，必须将变动的信息进行规范化的描述。这个环节的主要研究内容是制定适合不同变化层次、粒度的描述词表。目前这部分的研究成果比较多，应用比较广泛的词表有VoID[7、Changeset[8]、Dady[9]等。通常来说，变动描述词表将变动信息分为资源与行为两部分：资源就是发生变化的关联内容，可以是数据集、三元组，也可以是特定对象；行为则是资源变动的方式，常用的行为包括新增(Add)、移除(Remove)、转移(Move)等。图4给出了一个利用Changeset词表和RDF格式对资源http://example.com/res#thing进行变动描述的实例。
图3 关联链接维护核心技术流程
图4 资源http://example.com/res#thing的变动描述[10]
3.3 关联变动通知
关联变动通知是通过特定协议将关联数据集的变化情况通知相关的数据源端，为其更新提供依据，它体现了链接维护的核心通信模式，重点在于变动信息的交流、传播与通知。变动通知的研究内容有两部分：(1)变动通知协议；(2)协议传播模式。通知协议目前研究和应用者都倾向于利用已有的成熟协议，如Atom、OAI-PMH等。协议传播模式则研究如何更方便、更节省资源地将信息进行周期通知，节点分布来看包括“目标—源”和“目标—第三方—源”两种，从主从性质来看可以归为Push和Pull模式，即基于Push的更新通知模式和基于Pull的主动监测模式，在实际的框架应用中，既可以单独地采用其中一种，也可以是两者的结合。
3.3.1 基于更新通知的Push模式
Push模式的重点在于数据集的发布者或目标数据集将变动的信息或文件主动发布出来，方便消费者捕获，如有新的变动行为发生，就主动通知订阅变动的消费者或应用系统。在数据集变动的资源数量比较庞大时，可能会利用第三方平台来帮助实现变动信息的发布，发布者只需告知发生了变化并提供相应变动信息的下载地址。表1简单列出了一些与更新通知有关的协议或服务。
3.3.2 基于主动监测的Pull模式
Pull模式的重点在于本地数据集主动监测目标数据集的变动情况，周期性地发送变动请求(如SPARQL请求)，获取目标数据集中一段时间内的资源变动情况，并在本地数据集中采取一定的措施进行变动的同步维护。这种模式理论上普适性最强，且无需本地数据集与目标数据集维持一定的关系，其中最有代表性的就是Niko Popitsch和Bernhard Haslhofer等在链接动态性维护技术中提出的DSNotify框架。
3.3.3 二者的结合
两种基本模式结合的典范就是德国柏林自由大学(Freie Universitat Berlin)学者Julius Volz等提出的一个关联链接同步维护技术框架——WOD-LMP(Web Of Data Link Maintenance Protocol)[18]，它定义了三种应用场景(Link Transfer to Target、Request of Target Change List、Subscription of Target Changes)和五个消息传递函数，分别由数据集源端S、目标端D发起并完成通信的整个过程。WOD-LMP协议的突出特点是把Pull和Push两种模式都纳入到了框架中，既能实现源数据集主动请求变动又能完成目标数据集发布变动通知，其中应用场景Request Target Change List主要体现Pull模式，应用场景Subscribe to Target Change主要体现Push模式。虽然完整性的WOD-LMP协议涵盖的机制比较全面，但是要求S、D端要同时支持该协议，目前该协议还只是一种理论框架，尚未应用到相关的系统中。
3.4 数据源端同步
链接维护的最后一步就是要实现资源的同步，采用具体的措施进行资源的更新，修复那些失效的链接资源，确保链接有效。由于关联链接中的资源都是通过URI来唯一定位和标识，因此链接的同步与以往的数据资源同步存在本质的不同，可以通过简单的修改资源陈述中的单个三元组URI，就能完成链接的修复，使得链接重新有效。此外，在具体的同步维护中，可以根据应用需求的不同而有所差别，可粗可细，可深可浅。
4 维护机制典型案例
4.1 DBPedia Live
DBPedia Live是由莱比锡大学、柏林自由大学、OpenLink Software等组成的研究小组开发实现的，作为关联数据集DBPedia的扩展，目标在于解决Wikipedia每天成千上万个资源发生的更新变化问题，为基于DBPedia的关联数据消费者或应用提供最新的信息。这里，DBPedia是Wikipedia的一种镜像，抽取Wikipedia文章的结构化信息并将其转换为RDF记录[19]。由于Wikipedia的文章不断被修改和编辑，为了满足二者数据同步的需求，DBPedia Live应运而生。图5给出了DBPedia Live的系统技术框架，主要包括三个组件：Local Wikipedia、Mapping Wiki和DBpedia Live Extraction Manager。
图5 DBPedia Live系统框架
(1)Local Wikipedia。该部分一开始就被安装了，它将与Wikipedia进行同步，并在两者之间通过OAI-PMH协议来帮助应用实现获取来自Wikipedia的持续更新。
(2)Mapping Wiki。它本身也是一个Wiki，同样可以用OAI-PMH协议来获取DBPedia映射中的更新，DBPedia映射文件可以在http://mappings.dbpedia.org获取。一般说来，映射文件的一个变动将会对一些Wikipedia页面产生影响。
(3)DBpedia Live Extraction Manager。该组件是DBPedia Live的实际提取框架，利用提取器在需要的页面上进行处理，新提取的三元组插入到存储库后端，覆盖旧的三元组，最后写成N-Triples文件并进行压缩，供其他需要与DBPedia Live保持同步的应用或者DBPedia Live镜像资源下载，在线获取地址为http://live.dbpedia.org/liveupdates/。DBPedia Live除了提供四种主要的更新策略[20]来提高效率外，还可以在地址http://live.dbpedia.org/dumps/下载DBPedia Live的镜像dumping文件，实现快速的数据同步而无需下载大量的变动更新文件。
DBPedia Live核心技术框架突出体现的是一种Push模式，它能通过OAI-PMH协议及时捕捉到Wikipedia的变动信息并写入相应的更新文件，通知DBPedia或其他的相关应用系统下载和同步。但是该框架的针对性太强，只能用于DBpedia数据集的更新与同步维护。
4.2 DSNotify
DSNotify[21]是维也纳大学开发的一款基于关联链接完整性监测与维护的工具，图6是DSNotify的系统框架和工作流程示意图。
图6 DSNotify的系统框架和工作流程
DSNotify的核心功能包括两方面：监测关联数据集之间的关联链接变化和对断链信息进行修补维护。它首先定义了关联链接变化的事件Create、Remove和Move。Create表示实体从无到有；Remove则相反，表示一个对象永久地从数据集(或者服务器)中消失；Move表示一个对象位置的改变。而这里的位置，可以理解为URI的变化、访问路径的变化等等。因此，Move应该是Delete和Create的组合。不难看出，Move是监测和更新的难点。
DSNotify的核心部分是其索引体系。整个索引体系中包括三个不同类型的索引：条目索引(item index)、移除条目索引(remove index)和存档条目索引(archived index)。当Monitor模块发现有新的实体时，会将该实体的信息(URI、特征向量以及相关元数据信息)保存到条目索引。条目索引可以理解为目前目标数据集中存在的条目或子集。当Monitor模块发现有关联链接无法解析时，就把该实体暂时放到移除条目索引中。而移除条目索引则通过复杂的算法来比较这种“无法访问”的原因是Remove还是Move。如果是前者，则保留在本索引中，并在一定时间之后将其转移到存档条目索引中；如果是后者，则更新条目索引里该实体的信息。总之，DSNotify就是基于这三个索引之间的内容变化来判断目标数据发生的事件性质。
需要说明的是DSNotify小组设想了两种DSNotify的应用场景，一种是运行于关联数据源端；另外一种是运行于数据目标端。对于后者，监测变得非常容易。因此，上面的分析更多是在数据源端的工作流程。
4.3 Dady Demo
Dady Demo[22]是由Michael.Hausenblas等人开发的一个在关联数据发布者和消费者间管理数据集变动的工具，它的框架模型如图7所示。
图7 Dady Demo框架模型
Dady框架中交流的主体涉及Publisher和Consumer双方，通过两个核心模块DCM(Dataset Change Manager)和DCW(Dataset Change Watch-dog)来完成主要功能，技术流程大体分为三个环节：
(1)数据集的描述：发布者利用VolD和Dady词表对数据集以及变动行为信息进行描述。
(2)DCM观察发布变动：DCM观察捕捉变动，基于标准的Atom协议描述和发布更新变动文档。
(3)Feed的处理：这里通过两种方式处理，即：直接使用Feed，消费者直接处理DCM返回的变动文档信息；利用DCW处理Feed，DCW订阅变动Feed并进行处理，并将结果通知消费者，这里可以通俗地理解为引入了第三方处理机制。
该框架在实现的时候，除了基于一些广泛使用的标准(Atom、VoID)外，为了减少难度，还引用了一些已有的库文件，如Linked Data Spider、Quartz scheduler和ROME Atom lib等。在采用的Atom变动Feed描述中，入口还包含了(Add、Remove)资源陈述的链接。Dady Demo另一个突出点就是它集中体现了变动交流的Pull和Push两种机制，尤其是在Feed的处理过程中，直接使用Feed体现了主动的Pull模式，而利用DCW来进行Feed的处理过程则反映了更新通知的Push模式。
需要注意的是，该框架最初仅仅支持一个数据集RDF/XML文档的陈述。虽然该维护框架相对比较全面一点，但Demo的实现还仅仅是考虑了数据集中比较明显的变动，比如直接从文件中增加和移除的陈述，对事件和变动的捕捉还不完整和全面。
5 总结与展望
目前来看，对于数据集的动态性变化研究以及由此引起的一些链接完整性问题，已经得到了业界的广泛关注，尤其国外对该领域的实践探索非常重视，已在链接维护技术领域取得了很多成果，这些研究成果呈现出以下一些特点.
(1)技术标准不够统一，各自为政。这里不仅仅指技术的实现手段，更多的是不同的维护框架往往采用不同的协议标准。在动态性的描述上，往往根据自身的目标需求选取不同的词表，有的甚至为了描述的需求创建了新的词表，比如DSNotify为了更好地反映变动类型事件，构建了DSNotify Eventset Vocabulary[23]。在变动交流上，出现了Atom、OAI-PMH、PSHB等一些协议。此外在框架出发点上，可能针对的对象是Resource、Triple或最基本的Dataset等。
(2)成熟应用的系统少，操作性差。虽然在数据集链接维护上提出了一些技术框架，但真正运行起来的系统却很少，有的甚至还只是一个理论模型，如WOD-LMP协议到现在都还未有人将其实现。此外，很多框架往往也只是选取了个别数据集进行试验，面对万维网中庞大的数据集群体，框架的操作性究竟如何尚待考究。
(3)普适性不强，有针对性。维护框架在提出时，缺少对数据集自身变动特征的全面把握，在应用上往往缺乏普适性。甚至有的是针对专门的数据集而开发的，比如DBPedia Live框架模型就纯粹针对Wikipedia，只能适用于DBPedia数据集的变动情况，不能应用在其他机制的数据集中。
在关联数据技术的推动下，目前国内大量领域的数据也已经发布出来，正在不断经受数据集变动带来的考验，关联数据动态变化维护将是下一步我们要引起重视的环节。只有进一步处理好数据集动态性带来的一系列断链、失效问题，才能更有效地发挥关联数据环境带来的优势，更好地在万维网中获取我们想要的数据知识，更好地在语义网海洋中徜徉。