关联数据在DOI系统中的应用与实现，本文主要内容关键词为：系统中的应用论文,数据论文,DOI论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 前言
2011年4月，国际DOI(R)基金会(International DOI Foundation,IDF)①和其最大的注册机构(Registration Agency,RA)CrossRef联合宣布CrossRef所拥有的4600万DOIs可直接应用于关联数据，这意味着DOI标识符可以简单、有效地作为HTTP URI定位与关联数字对象。在DOI世界中，IDF和CrossRef等RA可以通过标准的HTTP协议，将其成员的数据发布为适合机读的RDF数据格式；RA的成员，如出版商、图书馆等可以在其现有的数字内容提供方面，通过丰富的RDF链接，增加更复杂、更富含语义的表达。这是IDF推动DOI进入更复杂应用的重要举措，即鼓励关联数据社团和各类关联数据应用与工具，充分链接和利用DOI成员在Web上所发布的数字内容，而无需考虑API的兼容性、数据的所有权等问题；另一方面，具备标准性、唯一性和持久链接的DOI，因其所具有的可维护、可更新机制，具有显著的优势，成为值得链接的数据[1]。
目前，IDF的其他RA尚未启动相应的关联数据服务，本文根据IDF目前的技术框架，通过实例剖析，实验了RA层面的中文DOI系统的关联数据应用改造，希望通过语义技术的介入，为中文元数据更丰富或富含语义的数字服务提供可能性。
2 DOI与关联数据
DOI是最早由美国出版协会(AAP)提出并建立的一个由国际DOI(R)基金会(International DOI Foundation，IDF)作为DOI最高管理机构，美国国家创新研究所CNRI②提供Handle System技术支持，多个注册机构并行的标识体系。它是CNRI Handle系统在出版行业的成功应用，其目的是建立互联网环境下数字对象标识和知识产权管理和保护的解决方案。DOI系统主要包括命名语法规范、数据模型/数据字典、解析系统和由组织结构、政策、注册/管理程序所组成的执行机制[2，3]。
DOI的发展非常迅速，注册与解析量逐年增长。2012年，IDF一年的DOI解析总量超过10亿次，注册总量达6400万，DOI系统成为数字对象唯一标识符的国际标准ISO 26324∶2012③[4]。成立最早和规模影响最大的RA-CrossRef，其加盟的出版社和社团已达4242个、图书馆1923个，其中包括许多世界知名的出版集团，如Elsevier、Springer、John Wiley等。截至2012年，CrossRef的DOI数量为5640万，年解析量为5.3亿次，分别比上一年增长了14%和27%[5]。中文DOI④作为由中国科学技术信息研究所(ISTIC)管理和运行的RA，目前DOI注册数量已突破1700万，其中期刊DOI注册数量超过1500万，覆盖的期刊种类达5500余种，新增学位论文DOI注册量超过127万。
DOI的应用也比较成熟，最成功的应用是学术出版领域的科技文献开放链接，即基于二次文献与全文的指示关系、文献间的引用关系，以DOI为核心，构建开放的科技文献知识链接体系。此外，DOI还应用于科学数据的引用和链接，基于价值链的权利信息管理，如版权管理、电子商务以及版权相关的标准化工作等[6]。
DOI在学术及出版界的成功和广泛应用绝非偶然。DOI的命名机制具有从源头注册、与数字对象绑定、中心登记和永久保存、解析系统完备的特点。数字对象的版权所有者，如出版商，为其具有版权的数字对象编制一个含有版权机构或版权者本身前缀的DOI，并将其附加到数字对象的描述元数据上，在DOI注册中心数据库中进行登记和永久保存，使DOI成为数字对象的一部分，始终与该数字对象共存；DOI所具有的解析机制，则实现了DOI标识与源数据的有效、持久链接[6]。尽管如此，随着网络世界的发展，DOI在应用层面显现出一些局限。首先，DOI的解析链接适合“人读”，而不适合“机读”，DOI解析链接的重定向URL所载入的是HTML页面，并不直接适用于机器处理，当需要机器采集和处理相应数据内容时，则需要DOI系统开发各类API程序，其结果是应用的复杂度提高，通用性也比较差，因此，需要面对机器处理，提供更标准化、更通用、更简便的通用接口[7]；其次，DOI目前的解析链接通常是对数据源的指向，如从二次文献到一次文献，从文献到参考文献原文等，在这一过程，缺少对富含语义的扩展链接和关联链接支持，影响了元数据应用的增值服务效果。因此，有必要结合一些其他技术，改进上述问题[8]。
关联数据技术是一组最佳实践的集合，是语义网技术的简单实现，它采用RDF数据模型，利用URI(统一资源标识符)命名数据实体，来发布和部署实例数据和类数据，从而可以通过HTTP协议揭示并获取这些数据[9]。关联数据实现的基本条件之一是使用HTTP URI作为统一资源标识。HTTP URI从严格意义上来说，没有规定具体的资源范围、命名规则等，仅定义唯一标识符的基本结构、语法和字符集等，独立于具体的应用。CNRI Handle位于HTTP URI基本框架之下，定义了唯一标识符的基本结构、语法和字符集，而且对唯一标识符的应用提出功能要求，并详细说明有关协议的细节。DOI则是在此基础上的应用领域的唯一标识符，建立相应的唯一标识符名称管理系统，能够在可操作的层次上体现唯一标识符的作用。因此，DOI可以视为URI机制中的命名域(Namespaces)或命名大纲(Naming Schemes)，具备作为HTTP URI使用的先决条件[10]。关联数据强调数据相互关联、相互联系，构建有益于人机理解的语境信息，这是通过RDF文件中的大量资源链接来实现的，因此，如果DOI系统可以增加决定数据语义的链接，并通过“属性”关联到其所能链接到的、大量的相关资源实体，将大大丰富其现有的链接作用，扩大数字对象服务的内涵。同时，关联数据对数据访问方式进行了标准化，把API用程序接口统一为HTTP，用户或代理无需知道某具体关联数据发布网站的体系架构、存储方式等技术细节，只要知道Web服务器地址，就可以直接定位或通过SPARQL进行访问，这无疑是统一和替代现有DOI各类API的有效途径。由此可见，DOI系统引入关联数据技术，有助于在应用层面发挥DOI的现有作用，弥补其不足，且具备可行性[9]。
3 DOI的链接机制和关联数据URI的参引机制
(1)HTTP协议工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法(如GET\POST)、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据[11]。
典型的请求头有：
User-Agent:产生请求的浏览器类型；
Accept:客户端可识别的内容类型列表；
Host:请求的主机名。
HTTP响应信息一些常见的状态码如表1所示。
图1 DOI的解析链接过程
图2 Handle的元数据存储[13]
DOI链接和关联数据的URI参引都使用了3××重定向，前者使用302，后者使用303;同时，关联数据请求面向机读的RDF内容类型，而不是面向人读的text/html等格式。
(2)DOI的链接机制
DOI链接的常见应用场景有全文链接和引文链接等。用户点击文章及其引文的DOI号，直接获得对应的全文或引文的HTML内容服务页面。由于DOI链接具有持久性，而URL具有可维护性，从而使全文或引文的链接更准确、更有效，是解决“死链”问题的有效机制。
DOI链接的工作过程需要由Handle系统(Handle System[
])和DOI系统代理服务器(DOI system proxy)⑤完成。Handle系统用于管理数据对象，完成解析。所谓解析是一个过程，即以一个标识符作为请求的输入，获得关于该标识实体，如一个地点或一篇文献、一个或多个状态信息的特定输出。DOI系统的代理服务器是位于Handle系统与HTTP之间的网关，基本上是一个Web服务器，负责与Handle系统对话交流。如图1示所，用户通过浏览器向DOI系统代理服务器发送基于HTTP的DOI链接请求，该请求由代理服务器的域名和DOI名称两部分组成，例如：http://dx.doi.org/10.1000/demo_DOI，代理服务器接收到请求后，交由Handle系统查询DOI名称，如图2所示，获取Handle记录中的URL，交由代理服务器返回给用户浏览器302重定向指令及所获得的URL地址，用户的浏览器则依据重定向规则自动跳转至该URL，即数字对象的内容服务或源数据[12,13]。
(3)关联数据URI参引的工作过程
关联数据URI参引的典型应用场景是语义浏览器发出对非信息资源对象的URI请求，要求返回关于该对象的描述信息文件。普通浏览器请求头信息中包含text/html请求或其他MIME文件类型，如图像文件、音视频文件等，返回代码200 OK和相应的HTML文件的网页。语义浏览器的请求头信息则包含application/rdf+xml，请求返回负责该对象语义描述的RDF文件。
基于HTTP的内容协商机制，服务器针对关联数据的上述URI请求，会返回给客户端一个303 See other指令，包含了RDF文件的所在地址，收到该指令的客户端根据重定向规则向RDF地址发送请求，根据客户端HTTP文件头请求的类型，返回相应的内容。
4 关联数据在DOI链接中的应用与实现
关联数据在DOI链接中的应用，是指在保持现有DOI的注册和解析机制的基础上，将DOI直接应用为URI使用。目前有两类应用改造方案。
图3 关联数据URI参引的工作过程[9]
(1)基于RA及其成员的局部改造[14]
首先，由RA构建其关联数据服务网关，如CrossRef构建了专门用于发布RDF数据的服务rdf.crossref.org。保持现有Handle系统的查询、注册、解析机制不变，当接收到请求类型为RDF格式的DOI查询请求时，按原有的链接机制，与Handle系统对话，获得相应的元数据，按请求格式需要，进行RDF格式封装，返回给客户端。
其次，对于想在其网站服务中增加关联数据服务功能的RA的各类成员，如期刊出版商等，则需对其原有的载入页面进行改造，即增加类型为RDF的链接元素。例如发表于期刊Journal of Psychoceramics的某一篇论文，其DOI为10.5555/1234567，在其出版商原有的HTML载入页面中，如表2所示，增加了指向rdf.crossref.org的三个rdf格式类型，分别为rdf+xml、json、turtle的链接[15，16]。
具体工作过程如下：语义浏览器向dx.doi.org请求DOI10.5555/1234567，即dx.doi.org/10.5555/1234567，如普通浏览器一样，依旧获得一个302，重定向至该论文期刊的出版商服务，在其URL地址的原HTML载入页面中，语义浏览器可探测到表2中的RDF页面链接元素，转向rdf.crossref.org，提交检索和RDF格式请求，获得相应的数据结果文档。
这一方案最大的优势在于简单易行，开发量小。对于RA来说，不需要在原有的DOI/Handle的系统层面上进行任何改造，只需要构建关联数据网关即可；而对于RA的成员来说，是否应用关联数据服务，不需特殊的准入和退出，自由灵活，只需要改造其载入页面即可。当然，如果RA成员想获得更好的关联数据增值服务效果，可以在CrossRef中存放的元数据中增加更多的语义链接。
该方案也存在一些问题，首先，由于没有支持内容协商机制，仍使用302转向，使DOI系统与关联数据规则不能完全兼容，例如一些严格的语义浏览器遇到302之后，有可能出现停留的情况；其次，从实现机制上来看，真正顺畅地实现运转，有赖于出版商的改造行动；另外，该方案只对完成改造的一个RA有效，对其他RA无法同时支持其关联数据服务。
(2)基于IDF、RA及其成员的全局改造方案[14]
针对上述方案的不足，应着重考虑从以下几个方面解决：①支持内容协商，使DOI遵循关联数据标识符的全部要求，完全满足语义浏览器的转向要求；②具备灵活性，对于常规数据请求和RDF数据请求，面对能提供关联数据服务的RA和不能提供关联数据服务的RA，具备关联数据服务的RA成员和不具备关联数据服务的RA成员，在该框架下，都能够顺畅流转，不致出现冲突和矛盾，同时仍然保持出版商对是否启用关联数据服务有自由权利和灵活的加入退出可能；③尽量保持对IDF、RA和其成员的最小开发改造。
所谓全局方案，涉及三个层面：第一是IDF层面，增加支持303转向的内容协商机制，且兼容不同类型的RA，包括RA是否具备关联数据服务能力，RA是否支持内容协商；第二是RA层面，对提供关联数据服务的RA，改造其支持内容协商机制，且允许其成员定义是否由RA提供关联数据服务，还是由其自身提供；第三个层面是RA成员，可独立构建不依赖于RA的关联数据服务，或仅仅是在其载入页面中增加RDF链接元素。
具体工作流程如图4所示。
1)IDF的dx.doi.org接收到以RDF为返回表达的DOI解析请求，视作以DOI为标识符的关联数据URI请求；
2)根据RA参数，判断其所控制的Handle系统是否具备关联数据服务能力，对不具备语义服务能力的RA解析器，向客户端返回302重定向指令，指向其RA成员所注册的URL地址，由RA成员负责RDF数据的返回，由于是通过302转向的，语义浏览器有可能发生停留；对于具备关联数据服务能力的RA，则IDF返回303重定向指令，语义浏览器不会发生停留问题；
3)判断具备关联数据服务的RA是否支持内容协商，如果不支持，则303重定向至RA成员在该RA的Handle系统中所注册的URL地址，即转向RA成员；对于支持内容协商的RA，则303重定向至RA的服务网关；
4)判断RA是否替其成员拦截查询请求，如果不是则将查询请求转给其成员，例如一些大的出版商，独立构建自己的RDF数据服务，则RA不需拦截其查询请求；
5)如果不由RA替其成员拦截，则基于RA提供关联数据服务，例如对于CrossRef则由其rdf.crossref.org负责返回所查询元数据的RDF表达。
图4 IDF的关联数据全局方案[14]
上述方案是目前IDF自2011年以来实施完成的方案[17]，能够保证语义浏览器在绝大部分情况下顺畅工作，同时具有很强的灵活性，兼容各类RA以及成员，保持了RA以及成员自由的准入和退出。从整体实施来看，在IDF和RA层面，需要在原有的程序中增加逻辑判断，RA成员在RA没有关联数据支持或无内容协商机制支持的情况下，仍需在其数据服务中增加关联数据服务。
5 中文DOI的关联数据服务改造
中文DOI作为RA，目前遵照DOI国际标准和IDF的各项政策提供服务，每个注册的内容资源将被赋予全球唯一的DOI，通过这个DOI和DOI解析机制，实现到内容资源的动态、持久链接。本文模拟现有中文DOI的注册与解析服务并进行了改造，实验构建了一个关联数据服务网关，以满足基于DOI的RDF数据请求。
首先，建立独立的关联数据服务网关，该服务网关是现有中文DOI系统的一部分，如图5所示，它负责处理通过内容协商接口获得的转向请求或来自语义浏览器的直接请求，并与中文DOI的元数据库进行交互。DOI元数据的数据内容及关联关系，是由用户在DOI注册时提交的，而关联数据网关会负责将返回的数据内容及关联关系封装为RDF的不同格式。
其次，对中文DOI进行改造，支持内容协商机制。目前通过实验，对中文DOI服务的解析应答过程进行了改造，增加了对请求类型的判断，当客户端的解析请求返回类型为RDF时，生成重定向代码303，并提供RDF数据网关地址。具体处理流程中还需要针对请求的文献类型进行判断和相应的处理。以期刊论文的关联数据服务为例，参见图6，关联数据服务网关接收到转换请求及头信息中包含application/rdf+xml的URI请求后，对请求信息进行解析，如果请求的是期刊论文的资源信息，就根据请求的DOI，从中文DOI系统的元数据库中查询相应的期刊论文元数据信息，包括所在的期刊母体URI，分类号、外部链接等信息，并将这部分元数据信息通过关联数据封装服务，封装成RDF/XML文件，由关联数据服务接口返回。
图5 中文DOI关联数据服务体系架构
图6 期刊论文的关联数据服务处理流程
用CURL语言模拟语义浏览器向中文DOI实验系统发出关联数据请求如下：
也可以通过语义浏览器Disco-Hyperdata Browser⑥获得更直观的该论文的RDF信息展示。如图7(a)所示，RDF数据中可见与该论文相关的属性对象的RDF链接，并通过这些链接可以进一步获得详细信息，如母体期刊，见图7(c)，论文中图分类号，见图7(b)，从而实现关联数据的URI参引和链接服务。
图7 语义浏览器的显示结果
6 总结与问题
通过上述实验，实践了IDF的关联数据框架中RA部分的基本改造任务。但要想最大程度上通过关联数据技术丰富DOI的应用和提升语义服务能力，对于中文DOI来说，还存在一些问题有待解决。首先是中文DOI元数据表达的标准化和规范化问题，目前的中文DOI元数据参照Crossef 4.3.0⑦制定的元数据规范，对通用词表的引用比较少，兼容性较差，会影响到关联数据消费方对中文DOI元数据的使用和关联；第二，中文资源中可公开使用的关联数据集比较少，同时中文期刊资源本身的结构化程度有限，例如许多期刊更多的是对论文进行DOI注册，而缺少对期刊本身的注册，造成数据之间无论是结构性的还是内容性的可相互关联的部分比较少，不利于数据应用的丰富和链接扩展；第三，随着应用推广和数据之间关联关系的丰富，客户端会发出频繁的HTTP请求，增大系统压力，因此应考虑额外提供SPARQL节点或类似的服务，来应答向服务器提交的复杂查询，而不是直接让客户端通过HTTP频繁获取或下载较大的数据集。
①http://www.doi.org/
②http://www.cnri.reston.va.us/
③http://www.ansi.org/news_publications/news_story.aspx?menuid=7&articleid=3246
④http://www.doi.org.cn
⑤http://www.doi.org/doi_proxy/index.html
⑥http://wifo5-03.informatik.uni-mannheim.de/rdfbrowser/
⑦http://www.crossref.org/schema/4.3.0/