语义万维网服务的自动发现
20090822-update:本文为加入Research Blogging而修订（在文后添加了他们所要求的引文代码，以便集成到RB的平台上），日期也应要求改成今天（原来是2005年2月24日）。需要说明的是，W3C的语义网服务发现的技术框架目前已经有了很大进展，目前轻量级的、更加松散耦合的approach逐渐占了上风，估计这种繁复和缺乏灵活性的方案不会得到普及。目前“关联数据（Linked Data）”的发布方式作为一种直接的数据服务（更复杂的语义服务尚无可能）正在得到追捧。特此说明。
我感兴趣的问题实际上就是Ontology based metadata services for information retrieval. 实际上是开发一个或一组智能代理，利用Semantic Web services架构解决异构系统的情报检索互操作问题。前提条件是一定的Semantic Web services架构。首先必须对这个概念解释清楚。这是个很热门的话题了实际上，一篇经典的文章见（2001年的文章，稍早一些，还没有DAML-S）：http://www.daml.org/services/ieee01-KSL.pdf，一个作者是越南人，第三作者是个中国留学生，都很年轻啊！
以下主要来自（Katia Sycara, Massimo Paolucci, Anupriya Ankolekar, Naveen Srinivasan, “Automated discovery, interaction and composition of Semantic Web services”）*
Web services 利用自主的代理在分布的环境中实现自动的”按需”服务，Semantic Web提供服务描述和服务接口的语义支持，目前这方面的标准正在逐步建立起来，然而多个Web service之间的协调和语义一致性是一个关键问题，目前BPEL4WS 和WSCI在这方面作了一些探索，然而最可能的途径是通过DAML-S提供解决框架。
组合多个Web services可以分为三方面的问题：
- “计划”Web服务之间的交互以及其提供的功能如何整合；
-
“发现”Web服务实现的的任务；
-
对Web服务之间的”交互”进行有效的管理。
这三个方面是交织在一起的，计划决定了如何去发现Web服务的类型，却依赖于Web服务的实现。同样，Web服务的交互过程依赖于计划的实施，计划本身又依赖于对交互的需求。
揭示一个Web服务，系统必须提供对于Web服务所能实现功能和能力的描述机制，并且能够识别和比较不同Web服务的功能和能力的异同。另一个挑战是系统还必须支持对不同Web服务的交互的支持。
也就是说需要从语义和语法两个方面提供互操作性，而不是仅仅是目前考虑的重点–从语法上制定协议标准（例如SOAP和WSDL，利用XSD展现消息数据的结构）。语法的互操作性仅仅提供了消息交换的结构，没有提供消息内容的解释。UDDI仅仅是关于Web服务的信息库，并不包含Web服务能力的揭示。WSCI和BPEL4WS描述了多个Web服务可以组合在一起成为一个更复杂的Web服务，但是其重点放在语法的规定上，因此并不支持自动的Web服务的组合。
语义互操作因此成为Web服务协同组合的关键问题。它必须：
-
表达和支持Web服务的任务实现（例如网上卖书或者信用卡认证等），以便通过对于Web服务功能清楚的描述和广告而实现自动发现；
-
表达和支持业务关系和规则（Business relations and rules）；
-
表达和支持消息排序（message ordering）；
-
理解消息的语义；
-
表达和支持使用特定Web服务的前提条件以及激活服务的效果；
-
允许Web服务组合成为更为复杂的服务。
Web服务可以直接在语义Web基础上直接建立，后者为Web提供了内容语义，能够被代理或者其他服务获取，代理能够通过严格定义的语义内容和规则进行推理，由本体提供的概念模型能够很好地解释Web网页的内容。从这一点来看，语义Web为Web服务提供了其所需得的语义互操作的基础，提供了形式化的语言和本体，用以支持服务描述、消息内容的理解、业务规则，并提供了不同本体之间的联系。语义Web和Web服务互相促进：前者使Web成为一个庞大的机读数据库，后者提供机器自动使用这些数据的工具。
由此可以认为，”语义Web服务”是语义元数据、本体、形式化工具和Web服务架构的集成，是基于良好定义的语言进行语义描述的Web服务(A Semantic Web service is a Web Service whose description is in a language that has well-defined semantics)。
因此，网络计算的不确定性得到了最大程度的消除，Web服务的发现、选择、组合、沟通、激活、监测、管理、恢复和补偿都得到了最大程度的自动化和实现。特别低，语义Web服务依赖语义Web描述：
-
消息交换的内容；
-
消息交换的顺序；
-
消息交换的状态变化。
结果为不同服务的无缝互操作提供了基础。
利用语义Web描述Web服务有很多具体内容，包括描述Web服务的许多附加属性，例如服务质量、安全性约束等，可能最重要的是在Web服务的运行过程中的状态描述，包括其输入和前提条件，以及输出和结果等，这些是对于其功能和能力描述所必需的。
文章的第二部分讨论了DAML-S对于发现和激活语义Web服务的作用，并进一步讨论了Web服务发现的不同方法和DAML-S处理模型的形式语义。第三部分集中讨论DAML-S怎样用于Web服务能力的发现，怎样在UDDI注册系统的基础上更进一步。在第四部分介绍了DAML-S虚拟机，主要用于第二部分介绍的”DAML-S处理模型”形式语义的处理。第五部分提供了DAML-S虚拟机运行效果的评价，我们可以看到其运行并不频繁。第六部分描述了一个具体的利用DAML-S组合服务的应用。第七部分是结论。
（语义Web服务图示及说明）。
服务描述一般包括三方面内容：服务能力描述；非功能性静态参数（元数据）；对该项服务负责的服务实体的描述。
服务能力描述：对于符合一定前提条件的Web服务输入产生一定的输出（返回消息），以及其间的副产品。例如一个付费新闻服务需要一个日期和信用卡帐号的输入，然后判断是否符合日期和信用卡的有效性以及信用卡没有被过度使用（超出信用额度的透支）的前提条件，所产生的输出是提交用户一个满足其日期请求的新闻网址，以及从信用卡中扣除相应的服务费用，其中可能会有非功能性静态参数（元数据）参与整个过程，例如对于新闻质量、收费标准以及新闻类别的选者和控制等。
处理过程和服务概要提供了描述Web服务的两个方面：服务概要描述服务内容和能力，而处理过程描述如何实现服务。例如Amazon的Web服务的概要描述了该网站的售书功能，而服务过程则必须详细描述为了实现卖书的过程，请求者必须首先查到他所需要的书，提供支付信息，并提供发货地址等。
*Sycara, K. (2003). Automated discovery, interaction and composition of Semantic Web services Web Semantics: Science, Services and Agents on the World Wide Web, 1 (1), 27-46 DOI: 10.1016/j.websem.2003.07.002
Popularity: 39% [?]
Tags: web服务, 研客, 语义Web, 语义技术Related posts
OCLC的元数据映射Web服务
OCLC上个月底推出了一项广域网环境下解决元数据互操作问题的Web服务：自动元数据映射服务（CWS: Crosswork Web Services)，该项服务的推出可以看做是基于Web的自动元数据服务的起点，具有里程碑式的意义。将来Web3.0的语义Web时代，此类服务可能无所不在（就像输电线路传到你家，实际上已经过了无数次变压转换一样）。
目前推出的是演示Demo版（在这里 ）基本情况如下：
1、公开了一个WSDL描述接口 ，支持用户编制客户端来访问该Web服务（但未有任何开放期限的承诺）；
2、支持每用户每天500条记录的映射，不论多少个请求（这有点太小气了）；
3、支持的元数据形式以三个方面的属性进行定义：元数据的格式（如MARC, DC, MODS等），结构（XML, RDF, ISO 2709等）和编码（MARC8, UTF-8, Windows 1251d等）；
4、开放了四个函数调用（详细情况参加API说明文档 ）：
- translate(…)
- getSupportedSourceRecordFormats() （返回所支持的转换源格式列表）
- getSupportedTargetRecordFormats() （返回所支持的目标格式列表）
- getSupportedJavaEncodings() 返回Java支持的编码列表，一些格式将支持Java所支持的所有编码
目前所知的仅这些。哪位有兴趣可以开发一个简单的客户端试试。
Popularity: 52% [?]
Tags: web服务, 互操作, 元数据, 语义技术Related posts
"语义万维网服务(SWSI)"- -
“语义万维网服务” Semantic Web Services Initiative (SWSI) 的目标是使目前的万维网技术结合相关的最新进展，得以发挥其最大潜能。
语义万维网技术
万维网协会主席 Tim Berners-Lee 认为万维网的未来是”语义万维网”–万维网向机读信息和自动服务的延伸而远远超出目前的能力。在数据、程序、网页以及其他万维网资源之上的语义呈现，将使万维网成为基于知识的万维网，使目前的服务提升到一个新的水平。通过”理解”万维网上的内容，达到更精确的过滤、分类以及检索信息资源，自动服务将在更大的范围上帮助人类实现目标。这个过程将最终实现极端丰富的知识系统以及在此基础上的特别的推理服务。这些服务将有助于我们日常生活的方方面面，像今天人们对于电力一样普遍而不可或缺。
目前的万维网只是信息的堆积而不提供信息的处理，也就是说并没有把计算机当作一种计算设备。最近围绕 UDDI, WSDL, 和 SOAP 等发展起来的新技术正在把 Web 变成一种新的水平层次上的服务。应用软件课题通过万维网而获得和执行，这个技术叫做 Web 服务。 Web 服务通过提供一种程序自动交流、发现服务的机制，从而可以大大提高万维网体系结构的潜能。因而得到众多软件开发公司的关注。 Web 服务使电脑设备连接在一起，以一种新的方式使用因特网交换和联合数据。 Web 服务技术的关键在于使用松散耦合的”随时”组合可重用软件组件的方式提供服务。这从技术和业务两方面都产生深远的影响。
Semantic Web Service 似乎又多了一个兄弟： Semantic Web enabled Web Services ，欧洲 IST 的一个项目。
相关的项目、组织或网站：
http://swws.semanticweb.org/
http://swsi.semanticweb.org/
Software can be delivered and paid for as fluid streams of services as opposed to packaged products. It is possible to achieve automatic, ad hoc interoperability between systems to accomplish organizational tasks. Examples include business application, such as automated procurement and supply chain management, but also non-commercial applications as well as military applications. Web services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communications devices. Organizations can be released from the burden of complex, slow and expensive software integration and focus instead on the value of their offerings and mission critical tasks. The dynamic enterprise and dynamic value chains would become achievable and may be even mandatory for competitive advantage.
Popularity: 26% [?]
Tags: web服务, 语义Web, 语义技术Related posts
关于OWL-S的服务描述- -
服务发现是否假设请求者和提供者使用同一本体？肯定不是。否则 OWL-S 的使用会大大受限，甚至失去意义了，因为其目的本来就是为了寻找合适的本体，其前提假设就有问题。（但是是否假设使用同一本体编码语言呢？也不应该是，但是不一定）
会对本体中介进行一些规范吗？就像 WSMO 对面向对象的中间件一样？虽然可以这样做，但是至今还没有这方面的研究计划和进展。 OWL-S 是采用 OWL 语言的一种服务描述语言，并不规定是否一定有中间件或者服务实现某些功能。
是否仅包含输入描述和输出描述？答案也是否定的。 OWL-S 纲要是用于”广告”语义 Web 服务的，描述的内容包括服务描述、产品描述、输入、输出、前提条件、效果、存取条件、服务质量、安全参数等等，凡是与服务有关的参数均可以用 OWL-S 进行描述。
来自于Katia Sycara” < katia+@cs.cmu.edu >的一帖关于owl-s服务描述问题的澄清，感到有必要存档一下。
There were a number of issues raised in this discussion:
1. Does OWL-S discovery assumes that requesters and provides use a unique ontology?
The answer is NO. OWL-S does not assume the use of a single onrology. It is difficult, however, to see what you mean by “one single ontology”. If you mean “one single OWL file”, then of course trivially OWL-S does not assume a single ontology since you can import as many OWL files as you desire in an OWL-S description, and use any of the concepts defined in those files to describe the OWL-S profile or any other OWL-S component. During the discovery process the Profile of the requested service may refer to a concept, say a:A (the concept A defined in “file” a), and an advertisement may refer to concept b:B that belong to a different ontology (different owl files), and yet b:B may be defined as a subclass of a:A. In this case, matching engines would still be able to match exploiting the logical relation between A and B. At CMU, we have shown different kinds of matches (e.g. exact, plug-in etc) in our matching algorithm (see e.g. [3]).
Another way in which the use of different ontologies can be handled in OWL-S is through mapping rules that could be expressed in SWRL. In this way, to the extent that the similarity between A and B can be made explicit, then the mapping can be exploited. Of course there are issues of where these mappings live, how it is discovered where they live, since of course in the process of service discovery one does not know a priori what the ontological needs of one request would be vis a vis the current advertisement knowledge base. Even if one assumes a unique knowledge base containing such mappings, another set of issues is of course, how this knowledge base gets searched efficiently. 我的论文的一部分就是要解决这个问题：采用登记服务自动完成映射工作，但是基于怎样的请求？机制仍然成问题。
The issue of ontological mapping is an old and well known one that has predated Semantic Web Services. Work on how to express mappings to achieve semantic interoperability efficiently (even assuming the mapping rules are known) has been going on since the late 80's (perhaps even earlier).
The general problem of arbitrary ontology mapping is an open research problem. The real scientific work is in trying to attack the technical issues that I outlined (and others that are there but I did not refer to). After we solve these scientific problems (ie. How to derive the mappings, and how to use them), we can worry about what to call the algorithms.
Since ONTOLOGY MEDIATION is an open research issue, OWL-S is agnostic about the actual ontology mediation process used.( 这方面应该有研究论文，也可以参考一下，属于论文中创新性的内容 ) To the extent that the mediation process is a service, rather than a set of rules, it can be represented in OWL-S and discovered.
2. Should OWL-S do something about ontological mediation like WSMO is doing with the OO mediators?
Up to now, there is no clear operational definition of what a WSMO mediator is, neither is there a clear specification of an ontology or language for describing mediators, or an algorithm for ontological mediation.
To the extent that WSMO mediators are services, rather than sets of rules, they can be represented in OWL-S by specifying what is their profile, process model and grounding (for a detailed discussion on this point see [2]). Furthermore, the discovery mechanism may then become similar to a composition procedure where you combine discovery of the appropriate mediator with the discovery of the appropriate service.
Note that if you take this viewpoint, the sentence “OWL-S has no mediators” is non-sensical: it is analogous to sentences like “Java has no Operating System” or other such sentences. OWL-S is a language (it uses OWL semantics) that allows you to describe Web services, it does not tell you what infrastructure Web services need, nor does it stipulate the existence of mediators or of a discovery registry or any other component. If you think you need a mediator, the role of OWL-S is to provide you the tools to describe a mediator if you decide to implement it as a Web service. If you look at [2] there is a discussion on how to do that.
Popularity: 24% [?]
Tags: OWL, web服务, 语义技术