关联数据的对象共指问题研究，本文主要内容关键词为：对象论文,数据论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 共指的概念
维基百科中共指(Co-reference)的定义是：在语言学中，当一句话或一个文档中多种表达指向同一个事物时，就会发生共指，语言学的术语是它们有共同的“指示物”。例如Mary说她会帮我，“Mary”和“她”指的是同一个人。类似的，我昨天看到Scott了，他在湖边钓鱼，“Scott”和“他”是共指[1]。
共指的概念也同样适用于语义网，当来自多个数据源的不同URIs描述同一个非信息资源对象时，不同的URIs是共指[2]。对象间的这种关系大部分情况下通过属性owl：sameAs链接。例如同一篇论文在Citeseer，DBLP，IEEE和ACM中用不同的URIs标识，URIs之间通过owl：sameAs建立链接。
共指不是一个新问题，它早就存在于语言学、情报学、数据库等多个领域。篇章共指消解是将篇章内的所有表达划分为现实世界中不同实体等价描述的过程，该问题是自然语言处理的核心问题，郎君等人在该方面做了很多研究工作[3]。在情报学领域，使用受控词表解决共指的问题，最著名的是《美国国会主题词表》(LCSH)。一个相关的研究是数字图书馆领域作者消歧问题。在数据库中，当来自不同数据库的记录被融合时，通过记录链接(Record Linkage)或去重(De-duplication)解决数据重复和不一致等问题。Glaser指出，每当知识被记录时共指就会发生[4]。
随着关联开放数据(Linked Open Data，LOD)项目的发展，越来越多的组织将自己的知识库发布为关联数据，建立到其他数据源的链接。与语言学或其他领域的共指不同，关联数据中对象共指更复杂，主要有以下3个方面的因素。
1)数据发布的开放性。任何人都可以将自己的数据发布为关联数据，与已有的任何关联数据源建立链接。如果把LOD中资源比喻为一本书，这本书的作者可以是任何人，作者之间可能没有任何沟通。对于书中的一个对象，如“张三”这个人，不同的作者可能使用不同的标识。
2)数据与上下文无关。同一个对象可能被不同的组织，以不同的目的、格式发布为关联数据。例如一篇文章被多个数据源发布，可能使用多个URIs标识，虽然文章的内容、作者相同，但它们有不同的元数据描述，因此使用信息时需要小心地处理上下文。
3)通用的资源标识。语义网的目标是集成Web 上机器可理解的知识，除了空节点外所有资源被分配通用的URIs。早期的数据源使用自己的命名模式，不考虑与外部系统的交互。而现在的设计者必须考虑标识的通用性，能够在全球范围内识别、使用资源。
2 关联数据对象共指问题
关联数据中对象共指问题主要是由于信息的分散性和URI的多样性造成的。单一数据集内部可能发生共指，一般是数据发布者的责任，发布者要保证数据整洁并与其他数据集一致。共指的主要问题发生在多个数据源交叉引用、识别、集成和重用时。Jaffri等人将关联数据的共指问题归结为两种情况：一个URI标识多个资源；多个URIs标识同一个资源[5]。
2.1 一个URI标识多个资源
这种情况在DBLP数据集中频繁发生，很多重名的人被错误地标识为同一个人。为评估DBLP中数据的质量，文献[5]中曾作过一个实验，选择英国最常用的9个姓和5个名，组成49个常用名，尝试判断这些名字是否属于同一个作者。结果显示，比较常用的名字中92%的作者被错误地合并出版物，最坏情况下15个不同的作者共享一个URI。在DBpedia 2.0版本中也存在一个URI标识多个资源的现象。如用户想要了解美国政治家R.Williams的信息，使用URI http://dbpedia.org/resource/Robert_Williams在语义网搜索引擎Sindice中检索相关信息时，歌手R.Williams，演员R.Williams的信息都会融入到一个页面中，无法区分URI描述的实例。DBpedia 3.0开始对共指给予更多的关注，使用以Wikipedia相同的消歧页面(Disambiguation Page)解决共指问题。
2.2 多个URIs标识同一个资源
这种情况频繁地发生在不同数据集用它们自己的URIs去标识同一个资源时。人物、地点这两种实体通常具有URI多样性，例如，在Sindice中搜索“Tim Berners Lee”，相关的URIs至少有几百条，包括：
http://dbpedia.org/page/Tim_Berners-Lee
http://dbpedia.org/resource/Tim_Berners-Lee
http://dbpedia.org:8890/resource/Tim_Berners-Lee
http://dblp.13s.de/d2r/resource/authors/Tim_Berners-Lee
http://rdf.freebase.com/rdf/en.tim_berners-lee
http://www.faviki.com/tag/Tim_Berners-Lee
http://data-gov.tw.rpi.edu/wiki/Tim_Berners-Lee
另外，同一个对象的不同表示方式，也可能导致多个URIs标识同一个资源。最常见的就是作者名称的缩写，如C.B.Jones，Cliff B.Jones，Cliff Jones实际上就是同一个人，却可能被错误地认为是3个不同的人，被分配不同的URIs。
共指问题具有深远的影响，从技术角度，直接影响关联数据的质量，给关联数据识别、集成、重用带来挑战；从应用角度，数据质量影响着关联数据应用的质量，以DBLP为例，如果应用以引文影响为依据分配研究资金，基于发文量对作者或机构进行排名是很不公平的。目前，随着LOD中数据的增长，关联数据的研究重点已经从开放权威的知识库转换为使用已有的关联数据构建应用，因此，共指问题必须引起高度重视。
3 关联数据对象共指识别方法
通过关联数据的对象共指问题分析可以看出，要想从根本上避免共指发生，必须保证两个不同的对象不共享相同的URI标识，相反，两个不同的URIs不能描述同一个对象。然而，在开放的关联数据空间中，允许任何人以自己的方式发布关联数据集，使得这两点都很难做到。因此，目前的共指问题解决方法集中于识别同一个对象的共指URIs。主要有两类方法：基于语义网OWL规则推理共指的URIs，包括owl：sameAs，IFP等；基于属性和属性值的相似度计算识别共指的URIs。
3.1 OWL规则
使用owl：sameAs谓词链接相等的URIs是使用最广泛的解决方法。很多重要的关联数据集都使用owl：sameAs建立彼此间的链接，如DBpedia，Freebase，GeoNames，New York Times等。据统计，2009年Billion Triples Challenge Dataset中已包含650万owl：sameAs语句[6]。然而，owl：sameAs并不像人们希望的那样能完全解决共指问题，相反它还产生了很多新的问题。这个方法的主要缺点是：在不考虑上下文的情况下认为两个URIs是永久的，完全相等的。
很多文献对owl：sameAs进行推理使用时的正确性提出了质疑[7-9]。Harry指出有4种更详细的关系可以替代owl：sameAs[8]，它们是：
1)同一个事物但属性不完全相同。这种情况下两个URIs指向同一个事物，但一个URI描述的所有属性，另一个URI不能完全接受，如钠和钠的同位素。OpenCyc中定义的钠不包括它的同位素，DBpedia中定义的钠包括它的同位素。同位素与标准钠的中子数不同，因此对钠的中子数，可以使用OpenCyc中的钠的定义，而不能使用DBpedia中的钠的定义。关联数据的发布者没有检查两个数据集中对象的所有属性，建立了错误的owl：sameAs链接。解决的办法是在建立链接时使用较弱的同一性，使用类似SKOS中的谓词，如skos：exactMatch，skos：closeMatch等。
2)同一个事物但处于不同的上下文中。这种情况中两个URIs指向同一个事物，均包含所有的属性，但不能在不同的上下文中重用。例如开家长会时张三的角色是学生家长，在工作中是大学教授。而在家长会的环境中教授的某些属性是不需要考虑的，即不同环境下同一个对象的属性可能不需要重用相同的数据。目前，已有研究将上下文的概念引入关联数据中，就是命名图(Named Graphs)，它规定两个URIs只有在特定的命名图中才能使用sameAs关系。
3)代表关系(Represents)。很多情况下URIs用来表示一个事物而不是事物本身，表示的事物和被表示的事物之间没有明显的界线。在自然语言中这种使用上的混淆是很普遍的，例如用个人主页或邮箱地址表示一个人，用Tim Berners-Lee的图片表示他这个人。解决的办法是使用较弱的同一性，在不同的命名图中区分这种代表关系。
4)近似关系。一些情况下，两个事物是不同的，但在某种程度上有很近似的关系，例如同位素和元素本身的关系，图片和图片复制品之间的关系等。这些事物十分接近，在关联数据中通常用owl：sameAs建立链接。目前，owl：sameAs大部分的错误来自这种关系。简单的解决办法是添加一个新的谓词“very similar to”或学习SKOS的谓词表示。SKOS词汇表有大量的谓词表示相近的意思，层级结构从skos：broadMatch，skos：narrowMatch到skos：closeMatch。
可以看出关联数据中表示同一性关系是很复杂的，远不是owl：sameAs关系能够表达的。已发布的关联数据集中存在着大量的、不准确的owl：sameAs关系，随着更多的数据集被创建和互联，owl：sameAs方法的弊端会像滚雪球一样被不断放大。虽然owl：sameAs有很多问题，但Harry认为重用关联数据中的owl：sameAs关系不是威胁而是机遇[8]。
除了owl：sameAs关系外，一些研究基于对反函数属性(Inverse Functional Property，IFP)和属性值的分析，识别并融合多数据源的共指URIs，即对两个三元组
为反函数性属性，并且
，那么可以判断实例
是等价实例。一个典型研究是实体合并算法[10]。该算法在预处理阶段将原始的三元组数据模型SPO扩展为四元组SPOC，即除主语、谓语、宾语外，增加了对数据上下文(Context)的存储，并按照POCS顺序建立索引。算法首先获取IFP属性，通过截掉资源谓词部分URI中最后的“#”或“/”之前的内容，获取属性描述信息。例如，对于谓词
，去掉“http://xmlns.com/foaf/0.1/”部分，即得到属性mbox。分析不同数据源的本体，通过owl：IFP标识识别出IFP属性。然后找到并存储共指的URIs，扫描POCS索引，如果两个四元组的宾语相等，谓词相等并且都是IFP属性，那么判定它们是同一个实例，用专门设计的数据结构成对地存储相等项。最后，融合相等的实例，用一个统一的、标准的URI描述实例属性，相等实例的主语、宾语被标准的URI描述替代，重写POCS索引。该算法被Falcons和SWSE等关联数据搜索引擎使用，识别和合并共指URIs。
基于IFPs属性识别对象共指的方法在一定程度上解决了共指问题，但可能排除了潜在的共指URIs，同时单纯依赖反函数属性来判断等价对象并不可靠，例如foaf：mbox，该方法认为具有相同Email地址的人是同一个人，但同一个Email地址可能会在不同时期分配给不同的人，并且不同的组织在使用这类属性的时候可能并不遵循反函数属性的语义规范。
3.2 属性和属性值的相似度计算
有一类方法基于属性和属性值的相似度计算识别共指的URIs。该类方法基于一个假设，即如果两个对象共享一些常见的属性和属性值，那么认为这两个URIs描述的是同一个对象。一个典型的研究是Hogan等人提出的使用统计学的方法识别和融合共指的URIs[11]。该方法的基本思路是如果两个实体共享一个属性，例如主页，那么他们可能相同的概率为p，集成这些概率值得到一个得分，通过阈值判断两个实体是否相等。
此外，有很多实例匹配的研究[12-14]，基于实例间属性值的相似度能识别共指关系，为共指问题提供了解决办法。基于属性和属性值相似度的这类方法存在的问题是计算结果可能不够精确。
综上所述，关联数据共指识别的方法主要有两大类：基于OWL规则推理相等的URIs；基于对象间属性和属性值的相似度识别共指的URIs。这两类方法的目的是识别出共指的URIs，融合这些URIs获取一个实体对象更多的描述信息或建立共指数据之间的链接。这些方法一般以特定的应用需求为背景，建立在固定的数据集合上，但不能从根本上解决整个LOD空间中的对象共指问题。
4 关联数据对象共指管理系统
一些研究关注于实际的关联数据对象共指管理系统，以解决LOD空间中的对象共指问题。系统能识别出共指关系并对共指数据进行管理，以方便其他应用或用户直接使用共指数据，获取某个实体对象的、多数据源的信息。虽然共指问题在语义网、关联数据中引起了越来越多的关注，但实际的解决系统却并不多。
本文在广泛的文献调研基础上，选择出两个具有代表性的关联数据对象共指管理系统，就两个系统的功能和技术原理进行详细分析。
4.1 一致引用服务
一致引用服务(Consistent Reference Services，CRS)是英国南安普敦大学开发的，目的是识别和管理语义网上的共指URIs。CRS与语义网中其他知识库或数据库一样，每个数据提供者管理他们自己的一个或多个CRSs。它的一个重要特点是将共指数据独立于原始数据进行存储，方便管理共指URIs且不会影响原始数据。系统的核心功能通过PHP和MySQL数据库实现，能与多种基于Web的应用或中间件轻松集成，RKB Explorer应用的底层架构使用CRS实现[15]。同时，CRS还提供一个独立的sameAs服务[16]，用户通过这个服务可以找到同一对象在不同数据集中的共指信息。
4.1.1 bundle机制 CRS尝试使用owl：sameAs，skos：exatcMatch等相等的语义关系识别并管理共指数据。为克服owl：sameAs不考虑上下文的缺点，提出了bundle的机制。bundle是多个相等URIs的集合，在给定的上下文中将描述同一个概念的资源进行打包，不同的bundles可能将相同资源的不同上下文做URIs分组。例如
包含一个人在机构A中的上下文，
包含同一个人在机构B中的上下文。CRS使用coreference本体[17]，bundle作为本体中的一个类，有以下几个描述属性：coref：canon，表示bundle中一个典型的URI，在bundle被调用时典型URI在相等集合中具有优先权；coref：duplicate，在特定上下文中相等的URIs；coref：lastUpdated，bundle的更新日期。作者H.Glaser在不同数据集中的共指信息被处理为一个bundle，用RDF/XML格式描述如下[7]：
一个URI至多存在于一个bundle中，属于一个CRS实例。bundles只对原子进行操作，融合成对的URIs。对给定的
，CRS首先检查每个URI是否已经存在于bundle中，如果没有，创建一个单独的bundle。当探测到一个相等关系时，bundles包含的URIs被合并，创造一个新的bundle，被融合的成员bundles被标记为不活跃(Inactive)，同时在新bundle中选择一个典型标识符。有多种方法可以用来选择融合后新bundle中典型的URI，如随机分配法、假设方法等，假设新bundle中典型的URI来自第一个被合并的bundle中的第一个URI。
4.1.2 CRS存储格式 CRS使用mySQL数据库作为终端存储，支持对大数据集的处理。查询CRS时，为快速获取共指信息，URIs被存储在索引过的哈希表中，CRS的数据库模式如图1所示[7]。这个存储结构使查询服务能快速找到给定URI在相应bundle中的共指URIs。存储有3个表，symbols表存储URI中的词汇；bundles表包括一个内部使用的序列标识bundleID，典型标识符，bundle的状态；uris表中的deprecated字段，在数据库中提供“deprecate”URI。从多个数据源获取的数据中包含低质量的信息，例如同名的不同作者被合并为同一个URI，解决办法是为每一个作者产生一个新的URI，分别执行共指分析。然而，这个过程会导致bundles包含来自同一个数据集的多个不相等的URIs，这些重复记录会产生严重的过载。共指分析完成后，要移除不需要的重复数据，减少查询迭代的数量。这些被移除的重复的URI在CRS中被标记为deprecated，当查询一个相等的URIs集合时，只有bundle中非deprecated的URIs会返回。
图1 CRS数据库模式
4.1.3 CRS查询 CRS可以被看成一个知识库，包含一些特定URIs的知识。当用户请求一个非信息资源对象时，请求被传递给服务器。根据客户端headers的不同，HTTP303重定向发出两个地址中的一个。如果请求header是application/rdf+xml，服务器通过SPARQL CONSTRUCT查询适合的知识库，产生一个RDF描述请求URI的详细属性，结果被缓存，303发出非信息资源的URI到客户端。如果请求的header是text/html，303 See Other被返回，标识一个html描述信息。每个机构管理自己的CRS中的URIs，通过下面的迭代算法找到所有相等的URIs。
4.2 实体命名系统
OKKAM实体命名系统(Entity Named System)是欧盟委员会第七框架计划(PF7)的大规模集成项目。该项目的目标是为不同的实例创建命名服务，类似计算机领域的DNS，该服务称为ENS。系统为发布到Web上的任何类型的实体，例如人物、地点、组织、时间、产品等，分配和管理唯一标识符，使语义网成为一个统一的、开放的、分布式的知识库，在数据集成时只需要简单地比较各实例信息的URI即可判断它们表示的资源是否相同，其中存储的任何一个实例都被OKKAM标识符唯一标识。
4.2.1 OKKAM系统架构 OKKAM系统是一个联合框架，OKKAMPUBLIC是其内部管理平台，由任意多个同步的节点组成，每个节点的整体结构如图2所示[18]。其主要分为两个不同的层次：核心层和服务层。核心层称为“OKKAM Core”，使用底层的多个oStore存储现有的本体实例和OKKAM系统的标识符。该层提供了创建和存储本体实例的OKKAM标识符，具有增加、删除、修改及查询实例的描述信息等基本功能。服务层位于核心层之上，提供了一系列更高级的服务，包括向oStore发布实例、搜索已存在的本体实例、对搜索结果进行排序等。客户端通过服务层操作OKKAM系统，客户端可以是用户或应用程序，应用通过查询该系统，获取满足一个实体的一系列属性值的描述并返回该实体的标识符；客户端可以在系统中插入一个新的实体并为该实体提供一系列属性值的描述，系统将返回一个新分配的标识符。
4.2.2 实例的数据结构 数据库oStore用来存储和描述本体实例，为能够存储不同类型的本体实例，例如人、地点、组织机构、事件等，OKKAM系统采用了图3所示的半结构化设计[19]。
图2 OKKAM系统架构
图3 OKKAM系统中实例的数据结构
一个本体实例有3种标识符：OKKAM数据库中的全局唯一标识符Entity Identifier；Preferred Identifier由本体实例的创建者提供，是其他唯一标识该实体的标识符，例如一个人的Email地址；Alternative Identifier是其他可以表示该本体实例的标识符。可以用键值对的形式存储本体实例的属性和属性值信息，Ontology Reference记录了本体实例所属本体的标识符。WordNet Identifier存储本体实例所属类的信息及WordNet版本，以便更加准确地搜索匹配的本体实例。利用这种半结构化的表示，该数据结构可以存储任何类型的本体实例，同时保存了所有本体实例共有的属性。
4.2.3 本体实例发布与搜索 OKKAM系统最主要的两个功能是新本体实例的发布和实例的搜索[20]。发布新本体实例，服务通过调用核心层的创建OKKAM标识符API和实例发布API为新本体实例产生一个OKKAM标识符，然后将其与新本体实例一起存储在oStore中。为避免不必要的空间浪费及数据冗余，在向数据库中添加一个新本体实例之前，系统采用人工干预的方法查询数据库中是否存在相应的本体实例，如果不存在，用户可以在本体实例发布页面中定义描述信息，如本体实例属性的标签，Ontology Reference等，然后存入数据库中。OKKAM系统另外一个重要的功能是搜索数据库中的本体实例以重用其URI。该功能根据用户输入的描述属性，在数据库中搜索与描述信息相匹配的本体实例及其全部信息，并将结果返回给用户。为避免“AND”链接的严格限制，OKKAM系统使用“OR”连接各个关键词进行查询，将每一个搜索到的实例属性信息与查询字符串进行相似度计算，根据相似度的大小将返回本体实例进行排序，根据具体的阈值将选择结果返回给用户。
这两个系统都尝试识别并管理关联数据对象的共指数据从而解决共指问题。CRS基于owl：sameAs，skos：exatcMatch，sc：isLike等谓词属性识别共指关系，并根据不同的上下文环境对共指数据进行分类存储，以便应用重用共指的URIs。OKKAM系统尝试为每个实体对象分配唯一的标识符，这种方法从宏观的角度提出了一个对语义Web中的资源进行全局统一管理的机制，但在开放的数据空间中实现起来具有很大的挑战性。
5 结束语
随着LOD中关联数据集的不断增长，关联数据的识别、重用、集成会越来越多。笔者认为，在使用关联数据时需要考虑数据的共指问题，可以通过人工识别、共指管理系统、语义网搜索引擎等方式识别出共指数据，确保数据的一致性和正确性。虽然目前已有一些尝试识别、融合、管理共指数据的方法，但都不能从根本上解决共指问题或实现起来难度较大。今后的研究中笔者将继续关注关联数据的共指问题，结合已有的方法尝试在实际应用中解决该问题。
标签：上下文论文; 语义分析论文; 实体关系图论文; 数据库系统论文; 信息存储论文; 对象存储论文; bundle论文;