The Summery of OWL-S 1.2

OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Web services.

This document mainly describes the differences between OWL-S 1.0 and OWL-S 1.2.

 

The Main Framework of OWL-S:

 

One: Profile

An OWL-S Profile describes a service as a function of three basic types of information: what organization provides the service, what function the service computes, and a host of features that specify characteristics of the service. 
           

1. The attribute hasEffect in owl-s 1.1 is called hasResult in 1.2.

The Profile has some function descriptions, such as hasInput, hasOutput, hasPrecondition, hasResult. The OWL-S Profile represents two aspects of the functionality of the service: the information transformation (represented by inputs and outputs) [ 传输信息 ] and the state change produced by the execution of the service (represented by preconditions and effects) [ 状态信息 ].

The mainly idea of the two attributes:

       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.

2. The Deprecated Profile Properties: serviceParameter, serviceCategory, serviceClassification, and serviceProduct.[ 不推荐使用 ]

       OWL-S users who need "special purpose" properties such as these, or domain-specific properties, are encouraged to create a new ontology that contains a subclass of Profile (and imports Profile.owl), and declares the additional needed properties with the subclass as their domain.

 

Two: Process (Mainly different) 
           

It is important to understand that a process is not a program to be executed. It is a specification of the ways a client may interact with a service or set of related services. An atomic process [ 原子流程 ] is a description of a service that expects one (possibly complex) message and returns one (possibly complex) message in response. A composite process [ 复合流程 ] is one that maintains some state; each message the client sends advances it through the process.

       A web service process can have two sorts of purpose. First, it can generate and return some new information based on information it is given and the world state. Information production is described by the inputs and outputs of the process [ 传输和处理的信息 ]. Second, it can produce a change in the world. This transition is described by the preconditions and effects of the process [ 流程执行对状态的改变 ].

       A process can have any number of inputs (including zero). [0 到多个输入 ] Inputs represent the information that must be specified for the service to produce a particular kind of result. Services can have any number of outputs [0 到多个输出 ], the information that the process provide back to the requester. There can also be any number of preconditions [0 到多个条件 ]. All preconditions must hold in order for the process to be successfully invoked. Finally, the process can have any number of effects [0 到多个结果 ]. Outputs and effects can depend on conditions that hold true of the world state at the time the process is performed. When a particular set of conditions hold, and a set of outputs and effects are produced, we cal this a result.

1. The description of IOPEs:

Inputs and outputs are subclasses of a general class called Parameter, itself a subclass of ProcessVar. Parameters, Existential variables, Participants, ResultVars and Local variables are all distinct (that is, disjoint) subclasses of ProcessVar. Parameters are the disjoint [ 不相交的并集 ] union of Inputs and Outputs.

<owl:Class rdf:ID="Parameter">

  <rdfs:comment>

      Parameter is the disjoint union of Input and Output

  </rdfs:comment>

  <owl:unionOf rdf:parseType="Collection">

    <owl:Class rdf:about="#Input"/>

    <owl:Class rdf:about="#Output"/>

  </owl:unionOf>

</owl:Class>

<owl:Class rdf:ID="Input">

  <rdfs:subClassOf rdf:resource="#Parameter"/>

  <owl:disjointWith rdf:resource="#Output"/>

</owl:Class>

Preconditions and effects are represented as logical formulas. The key idea underpinning our approach is to treat expressions as literals, either string literals or XML literals.[ 将表示 Preconditions 和 Effects 的逻辑公式视为文字 , String 或是 XML]

<owl:Class rdf:ID="Expression">

  <rdfs:subClassOf>

    <owl:Restriction>

      <owl:onProperty rdf:resource="#expressionLanguage"/>

      <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">

                   1</owl:cardinality>

    </owl:Restriction>

  </rdfs:subClassOf>

  <rdfs:subClassOf>

    <owl:Restriction>

      <owl:onProperty rdf:resource="#expressionBody"/>

      <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">

                   1</owl:cardinality>

    </owl:Restriction>

  </rdfs:subClassOf>

</owl:Class>

1.0 doesn’t have this part, in 1.0 doesn’t mention the description of the Effects and Precondition.

The connection between process and IOPRs: ( the links from a process to its parameters implicitly gives them scope.)

Property	Range	Kind
hasParticipant	Participant	ProcessVar
hasInput	Input	Parameter
hasOutput	Output	Parameter
hasExistential	Existential	ProcessVar
hasPrecondition	Condition	Expression
hasResult	Result	(see below)

Participant, input, output, and existential variables have as scope the entire process they occur in. We introduce result vars and local vars have a narrower scope.

Participant: A process involves two or more agents. One is TheClient, the agent from whose point of view the process is described. Another is TheServer, the principal element of the service that the client deals with. If there are others, they are listed using the property hasParticipant. [ 除了 Server 和 Client 以外的其他参与者 ]

[ 使用 owl:disjointWith 构造子可以表达一组类是不相交的。它保证了属于某一个类的个体不能同时又是另一个指定类的实例 ]

 

In OWL-S, if a process's precondition is false, the consequences of performing or initiating the process are undefined.

Result: We use the term result to refer to a coupled output and effect. [Result 用于联系 outputs 和 effects]

There is a fundamental difference between effects and outputs. Effects describe conditions in the world, while outputs describe information.

<owl:Class rdf:ID="Result">

  <rdfs:label>Result</rdfs:label>

</owl:Class>

<owl:ObjectProperty rdf:ID="hasResult">

  <rdfs:label>hasResult</rdfs:label>

  <rdfs:domain rdf:resource="#Process"/>

  <rdfs:range rdf:resource="#Result"/>

</owl:ObjectProperty>

In order to describe result, there is four attribute for it. The inCondition property specifies the condition under which this result occurs. The withOutput and hasEffect properties then state what ensues when the condition is true. The hasResultVar property declares variables that are bound in the inCondition .

 

2. Three kinds of processes: [same with 1.0]

Atomic Process : have no subprocesses and execute in a single step, as far as the service requester is concerned.

For an atomic process, there are always only two participants, TheClient and TheServer.

Composite Process: are decomposable into other (non-composite or composite) processes; their decomposition can be specified by using control constructs.

A CompositeProcess must have a composedOf property by which is indicated the control structure of the composite, using a ControlConstruct.

Simple Process: are not invocable and are not associated with a grounding, but, like atomic processes, they are conceived of as having single-step executions.

 

When we talk about the ControlConstructs, there are some more definitions: component and ControlConstructList, ControlConstructBag. Each control construct, in turn, is associated with an additional property called components to indicate the nested control constructs from which it is composed, and, in some cases, their ordering. ControlConstructList is a List of ControlConstructs, and they are ordered. A ControlConstructBag is like a ControlConstructList , but unordered. [ 可以认为 components 是 ControlConstruct 中的那些被控制的元素 ]

 

3. The kinds of ControlConstruct (10)

Sequence : A list of control constructs to be done in order. [ 顺序 ]

Split : The components of a Split process are a bag of process components to be executed concurrently. Split completes as soon as all of its component processes have been scheduled for execution. [ 并发 ]

Split+Join : Here the process consists of concurrent execution of a bunch of process components with barrier synchronization. That is, Split+Join completes when all of its components processes have completed. With Split and Split+Join, we can define processes that have partial synchronization. [ 并发与同步 , 在所有动作结束的时候同步 ]

Any-Order : Allows the process components (specified as a bag) to be executed in some unspecified order but not concurrently. [ 任意顺序 ]

Choice : Choice calls for the execution of a single control construct from a given bag of control constructs (given by the components property). [ 选择 ]

If-Then-Else : The If-Then-Else class is a control construct that has properties ifCondition, then and else holding different aspects of the If-Then-Else.

Iterate : The Iterate construct makes no assumption about how many iterations are made or when to initiate, terminate, or resume. [ 重复 ]

Repeat-While and Repeat-Until: Both of these iterate until a condition becomes false or true, following the familiar programming language conventions. [ 重复 ]

AsProcess : is slightly different from the others, is both a control construct and a process. Considered as a ControlCo nstruct, AsProcess has no components. However, if it is a CompositeProcess it may have a body (the value of its composedOf property). It allows you to associate outputs, local variables, effects, and even preconditions with an arbitrary subtree of a composite-process definition. [ 没有 components, 但是有 process body, 就是有 composedOf 属性 , 同时可以描述相关的输出 , 本地变量 , 状态结果 , 甚至是前键 ]

One could replace any use of AsProcess by a Perform of a process created ad hoc with roughly the same properties, but creating the extra process would be a distracting chore.

 

4. The Data flow

There are two complementary ways to specify how data flow from step to step: consumer-pulland producer-push.

Consumer-pull : uses the "pull" approach when specifying the source of a datum at the point where it is used: if step 1 feeds step 3, we specify this fact in the description of step 3 rather than the description of step 1. [ 对于数据流的描述是在消费者部分 ] It uses withOutput to "pull" the outputs out of terms available when a Result is declared.

Producer-push : At the point in a branch where the data required to compute the output are known, we insert a Produce pseudo-step to say what the output will be. Produce is a ControlConstruct that "pushes" to an Output a value available at run time.

 

Three: Grounding

The grounding of a service specifies the details of how to access the service - details having mainly to do with protocol and message formats, serialization, transport, and addressing. [grounding 对于服务访问细节 , 协议 , 消息格式 , 序列化 , 传输和寻址等相关描述 ]

A grounding can be thought of as a mapping from an abstract to a concrete specification of those service description elements that are required for interacting with the service.
        

In OWL-S, it uses the mapping from OWL-S to WSDL to describe the concrete information of the services.

The Three kinds of mapping:

1.      AN OWL-S atomic process corresponds to a WSDL (1.1) operation. [ 原子过程 - 操作 ]

2.      The set of inputs and the set of outputs of an OWL-S atomic process each correspond to WSDL's concept of message. [ 原子过程的输入输出 - 消息 ]

3.      The types (OWL classes) of the inputs and outputs of an OWL-S atomic process correspond to WSDL's extensible notion of abstract type. [ 输入输出的类型 - 抽象类型 ]

This document is mainly telling the main idea of OWL-S 1.2, and the differences between 1.0 and 1.2.