英语原文共 20 页，剩余内容已隐藏，支付完成后下载完整资料
DAML-S：Web服务的语义标记
DAML服务联盟：Anupriya Ankolekar，Mark Burstein，Jerry R. Hobbs，Ora Lassila，David L. Martin，Sheila A. McIlraith，Srini Narayanan，Massimo Paolucci，Terry Payne，Katia Sycara，曾红雷
摘要：语义Web应该不仅能够访问内容，还能访问Web上的服务。用户和软件代理应该能够发现，调用，编写和监视提供特定服务并具有特定属性的Web资源。作为DARPA代理商标记语言计划的一部分，我们已经开始开发一种称为DAML-S的服务本体，它将使这些功能成为可能。在本文中，我们描述了本体的整体结构，广告服务的服务配置文件，以及服务操作详细描述的流程模型。我们还将DAML-S与几个行业的努力进行了比较，以确定在Web上表征服务的标准。
1.介绍：语义网上的服务
努力创造语义网络正在获得动力[2]。很快，就有可能通过内容访问Web资源，而不仅仅是通过关键字。 DAML是DARPA的代理标记语言[10]的发展。 DAML能够为任何域创建本体，并在特定网站的描述中实例化这些本体。最重要的Web资源之一是提供服务的Web资源。所谓“服务”，是指网站不仅提供静态信息，而且允许人们在世界中实施一些行动或改变，例如销售产品或控制物理设备。语义网应该启用用户自动查找，选择，使用，编写和监视基于Web的服务。
为了使用Web服务，软件代理需要计算机可解释的服务描述以及访问它的方式。 DAML的一个重要目标就是建立一个框架，在这个框架内进行这些描述的制作和共享。 Web站点应该能够使用一组基本的类和属性来声明和描述服务，DAML的本体构造机制提供了适当的框架来完成这个工作。
本文描述了由BBN技术公司，卡内基梅隆大学，诺基亚公司，斯坦福大学和SRI国际组织共同合作，定义了这样的本体论。我们称这种语言为DAML-S。我们首先通过一些示例任务来激励我们的努力。在本文的核心部分，我们描述了我们开发的服务的上层本体，包括配置文件，流程和时间的本体，以及对过程控制未来本体的思考。然后，我们将DAML-S与最近的一些工业努力进行比较，以标准化服务的标记语言。
美国宾夕法尼亚州匹兹堡卡内基梅隆大学机器人研究所， BBN Technologies，马萨诸塞州剑桥市，人工智能中心，SRI国际，加利福尼亚门洛帕克， 诺基亚研究中心，马萨诸塞州伯灵顿，知识系统实验室，斯坦福大学，斯坦福，加利福尼亚州，作者姓名按字母顺序排列。
2.一些激励任务
服务可以是简单的或原始的，因为它们只调用一个Web可访问的计算机程序，传感器或不依赖于其他Web服务的设备，并且用户和服务之间不存在持续的交互，而不是简单的响应。例如，在给出地址时返回邮政编码或经纬度的服务将在此类别中。或者，服务可能很复杂，由多个原始服务组成，通常需要用户和服务之间的交互或对话，以便用户能够有条件地做出选择并提供信息。一个人与www.amazon.com购买书籍的互动就是这样;用户通过各种标准搜索图书，读取评论，可能或不可能决定购买，并给出信用卡和邮寄信息。 DAML-S旨在支持这两类服务，但复杂的服务为语言的功能提供了主要动机。以下四个示例任务将使读者了解我们期望DAML-S启用的各种任务。
1.自动Web服务发现。自动Web服务发现涉及Web服务的自动定位，它提供特定服务并遵守所要求的约束条件。例如，用户可能想要找到在两个给定城市之间销售机票并接受特定信用卡的服务。目前，该任务必须由可能使用搜索引擎来查找服务，读取网页并手动执行服务的人来执行，以确定它是否满足约束条件。使用服务的DAML-S标记，可以将Web服务发现所需的信息指定为服务网站上的计算机可解释的语义标记，并且可以使用服务注册表或本体增强的搜索引擎来自动定位服务。或者，服务器可以在服务注册中心（也称为中间代理[4,24,12]）中主动向DAML-S做广告，以便请求者在查询注册时可以找到它。因此，DAML-S必须提供可用于自动服务发现的服务属性和功能的声明式广告。
2.自动Web服务调用。自动Web服务调用涉及由计算机程序或代理自动执行识别的Web服务。例如，用户可以请求从特定航班上的特定站点购买机票。目前，用户必须前往提供该服务的网站，填写表单并点击按钮执行服务。或者，用户可以使用HTML中的适当参数直接向服务发送HTTP请求。无论如何，循环中的人是必要的。执行一个Web服务可以被认为是一个函数调用的集合。 Web服务的DAML-S标记为执行这些函数调用提供了声明式的，计算机可解释的API。软件代理应该能够解释标记，以了解服务调用需要哪些输入，返回哪些信息以及如何自动执行服务。因此，DAML-S应该为自动化Web服务执行所必需的Web服务提供声明性API。
3.自动Web服务组合和互操作。这项任务涉及Web服务的自动选择，组合和互操作以执行某项任务，只要对目标进行高级描述即可。例如，用户可能想要为会议旅行做出所有旅行安排。目前，用户必须选择Web服务，手动指定组合，并确保互操作所需的任何软件都是自定义创建的。使用Web服务的DAML-S标记，选择和编写服务所需的信息将在服务网站上编码。可以编写软件来操作这些表示，以及任务目标的说明，以自动完成任务。因此，DAML-S必须提供对自动服务组合和互操作所必需的个别服务使用的先决条件和后果的声明式规范。
4.自动Web服务执行监视。 单独的服务，甚至更多的服务组合，通常需要一些时间才能完全执行。 在此期间用户可能想知道他们的请求状态，或者他们的计划可能已经改变，需要软件代理所采取的行动的改变。 例如，用户可能希望确保他们的酒店预订已经完成。 为了达到这些目的，最好有能力找出过程中的要求，以及是否出现了任何意料之外的故障。 因此，DAML-S应提供执行服务的描述符。 DAML-S的这一部分是我们的目标，但尚未定义。
任何声明为服务的Web可访问程序/传感器/设备都将被视为服务。 DAML-S并不排除将简单的静态Web页面声明为服务。 但是我们定义DAML-S的主要动机是支持更复杂的任务，如上所述。
3.上层的服务本体
Service类位于服务分类的顶部，其属性是通常与各种服务相关联的属性。服务的上层本体对于服务的特定子类应该是什么，或者甚至是构建这个分类的概念基础都没有提及，但是预计分类将根据功能和领域差异以及市场需求来构建。例如，可以设想一个广泛的子类，B2C交易，它将包括从零售网站购买物品，跟踪购买状态，建立和维护网站帐户等服务。
我们构造服务本体的动机是需要提供关于服务的三种基本类型的知识（如图1所示），每种知识的特点都是它所回答的问题：
服务对用户或其他代理有什么要求，并提供给他们？这个问题的答案在配置文件中给出。因此，Service类提供了服务配置。
它是如何工作的？这个问题的答案在“模型”中给出。因此，服务类是
描述一个服务配置。
它是如何使用的？这个问题的答案在“接地”中给出。因此，类Service支持服务底层。
特性呈现，描述和支持是服务的属性。 服务配置文件，服务模型和服务底层类是这些属性的相应范围。我们期望每个服务的后代类（如B2C事务）都将呈现一个后代类Service-Profile，由服务模型的后代类描述，并支持Service-Grounding的后代类。从一种服务类型到另一种服务类型，模型和接地的细节可能差别很大 - 也就是说，从一个服务类别到另一个服务类别。但是这三个类中的每一个都提供了关于服务的基本信息类型，正如本文其余部分所描述的那样。
服务档案告诉“服务是干什么的”;也就是说，它提供了服务寻求代理所需的信息类型，以确定服务是否满足其需求（通常是诸如输入和输出类型，先决条件和后置条件以及绑定模式等）。在将来的版本中，我们将在这样的规范中使用逻辑规则或其等价物来表达参数之间的交互。例如，一条规则可能会说，如果一个特定的输入参数以某种方式被绑定，则某些其他输入参数可能不需要，或者可能由服务本身提供。作为DAML和DAML-S。
服务配置文件也被称为服务能力通告[20]。
图1 服务本体的顶层
以及它们的应用程序的演变，它们所支持的逻辑规则和推理方法可能在模型和基础以及配置文件中扮演越来越重要的角色。有关其他示例，请参见[5]。
服务模式告诉“服务如何工作”;也就是说，它描述了服务执行时发生的情况。对于非平凡的服务（那些由多个步骤组成的服务），服务寻求代理至少可以通过四种不同的方式使用此描述：（1）对服务是否满足其要求进行更深入的分析需要; （2）组合来自多个服务的服务描述以执行特定任务; （3）在服务制定过程中，协调不同参与者的活动; （4）监视服务的执行情况。对于非平凡的服务，前两个任务需要一个行为和过程模型，最后两个涉及另外一个执行模型。
服务基础（简称“基础”）指定代理人如何访问服务的详细信息。通常，接地将指定通信协议（例如，RPC，HTTP-FORM，CORBA IDL，SOAP，Java RMI，OAA ACL [12]）以及服务特定的详细信息，例如用于联系服务的端口号。另外，对于服务模型中指定的每个抽象类型，接地都必须明确指定一种与服务交换数据元素的明确方式（即采用的编组/序列化技术）。可能性是相对较小的一系列基础将被广泛用于与DAML服务相结合。接地将在各种众所周知的URI中指定。
一般来说，服务配置提供代理发现服务所需的信息。总之，与服务关联的服务模型和服务底层对象为代理提供足够的信息来使用服务。
服务的上层本体故意没有为属性表示，描述和支持指定任何基数。尽管原则上服务需要全部三个属性进行充分表征，但可以想象局部表征可能有用的情况。因此，没有规定最小基数。此外，服务当然应该可以提供多个配置文件，多个模型和/或多个基础。因此，没有规定最大基数。
一般来说，配置文件，模型和/或地面之间不必存在一对一的对应关系。在上层本体中可以适当表达的这三种表征中唯一的约束是对于每个模型，必须至少有一个支持接地。
在以下两节中，我们将更详细地讨论服务配置文件和服务模型（服务基础没有进一步讨论，但在随后的出版物中会有更深入的报道）
4.服务配置文件
服务配置文件提供服务及其提供者的高级描述[21,20];它用于请求或通过发现/位置注册表进行广告服务。服务配置文件由三种信息组成：人类可读的服务描述;由服务提供的功能的规范;以及一系列功能属性，这些功能属性提供有关该服务的附加信息和要求，以便在推理具有类似功能的多个服务时提供帮助。服务功能表现为从服务所需输入到生产输出的转变。例如，新闻报道服务会将自己宣传为一种服务，在给定日期的情况下，该服务将返回在该日期报道的新闻。功能属性指定了有关服务的其他信息，例如提供的响应时间或准确性的保证或服务的成本。
虽然服务提供商使用服务配置文件来宣传他们的服务，但服务请求者使用该配置文件来指定他们需要的服务以及他们对此类服务的期望。例如，一个请求者可能会寻找一个新闻服务，报道股市报价。注册管理机构的作用是将请求与其他服务所宣传的配置文件进行匹配，并确定哪些服务提供最佳匹配。
隐含地，服务配置文件指定服务的预期目的，因为它们仅指定公开提供的那些功能。图书销售服务可能涉及两种不同的功能：它允许其他服务浏览其网站以查找感兴趣的书籍，并允许他们购买他们找到的书籍。书商可以选择广告只是购书服务，或者浏览功能和购买功能。在后一种情况下，该服务公开表示它可以提供浏览服务，并且允许每个人在不购买书籍的情况下浏览其注册表。相反，通过仅广告书籍销售功能而不是浏览，代理不鼓励不打算购买的请求者进行浏览。关于要宣传哪些功能的决定决定了服务的使用方式：打算浏览但不购买的请求者将选择一种广告购买和浏览功能的服务，但不会宣传只购买广告的服务。
服务配置文件仅包含允许注册管理机构根据请求决定哪些广告匹配的信息。就此而言，配置文件中的信息是过程模型和服务接地中信息的摘要。在上面的例子中，如果服务不公布某些功能，它们将不会成为服务配置文件的一部分。但是他们是服务模式的一部分，只要他们需要实现广告服务。例如，寻找一本书是购买它的基本先决条件，因此它将在流程模型中指定，但不一定在配置文件中指定。同样，关于送货的信息可能会出现在流程模型中，但不包括配置文件。
4.1描述
在配置文件中提供有关该服务的信息，例如其出处或文本摘要。这主要供人类用户使用，尽管在查找请求的服务时需要考虑这些属性。
4.2功能描述
配置文件的一个重要组成部分是规定服务提供的内容以及必须满足成功结果条件的规范。另外，配置文件指定了什么条件是由服务产生的，包括服务活动的预期和意外结果。
该服务由配置文件的输入和输出属性表示。输入属性指定了服务进行计算所需的信息。例如，售书服务可能需要出售该书的信用卡号和书目信息。输出指定了服务操作的结果。对于图书销售代理人来说，输出可以是一个确认销售的收据。
lt;rdf:Property rdf:ID='input'gt;
lt;rdfs:commentgt;
Property describing the inputs of a service in the Service Profile
lt;/rdfs:commentgt;
lt;rdfs:domain rdf:resource='#ServiceProfile'/gt;
lt;rdfs:subPropertyOf rdf:resource='#parameter'/gt;
lt;/rdf:Propertygt;
全文共23822字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[14386]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
