Process.owl revision c4c2756a7ac6ba51ca2f35240bdb0cf99cf2092b
<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE uridef[
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns">
]>
<rdf:RDF
xmlns:rdf= "&rdf;#"
xmlns:shadow-rdf= "&shadow-rdf;#"
xmlns:expr= "&expr;#"
xmlns:rdfs= "&rdfs;#"
xmlns:owl= "&owl;#"
xmlns:swrl= "&swrl;#"
xmlns:xsd= "&xsd;#"
xmlns:service= "&service;#"
xmlns:process= "&process;#"
xmlns:grounding= "&grounding;#"
xmlns= "&DEFAULT;#"
xml:base="&process;">
<owl:Ontology rdf:about="">
<owl:versionInfo>
$Id$
</owl:versionInfo>
<rdfs:comment>
Upper-level OWL ontology for Processes.
</rdfs:comment>
<owl:imports>
<owl:Ontology rdf:about="&expr;"/>
</owl:imports>
<owl:imports>
<owl:Ontology rdf:about="&service;"/>
</owl:imports>
<owl:imports>
<owl:Ontology rdf:about="&shadow-rdf;"/>
</owl:imports>
</owl:Ontology>
<!--As long as we're not importing SWRL and time,
we need these declarations to keep us in OWL DL: -->
<owl:Class rdf:about="&swrl;#Variable"/>
<owl:Class rdf:about="&swrl;#AtomList"/>
<owl:Class rdf:about="&time;#IntervalThing"/>
<!--
######################################################
OWL-S Version 1.1 Ontology Structure
######################################################
Proposed New Structure of Processes - substantially revised for 1.1 (MB)
Parameter is subclass of swrl:Variable with a type description and an
optional value expression.
Parameter
parameterType (an XMLLiteral)
parameterValue - when the parameter is a constant, its value can be
stated here.
Input, Output, Local are subclasses of Parameter.
Local Parameters may only be used with Atomic Processes. Their
function is to identify variables whose scope is the process as a
whole, so that when they are bound in preconditions, they can be
referenced in outputs and effects. To describe data sharing between
steps in composite processes, use the Data flow mechanisms described
below (classes Binding, ValueOf).
Preconditions, Effects, and Result conditions are Logical Expressions
represented in DRS or SWRL or perhaps KIF (see
/generic/Expression.owl) that are 'quoted' by their encapsulation as
XMLLiterals.
Conditions are Expressions.
Process.hasPrecondition and Result.inCondition properties refer to
Conditions that are tested in specific contexts. Preconditions are
evaluated with respect to the client environment before the process is
invoked, result conditions are effectively meant to be 'evaluated' in
the server context after the process has executed.
Outputs are process parameters that are associated with descriptions
by OutputBindings (DataFlow objects) associated with particular Result
conditions.
Results:
A process can have different effects with corresponding outputs under
different conditions. For example, in the book-buying example, if the
condition "inStock(book)" holds, then the effect might be
"purchased(book)" and the output "SaleCompleted(book)". This Result
bundle is encoded using the Result class, related to Process by
hasResult
Result has zero or more inCondition properties, withOutput properties,
and hasEffect properties. If it has zero inCondition properties, then
the result condition is TRUE and always occurs when the process
executes. Multiple inCondition properties are conjoined, so they must
all be true for the result to occur (that is, for the outputs and
effects to be realized).
If a Result's conditions are true then the associated outputs and
effects should occur. Variables bound by unifying the condition with
the situational state resulting from the process execution may be
referenced in these outputs and effects.
Process
hasInput (an Input) {subprop of hasParameter)
hasLocal (a Parameter)
hasOutput (a Parameter)
hasPrecondition (a Condition)
hasResult (a Result)
Result
hasResultVar (a Variable) - A variable scoped to the Result block,
bound by the result condition.
inCondition (a Condition)
withOutput (an OutputBinding of an Output Parameter of the process
to a value form)
hasEffect (an Effect)
Binding
toParam (a parameter reference)
plus one of the following two forms of value expression can be used
(but not both):
valueForm - (an XMLLiteral) an OWL description pattern containing
ValueOf's or (this) process' variables where property values would
normally occur. The idea is to have a mechanism for forming OWL
descriptions using the bound parameters and variables available. The
intention here is to form (for outputs in particular) a DESCRIPTION OF
THE MEANING OF THE MESSAGE PRODUCED BY THE SERVICE WHEN EXECUTED. It
should therefore contain as properties the slots or parameters of such
a message.
valueSource - (a ValueOf) an expression describing the source of a
data value as a parameter of a perform in the same composite
process. This is the simple case where the parameter being set is
getting its value from another parameter, such as an input coming from
an output of a prior step.
valueType - a URI referring to an OWL class definition C. An instance of
valueType asserts that the value of the given parameter will belong to C.
C must be a subclass of the parameter's overall type, declared using parameterType.
valueFunction - (for future expansion) an XMLLiteral describing a locally
computable function taking as parameters bound process parameters
(variables) or ValueOf expressions. When a consistent mechanism for
procedural attachment is decided upon, this property will be used to
specify such things as type coersions for input parameters that come
from other process outputs.
OutputBinding is a Binding with
toParam (an Output)
InputBinding is a Binding with
toParam (an Input)
(in description patterns, parameter references are by Perform ID
and parameter ID)
ValueOf is a class used to describe the source of a value that is a
parameter of another process within a composite process.
ValueOf
theVar (a Parameter)
fromProcess (a Perform)
-->
<!--######################################################
Parameters
######################################################-->
<owl:Class rdf:ID="Parameter">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#parameterType" />
<owl:minCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Parameter">
<rdfs:comment>
This is the simplest way to relate parameters to
SWRL (and DRS) variables.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="&swrl;#Variable"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="parameterType">
<rdfs:domain rdf:resource="#Parameter"/>
<rdfs:range rdf:resource="&xsd;#anyURI"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="parameterValue">
<rdfs:comment>
If an Input parameter has a constant value, or (as in the case of
Output) is a description in terms of of some other process parameters,
then supply it here. Note that it must be interpreted after reading it
as an XMLLiteral.
In future, the interpretation of this literal may be extended to allow
more flexibility, such as functional expressions.
</rdfs:comment>
<rdfs:domain rdf:resource="#Parameter"/>
<rdfs:range rdf:resource="&rdf;#XMLLiteral"/>
</owl:DatatypeProperty>
<!-- ................... Input, Output, Local Parameters .................. -->
<owl:Class rdf:ID="Input">
<rdfs:subClassOf rdf:resource="#Parameter"/>
</owl:Class>
<!-- Outputs should be descriptions in terms of other process parameters -->
<owl:Class rdf:ID="Output">
<rdfs:subClassOf rdf:resource="#Parameter"/>
</owl:Class>
<owl:Class rdf:ID="Local">
<rdfs:comment>
A Local parameter is a variable other than an input that is bound
in a precondition of an Atomic Process for use in a result condition
or effect expression (or output expression)
THEY CANNOT BE USED IN COMPOSITE PROCESSES AT ALL.
This avoids problems associated with state sharing among
asynchronously related sub processes.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Parameter"/>
</owl:Class>
<!--Inputs and Outputs and Locals are disjoint -->
<rdf:Description rdf:about="#Input">
<owl:disjointWith rdf:resource="#Output"/>
<owl:disjointWith rdf:resource="#Local"/>
</rdf:Description>
<rdf:Description rdf:about="#Output">
<owl:disjointWith rdf:resource="#Local"/>
</rdf:Description>
<!-- .......... Conditional Effects and Outputs bundled in Results ...........-->
<owl:Class rdf:ID="Result">
<rdfs:label>Result</rdfs:label>
</owl:Class>
<!--
ResultVar is a place to declare an (implicitly universally quantified)
variable that is referenced in the result condition but is not a
process parameter. Although DRS allows explicit quantifiers, SWRL does
not, and the scope of these variables is the entire Result, so that
they may be referenced in outputs and effects.
For example, if the process produces data, then to reference this data
in an output it must first be bound by a result condition.
Process Buy
-> BuyOutput
Result (?transID - xsd:Number)
When (confirmedTrans ?transID TheParentPerform)
Output BuyOutput = (ConfirmedSale :trans ?transID)
-->
<owl:Class rdf:ID="ResultVar">
<rdfs:subClassOf rdf:resource="#Parameter"/>
<owl:disjointWith rdf:resource="#Input"/>
<owl:disjointWith rdf:resource="#Output"/>
<owl:disjointWith rdf:resource="#Local"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="hasResultVar">
<rdfs:label>hasResultVar</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="#ResultVar"/>
</owl:ObjectProperty>
<!--
Multiple Results objects can be associated with a process. It is
intended that the conditions described by these objects are mutually
exclusive, so that only one Result block applies in any single
situation. The reason is to avoid the possiblity of multiple result
conditions trying to "set" the same output parameters. However, this
is not explicitly enforced by the ontology, and is currently the
responsibility of the process model designer.
A reason not to enforce this explicitly would be that it may be
convenient to set different output parameters, or describe different
effects by associating them with non-exclusive conditions.
-->
<owl:ObjectProperty rdf:ID="inCondition">
<rdfs:label>inCondition</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasEffect">
<rdfs:label>hasEffect</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="&expr;#Expression"/>
</owl:ObjectProperty>
<!--
We distinguish the outputs produced by a particular result
condition from the OUTPUT PARAMETERs of the process. Intuitively, a
result condition binds output parameters to particular
values. Therefore the withOutput properties associated with a Result
refer to OutputBinding objects that relate particular output
parameters to particular value patterns. This means different result
conditions can "set" the same output parameter with a different values
(owl descriptions), and then consumers of that output can refer to
particular output values of the process.
-->
<owl:ObjectProperty rdf:ID="withOutput">
<rdfs:label>withOutput</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="#OutputBinding"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="ConditionalEffect">
<rdfs:comment> Deprecated as of version 1.1 </rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="ConditionalOutput">
<rdfs:comment> Deprecated as of version 1.1 </rdfs:comment>
</owl:Class>
<!-- ................... Bindings (DataFlow specifications) ................
Bindings are used in two ways in this process modeling ontology. They
are used to specify how output parameters are specified in different
result conditions for Atomic Processes, and they are used to specify
how input parameters acquire values when invoked by Perform's in
composite process descriptions. In each case, a binding takes a
reference to a parameter being 'set' - the #toParam, and one of
several ways of describing a value.
Binding
toParam - the parameter being set
.. and then EXACTLY ONE of these value descriptors ..
valueData | valueForm | valueSource | valueType | valueFunction
.. where ..
valueData is for constant XML data
valueForm is an XMLLiteral representing an OWL description with embedded
variables
valueSource is a simple reference to a ValueOf object that says the
value of this parameter comes from the value of a parameter in another
process reference (Perform) in the same composite process.
valueType is a URI refering to a class, and asserts that the value of
toParam will belong to that class. The specified class must be a subclass
of the parameter's type that's been declared using parameterType.
valueFunction is a similar XMLLiteral representing a local (client)
function call with parameters that are variables (mostly for future
expansion)
-->
<owl:Class rdf:ID="Binding">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#toParam"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<!-- only one of these properties should be used with an individual Binding -->
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#valueSource" />
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#valueSpecifier" />
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#valueData" />
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="toParam">
<rdfs:domain rdf:resource="#Binding"/>
<rdfs:range rdf:resource="#Parameter"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="valueSpecifier">
<rdfs:label>valueSpecifier</rdfs:label>
<rdfs:domain rdf:resource="#Binding"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="valueForm">
<rdfs:label>valueForm</rdfs:label>
<rdfs:comment>
valueForm is to be used to specify an pseudo-OWL description that is
legal OWL except that variables (including process parameters) and
ValueOf forms can appear as the object of properties where those
things violate the range of the property. The intent is that this be
interpreted as a pattern indicating the actual value of the binding
after the variables have been substituted for.
A similar notation is used with valueFunction to indicate the
application of a locally (to the client) available function to convert
data (specified by variables or ValueOf) to a correct form.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="#valueSpecifier"/>
<rdfs:domain rdf:resource="#Binding"/>
<rdfs:range rdf:resource="&rdf;#XMLLiteral"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="valueFunction">
<rdfs:label>valueFunction</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#valueSpecifier"/>
<rdfs:domain rdf:resource="#Binding"/>
<rdfs:range rdf:resource="&rdf;#XMLLiteral"/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="valueSource">
<rdfs:label>valueSource</rdfs:label>
<rdfs:comment>
This is the simplest kind of data flow
</rdfs:comment>
<rdfs:domain rdf:resource="#Binding"/>
<rdfs:range rdf:resource="#ValueOf"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="valueType">
<rdfs:label>valueType</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#valueSpecifier"/>
<rdfs:domain rdf:resource="#Binding"/>
<rdfs:range rdf:resource="&xsd;#anyURI"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="valueData">
<rdfs:label>valueData</rdfs:label>
<rdfs:comment>
valueData is for specifying constant (XML) data to be bound to a parameter.
Ideally, the valueData property would also be a subproperty of
valueSpecifier so that it would be one of the three possible
properties used to specify a value for a Binding. But as we cannot do
that, we treat it separately, but note that if it is used, the others
should not be.
For now, its range is any XML datatype.
</rdfs:comment>
<rdfs:domain rdf:resource="#Binding"/>
</owl:DatatypeProperty>
<owl:Class rdf:ID="ValueOf">
<rdfs:label>ValueOf</rdfs:label>
<rdfs:comment>
Within a value form, or when using valueSource, references to
parameters of other processes require a tuple of (perform-ref,
param-ref, which we represent with ValueOf
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#theVar"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
We allow for the possibility that another parameter of the same process is
referenced, in which case this property is optional (hence maxCard)
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#fromProcess"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="theVar">
<rdfs:domain rdf:resource="#ValueOf"/>
<rdfs:range rdf:resource="#Parameter"/> <!-- more generally a variable? -->
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="fromProcess">
<rdfs:domain rdf:resource="#ValueOf"/>
<rdfs:range rdf:resource="#Perform"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="OutputBinding">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Binding"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#toParam"/>
<owl:allValuesFrom rdf:resource="#Output"/>
</owl:Restriction>
</owl:intersectionOf>
<rdfs:comment>
The subClassOf element is redundant, but we keep it because it is
helpful to some tools
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Binding"/>
</owl:Class>
<owl:Class rdf:ID="InputBinding">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Binding"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#toParam"/>
<owl:allValuesFrom rdf:resource="#Input"/>
</owl:Restriction>
</owl:intersectionOf>
<rdfs:comment>
The subClassOf element is redundant, but we keep it because it is
helpful to some tools
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Binding"/>
</owl:Class>
<!--######################################################
Processes
######################################################-->
<owl:Class rdf:ID="Process">
<rdfs:comment> The most general class of processes </rdfs:comment>
<rdfs:subClassOf rdf:resource="&service;#ServiceModel"/>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#AtomicProcess"/>
<owl:Class rdf:about="#SimpleProcess"/>
<owl:Class rdf:about="#CompositeProcess"/>
</owl:unionOf>
</owl:Class>
<!--
Processes can have a name, parameters, participants, preconditions,
and results. Input and output are parameters.
-->
<owl:DatatypeProperty rdf:ID="name">
<rdfs:domain rdf:resource="#Process"/>
</owl:DatatypeProperty>
<owl:Class rdf:about="#Process">
<rdfs:comment>
A Process can have at most one name, but names need not be unique.
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#name"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
A process can have parameters (inputs and outputs, locals), preconditions,
and (revised in 1.1) Results that include both effects and outputs
with a corresponding condition under which they occur.
-->
<owl:ObjectProperty rdf:ID="hasParameter">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Parameter"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasInput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Input"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasOutput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Output"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasLocal">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Local"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasResult">
<rdfs:label>hasResult</rdfs:label>
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Result"/>
</owl:ObjectProperty>
<!-- Participant
-->
<owl:Class rdf:ID="Participant">
</owl:Class>
<owl:ObjectProperty rdf:ID="hasParticipant">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Participant"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasClient">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:subPropertyOf rdf:resource="#hasParticipant"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="performedBy">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:subPropertyOf rdf:resource="#hasParticipant"/>
</owl:ObjectProperty>
<process:Participant rdf:ID="TheClient"/>
<process:Participant rdf:ID="TheServer"/>
<owl:Class rdf:about="#AtomicProcess">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasClient"/>
<owl:hasValue rdf:resource="#TheClient"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#performedBy"/>
<owl:hasValue rdf:resource="#TheServer"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
hasPrecondition is a property of Process. Expressions here can be in
any allowed logical language, and use parameters (primarily input,
local) variables The condition may be knowledge preconditions (agent
knows credit card number) or world preconditions (baud rate > 56Kb).
-->
<owl:ObjectProperty rdf:ID="hasPrecondition">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<!--######################################################
Atomic and Simple Processes
######################################################-->
<!--
Atomic processes are the basic units of implementation. To interact
with an atomic process involves (at most) 2 messages: one carrying its
inputs, and one carrying its outputs. (Note, however, that messages
are not explicitly defined in this ontology, but rather are specified
by the Grounding.)
An atomic process is a "black box" representation; that is, no
description is given of how the process works (apart from inputs,
outputs, preconditions, and effects).
To be used, an atomic process must be associated with a Grounding.
This association is expressed indirectly, by means of a Grounding
instance, which is declared independently of the process. Thus, to
get to the grounding for a given atomic process, navigate from the
process to the service object (via "describes"), and then from the
service object to its grounding (via "supports"). The grounding
contains a relation mapping atomic processes to their groundings.
-->
<owl:Class rdf:ID="AtomicProcess">
<rdfs:subClassOf rdf:resource="#Process"/>
</owl:Class>
<!--
Simple processes provide an (optional) level of abstraction. They
describe themselves in the same way as Atomic processes, but, unlike
atomics, they give additional characterization of how they work, in
terms of other processes (using the "expandsTo" and "realizedBy"
properties). They are not directly callable.
A simple process can be thought of as a "view" on either an atomic or
a composite process. Simple processes provide a means of
characterizing other processes at varying levels of granularity, for
purposes of planning and reasoning.
Future releases will allow for a formal specification of a mapping
between a simple process and the process that it abstracts.
-->
<owl:Class rdf:ID="SimpleProcess">
<rdfs:subClassOf rdf:resource="#Process"/>
<owl:disjointWith rdf:resource="#AtomicProcess"/>
</owl:Class>
<!--
A simple process that abstracts an atomic process is "realized
by" that process.
-->
<owl:ObjectProperty rdf:ID="realizedBy">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#AtomicProcess"/>
<owl:inverseOf rdf:resource="#realizes"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="realizes">
<rdfs:domain rdf:resource="#AtomicProcess"/>
<rdfs:range rdf:resource="#SimpleProcess"/>
<owl:inverseOf rdf:resource="#realizedBy"/>
</owl:ObjectProperty>
<!--
There are two fundamental relations that can hold between simple
processes and composite processes. One pertains to "expanding" a
process to its underlying CompositeProcess (zoom-in) and the other
corresponds to "collapsing" a composite process into a simple process
(zoom-out).
-->
<owl:ObjectProperty rdf:ID="expandsTo">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#CompositeProcess"/>
<owl:inverseOf rdf:resource="#collapsesTo"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="collapsesTo">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#SimpleProcess"/>
<owl:inverseOf rdf:resource="#expandsTo"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="expand">
<rdfs:comment>This is a deprecated usage; expandsTo is preferred.</rdfs:comment>
<owl:equivalentProperty rdf:resource="#expandsTo"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="collapse">
<rdfs:comment>This is a deprecated usage; collapsesTo is preferred.</rdfs:comment>
<owl:equivalentProperty rdf:resource="#collapsesTo"/>
</owl:ObjectProperty>
<!--######################################################
Composite Processes and Control Constructs
######################################################-->
<!--
Composite processes are composed of subprocesses, and specify
constraints on the ordering and conditional execution of these
subprocesses. These constraints are captured by the "composedOf"
property, which is required for a composite process.
Composite processes are constructed using control constructs and references to
processes called PERFORMs. These are analogous to function calls in
procedural language function bodies. Perform itself is a kind of control construct
specifying where the client should invoke a process provided by some server.
Performs may be references to Atomic or other Composite processes.
Perform's are composed using other ControlConstructs. The minimal initial set
includes Sequence, Split,
Split + Join, Any-Order, Condition, If-Then-Else,Iterate, Repeat-While
and Repeat-Until.
-->
<!-- ................. Perform - references to processes ........... -->
<owl:Class rdf:ID="Perform">
<rdfs:comment>
The PERFORM construct is how one references a process in a composite
process. This is analogous to a function call in a program body. The
inputs to the PERFORM are described using the hasDataFrom property.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#process"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="process">
<rdfs:domain rdf:resource="#Perform"/>
<rdfs:range rdf:resource="#Process"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasDataFrom">
<rdfs:comment>
This property has as range a Binding object, which may either indicate
constants or values that are derived from the parameters (typically
outputs) of other performs in the SAME COMPOSITE PROCESS.
</rdfs:comment>
<rdfs:domain rdf:resource="#Perform"/>
<rdfs:range rdf:resource="#Binding"/>
</owl:ObjectProperty>
<Perform rdf:ID="TheParentPerform">
<rdfs:comment>
A special-purpose object, used to refer, at runtime, to the execution
instance of the enclosing composite process definition.
</rdfs:comment>
</Perform>
<Perform rdf:ID="ThisPerform">
<rdfs:comment>
A special-purpose object, used to refer, at runtime, to the execution
instance of the enclosing atomic process definition.
</rdfs:comment>
</Perform>
<owl:Class rdf:ID="Produce">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="producedBinding">
<rdfs:domain rdf:resource="#Produce"/>
<rdfs:range rdf:resource="#OutputBinding"/>
</owl:ObjectProperty>
<!-- ................. Composite Processes ........................... -->
<owl:Class rdf:ID="CompositeProcess">
<rdfs:subClassOf rdf:resource="#Process"/>
<owl:disjointWith rdf:resource="#AtomicProcess"/>
<owl:disjointWith rdf:resource="#SimpleProcess"/>
<rdfs:comment>
A CompositeProcess must have exactly 1 composedOf property.
</rdfs:comment>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Process"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#composedOf"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="composedOf">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="invocable">
<rdfs:comment>
Invocable is a flag that tells whether the CompositeProcess bottoms
out in atomic processes. (If so, it is "invocable".)
</rdfs:comment>
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="&xsd;#boolean"/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="computedInput">
<rdfs:comment>
A computed input is a single expression that characterizes the
inputs required by a composite process, and the conditions under
which they are required. This expression may, if needed, tie
together 2 or more inputs; for example, "either a credit card number,
or a bank account number must be given", or "if product
id starts with 'M', no shipping method need be given".
Additionally, this expression may refer to things other than inputs;
for example; "if user's credit rating is 'excellent' or better,
Social Security number is not required", or "if product weight
is less than 1 lb., no shipping myth did need be given".
A "computed" input is so named because it is meant to be computed
automatically by some tool, by inspecting the makeup of the composite
process.
The language used to represent a computed input is not specified
here, and will be the subject of future work; hence, the use of Thing
as range. It will require expressiveness greater than that of
OWL.
</rdfs:comment>
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="&owl;#Thing"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="computedOutput">
<rdfs:comment>
A computed output is a single expression that characterizes the
outputs required by a composite process, and the conditions under
which they are required. See comment for computedInput.
</rdfs:comment>
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="&owl;#Thing"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="computedPrecondition">
<rdfs:comment>
A computed precondition is a single expression that characterizes the
preconditions of a composite process, based on the preconditions
of its sub processes.
</rdfs:comment>
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="&owl;#Thing"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="computedEffect">
<rdfs:comment>
A computed effect is a single expression that characterizes the
effects of a composite process, based on the effects
of its sub processes. This is not well defined for conditional effects at present.
</rdfs:comment>
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="&owl;#Thing"/>
</owl:ObjectProperty>
<owl:Class rdf:about="#CompositeProcess">
<rdfs:comment>
A CompositeProcess can have at most one invocable property. Similarly for
computedInput, computedOutput, computedEffect, and
computedPrecondition.
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#invocable"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#computedInput"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#computedOutput"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#computedEffect"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#computedPrecondition"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
ControlConstruct Class
-->
<owl:Class rdf:ID="ControlConstruct">
</owl:Class>
<owl:ObjectProperty rdf:ID="components">
<rdfs:comment>
The components propery of selected control construct subclasses holds
a specific arrangement of subprocesses or control constructs.
The range is declared at each relevant subclass of ControlConstruct.
</rdfs:comment>
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Sequence"/>
<owl:Class rdf:about="#Split"/>
<owl:Class rdf:about="#Split-Join"/>
<owl:Class rdf:about="#Any-Order"/>
<owl:Class rdf:about="#Choice"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:Class rdf:ID="ProcessComponent">
<owl:equivalentClass rdf:resource="#ControlConstruct"/>
<rdfs:comment>
Deprecated as of v. 1.1.
Note: the old concept ProcessComponent is no longer needed. ControlConstruct
which includes Perform as a subclass should be used anywhere that
ProcessComponent might have been used (which in the OWL-S 1.0 ontology
was only in describing the relationship to temporal aspects)
</rdfs:comment>
</owl:Class>
<!-- Collections of Control Constructs -->
<owl:Class rdf:ID="ControlConstructBag">
<rdfs:comment> A multiset of control constructs </rdfs:comment>
<rdfs:subClassOf rdf:resource="&shadow-rdf;#List"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&shadow-rdf;#first"/>
<owl:allValuesFrom rdf:resource="#ControlConstruct"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&shadow-rdf;#rest"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
ControlConstructList.
-->
<owl:Class rdf:ID="ControlConstructList">
<rdfs:comment>
OWL does not make any distinction between bags and lists. We redefine
the ControlConstructList class, rather than use equivalentClass, so as
to make that distinction.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="&shadow-rdf;#List"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&shadow-rdf;#first"/>
<owl:allValuesFrom rdf:resource="#ControlConstruct"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&shadow-rdf;#rest"/>
<owl:allValuesFrom rdf:resource="#ControlConstructList"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
Sequence.
-->
<owl:Class rdf:ID="Sequence">
<rdfs:comment>
Sequence is defined as having a list of component processes that
specify the body. The Preconditions, parameters and effects of the
sequence are not defined in the minimal version. An obvious extension
would be to define the effect of the sequence to be the union of the
effect of the individual members, and the parameters of the sequence
to be the union of the parameters of individual members. However, some
implementations may decide to use the last event's effects as the
effect of the sequence, etc.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructList"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
Split.
-->
<owl:Class rdf:ID="Split">
<rdfs:comment>
Here the process consists of concurrent execution of a bunch of
sub-processes. No further specification about waiting,
synchronization, etc. Similar to other ontologies' use of "Concurrent"
or "Parallel".
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
Split and Join.
-->
<owl:Class rdf:ID="Split-Join">
<rdfs:comment>
Here the process consists of concurrent execution of a bunch of
sub-processes. with barrier synchroniztion. With Split and Split and
Join, we can define processes which have partial synchronization
(ex. split all and join some subset).
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- end Split - Join -->
<!--
Any-Order.
-->
<owl:Class rdf:ID="Any-Order">
<rdfs:comment>
Allows the process components (specified as a bag) to be executed in
some unspecified order but not concurrently. Execution and completion
of all components is required. The execution of processes in an
"Any-Order" construct cannot overlap, i.e.atomic processes cannot be
executed concurrently and composite processes cannot be interleaved.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Unordered">
<rdfs:comment>
Deprecated. As of version 1.1, renamed to Any-Order.
</rdfs:comment>
<owl:equivalentClass rdf:resource="#Any-Order"/>
</owl:Class>
<!--
Choice.
-->
<owl:Class rdf:ID="Choice">
<rdfs:comment>
Choice calls for the execution of a single control construct from a given bag of control
constructs (given by the components property). Any of the given control constructs
may be chosen for execution.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!--
If-Then-Else.
-->
<owl:Class rdf:ID="If-Then-Else">
<rdfs:comment>
If-Then-Else Class is a ControlConstruct that consists of a Condition, a
then and an optional else process.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#ifCondition"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#then"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#else"/>
<owl:maxCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="ifCondition">
<rdfs:comment> The if condition of an if-then-else</rdfs:comment>
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="then">
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="else">
<rdfs:domain rdf:resource="#If-Then-Else"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</owl:ObjectProperty>
<!--
Iterate.
-->
<owl:Class rdf:ID="Iterate">
<rdfs:comment>
Iterate is an "abstract" class, in the sense that it's not detailed
enough to be instantiated in a process model. It's here to serve as
the common superclass of Repeat-While, Repeat-Until, and potentially
other specific iteration constructs that might be needed in the
future.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</owl:Class>
<!--
Repeat-While.
-->
<owl:Class rdf:ID="Repeat-While">
<rdfs:comment>
The Repeat-While class specializes the ControlConstruct class
where the with properties "whileCondition" (range of type Condition)
and ``whileProcess'' (range of type Repeat). Repeat-While tests for
the condition, exits if it is false and does the operation if the
condition is true, then loops.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Iterate"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#whileCondition"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#whileProcess"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="whileCondition">
<rdfs:domain rdf:resource="#Repeat-While"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="whileProcess">
<rdfs:domain rdf:resource="#Repeat-While"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</owl:ObjectProperty>
<!--
Repeat-Until.
-->
<owl:Class rdf:ID="Repeat-Until">
<rdfs:comment>
The Repeat-Until class specializes the ControlConstruct class where
the with properties "untilCondition" (range of type Condition) and
"untilProcess" (range of type Reapeat). Repeat-Until does the
operation, tests for the condition, exits if it is true, and otherwise
loops.
</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Iterate"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#untilCondition"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#untilProcess"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="untilCondition">
<rdfs:domain rdf:resource="#Repeat-Until"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="untilProcess">
<rdfs:domain rdf:resource="#Repeat-Until"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</owl:ObjectProperty>
<!--######################################################
Temporal Aspects
######################################################-->
<!-- timeouts are defined over intervals -->
<owl:ObjectProperty rdf:ID="timeout">
<rdfs:comment>
Interval of time allowed for completion of the process component (relative
to the start of process component execution).
</rdfs:comment>
<rdfs:domain rdf:resource="#ControlConstruct"/>
<rdfs:range rdf:resource="&time;#IntervalThing"/>
</owl:ObjectProperty>
<owl:Class rdf:about="#ControlConstruct">
<rdfs:comment>
A ControlConstruct can have at most one instance of timeout.
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction owl:maxCardinality="1">
<owl:onProperty rdf:resource="#timeout"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
</rdf:RDF>