Web服务：处理上下文和语义的挑战

理论计算机科学电子笔记146（2006）3-16www.elsevier.com/locate/entcs将Web服务置于上下文大卫·马丁1SRI国际人工情报关闭CA，USA摘要当考虑与Web服务相关的活动的全部范围时，很明显，处理上下文是一个主要的挑战，需要比当前广泛接受的Web服务堆栈的构建块所提供的更大的表达能力、推理能力和体系结构组件。本文提出了一个非正式的概念，要求和挑战，处理上下文知识与Web服务的概述，并简要讨论了几个有趣的项目在这一领域的研究。关键词：上下文，Web服务，语义Web，语义Web服务1引言乍一看，Web服务似乎应该以“上下文无关”的方式描述。毕竟，Web服务通常被认为是一个整洁封装的功能模块，只要输入、输出和消息传递协议符合其描述，就可以轻松重用。然而，当我们开始超越玩具的例子，我们看到的图片是不是那么简单。例如，为了支持改变世界的服务的自动发现和选择，服务描述必须明确哪些情况将保证成功的服务使用，以及这些使用将导致哪些新情况。对于某些类别的服务，服务行为可能随时间、位置、用户历史、预先存在的1电子邮件：martin@ai.sri.com1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2005.11.0034D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3合同承诺等等;对这些区别的描述可能很快变得复杂。此外，服务使用和管理的许多方面可能需要通常不在服务描述中捕获的知识媒人可能要考虑供应商的跟踪记录、声誉和第三方的推荐。为了有效地进行服务组合，可能需要考虑各种资源约束和服务提供者之间的相互关系。从故障中恢复可能涉及一组复杂的因素，包括用户偏好、帐户状态、针对不同类型的交易而变化的策略、适当替代品（项目或动作）的可用性等。事实上，当考虑与服务相关的活动的全部范围时，很明显，处理上下文是一个主要的挑战，需要比当前广泛接受的Web服务堆栈的构建块所本文关注Web服务的上下文表示需求，以及它们与当前Web服务技术工作的关系。目标是为讨论和进一步研究Web服务的上下文奠定基础（不是说“创建上下文”），为此，我对该领域的概念、问题、需求和挑战进行了非正式的概述。下一节讨论语境的性质及其定义。在第3节中，我考虑了基于Web服务的系统可能需要处理哪些类型的上下文知识。第4节给出了几个以有趣的方式使用上下文或提出新的处理方法的项目的样本第6节讨论了与这些挑战相关的Web服务和语义Web服务技术的现状，第7节给出了一个简短的总结。2上下文和Web服务什么是“context”？与许多广泛而抽象的概念一样，没有一个被普遍接受的明确定义。这个词在逻辑学、语言学、认知科学和信息科学中有许多不同的意义。即使在信息科学中，也没有被广泛接受的定义。一些定义关注于软件系统与其环境之间的交互。例如，Brezillon在[1]中将上下文定义为“表征人类、应用程序和周围环境之间交互的信息”。其他定义侧重于对某一情况的描述。Pomerol和Brezillon [2]给出的一个例子D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）35以及使情况独特和可理解的环境因素”。为了本文的目的，我们将采用一个简单的，非正式的定义，它更符合后一个类别，但也与完成某件事有关：上下文是“完成某项任务时有用的背景知识”。什么任务？一般来说，它可以是任何事情：解决问题，得出结论，做出决定，回答问题，采取行动。特别是对于Web服务，选择服务和创建服务组合是典型的任务。 背景知识是什么知识不是注意力的焦点，也就是说，不是制定任务的核心。背景知识包括我们通常所说的问题或任务的“已知”，即已知或被认为是理所当然的知识。 （“考虑到我属于联合航空的常客俱乐部，我的旅行社选择了这家航空公司前往巴黎。总的来说，这种知识比重点明确的任务更普遍，持续时间更长，但这并不总是如此。这个案子了用户偏好为这些想法提供了一个很好的说明我们通常期望系统以透明的方式使用用户偏好。我们期望发出一个请求，比如因此，偏好是隐式的，并且可以被视为与该请求相关的背景关于服务的上下文的许多工作与移动服务用户及其通信设备的位置有关。在这里，一个典型的任务可能是找到附近的商店，在那里可以购买特定类型的产品（例如，药品）。这一任务通常会被明确化，比如说，“找到一家我可以快速到达的药品商店”。在这里，请求的重点是商店和时间限制，相关的背景知识包括我的当前位置。这种前景与背景信息的概念有些微妙，并且不可否认地不承认“清晰”的定义。例如，前一任务的替代表述可以是“查找在我当前位置的一英里内销售药品的商店”，在这种情况下，明确地提到了“位置”的概念。然而，在这种情况下，将我的位置视为背景知识仍然是合适的，因为系统被期望知道（或能够确定）我的精确位置，这是理所当然的;它被认为是“给定的”。对于这个请求的主要焦点，找到一个商店，就不能这么说了。在这种情况下，系统6D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3并不期望它知道这样一个商店的身份;实际上，如果期望它已经知道这一点，那么请求此外，当请求得到满足时，商店的身份将对我（请求者）显式显示，这不一定适用于我当前的位置。由于这些原因，商店3语境知识记住我们对上下文的非正式定义，我们可以通过思考Web服务任务和可能有助于完成这些任务的背景知识的种类来识别上下文知识的一些在下面的列表中，这些类别是根据变化频率非常粗略地排序的。也就是说，在靠近列表开头的类别中，上下文身体知识变化缓慢，而在靠近列表末尾的类别中，上下文身体知识变化更快。例如，用户位置（在下面的用户情况类别中）相当频繁地改变，至少一天几次，使得关于用户位置的给定命题不会保持为真很长时间。另一方面，用户偏好通常不会变化得如此之快，因此它们属于列表中较早出现的“用户特征”类别。类似地，组织安排，如组织的政策和结构，被认为比用户情况变化得更慢（当然也有例外）。值得再次强调的是，这是一个粗略的分类方案，也不打算成为一个详尽的分类。• 组织安排包括组织结构、组织之间的关系、人与组织之间的关系（例如，成员资格）;组织内部人员之间的关系;持续的政策;合同承诺;以及持续的部分-- 是的例如，如果一个Web服务是由一个与我的组织有持续合同关系的组织提供的，这与公司采购目的的服务选择任务有关。此外，我和老板之间的经理/下属关系是关于优先处理我收到的电子邮件的任务的相关背景知识。• ServiceCharacteristics类别包括所有可用的Web服务（及其描述）、服务注册中心、代理等。 - 粗略地说，是组成Web服务世界的静态元素。这可以D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）37还包括关于服务提供商信誉、来自第三方的推荐等的各种信息。例如，如果Web服务保证在3天内交付产品，则这可能与购买服务选择的任务相关在我儿子生日前买一台摄像机如果天气服务只提供欧洲境内的位置信息，则与获取我行程中明天旅行目的地的天气报告的任务相关。 服务描述（如WSDL或OWL-S描述）是否应该被视为上下文的一部分是有争议的，因为它们是许多Web服务任务的核心。为了目前的目的，它们被包括在这里，如果只是为了强调一点，即什么被认为是上下文是相对于任务的制定• 用户特征包括（人工和/或软件代理）服务用户的相对稳定的特征，例如偏好和约束、专业知识水平，以及可能的用户在某些设置中。上面的旅行示例，涉及用户• 用户情况包括诸如位置、该位置处的一天中的时间、（人类和/或代理）服务用户的物理特性和环境之类的事情。它还包括用户可用的资源和设备、移动性与稳定性、网络连接性和资源需求。用户上面与寻找药店有关的例子说明了这一类别。• 事务历史记录包括涉及Web服务的过去事务的记录。显然，这与服务特性类别有关，但这里的重点是（相对完整的，最新的）记录，个人使用服务。例如，如果记录显示特定服务提供商最近对服务请求的响应较慢，则可以在随后的提供商选择中考虑这一点。如果记录显示，当服务A和B都由同一个提供者提供时，它们的组合处理得更快，那么这种上下文知识可能会促使我继续为两者选择同一个提供者。• 资源状态包括有关连接中的资源使用情况的信息8D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3Web服务。例如，如果特定服务提供商的机器或网络连接当前过载，则该信息可以促使代理选择提供相同或类似服务的不同事务状态（下面）反映的是特定事务的状态，而资源状态反映的是与许多事务相关联的一组资源的状态• 事务状态包括用户当前参与的事务的各个方面，例如提供者身份和较大组合服务中特定服务它也可以包括这样的东西作为组合服务中到达的步骤，以及自事务启动或自最后一条消息发送以来经过的时间。如上所述，这种分类粗略地反映了知识变化速度的时间方面。虽然空间不允许这样做，但按照位置和出处的维度对上下文知识进行分类也可能是有趣的。也就是说，人们可以考虑以下问题：在网络空间中，不同类型的上下文知识是在哪里创建、存储和需要的？在组织空间中，它们是由谁创造的，又是由谁拥有的？3.1与服务管理任务由Web服务完成的任务是有区别的- 例如进行权限保留-以及与Web服务本身的使用或提供相关的任务，例如服务开发、选择、签约、组合、监视等。由于缺乏任何通用术语，让我们将后一类任务称为服务管理任务。上下文与这两种类型的任务相关简单地考虑一下什么样的上下文与不同的服务管理任务最相关，这可能是有用的。 这些并不是规则或约束，而只是基于我对这些任务和上下文类别的看法的粗略结论。就开发和出版的服务管理任务而言，服务特性和组织安排是最重要的上下文类型。值得注意的是，发现和选择可以依赖于所有类别，但事务状态可能除外。签约和谈判可能依赖于交易历史、组织安排、服务特征、用户特征，有时还依赖于用户情况。组合（与其对发现的依赖分开考虑）主要依赖于服务特征和资源状态。监控和恢复是D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）39可能会利用除交易历史之外的所有类别。4案例研究在这里，我们简要地讨论了几个研究系统，处理服务的参考上下文，并考虑他们解决的问题，被视为上下文的知识的种类，这种知识所属的类别，以及所采用的技术。任务计算（Task Computing）[10]，由美国富士通实验室开发，是一个框架，它透明地提供对完成（相对高级）用户任务所需的（相对低级）服务的访问也就是说，该框架填补了用户任务和可用手段之间的差距把他们带出去。特别关注在给定物理环境中自动化对计算资源的访问，该给定物理环境可能是用户不熟悉的例如，在会议室中，用户可以请求“从我的类似地，在汽车中，请求可能是上下文知识主要包括用户位置和用户设备的可用性（用户情况）、用户与文档的关系（用户特征）以及资源状态和事务状态的元素。所采用的相关技术包括语义Web服务描述、匹配器、合成器以及其他基于OWL-S的工具和组件（特别是，可以基于WSDL或UPnP的原子过程）。由卡内基梅隆大学开发的MyCampus[7]是一个系统，旨在发现，组合和执行服务，以完成复杂环境中的各种该系统旨在支持用户可以从移动设备访问，并帮助用户完成各种日常活动，例如安排会议、查找目的地、共享文档、组织活动、过滤和路由消息等。例如，如果系统被要求找到一家餐馆吃一顿快餐，它可能会根据用户的当前位置、餐馆是否被归类为“快餐”以及天气来考虑步行时间。（如果从以上描述可以看出，上下文知识是10D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3变化并且主要落入用户特征和用户情境的类别中注意用户偏好以及安全和隐私问题。技术方法包括基于规则的信息源访问，以及将上下文信息源本身建模为可以被发现、组合等的Web服务。这里还使用OWL-S基础原子进程，以及传感器、触发器和封装特定用户的安全和隐私机制的eWalletOWL-SF[6]是一种为一组用户提供主动呼叫转发的系统。该系统基于其对诸如用户的信息之类的事情的感知来决定是否联系用户以及在哪里联系用户（或重定向呼叫）位置、日历条目、一天中的时间以及用户附近的人。 例如，如果用户正在参加高优先级会议（如他的日历所示），则呼叫将被重定向到语音邮件，以免中断会议。另一方面，如果用户在自助餐厅，并且独自坐着，则呼叫将被路由到他的蜂窝电话。这个应用程序主要关注用户情况。技术方法包括使用基于OWL的包容推理，这发生在演绎服务器中。语义发现服务是由斯坦福大学的知识系统实验室开发的[4]可以使用语义Web服务（OWL-S）描述进行扩充。在OWL-S中捕获的附加服务特征允许选择更合适的服务，也允许自动选择和使用数据中介服务。 在一个典型的场景中，一个正在寻求在线抵押贷款的用户已经从英国搬到了美国。他的软件代理有能力执行一个可执行的工作流程，该流程执行获取抵押贷款所涉及的步骤，并在运行时进行动态服务绑定。在该场景中，OWL-S添加的服务语义用于选择英国的信用报告服务，基于系统的知识，他的信用历史位于那里。它还可以选择一个中介服务，将英国信用历史报告转换为根据美国惯例格式化的报告。该场景中的相关上下文信息是在两个不同时间的用户住所的（实际或预期的）位置。此信息在用户特征下分类。系统还可以考虑处于相同类别中的用户偏好。核心技术是BPEL 4 WS和OWL-S，包括动态绑定和基于OWL-S的匹配。ConWeS是由Sattanathan、Narendra和Maple开发的一个框架，用于管理与服务组件执行有关的上下文D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）311岗位它解决了组合中的供应、协调、资源管理和本体中介（用于应用程序数据和上下文管理）的问题。它处理有关服务实例执行状态的上下文信息，允许和当前部署的实例数量，实例完成的时间约束（截止日期），以及组合服务之间的相互依赖性。此上下文信息主要属于事务状态类别，但也包括资源状态。这项工作提出了一个新的本体，OWL-C，和一个新的体系结构，用于存储和管理有关事务状态的信息。5服务上下文表示和推理的挑战处理Web服务的上下文显然提出了许多挑战，这些挑战尚未被Web服务社区广泛认识或解决这里的首要问题是如何表示上下文知识，以及如何以一种能够进行推理、决策和采取行动的方式使其在需要的地方可用在本节中，我总结了这一领域工作中出现的一些主要问题表示. 我们可以从考虑表示上下文知识的语言要求开始。 由于上下文的定义是如此广泛，很难得出任何关于表达式的确切结论。可能需要的语言特征。（毕竟，原则上，“知识”包括一切可以被表示的东西，包括最复杂和抽象的定义和公理化。然而，大多数系统处理上下文的日期只创建了非常适度的，甚至是最低限度的表示要求，这可以满足基本的关系数据库，基本使用的描述逻辑，或简单使用的规则语言。这也许可以通过重新审视第3节中提出的语境知识的类别来理解。其中四个类别--用户情况、事务历史、资源状态和事务状态--与简单、容易捕获的事实有关。(That在给定适当的本体或模式的情况下，表示关于用户情况、事务历史和事务状态的事实应该是直接的。此外，用户情况是服务上下文工作中最常见的两个类别之一另一个最广泛使用的类别-用户特征- 提高了使用规则的可能性，至少在涉及偏好和约束时。例如，在偏好方面，人们可以很容易地想象出这样的规则：12D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3智慧之窗”。但是，大多数这样的例子都很容易使用基本的规则语言特性来处理。组织安排和服务特征类别中的每一个都有上下文表示的特殊挑战，至少在原则上是这样。在《组织安排》中，人们可能希望列入组织之间的合同协议，这可能很复杂。然而，我不知道到目前为止有任何关于服务上下文的工作试图这样做。类似地，如果服务描述（在其所有潜在的一般性中）被视为上下文知识的元素，那么这里同样会有大量的复杂性需要处理。安全和隐私。处理上下文会引发与安全和隐私相关的重大问题。显然，有关用户特征（如偏好）、用户情况（如位置和财务状况）的信息社会账户）和组织（如合同安排）需要仔细保护。同样清楚的是，从各种设备移动访问此类信息会造成需要采取特别措施的情况。此外，每当服务管理组件想要考虑多个组织或用户的上下文时，就需要做出允许共享该信息的安排。交易历史不能共享，至少不能完全共享，除非有特殊安排。对于所有这些情况，需要设计和标准化架构结构和机制，以允许通过适当级别的访问控制访问上下文信息。分布性、异质性和中介性。处理上下文，特别是在移动和多组织环境中，可能会对从广泛的分布式、异构的知识源、设备和服务。在[8]中，Sattanathan，Narendra和Masters提出了OWL-C（Ontology Web基于内容的上下文）本体，其主要目的是促进与组合服务执行相关的上下文信息的整合和调解。(This信息属于事务状态类别。）可扩展性。我们的两个上下文类别-服务特征和事务历史-提出了可扩展性的问题，仅仅是由于捕获这些类型的信息的知识库的潜在的巨大规模。其他相关问题包括检索给定任务的上下文信息的速度，以及推理所需的时间，特别是在资源有限的设备上。传感器和触发器。许多场景都涉及到传感器和触发器在收集和处理上下文信息方面的重要使用，尤其是D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）313通常在用户情况和事务状态的类别例如，系统类似地，系统触发器是对某些条件做出反应的机制，当它们成为现实时，通过启动一些适当的动作。这些条件通常被视为语境知识的一部分例如，任务请求为了使服务（提供者和客户机）开发人员能够轻松地使用这两种机制，可能需要提供体系其他建筑问题。其他一些问题主要与体系结构有关;也就是说，需要一种机制，在正确的时间和地点向需要它的代理人提供上下文信息。在某些情况下，配对和服务组合组件可能会超过目前处于研究前沿的基本上“上下文无关”的方法。所谓“上下文无关”是指这样的方法，其中基本服务请求（提供给匹配器）或服务目标（提供给组合器）被假定为包含这些组件完成其工作所需的所有信息。随着这些组件开始更好地利用上下文信息，它们将需要有效的标准方法来查找、访问和推理上下文信息。例如，在某些应用中可能需要反映多个服务提供者的活动并且可以由多个服务提供者访问的上下文存储库，如[8]的C上下文所示。同样，可能需要建立交易历史登记册，作为分享有关服务和服务提供者跟踪记录的信息的手段。在某些情况下，共享上下文知识的需求可以通过信息传播机制来满足，例如黑板，发布/订阅方法或[3]中提出的三重存储方法。与架构相关的其他一般问题包括：上下文是如何构造的，如何检测和评估上下文更新目的的更改，以及考虑上下文对Web服务的负载是什么？我们在这里看到，为Web服务启用上下文推理从总体上说，产生了一系列非常广泛的挑战。随着基于Web服务的系统在其范围和能力方面变得越来越雄心勃勃，根据这些挑战设计Web服务语言和体系结构将变得越来越重要。14D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）36讨论我们很可能会问，我们在处理上下文信息的技术基础设施和方法方面处于什么地位。虽然基本的Web服务技术栈提供了互操作性和消息传递机制，通过这些机制可以在Web上的参与者之间传输信息，但它基本上没有说明不同类别的上下文信息将如何表示，它们将存储在哪里，如何以及由谁维护，何时共享，将使用什么样的推理，如何确保它们的可伸缩性和安全性，等等。人们也可以看看语义Web服务（SWS）的研究领域。SWS的工作主要集中在开发语言和本体，适合用于表征服务。这一领域最引人注目的工作包括OWL for Services（OWL-S）[5]、语义Web服务框架（SWSF）[9]和Web服务建模本体论[11]。由于SWS的愿景是广泛的，它的目标是雄心勃勃的，SWS的研究人员已经开发出非常有表现力的，通用的语言，在一个单一的框架表示广泛的服务特性。因此，这些框架中的表达性对于上下文处理来说已经足够了。此外，关于服务元素的领域独立本体的工作是有前途的，因为它从原始元素建立起来，以定义一个单一的综合概念集，可以用来捕获许多不同种类的上下文知识。在这方面，SWSF虽然有些不成熟，但却是一个很好的典范。但是，为了覆盖上下文感知系统的能力，即使是容易实现的成果，在许多领域仍然需要本体开发，如[8]中的本体论建议所示。 另一个领域在SWS中的工作，以及一般的语义Web工作中，可以应用于上下文知识处理的是中介，这是WSMO分类中最特别的焦点，并且在[8]中也进行了讨论。从上下文处理的角度来看，体系结构需求基本上还没有得到解决。实际上，关于前景知识（如服务的前提条件和效果）如何在现实环境中表达和处理仍然有许多未回答的问题-例如如何，何时以及在何处评估前提条件和效果表达式SWSF和类似的组织假定服务客户和提供者有当地的知识库，但尚未对服务和提供者（或同行）知识库之间的知识交流和一致性有一个完整的了解。也没有一个明确的界定类型和知识的范围，可以预期存在于任何特定的供应商，客户，或同行网站。这些问题在下列情况下更为复杂：D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）315涉及多个提供者或对等体的分布式组合服务。背景知识（语境）的处理很少受到SWS研究者的关注。然而，刚刚提到的问题与上下文相关的问题密切相关，可以预期这些问题的进展将适用于上下文问题。除了SWS领域，更一般地考虑语义Web技术以及网格计算和语义网格也是有价值的，但这些领域超出了本文的范围。 然而，至少应该注意的是，OASIS在Web服务资源框架（WSRF）[12]上的工作包括一些技术，这些技术可能有助于管理我们的事务历史，资源状态和事务状态类别的上下文信息。原则上，与上下文知识相关的挑战可能与知识表示和推理本身的领域一样广泛。然而，正如第4节中引用的工作所说明的那样，有各种假设和限制可以导致特殊目的的方法。因此，可以实现大量有价值的功能，而无需解决所有这些挑战的全部一般性。此外，一些高回报领域可以很容易地识别，例如用户位置和物理环境、用户偏好、约束和会员资格、服务提供商的跟踪记录以及执行实例的状态和历史。在这些领域中，相对简单的表征手段可以产生大量的效用。语义网技术已经提供了基本的基础设施，通过它可以捕获和利用这些领域的知识。剩下的任务是围绕共享本体构建和建立共识，并创建可以管理知识的架构组件。总的来说，这些是目前这一领域工作的主要重点7总结虽然本文讨论了可以被视为上下文的不同类型的知识，关于Web服务任务，以及围绕满足试图构建上下文感知系统的开发人员的需求的许多挑战此外，它还介绍了几个项目，这些项目对我们理解上下文的作用做出了贡献，并考虑了Web服务研究中所需的方向，以便更有效地处理16D. Martin/Electronic Notes in Theoretical Computer Science 146（2006）3广泛的上下文知识，可能会被纳入未来的基于Web服务的系统。8致谢这篇论文源于我在CWS-05 Web服务上下文国际研讨会上作为主讲人的我要感谢研讨会的组织者-Djamal Benslimane、Chirine Ghedira和Zakaria Maiden邀请我参加这次活动，并感谢他们在组织研讨会方面所做的出色工作。引用[1] 帕特里克·布雷齐隆聚焦以人为中心的计算环境。IEEE智能系统，18（3）：62[2] 帕特里克·布雷齐隆和让·查尔斯·波美侯。决策过程中的情境程序化。在p.Blackburn等人，编辑，CONTEXT 2003，第491史普林格出版社[3] D.芬塞尔三重空间计算：基于信息持久发布的语义Web服务。Semantic Web Services：Preparing to Meet the World of Business Applications，2004年。[4] Daniel J. Mandell和Sheila A.麦克莱斯使BPEL4WS适应语义Web：Web服务互操作的自底向上方法。国际语义网会议，第227-241页，2003年[5] D.马丁，M。Paolucci，S. McIlraith，M.伯斯坦，D. McDermott，D. McGuinness，B. 帕西亚，T.佩恩，M.萨布湾Solanki，N. Srinivasan和K.西卡拉将语义引入Web服务：OWL-S方法。在第一届语义Web服务和Web流程组合国际研讨会（SWSWPC 2004）中，美国加利福尼亚州圣地亚哥，2004年。[6] B. Mrohs，M.卢瑟河Vaidya，M.瓦格纳，S。Steglich，W.Kellerer和S.阿巴诺夫斯基OWL-SF-分布式语义服务框架。在Proceedings of the Workshop on Context Awareness for ProactiveSystems（CAPS 2005），2005年。[7] 诺曼·M Sadeh，Enoch Chan，and Linh Van. MyCampus：一个基于Agent的上下文感知移动服务环境。在嵌入式、可穿戴和移动设备上的无处不在的代理研讨会论文集。（Ubiagents2002），2002年。[8] S. Sattanathan，N. C. Narendra和Z.马奇Web服务的本体论和语义上下文。在第一届Web服务上下文国际研讨会（CWS'2005）[9] SWSF。 语义Web服务框架网站。 http://www.daml.org/services/swsf/。[10] 任务计算 任务计算网站。http://www.taskcomputing.org/网站。[11] WSMO。 Web服务建模本体网站。http://www.wsmo.org/网站。[12] WSRF。Web服务资源框架网站。http://www.oasis-open.org/committees/tchome.php? wgabbrev=wsrf。