<rdf:RDF
  xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"
  xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
  xmlns:service = "http://www.daml.org/services/daml-s/2001/10/Service#"
  xmlns      = "http://www.daml.org/services/daml-s/2001/10/Process#"
>

<daml:Ontology rdf:about="">
  <daml:versionInfo>
    $Id: Process.daml,v 1.38 2001/10/08 08:47:23 martin Exp narayana $
  </daml:versionInfo>
  <rdfs:comment>
    Upper-level DAML ontology for Processes.
    Part of the DAML-S effort; see http://www.daml.org/services/.
  </rdfs:comment>
  <daml:imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/>
  <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml"/>
  <daml:imports rdf:resource="http://www.daml.org/services/daml-s/2001/10/Service.daml"/>
</daml:Ontology>

<!--######################################################
    Connections to upper level Service ontology 
    ###################################################-->

<daml:Class rdf:ID="ProcessModel">
  <rdfs:comment>
    A ServiceModel describes how a Service works, and
    a ProcessModel is a type of ServiceModel (the only
    type being defined for DAML-S).
    See introductory comments to Service.daml.  
  </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/services/daml-s/2001/10/Service#ServiceModel"/> 
</daml:Class>

<rdf:Property rdf:ID="topLevelProcess">
  <rdfs:domain rdf:resource="#ProcessModel"/>
  <rdfs:range rdf:resource="#Process"/>
</rdf:Property>

<daml:Class rdf:ID="ProcessControlModel">
  <rdfs:comment>
    A ProcessControlModel is used to monitor and control execution of 
    a Process. This is just a "stub" for now; will be developed further
    in future releases of DAML-S.
  </rdfs:comment>
</daml:Class>

<!--######################################################
    Processes
    ###################################################-->

<daml:Class rdf:ID="Process">
  <rdfs:comment> The most general class of processes </rdfs:comment>
  <daml:unionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#AtomicProcess"/>
    <daml:Class rdf:about="#SimpleProcess"/>
    <daml:Class rdf:about="#CompositeProcess"/>
  </daml:unionOf>
</daml:Class>

<!--

Processes can have a name, parameters, preconditions, and effects.
Input, output, and participant are subproperties of parameter. Each
input, output, parameter, precondition or effect is a property of
process, left unrestricted at this level (it ranges over "Thing"). The
basic attributes are similar to the PDDL definition of events with the
addition of input, output and participant attributes.  NOTE: There is
no assumption about which features go into each of input, output,
effect etc. A specific service provider can choose to declare certain
features as inputs and/or precondition; effect and/or output etc.

Processes can also be at an instant (atTime) or during an interval
(during).  [jh 2001/07/11]

-->

<rdf:Property rdf:ID="name">
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</rdf:Property>

<daml:Class rdf:about="Process">
  <rdfs:comment>
    A Process can have at most one name, but names need not be unique.
  </rdfs:comment>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#name"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

<!--
Precondition is a property of Process. The top level ontology
doesn't restrict them at all. A precondition can be any kind of daml
object (Thing).  Specific processes will specialize this property by
restricting the range appropriately using subPropertyOf; such as knowledge
Preconditions (agent knows credit card number) or world Precondition
(baud rate > 56Kb) 
-->

<rdf:Property rdf:ID="precondition">  
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</rdf:Property>

<!--
Parameters are properties of processes. The top level ontology
doesn't restrict them at all. A parameter can be any kind of daml
object (Thing).  Specific processes will specialize this property by
restricting the range appropriately using subPropertyOf; such as the
credit card number sub-property of a buying event would be restricted
to have a range of type integer.  
-->

<rdf:Property rdf:ID="parameter">
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</rdf:Property>

<!--
Effect is a property of process. The top level ontology
doesn't restrict them at all. An effect can be any kind of daml
object (Thing).  Specific processes will specialize this property by
restricting the range appropriately.

NOTE: A conditional effect can be specified by specifying the range of the
Effect to be an IF-THEN-ELSE object
 -->

<rdf:Property rdf:ID="effect">  
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</rdf:Property>

<!-- We provide three common subtypes of parameters in the top level
ontology.  The types are input, output, and participant.  -->

<!-- An input is a type of parameter and is a property of
a process. The top level ontology doesn't restrict them at all. An input
can be any kind of daml object (Thing).  Specific processes will
specialize this property by restricting the range appropriately; such
as required inputs, derivable inputs, etc.
 -->

<rdf:Property rdf:ID="input"> 
 <rdfs:subPropertyOf rdf:resource="#parameter"/> 
</rdf:Property>

<!-- An output is a type of parameter and is a property of
a process. The top level ontology doesn't restrict them at all. An output
can be any kind of daml object (Thing).  Specific processes will
specialize this property by restricting the range -->

<rdf:Property rdf:ID="output">  
  <rdfs:subPropertyOf rdf:resource="#parameter"/>
</rdf:Property>


<!-- A participant is a type of parameter and is a property
of a process. The top level ontology doesn't restrict them at all. A
participant can be any kind of daml object (Thing).  Specific processes
will specialize this property by restricting the range to types of
agents, objects, entities, etc.  -->

<rdf:Property rdf:ID="participant">  
  <rdfs:subPropertyOf rdf:resource="#parameter"/>
</rdf:Property>


<!-- Bookkeeping Properties. These properties are specified for processes
and are mostly unrestricted at this level. The are useful for tracking,
workflow enactment, and database management. 
 -->

<rdf:Property rdf:ID="address">
 <rdfs:comment> 
  Address is a machine name, leave it unrestricted for now
</rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
</rdf:Property>

<rdf:Property rdf:ID="docRead">
 <rdfs:comment> 
  Documents that are read by the Process (could be a database, an html form,
  whatever), range is left unrestricted at this level.
</rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
</rdf:Property>

<rdf:Property rdf:ID="docUpdate">
 <rdfs:comment> 
  Documents that are updated by the Process (could be a database, an html form,
  whatever), range is left unrestricted at this level.
</rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
</rdf:Property>

<rdf:Property rdf:ID="docWrite">
 <rdfs:comment> 
  Documents that are written to by the Process (could be a database,
  an html form or other); range is left unrestricted at this level.
</rdfs:comment> 
 <rdfs:domain rdf:resource="#Process"/>
</rdf:Property>


<!-- Optional Properties that relate to the start, end, and duration
of a process.  These are a minimal set, defined in terms of the time
ontology in the accompanying spec. document. -->

<rdf:Property rdf:ID="atTime">
 <rdfs:comment> Time of an instantaneous Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Instant"/>
</rdf:Property>

<rdf:Property rdf:ID="startTime">   
 <rdfs:comment> Start time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Instant"/> 
</rdf:Property>

<rdf:Property rdf:ID="endTime">
 <rdfs:comment> End time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Instant"/>
</rdf:Property>

<rdf:Property rdf:ID="during">
 <rdfs:comment> Event/Process is during Interval, the exact time 
                interval over which the event occurs 
 </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Interval"/>
</rdf:Property>

<!-- timeouts are defined over intervals -->

<rdf:Property rdf:ID="timeout">
 <rdfs:comment> Start time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Interval"/>
</rdf:Property>

<!-- We may need absolute timeout (like calender time or timeOfDay, so
we allow for the timeoutAbsolute property -->

<rdf:Property rdf:ID="timeoutAbsolute">
 <rdfs:comment> Start time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Time.daml#Interval"/>
</rdf:Property>

<!--######################################################
    Atomic and Simple Processes
    ###################################################-->

<!-- 

Atomic processes are the basic units of implementation; that is, they
are the only processes that can actually be "called", or directly
interacted with, by a using agent.

-->

<daml:Class rdf:ID="AtomicProcess">
  <daml:subClassOf rdf:resource="#Process"/>
</daml:Class>

<!-- 

Simple processes provide an (optional) level of abstraction.  They
describe themselves in the same way as Atomic processes, but 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.

-->

<daml:Class rdf:ID="SimpleProcess">
  <daml:subClassOf rdf:resource="#Process"/>
</daml:Class>


<!-- 

A simple process that abstracts an atomic process is "realized
by" that process.

-->

<rdf:Property rdf:ID="realizedBy">
  <rdfs:domain rdf:resource="#SimpleProcess"/>
  <rdfs:range rdf:resource="#AtomicProcess"/>
  <daml:inverseOf rdf:resource="#realizes"/>
</rdf:Property>

<rdf:Property rdf:ID="realizes">
  <rdfs:domain rdf:resource="#AtomicProcess"/>
  <rdfs:range rdf:resource="#SimpleProcess"/>
  <daml:inverseOf rdf:resource="#realizedBy"/>
</rdf:Property>

<!-- 

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).

-->

<rdf:Property rdf:ID="expand">
  <rdfs:domain rdf:resource="#SimpleProcess"/>
  <rdfs:range rdf:resource="#CompositeProcess"/>
  <daml:inverseOf rdf:resource="#collapse"/>
</rdf:Property>

<rdf:Property rdf:ID="collapse">
  <rdfs:domain rdf:resource="#CompositeProcess"/>
  <rdfs:range rdf:resource="#SimpleProcess"/>
  <daml:inverseOf rdf:resource="#expand"/>
</rdf:Property>

<!--######################################################
    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 bottom out in non-composite (atomic and/or
simple) processes.

NOTE: While CompositeProcess is a Process with components, and it may
have slots for precondition and effect, there may be no easy way to
compute these values for an arbitrary process given the component
sub-processes.  The automatic computation of the values for these
attributes will not be addressed in this version.

-->

<daml:Class rdf:ID="CompositeProcess">
  <daml:intersectionOf rdf:parseType="daml:collection">
      <daml:Class rdf:about="#Process"/>
      <daml:Restriction daml:minCardinality="1">
         <daml:onProperty rdf:resource="#composedOf"/>
      </daml:Restriction>
  </daml:intersectionOf>
</daml:Class>

<rdf:Property rdf:ID="composedOf">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</rdf:Property>

<rdf:Property 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="http://www.w3.org/2000/10/XMLSchema#boolean"/>
</rdf:Property>

<daml:Class rdf:about="CompositeProcess">
  <rdfs:comment>
    A CompositeProcess can have at most one invocable property.
  </rdfs:comment>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#invocable"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

<!-- 

    ControlConstruct Class

Here, we specify a minimal set of control constructs that can be used
to specify a variety of web services. The minimal initial set are
Sequence, Split, Split + Join, Unordered, Condition, If-Then-Else,
Repeat-While, Repeat-Until.

-->

<daml:Class rdf:ID="ControlConstruct">
</daml:Class>

<rdf:Property rdf:ID="components">
 <rdfs:comment> 
  The components propery of a control construct holds
  a specific arrangement of subprocesses or control constructs. 
  The range is declared at each subclass of ControlConstruct.
 </rdfs:comment> 
 <rdfs:domain rdf:resource="#ControlConstruct"/>
</rdf:Property>

<!-- ProcessComponent Class -->

<daml:Class rdf:ID="ProcessComponent">
  <rdfs:comment>
    A ProcessComponent is either a Process or a ControlConstruct.    
  </rdfs:comment>
  <daml:unionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#Process"/>
    <daml:Class rdf:about="#ControlConstruct"/>
  </daml:unionOf>
</daml:Class>

<rdf:Property rdf:ID="currentProcessComponent">
 <rdfs:comment> 
   Attribute to keep a pointer to the current process component.
 </rdfs:comment> 
 <rdfs:domain rdf:resource="#ControlConstruct"/>
 <rdfs:range rdf:resource="#ProcessComponent"/>
</rdf:Property>

<rdf:Property rdf:ID="nextProcessComponent">
 <rdfs:comment> 
   Attribute to keep a pointer to the next process component.
 </rdfs:comment> 
 <rdfs:domain rdf:resource="#ControlConstruct"/>
 <rdfs:range rdf:resource="#ProcessComponent"/>
</rdf:Property>

<daml:Class rdf:about="ControlConstruct">
  <rdfs:comment>
    A ControlConstruct can have at most one currentProcessComponent and
    one nextProcessComponent property.
  </rdfs:comment>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#currentProcessComponent"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#nextProcessComponent"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

<!-- Collections of Process Components -->

<daml:Class rdf:ID="ProcessComponentBag">
<rdfs:comment> A multiset of ProcessComponents </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#List"/>
  <rdfs:subClassOf>
   <daml:Restriction>
    <daml:onProperty rdf:resource="http://www.daml.org/2001/03/daml+oil#item"/>
    <daml:toClass rdf:resource="#Process"/>
   </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

<!-- 

Daml does not make any distinction between bags and lists.  We
redefine the ProcessComponentList class, rather than use sameClassAs,
so as to make that distinction.

-->

<daml:Class rdf:ID="ProcessComponentList">
<rdfs:comment> A list of ProcessComponents </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#List"/>
  <rdfs:subClassOf>
   <daml:Restriction>
    <daml:onProperty rdf:resource="http://www.daml.org/2001/03/daml+oil#item"/>
      <daml:toClass rdf:resource="#Process"/>
   </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

<!-- 
The various control constructs that can be used for specfifying
and composing processes. The minimal initial set are Sequence, Split,
Fork + Join, Unordered, Condition, If-Then-Else,Iterate, Repeat-While
and Repeat-Until 
-->

<!-- The sequence class.  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 paramaters 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.  
-->

<daml:Class rdf:ID="Sequence">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentList"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<!-- Split.  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 fork or
Parallel, which we define using the sameClassAs relation.  -->

<daml:Class rdf:ID="Split">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<daml:Class rdf:ID="Concurrent">
  <daml:sameClassAs rdf:resource="#Split"/>
</daml:Class>

<daml:Class rdf:ID="Parallel">
  <daml:sameClassAs rdf:resource="#Split"/>
</daml:Class>

<!-- 
Split and Join.  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)
-->

<daml:Class rdf:ID="Split-Join">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<daml:Class rdf:ID="Fork-join">
  <daml:sameClassAs rdf:resource="#Split-Join"/>
</daml:Class>

<daml:Class rdf:ID="Concurrent-Sync">
  <daml:sameClassAs rdf:resource="#Split-Join"/>
</daml:Class>

<daml:Class rdf:ID="Parallel-Sync">
  <daml:sameClassAs rdf:resource="#Split-Join"/>
</daml:Class>

<!-- end Split + Join  -->

<!-- Unordered.  Here a bag of processes can be executed in any
order. No further constraints are specified.  -->

<daml:Class rdf:ID="Unordered">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<daml:Class rdf:ID="Any-Order">
  <daml:sameClassAs rdf:resource="#Unordered"/>
</daml:Class>

<!-- end Unordered -->

<!-- Choice
Choice is the selection among a bag of Processes.
The choose property, takes a choice bag and returns 
a chosen bag. The cardinality of the bag can be specified
through a restriction to get choose(n) (0<n<=|bag|).
-->

<daml:Class rdf:ID="Choice">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<!-- 
note given Chosen and ChooseFrom, we can define both a control
operator such as sequence or unordered (ex. choose and do chosen in
sequence, or choose and do chosen in parallel) as well as a class that
restricts the size of the Process Bag that corresponds to the
"components" of the chosen and chooseFrom subprocesses using
cardinality, mincardinality, maxcardinality to get choose at least n
from m, choose n from m, and choose at most n from m, etc.  
These extensions are left as an exercises to the reader :)
-->

<rdf:Property rdf:ID="chooseFrom">
   <rdfs:domain rdf:resource="#Choice"/>
   <rdfs:range rdf:resource ="#ProcessComponentBag"/>
</rdf:Property>

<rdf:Property rdf:ID="chosen">
   <rdfs:domain rdf:resource="#Choice"/>
   <rdfs:range rdf:resource ="#Process"/>
</rdf:Property>

<!-- This version does not distinguish choice from alternative -->

<daml:Class rdf:ID="Alternative">
  <daml:sameClassAs rdf:resource="#Choice"/>
</daml:Class>

<!-- end choice -->

<!-- Conditions are simple processes that have a relation whose domain
is a process and whose range is a binary value. Usually correspond to
test actions, but may be world states, resource levels, timeouts or
other things affecting the evolution of processes. Could be subtyped
from a test process.. -->

<daml:Class rdf:ID="Condition">
  <rdfs:subClassOf rdf:resource="#Process"/>
</daml:Class>

<!--Condition Value is an output of the condition test process.
The output value could be true or false, depending on the
result of the test-->

<rdf:Property rdf:ID="conditionValue">
  <rdfs:subPropertyOf rdf:resource="#output"/>
   <rdfs:domain rdf:resource="#Condition"/>
   <rdfs:range  rdf:resource ="#Value"/>
</rdf:Property>

<!-- 
For now, we make Value a boolean, may need to
change to be more general, with one possible subclassing
scheme as a boolean
-->

<daml:Class rdf:ID="Value">
  <daml:oneOf rdf:parseType="daml:collection">
    <Value rdf:ID="True"/>
    <Value rdf:ID="False"/>
  </daml:oneOf>
</daml:Class>

<!-- end condition Class -->

<!-- IF then Else Class is a process that consists of a condition, a
then and an else process-->

<daml:Class rdf:ID="If-Then-Else">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<rdf:Property 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="#Condition"/>
</rdf:Property>

<rdf:Property rdf:ID="then">
  <rdfs:domain rdf:resource="#If-Then-Else"/>
  <rdfs:range rdf:resource="#Process"/>
</rdf:Property>

<rdf:Property rdf:ID="else">
  <rdfs:domain rdf:resource="#If-Then-Else"/>
  <rdfs:range rdf:resource="#Process"/> 
</rdf:Property>

<!-- 

Iterate is a composite process whose currentProcessComponent property
has the same value as its nextProcessComponent property.  Thus the
iterate process never terminates. The termination of maintainence
condition could be specified with a whileCondition or an
untilCondition as below.

-->

<daml:Class rdf:ID="Iterate">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <daml:Class rdf:about="#ControlConstruct"/>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessComponentBag"/>
   </daml:Restriction>
   <daml:Restriction>
    <daml:onProperty rdf:resource="#nextProcessComponent"/>
    <daml:samePropertyAs rdf:resource="#currentProcessComponent"/>
   </daml:Restriction>
 </daml:intersectionOf>
</daml:Class>

<daml:Class rdf:ID="Repeat">
 <daml:sameClassAs rdf:resource="#Iterate"/>
</daml:Class>

<!-- 
The Repeat-While class specializes the ControlConstruct class
where the with properties "whileCondition" (range of type Condition)
and ``whileProcess'' (range of type Reapeat).  No committments are
made about whether this is aysnchronous (w/o priortized interrupts) or
synchronous (with specific polling/busy-wait strategies), etc.  This
is left for the particular execution model to specify.
-->

<rdf:Property rdf:ID="whileCondition">
  <rdfs:domain rdf:resource="#Repeat-While"/>
  <rdfs:range rdf:resource="#Condition"/>
</rdf:Property>

<rdf:Property rdf:ID="whileProcess">
  <rdfs:domain rdf:resource="#Repeat-While"/>
  <rdfs:range rdf:resource="#Process"/>
</rdf:Property>

<daml:Class rdf:ID="Repeat-While">
 <rdfs:comment> The repeat while process</rdfs:comment> 
  <rdfs:subClassOf rdf:resource="#Process"/>
</daml:Class>

<!-- 
The Repeat-Until class specializes the ControlConstruct class
where the with properties "untilCondition" (range of type Condition)
and ``untilProcess'' (range of type Reapeat).  No committments are
made about whether this is aysnchronous (w/o priortized interrupts) or
synchronous (with specific polling/busy-wait strategies), etc.  This
is left for the particular execution model to specify.  
-->

<rdf:Property rdf:ID="untilCondition">
  <rdfs:domain rdf:resource="#Repeat-Until"/>
  <rdfs:range rdf:resource="#Condition"/>
</rdf:Property>

<rdf:Property rdf:ID="untilProcess">
  <rdfs:domain rdf:resource="#Repeat-Until"/>
  <rdfs:range rdf:resource="#Process"/>
</rdf:Property>


<daml:Class rdf:ID="Repeat-Until">
 <rdfs:comment> The repeat until process</rdfs:comment> 
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</daml:Class>

<!--######################################################
    Process Control
    ###################################################-->

<!-- 
Minimal Support for Process Control. We expect the ontology
below to grow significantly to support process control and
exectution monitoring.

-->

<rdf:Property rdf:ID="currentStatus">
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="#ProcessControlStatus"/>
</rdf:Property>

<daml:Class rdf:ID="ProcessControlStatus">
  <daml:oneOf rdf:parseType="daml:collection">
    <daml:Thing rdf:ID="Ready"/>
    <daml:Thing rdf:ID="Ongoing"/>
    <daml:Thing rdf:ID="Suspended"/>
    <daml:Thing rdf:ID="Aborted"/>
    <daml:Thing rdf:ID="Canceled"/>
    <daml:Thing rdf:ID="Completed"/>
  </daml:oneOf>
</daml:Class>


</rdf:RDF>