关于profile的翻译

4. Service Profiles

Web服务上的事件处理主要包括以下三个部分：服务请求者（寻求一种服务来完成它的工作）；服务提供者（提供服务）；基础构件。在Internet 这个开放的环境中，请求者也许事先不知道是否有他所需要的服务提供者的存在，所以请求者依靠类似注册的基础构件来找到合适的提供者。譬如，一个请求者也许需要一个报道股票及时报价的新闻服务。注册的功能是将请求者和提供者进行匹配以找到最优解。在OWL-S 结构中，Service Profile提供一种方法来描述提供者所提供的服务和请求者所需要的服务。

The Service Profile并没有指定服务的表现形式，但是，通过OWL subclassing 也是有可能创建特定的服务表现形式用作service profiles 。OWL-S通过Profile类提供了一个可能的表现形式。一个OWL-S Profile将服务描述成一种功能包括三种基本信息：哪个组织提供；服务的功能；服务的特性。

提供者信息包括提供服务的实体的联系信息。譬如，联系信息可能指的是负责服务运行的维护者，或者是能够提供服务的附加信息的具有代表性的消费者。

服务功能的描述按照服务的转换来表达。具体来说，服务功能的描述指定服务所需要的inputs 和所产生的outputs ；进一步来说，因为一个服务可能需要外在条件，或是它对这些条件产生影响，profile 描述服务的前提条件和其运行的预期结果。举例来说，一个销售服务可能需要输入一个有效的信用卡帐号，而产生的结果就是该卡被消费。

最后， profile 允许用来描述服务特性的描述。这种信息的第一个类型是来指定一个给定服务的分类，比如一个服务是属于UNSPSC 这个类别里；第二个类型是评定服务的等级，一些服务可能是运行良好，可信，或是响应迅速，而另外一些服务就可能是不可信的，并且迟缓，甚至是有恶意的。在采用某种服务前，请求者可能需要去检查他所将得到的服务是属于哪一等级，因此服务必须通过一个特定的等级系统来发布自己的等级以来显示自己的质量，请求者通过这种信息来检验它是否正确和来确定接下来的行为；第三个类型是一个服务参数的集合。OWL-S Profile提供一种用来表现这些参数的机制，其中可能包括提供最大响应时间的参数。

4.1 Compiling a Profile: The Relation with Process Model

一个服务的Profile向注册提供服务的准确描述 ，然而一旦服务被选中，Profile就变的没有用处。但是，客户将会通过Process Model 来控制服务的交互。虽然在Web services的处理过程中， Profile 和Process Model 扮演的角色不同，他们是一个服务的两种不同表现形式。所以很自然地去期望两者的IOPE互相映射。

OWL-S 并没有在Profile 和Process Model 二者之间指定任何限制条件，所以两种描述可能是不一致的。但是，如果两者真的不一致，交互过程就可能中断。举一个极端的例子来说，想象一个服务被宣称为一个旅游代理，但是process model 中确是一个图书销售代理，如果它被选来预定旅游服务，但是显然这是失败的，它会要求你输入图书的名字或者是ISBN。另外，这个服务将也不会被请求者所选择，它将不会售出任何一本书。

Profile 里IOPE的选择是一个非常机警的过程。它应该避免服务的错误描述，所以理想状态下，它需要参照Process Model 里的IOPE。从另一方面来看，一部分IOPE可能太广泛以致于不能描述服务。另外要考虑的是用来匹配请求者和提供者的注册算法。此外，Profile 含蓄地指出了服务的目的：它为服务所能提供的功能做广告，虽然也可能隐藏一些并没有公开声明的其他功能。举例来说，一个图书销售服务可能包含两大功能：一是允许其他服务来浏览它的网站以找到自己所感兴趣的书；二是允许购买。服务销售者可以选择只宣传自己的购买功能或是包括浏览功能。如果包含两种功能的话，服务就会公开地表示自己能够提供的服务，当然包括两者。但是相反来说，如果只宣传购买功能，就会阻止另外一些没有想要购买图书的个体去浏览网站。 选择宣传哪种服务直接决定了这个服务如何被应用：请求者想去浏览而不想去买，这种情况下，就必须去选择公布两种功能的服务。

从上面的描述中，我们可以假设，一个服务功能的宣传所在的注册模型被做广告，然后根据服务的要求去匹配。这是一个被类似UDDI的注册所采用的模型。虽然这是Web服务最可能采用的模型，但是其他的注册模型也是有可能被采用的。比如，当一个服务的要求高于其支持，那么宣传服务的需要比宣传它所能提供的功能要更有效率，原因是提供者在当他空闲时就可以选择下一个请求。另外，在一个纯P2P架构中将没有注册的存在。事实上，注册的种类也许会有很大的差别，有28种已经被明确。通过Web服务宣言式的描述，profile将不忠于任何种类的注册，但是可以被用于任何注册中。由于profile描述了服务的提供和服务的需求，它将会被用到一个相反的注册中，其里面记录了需求和queries on offers。

4.2 Profile Properties

接下来我们将描述profile model 里的细节问题。我们先将细节分为四大类：描述用于连接Service Profile类和Service类以及Process Model类的属性；描述联系信息和profile；按照IOPE讨论功能描述；描述profile的属性。

4.2.1 Service Profile

ServiceProfile类提供各种服务高级描述的父类。ServiceProfile 并没有指定任何服务的表现形式，但是它指定用于连接profile实体和service实体的基本信息。

service 和profile 之间的关系是双向的，所以一个服务与一个profile 相映射。这些关系是由presents 和presentedBy 两个属性所描述。

presents

describes a relation between an instance of service and an instance of profile, it basically says that the service is described by the profile.

presentedBy

is the inverse of presents; it specifies that a given profile describes a service.

4.2.2 Service Name, Contacts and Description

profile 的部分属性提供人类可读的信息，而不可能被自动的处理。这些属性包括serviceName, textDescription 和contactInformation.。一个profile 可能有最多一个service name 和 text description,，但是提供者会提供尽可能多的联系信息。

serviceName

refers to the name of the service that is being offered. It can be used as an identifier of the service.

textDescription

provides a brief description of the service. It summarizes what the service offers, it describes what the service requires to work, and it indicates any additional information that the compiler of the profile wants to share with the receivers.

contactInformation

provides a mechanism of referring to humans or individuals responsible for the service (or some aspect of the service). The range of this property is unspecified within OWL-S, but can be restricted to some other ontology, such as FOAF, VCard, or the now depreciated Actor class provided in previous versions of OWL-S.

4.2.3 Functionality Description

profile 里一个必要的成分是关于功能的详细描述，包括服务所能提供的功能以及正常运行前所必须满足的前提条件。此外，profile 指定了服务运行的结果，包括一些预期的和非预期的。Profile 描述了服务的功能性的两个方面：转换信息和服务运行所产生的状态改变。举例来说，去完成一个销售，图书销售服务需要一个信用卡帐号和有效使用期作为输入，以及信用卡帐号是否存在或是否透支。销售的结果就是一个是否接受的结果，那就是确认了这次处理的正常运行，而作为状态改变就是，一本书的所属权改变和书的存储地点改变，由仓库变到购买者手上。

Profile本体没有提供一个计划来描述IOPE实体。但是，这样一个计划存在于 Process本体中。理想地，我们想象由Profile所公布的IOPE's是由Process所公布的IOPE's的子集。 因此， Process这一部分将创建所有的IOPE实体，而 Profile实体可以很容易对应到他们之中。在这种情况下，一个IOPE所创建的实体将不同于以前OWL-S的版本。但是，如果Profile 的IOPE's不同于Process的 IOPE's，Profile 将仍然会通过Process本体中所提供的计划创建自己IOPE的实体。

Profile 本体定义了Profile 类里的以下属性：

hasParameter

ranges over a Parameter instance of the Process ontology. Note that the Parameter class models our intuition that Inputs and Outputs (which are kinds of Parameters) are both involved in information transformation and therefore they are different from Preconditions and Effects. As a consequence, we do not expect this class to be instantiated. It's role is solely making domain knowledge explicit.

hasInput

ranges over instances of Inputs as defined in the Process Ontology.

hasOutput

ranges over instances of type Output, as defined in the Process ontology.

hasPrecondition

specifies one of the preconditions of the service and ranges over a Precondition instance defined according to the schema in the Process ontology.

hasResult

specifies one of the results of the service, as defined by the Result class in the Process ontology. It specifies under what conditions the outputs are generated. Furthermore, the Result specifies what domain changes are produced during the execution of the service.

See Figure  2, which shows selected classes and properties of the Profile.

Figure 2: Selected classes and properties of the Profile

4.2.4 Profile Attributes

在前文我们已经介绍了服务的功能性描述，但是还有关于服务的其他方面读者必须关注。这些额外的属性包括服务所提供的质量保证，可能的分类和其他一些服务必须明确的参数。

serviceParameter

is an expandable list of properties that may accompany a profile description. The value of the property is an instance of the class ServiceParameter (4.2.5).

serviceCategory

refers to an entry in some ontology or taxonomy of services. The value of the property is an instance of the class ServiceCategory (4.2.6)

4.2.5 ServiceParameter

serviceParameterName

is the name of the actual parameter, which could be just a literal, or perhaps the URI of the process parameter (a property).

sParameter

points to the value of the parameter within some OWL ontology.

4.2.6 ServiceCategory

ServiceCategory 根据等级来描述服务的分类，这些等级可能在OWL-S外甚至在OWL外。在后者情况下，如果需要推论，他们也许就需要一些指定的推理机。

categoryName

is the name of the actual category, which could be just a literal, or perhaps the URI of the process parameter (a property).

taxonomy

stores a reference to the taxonomy scheme. It can be either a URI of the taxonomy, or a URL where the taxonomy resides, or the name of the taxonomy or anything else.

value

points to the value in a specific taxonomy There may be more than one value for each taxonomy, so no restriction is added here.

code

to each type of service stores the code associated to a taxonomy.

4.2.7 Specifying Service Type and Product

serviceClassification 和 serviceProduct,两个属性被用于指定service 的种类和通过服务所操作的产品。这两个属性的值是服务和产品的OWL 本体中类的实体。serviceClassification 和 serviceProduct 与serviceCategory 相似，但是他们不同在于，属性的值是OWL实体而strings referring to some non-OWL business taxonomy。

serviceClassification

defines a mapping from a Profile to an OWL ontology of services, such as an OWL specification of NAICS.

serviceProduct

defines a mapping from a Profile to an OWL ontology of products, such as an OWL specification of UNSPSC.