RESTful服务的无缝集成到Web的数据

文摘

我们生活在一个时代的不断增长的大量的数据。应对我们每天遭受的信息过载,需要更复杂的方法来访问,操作和分析这些巨大无比的大量的数据。拥抱的异质性,这是不可避免的在这样一个规模,并接受这一事实的数据质量和意义模糊,更具有适应能力、灵活、可扩展的系统可以建立。RESTful服务结合语义Web技术可能是一个可行的路径来实现。他们的组合允许数据集成规模空前的,解决了Web开发人员的一些问题不断挣扎。介绍了一种新颖的方法来创建RESTful服务的机器可读的描述,这一雄心勃勃的目标的第一步。它还表明,这些描述以及一个算法SPARQL查询转换成HTTP请求可以使用RESTful服务融入全球网络读写数据。

1。介绍

我们生活在一个时代,艾每年产生的数据;人类历史上从未有我们来处理如此大量的信息。应对信息过载,更复杂的方法是需要访问、操作和分析这些巨大无比的大量的数据。面向服务的体系结构(soa)建立在Web服务是第一次尝试解决这个问题,但统一的服务接口标准的乌托邦式的承诺,元数据,和普遍服务注册中心,形式的SOAP、WSDL和UDDI已被证明难以捉摸。这个和其他集中,基于注册方法是被网络的增长和缺乏一个公认的分类方案。结果是,使用基于soap的服务主要是限于公司内部系统和遗留系统的集成。然而在实践中,这种清脆的定义数据是罕见的。今天的系统集成数据,还可以从许多别的来源。数据质量和意义模糊的模式,如果存在,可能会有所不同,不同的来源。在非常大的和松散耦合的系统,比如互联网,收获的适应性,灵活性和可扩展性,在过渡远离严格和正式的输入简单的名称/值对或三元组,超过造成损失了“正确性”。

因此,毫不奇怪,RESTful服务,尤其是使用轻量级的JavaScript对象表示法(JSON) [1序列化格式),越来越受欢迎。根据ProgrammableWeb,现在74%的Web服务是宁静的,45%的人使用JSON作为数据格式(2),但是,尽管他们的越来越普及,基于rest的服务仍然受到一些严重的缺点。

的主要问题是,基于rest的服务Web api,最近出现的术语来区分他们从传统的基于soap的同行,不同意机器可读的描述格式存在。如何调用它们所需的所有信息和如何解释各种资源表示形式传达带外的人类可读的文件。因为机器有巨大的问题理解这样的文件,机器对机器通信通常是基于静态知识导致紧密耦合的系统。挑战因此带来一些人类网络的自适应性网络的机器允许构建松散耦合的、可靠的、可伸缩的系统。

语义注释可以被证明是一个切实可行的路径来实现,但是,在语义网的愿景已经存在了超过15年,它还有很长的路要走主流采用将实现。其中一个原因是,在我们看来,一般的Web开发人员的恐惧使用语义Web技术。他们常常被(感知)复杂性或认为他们必须人工智能专家利用语义Web。其他人仍在等待一个杀手级应用成为一个经典的“鸡生蛋还是蛋生鸡”问题。普遍认为,语义Web是一个颠覆性技术使它致命的企业需要发展他们的系统和建立在现有的基础设施投资。显然,一些开发商也只是不愿意使用新技术。尽管如此,我们认为大多数Web开发人员使用语义Web技术由于某种原因或恐惧;这种现象我们表示Semaphobia(3]。帮助开发人员克服这种恐惧,并告诉他们,使他们没有必要害怕但恐惧本身,简单明确的激励机制以及规范和指导方针是必要的。只要有可能,应提供现有系统升级方案建立在现有的投资。

这正是使关联数据运动如此成功。它简化了技术堆栈和为注释数据提供了明确的激励机制。结果,也就不足为奇了被大多数Web开发人员忽略了后很长一段时间,轻量级的语义标注终于开始在社区获得接受。Facebook的开放图谱协议,例如,实现在50000多个网站推出的第一个星期内(4)和当前估计大约10%的网页都是注释。

似乎只会随之结合二者的优点,休息和关联数据的原则,但实际上他们仍然很大程度上分离。而不是提供关联数据通过一个基于rest的服务接口,目前工作部署centralistic SPARQL端点或者只是上传RDF数据的静态转储。这也意味着,大多数当前的语义Web项目提供底层数据只读接口。这显然抑制网络效应和接触的人群。

为了解决这些问题,我们开发了一个数据的语义描述RESTful服务的新方法,这使得他们的无缝集成到Web的数据。我们把重点强调简单和不需要任何更改Web服务本身。这将为未来的Web开发人员和降低进入门槛为现有的基础设施提供一个可行的升级路径。同时,这种方法是可扩展和灵活地适用广泛的应用领域。

提醒的纸是组织如下。节2,我们给相关工作的概述。然后,在节3,我们提出需求和SEREDASj的设计,我们的方法语义描述RESTful服务。部分4显示如何使用SEREDASj不同的基于rest的服务集成到Web的数据,最后,部分5总结了纸和未来工作的概述。

2。相关工作

相比传统的基于soap的服务,达成标准的形式[WSDL和——SAWSDL5)被描述,,语法和语义上,不存在标准的基于rest的服务。结果,基于rest的服务几乎完全被人类可读的文件描述url和预期的数据作为输入和输出。已经有了许多建议来解决这个问题;SA-REST [6],hRESTS [7],WADL [8)可能是最著名的。

Web应用程序描述语言的方法(WADL) [8)密切相关的WSDL,开发人员创建一个独立的XML文件包含所有的信息服务的接口。鉴于WADL是专门设计来描述RESTful服务(或基于http的Web应用程序,因为他们被称为WADL的规范),模型提供的资源服务以及它们之间的关系。每个服务资源被描述为包含所使用的HTTP方法和请求所需的输入以及零个或多个反应描述预期的服务响应表征和HTTP状态代码。请求和响应的数据格式表示被嵌入或引用的数据格式定义。尽管WADL不授权任何特定的数据格式定义语言,只是使用RelaxNG和XML Schema规范中描述。WADL的主要批评是复杂,因此需要开发人员,有一定的培训和工具支持,使WADL的使用。这种复杂性与简单的基于rest的服务。此外,WADL敦促使用特定的资源层次结构引入一个明显的客户机和服务器之间的耦合。服务器应该有完全的自由控制自己的名称空间。

hRESTS RESTful服务(HTML) [7]遵循完全不同的方法,因为它试图利用这一事实几乎所有基于rest的服务已经有了一个文本文档以网页的形式。hRESTS的想法是因此丰富,主要是已经存在的,人类可读的文件与所谓的微格式(9)让他们计算机可处理的。单个HTML文档富含hRESTS微格式可以包含多个服务描述,相反在一起可以使用多个HTML文档记录单个服务(它是一种常见的做法,服务文档分割成不同的HTML文档,使它们更易于理解的)。每个服务的描述操作,也就是说,客户端可以对服务执行操作,与相应的URI, HTTP方法,输入和输出。虽然hRESTS提供了一个相对简单的解决方案来描述的资源和支持业务,有一些缺乏描述使用数据模式的支持。除了潜在的标签,hRESTS不提供任何支持进一步的机器可读信息的输入和输出。扩展像SA-REST6]和MicroWSMO [10解决这一问题。

MicroWSMO试图适应——SAWSDL RESTful服务的语义描述方法。它使用,正如hRESTS,它依赖,微格式向HTML添加语义标注服务文档。类似于——SAWSDL, MicroWSMO有三种类型的注释:(1)模型,可以使用在任何hRESTS服务属性指向适当的语义概念;(2)提升,(3)降低指定语义数据之间的映射和底层技术如XML格式。因此,MicroWSMO使语义注释的RESTful服务基本上以同样的方式——SAWSDL支持WSDL描述的Web服务注释。

RESTful服务的语义描述的另一个方法是在上述的SA-REST [6]。它依赖于RDFa标记服务属性在现有HTML服务描述,类似于hRESTS MicroWSMO。事实上,这是第一种方法重用现有的HTML服务文档创建计算机可处理的基于rest的服务的描述。这两种方法之间的主要区别是的确不是底层的原则,而是实现技术。SA-REST提供以下服务元素:(1)输入和(2)输出为了方便数据中介;(3)提升和(4)降低模式翻译代表输入和输出的数据结构的数据结构本体,接地模式;(5)行动,它指定所需的HTTP方法来调用服务;(6)操作它定义了什么服务;和(7)的错标注错误。

原则上,一个rest式服务,甚至可以通过使用WSDL 2.0描述(11与——SAWSDL []5后)和本体owl - s或WSMO-Lite。为了进行Web服务(Web本体语言)[12)是一个上层本体基于W3C标准的本体OWL语义Web服务注释。为了进行包括以下主要上层本体:(1)服务配置文件广告和发现服务;(2)服务(流程)模型,提供服务的操作的详细描述,描述了组成(编排和编制)的一个或多个服务;(3)服务的基础,它提供了所需的传输协议来调用服务的详细信息(例如,基于逻辑之间的绑定服务描述和服务的WSDL描述)。一般来说,服务配置为代理提供了所需的信息,发现一个服务,而服务模式和服务基础,综上所述,为代理人提供足够的信息使用一个服务,一旦发现(12]。为了进行的主要批评是其有限的表达能力在实践中服务描述。因为它实际上对应于owl dl,它只允许静态和确定性方面的描述;它不包括任何时间和变化的概念,也不确定性。除此之外,一个为了进行过程不能包含任何数量的完全无关的操作(13,14),与WSDL。

WSMO-Lite [15)是另一个本体来填补——SAWSDL注释的具体服务语义。——SAWSDL本身并不为代表指定一种语言语义模型只是定义了如何将语义注释添加到WSDL文档的各个部分。WSMO-Lite允许服务和采用自底向上的建模,顾名思义,WSMO [16轻)模型,并使其语义。WSMO-Lite描述Web服务的以下四个方面:(1)信息模型,它定义了数据模型的输入,输出,和故障信息;(2)功能语义定义的功能,服务提供;(3)行为语义,它定义一个客户端如何与服务;(4)非功能描述,它定义的服务质量或价格等非功能属性。WSMO-Lite的一个主要优势是,它不是绑定到特定的服务描述格式,例如,WSDL。因此,它可用于集成的方法,例如,hRESTS(结合MicroWSMO)与传统基于wsdl服务描述。因此,任务,如发现、组合、和数据中介可以完全独立于底层执行Web服务技术。

虽然乍一看似乎所有上述思想从根本上不同于WSDL,底层模型仍与WSDL的结构密切相关。导致的结果是,所有提出的方法严重依赖RPC(远程过程调用)的缺陷(17]行动模型忽略了其他建筑的基本属性。而不是描述资源表示形式,从而使客户理解他们,他们坚持的被广泛运用的、类似rpc模型描述输入和输出以及所支持的操作导致紧密耦合。显而易见的结果是,这些方法不一致和清晰的rest式服务的设计。

避免RPC-orientation的方法之一,因此更适合基于rest的服务,是雷尔(18),资源链接语言。这是一个语言来描述RESTful服务与强调的超媒体特征模型。例如,这允许一个履带自动检索数据公开的Web api。的目的之一雷尔的确是爬到RDF数据转换为了收获这些已经存在的网络资源,将其整合成语义Web。然而,雷尔不支持语义标注,但依赖于XSLT转换的RDF。这显然限制雷尔的表现性是无法描述资源表示语义。

有很多其他的方法,允许,正如雷尔,转换数据暴露Web api RDF。事实上,大部分地区当前的Web工具,如从non-RDF数据库生成的数据D2R [19]或Triplify [20.),但当前的语义Web的限制之一是,它通常只是提供了底层数据的只读接口。因此,尽管一些语义Web浏览器,如制表机(21],呼噜声[22),或者迪斯科23),已经开发RDF数据显示,如何编辑的挑战,扩展,或注释数据到目前为止几乎没有解决。存在几个个图中编辑包括RDFAuthor [24]和ISAViz [25)但是,我们最好的知识,制表机回来的(26)是唯一的图形编辑器,允许编辑来自多个来源。

为了缓解这种情况,推迟项目(27]在2009年发起的(目前还不清楚这个项目仍然活跃)开发方法写入数据的RDF图non-RDF数据源如Web api。选择的方法推迟项目扩展RDF包装,non-RDF Web api的数据转换为RDF数据,另外支持写操作。这是通过这一过程被称为融合自动注释与RDFa现有的HTML表单。由此产生的RDForm然后报告更改的数据为RDF回推迟控制器进而继电器RDF写包装的变化,最终将其转换为一个HTTP请求可以理解Web API。的主要挑战之一是创建读写包装如有,如上所述,没有一个统一的标准来描述RESTful服务;语法和语义。揭露这些Web api读写数据有关,因此,更多的一种艺术而非科学。

3所示。基于rest的服务的语义描述

机器可读的文档服务的接口和数据公开是第一步(半)自动集成。在本节中,我们首先讨论基于rest的服务的语义描述语言的要求然后SEREDASj,一种新颖的方法来解决这一雄心勃勃的挑战。

3.1。需求

分析相关的工作,考虑到我们在创建RESTful服务的经验和整合成混搭,我们推导出一组语义描述语言的核心要求。

由于描述语言是针对RESTful服务,显然必须遵守其他的体系结构约束28),可以概括如下:(1)无状态的交互,(2)统一的接口,(3)识别的资源(4)操作资源的表示(5)自描述信息,(6)超媒体应用程序状态的引擎。无状态意味着所有的交互会话状态保持完全在客户端,从客户端到服务器的每个请求必须包含所有必要的信息服务器理解请求;这使得与服务器交互彼此独立,将客户端从服务器。RESTful系统的所有交互执行通过一个统一的接口,将他们所提供的服务的实现。获得这样一个统一的接口,每一个资源都是通过代表(代表是否在相同的格式的原始来源,或来自源,仍然隐藏在接口),并有一个标识符。所有资源表示应该是自描述的,也就是说,他们不知何故贴上类型,指定如何解释。最后,超媒体应用程序状态的引擎(HATEOAS)约束指的是使用超链接的资源表示形式的应用程序的导航状态机。

被广泛接受的方法有基于核心Web标准。这意味着它应该使用统一资源标识符(uri)来确定资源,超文本传输协议(HTTP)来访问和修改资源表示,和资源描述框架(RDF)的统一数据模型来描述资源。为了缓解数据集成等任务,访问异构数据源的统一接口在一个统一的和直观的方式,必须提供。反过来,这将导致可重用性和灵活性的重要方面采取这样的一种新方法。通过语义注释数据,开发人员也可以支持数据集成和调解过程中不仅是企业重要的场景还创建mashup。通常所需的数据中介代码的时间比实际的业务逻辑。通过语义注释数据,可以将它(半)自动与其他数据源。

尽管这些限制在设计一个rest式服务很重要,语义描述语言的最重要的方面是如何可以访问的资源,如何表示,它们是如何相互关联的。描述语言应该足够表达来描述如何检索资源表示形式和操纵,和那些表示的意义是什么。语义Web服务集成到,描述语言还应提供意味着将RDF三元组的表示。为了能够发展系统和建立在现有的基础设施,一个重要的要求是没有(或很少)的变化对现有系统是必需的;这意味着需要支持部分描述。最后但并非最不重要,应该尽可能简单的方法降低进入门槛为开发人员和促进它的采用。

3.2。SEREDASj

考虑在前一节中描述的需求,我们设计了SEREDASj语言来描述数据语义REstful服务。“j”结束时应该强调我们的方法基于JSON。JSON的声望在Web api并不是唯一的原因。

固有的阻抗失配(所谓的O / X阻抗失配)之间的XML,用于传统的基于soap的Web服务和面向对象的编程结构往往导致严重的互操作性问题。最根本的问题是,XML Schema语言(XSD)有许多类型的系统结构中并不存在等常用的面向对象编程语言,例如Java。这导致结果的互操作性问题,因为每个SOAP堆栈都有其自己的方式映射不同的xsd类型系统构造目标平台的编程语言中的对象,反之亦然。

在大多数用例通过Web服务来解决,所有开发人员想要做的是交换数据我们区分数据交换和文档交换。JSON是专门为这个设计:这是一个轻量级的,独立于语言的数据交换格式易于解析和易于生成。此外,它为开发人员更容易理解和使用。JSON的整个规范(1)由10页(实际内容是只有四页)相比,XML, XML核心工作组独自[29日)列表XML,XML名称空间,XML包含,XML信息集,xml: id,XML基础,将样式表与XML作为标准;不包括XML Schema第1部分和XML Schema第2部分。

总结,JSON是简单,易于集成,提高采用跨Web社区(2)描述语言的第一选择,但我们想强调,我们的方法的原则适用于任何序列化格式。

SEREDASj指定描述RESTful服务,类似于模式,一个特定的JSON表示的句法结构。此外,它允许引用JSON元素概念的词汇或本体和进一步描述语义注释的元素本身。图1描述了SEREDASj的结构描述。

包括元数据和描述的描述它描述了JSON实例数据结构表示。元数据包含超链接相关的实例数据信息和前缀定义缩写长uri的语义标注居里(30.]。链接为客户描述包含所有必要的信息检索和操作实例数据。另外链接的目标,它的媒体类型和目标SEREDASj描述,链接描述可以包含所需SEREDASj请求描述创建请求和语义注释来描述链接,例如,它与当前的关系表示。链接的目标是表达的链接模板相关联的变量可以被绑定到一个元素的实例数据和/或链接到一个概念模型,例如,一个类或属性本体。模板的联系的变量可以进一步描述的通用语义标注的形式predicate-object对。链接的SEREDASj允许客户端请求描述构建请求体中使用帖子或把创建或更新资源的操作。

的结构实例的描述表示(表示元素描述图1)定义了JSON数据类型(s)以及概念模型的链接。此外,它可能包含语义注释来描述一个元素进一步,如果元素代表一个JSON对象或数组,其属性的描述,分别的,同样,一个元素的描述。JSON结构的实例出现嵌套元素的描述。允许重用,可以设置一个元素的类型描述另一个模型定义的URI或另一部分在当前模型定义。为了解决模型的不同部分,使用斜杠分隔片段的决议。在清单1例如,/ enddate event.json #属性是指定义的结束日期属性SEREDASj文档event.json。

为了更好的说明方法,JSON表示的一个简单的例子及其对应的SEREDASj描述给出清单1。的例子是一个表示一个事件及其演员从一个虚构的事件网站的API。没有注释,数据不能被机器理解甚至人类并不明显,表演者的ID实际上是一个链接到一个特定表演者的更详细的表示。SEREDASj解决这些问题通过描述的所有重要方面如此表示。结果是,不仅是可以提取超链接,还要创建一个人类可读的文档的数据格式(见[3),将JSON表示RDF表示。

SEREDASj描述清单1包含两个链接的定义。第一个指定了表演者的表征通过其ID链接。它使用的变量绑定到一个URI模板# /演员/ id属性。这个链接的定义还显示了如何使用进一步的语义标注;这是一节详细描述4.1。第二个链接指定一个搜索界面,因而没有绑定到实例数据元素;相反,引用指定变量的模型。这个链接是语义注释,这样代理就知道这个链接指定一个搜索界面。这些语义标注允许开发者实现智能客户资源的关系,从而了解后剩下的超媒体应用程序状态约束的引擎。

以下的描述基本上表示的结构结构映射到schema.org[定义的本体31日]。映射策略类似于table-to-class column-to-predicate当前战略关系database-to-RDF方法(32];JSON对象映射到类,所有其余的谓词。尽可能通过重用schema.org的本体,开发人员能够利用现有各种元素和人类可读的描述自动生成完全一个人类可读的文档。

SEREDASj描述没有完成,也就是说,它们不需要描述每个元素在所有细节。如果遇到一个未知的元素表示一个实例,它仅仅是忽略。这种方式,SEREDASj允许向前兼容性以及可扩展性和减少耦合。在这种情况下,还应该强调,并不意味着SEREDASj描述服务和客户机之间共享数据模型。它只是提供了一个描述服务的表示来缓解客户的数据模型的映射。

4所示。RESTful服务的无缝集成到Web的数据

目前mashup开发人员必须处理大量的异构数据格式和服务接口,没有工具支持。RDF,首选语义Web的数据格式,是试图建立一个通用数据格式适用于缓解数据集成,但是,不幸的是,当前的语义Web应用程序主要提供只读接口底层数据。我们认为它应该是可行的mashup开发过程标准化和精简化相结合的技术,同时,世界的Web api和语义Web。首先,这将导致更高的生产率,随后可能导致大量的新的应用程序。可能它还可以促进创建mashup编辑器在更高的抽象级别可以,希望,甚至允许非技术专家创建mashup履行情境的需要。

基于SEREDASj,我们介绍了在前面的小节中,我们将提出一个新的参考模型将传统的Web服务接口集成到一个全球读写的数据图。图2展示了我们的方法的体系结构。

我们大致区分一个特定于应用程序的(顶部)和一个独立于应用程序层(底部)。应用独立层底部被用作通用的数据访问层。它将应用程序和表示逻辑与共同需要管理和操纵来自大量不同数据源的数据。这种关注点的分离会导致更好的可重用性和提高开发效率。

SEREDASj从基于json Web服务描述的数据转换为RDF数据和存储来自本地RDF数据源的数据如SPARQL端点、静态RDF垃圾场,或RDF嵌入在HTML文档在本地三重存储。这个统一的数据格式是第一步这些异构数据源的集成。我们使用RDF,因为它反映了数据存储和网络相互关联,即一个图表的形式。这一事实是没有模式和基于三元组使其异构数据源的最小公分母,灵活、容易可发展的。除了作为一个数据集成层,这三重店里也用于缓存数据在网络应用中是一项基本要求。此外,集中处理更有效比联邦查询等。看看,例如,谷歌的集中式处理相比,联邦数据库查询,请记住,我们不是反对可实现的速度增加了并行化。

所有数据通过数据访问和修改持久层并最终将转移回原始数据源。接口连接数据访问层和业务逻辑层都必须了解哪些数据可以改变,不能因为一些数据源或数据表示的一部分可能是只读的。根据场景中,开发人员可以选择包含一个存储服务(三重存储或传统的Web API),允许存储变化甚至不可变的数据。然后数据集成层的责任“取代”或“覆盖”这个用其取代数据只读数据。跟踪数据的来源是一个非常重要的特性。

为了分离特定于应用程序层的独立于应用程序的数据层,它们之间的接口必须标准化。已经存在一个标准的工作草案,即SPARQL [33)和SPARQL Update (34]。我们重用他们为了建立我们的方法对现有的工作。当然,应用程序开发人员可以自由地添加另一个抽象层之上,类似的惯例使用O / R映射器(对象-关系映射器)来访问SQL数据库。

虽然这三层架构是广为人知并被广泛使用在应用程序开发中,我们最好的知识还没有被用于将Web服务集成到语义网。此外,这种集成方法并没有被用来概括Web服务的接口。开发人员仍在挣扎与高度多样化的Web服务接口。

4.1。数据格式协调

翻译SEREDASj JSON表示描述RDF三元组,第一步将它们集成到关联数据云,是一个简单的过程。翻译从JSON表示的根源开始,考虑所有模型的JSON对象的引用和tuple-typed数组RDF类,而所有其他元素的模型被认为是RDF谓词引用该元素的值将被视为对象。如果包含嵌套对象表示,正如清单1,一个斜杠分隔的URI片段是用来识别嵌套对象。语义标注的形式语义属性,作为一个表演者所示的链接清单1,包含谓词和对象。对象可能指向一个特定的元素SEREDASj描述和最终翻译实例数据的链接。

自动翻译的例子从清单1RDF是清单所示3。事件及其表现很好地映射到schema.org本体。为每个数组项,创建一个新对象URI URI使用斜杠分隔片段。最终,这些URI映射到演员的“真实”URI链接的语义注释。请注意,查询链接不包括在RDF表示。原因是查询变量不绑定到任何实例元素,因此它的值是未知的。因此,译者无法构造URI。

4.2。与其他数据源的集成

在前一节中解释说,转换为RDF是一个集成来自不同数据源的数据的第一步。完全集成,最终从所有来源的数据必须使用相同的语义标注,也就是说,同样的词汇,同样的标识符。传统上,这个同质化已经完成以命令式的方式通过编写数据中介代码。语义Web技术堆栈另一方面接受不可避免的异质性和提供意味着以声明方式解决这个问题通过创造新知识的形式,例如,模式或标识符映射。通过研究数据的内容和不同的数据项之间的关系,有时候可以推断(半)自动两种看似不同的物品都是一致的。

是直接把数据从我们的清单3Lady Gaga的数据存储在,例如,DBpedia(一个项目旨在从维基百科)中包含的信息中提取结构化内容。我们要做的是schema.org的一些概念和我们当地的标识符映射到概念和Lady Gaga在DBpedia的标识符。DBpedia提供的模式映射已经(http://mappings.dbpedia.org/)所以我们要做的是找到DBpedia的标识符,并将其映射到我们当地的标识符。一个推理引擎可以轻松地通过运行查询清单所示2DBpedia的SPARQL端点。结果是我们正在寻找的URI:http://dbpedia.org/resource/Lady_Gaga。后将该URI映射到本地使用OWL的标识符篇概念,我们可以很容易的查询所有的数据从DBpedia Lady Gaga,因为它将是我们的Web服务的一部分;图中的数据层2负责照顾所有必要的细节。

4.3。存储更改回源

DBpedia一样,当前语义网的一个重要部分由数据从Web api或关系数据库从网站提取RDF或数据。结果是,绝大多数的当前语义网是只读的,也就是说,不能存储变化回到最初的来源。因此,在本节中,我们将展示如何SEREDASj允许数据被更新和转移回原始Web服务(显然我们不能更新静态Web页面)。

下列描述中,我们假设所有的数据和结果的相互关联的网络SEREDASj描述已经检索查询(这是否意味着爬或专门为这项工作无关)。目标是然后更新收集数据或添加新的数据通过使用SPARQL update。

SPARQL Update操作数据通过添加或删除图三元组。的插入数据和删除数据分别操作添加,删除一个三元组的图用具体数据(没有指定变量)。相比之下,插入和删除操作也接受模板和模式。SPARQL没有改变现有的三重三元组的操作被认为是二进制:三重存在,或者不存在。这可能是最大的不同的SQL和SPARQL查询之间的Web api和复杂的翻译和等效HTTP请求与Web服务进行交互。

4.4。翻译插入数据和删除数据

关于Web服务的插入数据操作,例如,可以导致创建一个新的资源或操纵的现有现有资源如果先前设置的属性之一。同样的申请删除数据资源的操作,可以设置一个属性或删除资源。资源只会被删除,如果删除所有三元组描述资源。这种不匹配,或者更好的,概念上的三元组之间的差距和资源属性意味着Web服务的接口所施加的约束转移到SPARQL的语义层。结果是,有些操作是完全有效的,如果应用于原生三重存储应用于Web API时是无效的。如果这些约束是记录接口描述,也就是说,SEREDASj文档,语义标注的形式,客户能够构建有效的请求,分别检测无效请求和提供有意义的错误消息。如果这些约束不记录,客户别无选择,试图向服务器发出请求并评估其响应。这是类似于HTML表单,没有人类的Web客户端表单验证。

为了更好地解释翻译算法,概念证明,我们实现了一个简单的事件引导Web服务基于清单中描述的接口1。它唯一的功能是存储事件和各自的表演者通过RESTful接口。CRUD操作映射到HTTP动词POST、GET、PUT,删除,没有身份验证机制作为我们目前没有SEREDASj文档中的本体来描述这个(这个限制将在后续工作)。

可以访问时表示/事件/{id}uri,而表演者都可以访问/人/{id}uri。都可以抛下一个更新的JSON表示编辑相应的URI。可以创建新事件和演员/人通过发布一个JSON表示集合URI。所有这些信息以及映射到相应的词汇是由SEREDASj机器可读的描述文档。

由于SPARQL区分数据和模板操作,我们将翻译算法分为两个部分。算法1翻译SPARQL数据操作HTTP请求与Web服务交互和算法2处理SPARQL的删除/插入操作使用模式和模板。

清单4包含一个模范插入数据操作,我们将使用算法来解释1。它会创建一个新事件和新演员。事件与新创建的表演者以及现有的一个。

翻译的操作清单4在HTTP请求适合与Web服务交互,在算法的第一步(2行1),所有潜在的检索请求。这是通过检索所有SEREDASj描述包含模型引用对应类或谓词中使用SPARQL三元组;这一步也考虑现有资源是否应该更新或创建一个新的。因为清单4不参考现有资源(珀耳斯:p84098在10号线只是用作对象),所有潜在的HTTP请求必须创建新的资源,也就是说,必须的帖子请求。在我们的小例子中,我们有两个潜在的请求,一个用于创建一个新的事件资源,另一个是新人/演员资源。这些请求模板然后充满信息从SPARQL三元组(第6行)以及信息存储在本地三重存储(第7行),然后提供一个请求是有效的(第8行),也就是说,它包含所有强制性的数据,它将提交(9行)。如清单所示5,第一个有效的请求创建一个新的事件(1 - 3行)。因为空白节点的ID_:比伯还不知道(它被创建的服务器),它仅仅是忽略。提供HTTP请求是成功的,在下一步中响应解析和新Web服务公开的三元组的SPARQL三元组(11行)并添加到本地三重存储(12行)。此外,剩下的SPARQL三元组的空节点替换为具体的条款。在我们的示例中,这意味着三元组7 - 10在清单一致4删除和空白节点在第11行三取代了新创建的吗/事件/ e51972URI。最后,请求从潜在的删除请求列表和一个标记设置(13 - 14日,算法1)表明在当前的进展做而迭代。如果在一个循环迭代,循环通过所有潜在的请求,没有进展,这个过程停止(第18行)。在我们的示例中,这个过程是重复请求创建一个人的结果帖子请求(6 - 8行,清单5)。因为没有更多的潜在要求,下一次迭代做而循环就开始了。

唯一剩下的三之前更新三线11(清单4),因此,只有这一次是一个潜在的请求把请求更新新创建的/事件/ e51972。和之前一样,请求模板充斥着“知识”从本地三重存储和剩下的SPARQL三元组和最终处理。因为没有更多的SPARQL三元组来处理,做而循环终止并返回一个成功消息到客户端(第20行,算法1),所有三元组已经成功处理。

4.5。翻译删除/插入操作

形成鲜明对比数据-表单操作,需要具体的数据和不允许指定变量的使用,删除/插入操作是基于模式的使用模板删除或添加组的三元组。处理这些操作,首先执行的查询模式在哪里条款将值绑定到一组命名变量。然后,这些绑定用于实例化删除和插入模板。最后,具体执行删除具体插入紧随其后。的删除/插入操作,因此,事实上,转化为具体删除/插入数据操作之前执行。我们在算法利用这一事实2这转换删除/插入操作删除/插入数据,然后翻译的操作算法1在HTTP请求。

清单6包含一个模范删除/插入操作,取代了性别的人的名字“Lady Gaga”和他的出生日期是3月28日,1986年,“女性”,不管那是什么。这个操作是第一个翻译删除/插入数据操作的算法2然后通过算法的HTTP请求1。

第一步(1号线算法2)是创建一个选择查询的在哪里条款。这个查询然后在本地执行三重存储返回的绑定删除和插入模板(2)行。这意味着所有相关数据必须包含在本地三重存储(一个假设在这个工作),否则,该操作可能只是部分执行。为每个检索绑定(第3行)删除数据(4号线)和一个插入数据(第6行)创建操作。在我们的例子中,结果由一个绑定,即< /人/ p84098 >为每?和一些未知的值性别呢?。因此,只有一个删除数据和一个插入数据操作创建如清单所示7。最后,这些操作排序(9)行删除之前执行插入和最终转化为HTTP请求(第10行)算法1。

在许多情况下,就像在这个例子中,一个删除/插入操作会代表一个更换三元组。因此,这两个,删除数据和插入数据在本地操作执行之前发出HTTP请求。这种优化减少HTTP请求的数量,因为属性不需要重置之前设置为所需的值。在我们的例子中巩固把一个请求。

5。结论和未来的工作

在本文中,我们提出了SEREDASj,一种新的方法来描述RESTful数据服务。与以前的方法相比,我们把重点强调简单降低进入门槛。Web开发人员可以使用工具和知识,他们大多已经熟悉。自SEREDASj不需要任何更改描述Web服务,它提供了一个可行的现有基础设施的升级路径。我们还介绍了两个算法翻译SPARQL Update操作HTTP请求与一个SEREDASj-described Web API进行交互。这将创建一个标准接口,不仅增加了开发人员的生产力,还可以提高代码的可重用性。

限制目前的建议是限制在JSON资源代表;目前没有其他媒体类型支持。在未来的工作中,应该扩展到支持其他格式等,例如,XML。可能,这可能是通过映射XML表示JSON已经有前途的方法如JSON标记语言(JsonML) [15]。这将允许透明地支持XML表示不改变当前的方法。同样,URI模板可以用来支持流行的应用程序/ x-www-form-urlencoded媒体类型。

在未来的工作中,我们还想创建一个开发人员工具套件支持创建SEREDASj描述,如果需要,领域本体的自动创建技术类似的用于创建领域本体从关系数据库32]。此外,我们想等研究方面服务发现和组合,包括身份验证等问题,可能需要创建一个轻量级本体描述。

引用

1. application / json的媒体类型为JavaScript对象表示法(json),注释请求4627年,互联网工程任务组(IETF), 2006年。
2. t . Vitvar和j·穆瑟,”ProgrammableWeb.com统计、趋势和最佳实践,”诉讼的第四届国际研讨会mashup Web api和服务,2010年。视图:谷歌学术搜索
3. m . Lanthaler和c . Gutl RESTful数据服务的语义描述语言对抗Semaphobia”学报》第五届IEEE国际会议上数字生态系统和技术(桌子的11),页47-53,IEEE 2011。视图:出版商的网站|谷歌学术搜索
4. s . l .黄“f8-resources构建个性化的Web,”Facebook开发者博客,2010年,http://developers.facebook.com/blog/post/379。视图:谷歌学术搜索
5. 语义标注为WSDL和XML模式(——SAWSDL), W3C推荐标准,2007年。
6. j . Lathem k Gomadam, a . p . Sheth”SA-REST和(S) mashup:添加语义RESTful服务,”程序的语义计算国际会议(ICSC ' 07)IEEE,页469 - 476年,2007年9月。视图:出版商的网站|谷歌学术搜索
7. j . Kopecky k Gomadam, t . Vitvar”hRESTS: HTML微格式来描述RESTful Web服务”《IEEE / WIC / ACM国际会议上Web智能和智能代理技术(WI 08年),第625 - 619页,2008年。视图:出版商的网站|谷歌学术搜索
8. Web应用程序描述语言(WADL) M.J.哈德利说,2009年。
9. r·哈雷和t·侯赛因,“微格式:一个务实的道路语义web, 2006年“科技,众议员06-01 CommerceNet实验室,帕洛阿尔托,加州,美国http://wiki.commerce.net/images/e/ea/cn - tr - 06 - 01. - pdf。视图:谷歌学术搜索
10. j . Kopecky和t . Vitvar D38v0.1 MicroWSMO: RESTful服务的语义描述,2008年http://wsmo.org/TR/d38/v0.1/20080219/d38v01_20080219.pdf。
11. Web服务描述语言(WSDL) 2.0版本,W3C推荐标准,2007年。
12. 猫头鹰:Web服务语义标记,W3C成员提交草案,2004年,http://www.w3.org/Submission/OWL-S/。
13. m . Klusch“语义web服务描述,”CASCOM:智能语义Web服务协调,m·舒马赫h . Schuldt h和Eds。页31-57 Birkhauser,巴塞尔,德国,2008年。视图:谷歌学术搜索
14. r·劳拉·d·罗马、答:轮询器和d . Fensel”概念的比较后WSMO和owl - s、”Web服务(欧洲会议ECOWS ' 04)卷,3250年,页254 - 269,爱尔福特,德国,2004年。视图:谷歌学术搜索
15. JSON标记语言(JsonML), 2011年,http://jsonml.org/。
16. d .罗马,凯勒,h . Lausen和j . d . Bruijn“Web服务建模本体,”应用本体,1卷,不。1,第106 - 77页,2005。视图:谷歌学术搜索
17. j . Waldo g . Wyant A Wollrath,肯德尔,“分布式计算的注意,”科技。代表,山景城,加州,美国,1994年。视图:谷歌学术搜索
18. r·阿拉和e·王尔德“从RESTful服务链接数据,”学报第三关联数据网络研讨会,2010年。视图:谷歌学术搜索
19. c . biz和r . Cyganiak D2R server-publishing关系数据库语义Web,”第五届国际语义Web研讨会论文集(ISWC 06年),2006年。视图:谷歌学术搜索
20. 奥尔,s . Dietzold j·莱曼,s .张春,d . Aumueller“Triplify-lightweight关联数据从关系数据库出版,”18学报》国际会议上万维网(WWW ' 09),第630 - 621页,2009年。视图:谷歌学术搜索
21. l·t·伯纳斯-李y . Chen Chilton et al .,“制表机:探索和分析相关数据语义web,”第三国际语义Web用户交互研讨会(SWUI 06年),2006年。视图:谷歌学术搜索
22. o .斯莱虽然“浏览语义Web,”《第五国际研讨会的语义(06年网),第369 - 365页,2006年。视图:谷歌学术搜索
23. c . biz和t . GaußDisco-Hyperdata浏览器,http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/。
24. d .引导RDFAuthor,http://rdfweb.org/people/damian/RDFAuthor/。
25. e . Pietriga IsaViz: RDF可视化编辑工具,http://www.w3.org/2001/11/IsaViz/。
26. t·伯纳斯·李,j . Hollenbach k, j . Presbrey大肠保诚d 'ommeaux和M.M. Schraefel,“制表机的再现:编写语义web,”科技,众议员ECSIAM-eprint14773南安普顿大学,南安普顿,英国,2007年。视图:谷歌学术搜索
27. pushback-Write Non-RDF从RDF数据来源,http://www.w3.org/wiki/PushBackDataToLegacySources。
28. 保留时间部署,架构风格与基于网络的软件架构设计、博士论文、部门的信息和计算机科学,加州大学欧文分校加州,美国,2000年。
29. XML核心工作组公共Page-Pubblications XML核心工作小组,2011年,http://www.w3.org/XML/Core/出版物。
30. 1.0居里语法:语法表达紧凑的uri, W3C工作组。W3C, 2010,http://www.w3.org/TR/curie/。
31. 谷歌、雅虎和微软公司。Schema.org,http://www.schema.org/。
32. f . Cerbah“学习高度结构化语义从关系数据库存储库:RDBToOnto工具,”第五届欧洲语义Web研讨会论文集(ESWC ' 08)施普林格,页777 - 781年,2008年。视图:谷歌学术搜索
33. RDF的SPARQL查询语言。W3C推荐标准,2008年,http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/。
34. SPARQL 1.1更新。W3C工作草案,2011年,http://www.w3.org/TR/2011/WD-sparql11-update-20110512/。

版权

版权©2012马库斯Lanthaler和基督教Gutl。这是一个开放的分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。