服务描述就是对服务的相关信息进行描述，WSDL 并不能很好地表达 Web Service 的语义信息，无法解释其中的标识所表达的语义。而本体具有概念化，明确化，形式化和共享的特点，并且具有的良好的概念层次结构和对逻辑推理的支持能力，因此本节在上一章提出的基于本体的语义网络地理信息服务架构的基础上，采用本体对网络地理信息服务进行标注，实现对服务的语义化描述。
5.4.2.1 地理信息服务的语义标注对象
信息资源和本体之间的关系可以通过一个称为 “标注”的过程得以实现(Lemmens，2006)。这个过程可以看做是信息资源的元数据信息的创建，只不过使用的是本体作为参考框架。因此服务的语义化描述，可以通过在一个良好的框架下，使用合适的方法对其进行标注得以实现。这个框架和方法取决于被标注资源的特性。本节首先介绍了一般服务所具有的一些特征，以及现有的服务语义模型和方法，并在此基础上着重分析地理空间信息网络服务可能存在的语义方面及适合于它的语义描述模型和方法。
地理空间语义可以传递地理空间数据、实体、现象、功能、关系、流程、服务等许多方面的内容，它涵括的范围可以非常广泛(乐鹏，2007)。本研究主要关注于网络地理信息服务的语义描述，从而能够有助于动态和自动的组合异构数据和不同类型的服务来解决实际地理应用问题。因此，为了建立地理空间信息网络服务语义，首先要理解网络服务的语义。
图 5.20 基于本体的网络服务描述(Su et al.，2003)
Su 等(2003)提出的一种基于本体的全面的服务描述模型。从图 5.20 中可以看见，服务的许多特征可以描述和语义标注。为了使得这些特征之间的关系更加清晰，Sheth(2003)把他们划分为如下四类。
(1)数据或信息语义: 数据语义形式化的标明了网络服务输入输出数据的语义。所有的服务都有一系列的输入和输出，服务交互时它们相互衔接就构成了消息流。这些语义信息在服务的发现和互操作上发挥重要作用。然而现有的 WSDL 只能提供数据语法和结构上的细节，这些细节仅仅能够被程序级的远程接口调用。为了智能化的发现服务，必须赋予输入输出数据以定义良好的语义信息。可以通过引用以形式化、显式化的本体语言建立的本体概念对这些输入输出数据进行标注，实现对他们的语义化描述。
(2)功能或操作语义: 操作语义形式化的标明了网络服务功能的语义。这些语义在服务发现和聚合的时候起关键作用。Web 服务期望满足服务请求者需求的服务被发现。但是目前通常用的基于输入输出的匹配并不一定能找到满足功能需求的合适的服务。输入输出的匹配是必要的，但不是充分的。因为，具有相同输入输出的两个服务很有可能具有完全不同的功能。比如栅格数据相加分析和栅格数据相减分析，它们输入都是栅格数据，输出数据类型也都是栅格数据。但是他们却代表完全不同的任务。因此，仅仅依靠输入输出的数据语义表示并不能充分描述服务的功能，它只是部分实现了功能语义。必须考虑接口语义以及功能实际的效用语义才能更好地得意表达。这可以通过对服务的操作的接口参数，前提条件(precondition)，后效(effect)等用本体进行标注实现。
(3)执行语义: 显式化地表达服务操作的执行的要求以及执行过程中的信息流和行为流。他们可以用来分析和验证处理过程以及异常处理。这些可以通过状态图，Petri 网，或者活动图来实现。
(4)质量语义(Quality of Service，简称 QoS): QoS 语义提供了选择服务的质量标准，形式化描述了服务的操作度量。通常我们会得到不止一个匹配的服务，那么下一个步骤就应该是选择最合适的服务。每个服务都有自己的质量属性，而服务选择是服务组合非常关键的步骤，因此需要服务语义具有质量语义信息以辅助进行服务选择。这些可以通过 QoS模型来实现。
地理空间信息服务作为一种特殊的网络服务，它在这些方面的语义信息比一般网络服务要复杂得多。这是由于地理信息服务所处理地理数据具有海量、高维、非结构化、复杂的特征造成的。地理信息服务的输入输出通常是一个数据量达百兆的非结构化的遥感影像，而不仅仅是像普通服务那样只是一个字符串。地理信息服务的处理模型也可能涉及多方面的子模型，并且可能是高数据和计算密集型的。这些都使得地理信息服务的语义化标注更加复杂。而由前面的论述可知，海洋数据是地理信息中特殊的一类，具有更加丰富的特性。这使得海洋信息服务的语义化描述更富有挑战性。
通常来讲，全面的找出现实世界对象的所有特征属性非常难，基本上不可能通过属性定义语义的最主要的一个任务就是确定所要选的属性。考虑到本研究中的主要任务是实现地理信息服务的发现和组合; 此外，服务的质量方面的语义特性不明显，更像是一种元数据; 因此本研究中不考虑服务质量的语义。
鉴于 OGC 的服务领域的规范已经被越来越多的组织和个人所接受，已成为行业标准。它们都有明确、标准的开放接口，对它们的调用执行也比较明确，因此我们主要关注于满足 OGC 标准规范的下三类最常用的服务，并从数据/信息方面，功能方面、接口方面对这些服务进行语义标注。对这种服务的描述不应该从服务本身的操作接口来描述，而应该从其实际底层支持的数据或功能的语义来描述。
(1)数据服务: 比如 WFS，WCS。这些服务使得用户通过 Internet 获取远程的地理数据成为可能。对于这类服务，没有必要描述它的内部结构与流程。而只关注其最终提供的数据是什么数据，被抽象成什么模式。因此对这种类型的服务只需从所提供的数据的语义来进行描述，主要包含几个方面来描述: ①专题类型，表示服务是什么数据。②地理形态: 表明地理数据被抽象成什么空间形态。③数据模式: 主要表达数据被抽象成什么数据模型。④数据的时空尺度。通常数据的专题类型和时空尺度是常用的。
(2)地理学处理模型服务: 比如 WPS。它可以使用户通过 Internent 访问远程的处理功能成为可能。对这类服务的语义描述可以从以下几个方面来刻画: ①地学处理模型的分类; ②地学处理的输入输出; ③服务操作的内部结构与流程; ④服务的前提及后效。对这类数据服务的功能分类和内部结构与流程是最关键的。
(3)可视化服务: 比如 WMS。通常用来提供可视化的地图，为用户提供定位功能。这类服务同数据服务很相似，唯一不同的是，数据服务可以获取实际的数据，而这类服务只能获取这些数据的可视化展示结果。因此对这类服务的语义描述，可以参考数据服务的语义描述，主要从以下三个方面来进行。①专题(可能具有多专题)。②时空尺度。③数据模式。同样，对这类服务，也没有必要描述其功能接口、内部结构与内部流程方面的语义。
5.4.2.2 海洋地理信息服务语义标注方法
原则上，对于任何能为网络服务提供语义的语义描述语言都能够用于描述地理信息服务。但是由于不同的描述语言具有各自的特色和侧重点，因此也各有适用面。
当前关于语义网络服务有一些不同的技术方案存在，各有不同的侧重点。关于服务的语义描述目前已经有很多研究工作，比如已经提交到 W3C 的有: OWL-S(W3C，2004)、网络服务建模语言(Web Service Modelling Language，WSML)(W3C，2005)、网络服务本体建模(Web Servie Modelling Ontology，简称 WSMO)(W3C，2005)，网络服务语义描述语言(Web Service Descrpition Language Semantic，简称 WSDL-S)(W3C，2005)以及网络服务描述语言的语义标注(Semantic Annotations for Web Service Description Language，简称 SAWSDL)(W3C，2007)。
Hassina Nacer Talantikite 等(2009)从以下六个方面对这些本体语言进行了一个综合性的比较(表 5.1)。
表 5.1 网络服务语义描述方法对比
(1)资源: 语义描述对应的资源(XML Schema，WSDL，UDDI 等)。
(2)属性: 文档中所能描述的属性。功能性如(输入、输出)或非功能属性如实施方法等。
(3)语言: 指语义模型的表达语言。比如 OWL，WSML 等。
(4)标注: 指标注存储于文档内(内部方式)还是独立于文档本身(外部方式)。
(5)模型: 指语义参考的领域模型是内部的还是外部定义的。
(6)匹配: 指匹配算法的类型和对应的一些属性。
通过对比可知，WSMO 逻辑表达不局限于描述逻辑，因此它们没有像 OWL-S 那样建立在 W3C 推荐的标准 OWL 的基础上。WSDL-S 和 SAWSDL 侧重于对 WSDL 元素进行扩展，而没有提供一个描述服务的完整本体框架。许多已有的工作使用了 OWL-S，而且已经有不少软件工具支持 OWL-S，OWL-S 因此成为了很多研究者的首选。
5.4.2.2.1 OWL-S 适用性分析
OWL-S 是基于 OWL 语言的语义 Web 服务的本体描述框架。OWL-S 定义了一组核心语言构件，用于对 Web 服务进行逻辑化描述，所生成的描述文件支持机器理解，从而支持代理程序基于逻辑语义实现对 Web 服务的自动发现、调用、组合及监控。
OWL-S 预先定义了一组用来描述服务的顶层本体(Ontology)，通过这些本体让机器能够理解 Web 服务。如图 5.21 所示，OWL-S 的本体由三部分组成: ServiceProfile、Ser-viceModel 和 ServiceGrounding。它们都是关于服务的最本质的描述，分别描述了服务的作用，服务如何工作，以及如何访问服务。
图 5.21 OWL-S 的顶层服务本体模型
Service 类是语义描述的 Web 服务的引用点，其实例将对应一个发布的服务。通过属性 pres-ents、 describedBy 和 supports 与 ServiceProfile、ServiceModel 和 ServiceGrounding 相关联。这三个类的实例从三个不同角度对 Web 服务进行描述，根据所描述的服务的不同，其内容可能大不相同，但都描述了一个 Web 服务的重要内容。
(1)ServiceProfile: 主要描述服务做了什么，对于 Web 服务而言，相当于服务的广告，描述服务的能力; 对于用户而言，是用户需求服务的描述。OWL-S 提供了服务的一个可能的表达 Profile 类(图 5.22 )。Profile 为服务添加三种类型信息: 服务的提供者，服务提供的功能，服务的特征属性。提供者信息包括服务该提供者的联系信息; 服务的功能描述包括: 服务的输入、输出; 服务执行的前置条件以及服务执行产生的预期效果; 服务特征属性包括: 服务所属的种类; 服务的质量评价; 一个不限长度的服务参数列表，可以包含任何类型的信息，如: 服务的最大响应时间，服务的领域特性等其他属性。
(2)ServiceModel: 描述服务如何工作，即描述服务在执行时是如何运作的。一个服务(Service)被视为一个过程(Process)。OWL-S 定义了 ServiceModel 的一个子类———ProcessModel。过程本体(Process)又分为 3 种，分别是: 原子过程(Atomic Process)，简单过程(Simple Process)以及组合过程(Composite Process)(图 5.23)。过程本体(Process)通过输入、输出、前提条件、效果来描述过程。其中输入、输出属性取值可以为任何事物。而在特定领域中，过程类的子类可以用 OWL 语言元素来声明值域限制，包括这些属性的取值个数限制。原子过程是不可分解的 Web 服务，能够被直接调用，且可以单步执行。Web 服务被调用后，响应用户调用后立即结束，不需要调用它的用户或Web 服务与之建立会话过程。
图 5.22 Profile 类的相关属性(部分)
图 5.23 Process 类的相关属性
(3)ServiceGrounding: 指明了访问一个 Web 服务的细节。通常包括消息格式、通信协议以及其他如端口号等和服务相关的细节。还指定对于在 ServiceModel 中说明的抽象类型，在进行信息交换时的数据元素的明确的表达方式。原子过程被认为是基本的过程的抽象描述。OWL-S 的 ServiceGrounding 最主要的功能就是描述原子过程的输入、输出是怎样被具体实现为消息的。
从上面的分析可见，虽然 OWL-S 提供了一个比较全面的通用的服务语义描述框架，但是 OWL-S 针对地理空间信息服务，尤其是海洋领域，存在一定的缺陷，主要表现在:
(1)OWL-S 是高层本体模型，并不提供任何领域本体。领域本体的建立必须靠领域内的团体自己去完成。然而 OWL-S 作为一种通用性质的框架，不可能对具体的行业领域的特性进行特殊的考虑，因此在地理空间信息服务这种复杂的服务的语义描述上不够。
(2)OWL-S 对服务的标注的最小单位是服务接口下的各种实际的操作方法。比如对于一个网络服务，其可能支持好几个操作方法，OWL-S 提供了对这些方法的语义描述。而对于 OGC 这种标准化接口的服务，这种服务语义建模方法显然不适用。因为 OGC 服务的方法和其相应的接口参数都是已知的、已标准化的。如图 5.24 为 WPS 服务所支持的操作列表，从图中可知 OGC 标准规范的 WPS 服务具有哪些方法，并且各方法的含义也是已知的，比如 “Excute”方法为执行某项功能。如图 5.25 为 “Excute”方法的参数列表。从图中可知该方法的各个参数类型和结构。但是该方法底层所支持的实际功能以及功能的各参数的实际意义却被这些参数给屏蔽了。因此 OGC 服务本身开放的那些操作方法的语义标注与描述意义不大。这就好比当我们按照 OGC 的 WFS 服务接口标准实现了网络要素数据服务，我们就没必要再像其他普通的网络服务那样提供一个 WSDL 文件，来对服务进行描述一些样。因为这个服务的接口已经是众所周知的。所以关于这类服务的描述重点不在于这个接口，而在于这些接口方法背后所提供的数据或功能服务。但是 OWL-S 却没法对这些服务后台所支持的实际的数据或者方法做相应的语义描述。
图 5.24 WPS 的接口
(3)由于在知识库中已经把数据以及模型显式化的用 OWL 的方式表达出来，对于服务尤其是 OGC 标准的服务来讲，语义标注已经不必太复杂。对于数据服务来讲只需从上述论述的八方面对服务输出的数据进行标注即可，对于功能服务则更简单，只需简单的引用模型库中的模型本体的概念对服务的模型属性进行标注。
(4)OWL-S 中存在 ServiceProfile 和 ServiceModel 对参数描述方面存在重复。OWL-S中将服务的语义和语法混合起来，使得逻辑不清晰。服务的语义描述和服务的语法接口描述(WSDL)没有必要放在一起。而且对于 OGC 标准化接口服务，其调用调用执行也比较明确，没有必要对其绑定等信息进行描述，因此 OWL-S 中的 ServiceGrounding 对于 OGC标准服务来说不是很必要。
图 5.25 WPS 的 Excute 方法的参数对照表(部分
(5)OWL-S 中的思路是对每个服务都进行语义建模，相当于对服务的建模到了实例级别。但是事实上这种是没必要的。因为我们只需要定义到模型级别就可以了。OWL-S 中每个服务都要重复的(尽管也可以重用已 经建立 的 模 型)进 行 定义 profile，process，ground，使得效率很 低。而本 研究 采 用的 策 略 是， 只 对 模 型级 别 进 行 建 模，不对服务实例建模。服务的语义描述，仅需简单的引用已经建立的模型本体概念，来实现对它的语义表达。而且这中语义信息通常可以用数据库表的形式进行组织。
(6)OWL-S 中服务的模型接口参数的类型定义是参考相应的本体，而这个本体是属于类级别，代表属于某个类。但是这种以一个简单的类来区别参数的方法只能适用于简单的数据类型，比如售票服务中的航次信息，而地理信息服务的参数是复杂的，不能通过简简单单的本体类来区别。前面已经论述了地理数据的语义可以从八方面的来进行描述，显然 OWL-S 这种表达方式适应不了。
(7)现有的很多基于 OWL-S 的服务检索方法，都是基于 OWL 格式文件进行匹配，其检索效率和基于数据库存储的方式显然不言而喻。
5.4.2.2.2 基于 OWL 的服务语义标注
本研究中服务语义标注的主要目的是进行服务的发现和集成，主要考虑服务的数据语义和功能语义，暂不考虑服务的质量语义及执行过程中的一些语义。此外服务语义标注的目标范围设定在满足 OGC 标准的地理空间信息服务。在这些前提下，当基于语义的服务发现后，服务的调用执行则可以通过已知的标准化接口获取其实际的操作和所需的参数，进行相应的调用执行。
通过上一节分析可以看出，目前一些服务语义描述语言(包括 OWL － S)在面对海洋信息服务方面都存在一定缺陷。为此本研究采用了一种知识库的建立和服务语义标注分离的策略，并基于 OWL 对服务进行语义描述。
在建立海洋知识库基础上，海洋信息服务的描述相对比较简单。对于数据服务，只需从 5.4.1 中阐述的数据的八个方面，用知识库中相应的本体概念对这八个方面进行标注即可(图 5.26)表达; 对于功能服务，则更为简单，只需简单对服务的模型语义属性标记为模型库中对应的模型即可(图 5.27)。表 5.2 以及表 5.3 是数据服务和功能服务对应的语义描述示例。
表 5.2 WCS 数据服务的语义标注示例
表 5.3 功能服务的语义标注示例
图 5.26 数据服务的语义标注
图 5.27 功能服务的语义标注
通过这种将数据类型、抽象模型等领域知识库的语义建模与服务本身的语义标注分离，具有这样一些优势: ①逻辑清晰，维护容易。领域知识库由领域专家建立，而服务的语义标注则可以由很普通的服务提供者(是非专家用户)完成。②服务的语义标注非常简单，只需简单地对服务的各需标注的元素引用已经建立的一些本体概念进行标注。③重用度高，同类型的服务不必经过繁琐的过程，只需简单引用同一个抽象模型即可。
本回答被网友采纳