<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:dex ="http://www.daml.org/2001/03/daml+oil-ex#"
  xmlns:exd ="http://www.daml.org/2001/03/daml+oil-ex-dt#"
  xmlns:service = "http://www.daml.org/services/daml-s/2001/05/Service#"
  xmlns      = "http://www.daml.org/services/daml-s/2001/05/Process#"
>

<daml:Ontology rdf:about="">
  <daml:versionInfo>
    $Id: Process.daml,v 1.4 2001/07/15 06:24:33 martin Exp $
  </daml:versionInfo>
  <rdfs:comment>
    Upper-level DAML ontology for Processes; first cut; incomplete. Created
    by Srini Narayanan (srini@ai.sri.com).
  </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/05/Service.daml"/>
</daml:Ontology>

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

<rdfs:Class rdf:ID="ProcessModel">
  <rdfs:comment>
    A ProcessModel characterizes how a ProcessService works.  
    See introductory comments to Service.daml.  
  </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/services/daml-s/2001/05/Service#ServiceModel"/> 
</rdfs:Class>

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

<rdfs:Class rdf:ID="ProcessControlModel">
  <rdfs:comment>
    A ProcessControlModel is used to monitor and control execution of 
    a Process. See introductory comments to Service.daml.  
  </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/services/daml-s/2001/05/Service#ServiceModel"/> 
</rdfs:Class>

<!-- Basic Process Class -->

<rdfs:Class rdf:ID="Process">
  <rdfs:comment> A simple process class </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/services/daml-s/2001/05/Service#ServiceModel"/> 
</rdfs:Class>

<!--

Processes have a name, parameter, precondition, and effect.  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>


<!--
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 events 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 events 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 events 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>

<rdf:Property rdf:ID="conditionalEffect">
<rdfs:subPropertyOf rdf:resource="#effect"/> 
</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 are properties of
events. The top level ontology doesn't restrict them at all. An input
can be any kind of daml object (Thing).  Specific events 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 outputs are properties of
events. The top level ontology doesn't restrict them at all. An output
can be any kind of daml object (Thing).  Specific events 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 outputs are properties
of events. The top level ontology doesn't restrict them at all. A
participant can be any kind of daml object (Thing).  Specific events
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 an 
events with duration and the time of an instantaneous event.
These are a minimal set, defined in 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>

<!-- Collections of Processes -->

<rdfs:Class rdf:ID="ProcessBag">
<rdfs:comment> A multiset of Events </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>
</rdfs:Class>

<!-- Daml does not make any distinction between bags and lists. Though
one might want to subclass and make the distinction. In any case,
I have redefined the processList class, rather than use sameClassAs
to support efforts that want to make the distinction.
-->


<rdfs:Class rdf:ID="ProcessList">
<rdfs:comment> A multiset of Events </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>
</rdfs:Class>


<!-- 
CompositeProcesses are complex events that have additional properties
with respect to the ordering and conditional execution of individual
events. The attempt here is to come up with a minimal set of process
classes that can be specialized 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.

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="#components"/>
      </daml:Restriction>
  </daml:intersectionOf>
</daml:Class>

<rdf:Property rdf:ID="components">
 <rdfs:comment> 
  The components propery of a composite process holds
  a specific arrangement of subprocesses. 
 </rdfs:comment> 
 <rdfs:domain rdf:resource="#CompositeProcess"/>
</rdf:Property>

<rdf:Property rdf:ID="currentProcess">
 <rdfs:comment> 
   Attribute to keep a pointer to the current process 
 </rdfs:comment> 
 <rdfs:range rdf:resource="#Process"/>
</rdf:Property>

<rdf:Property rdf:ID="nextProcess">
 <rdfs:comment> 
   Attribute to keep a pointer to the next process 
 </rdfs:comment> 
<rdfs:range rdf:resource="#Process"/>
</rdf:Property>

<!-- 

There are two fundamental relations between 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 an atomic process (zoom-out) 

-->

<rdf:Property rdf:ID="expand">
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="#CompositeProcess"/>
</rdf:Property>

<rdf:Property rdf:ID="collapse">
  <rdfs:domain rdf:resource="#CompositeProcess"/>
  <rdfs:range rdf:resource="#Process"/>
</rdf:Property>


<!-- 
The various process subclasses 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.  
-->

<rdfs:Class rdf:ID="Sequence">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <rdfs:Class> rdf:about="#CompositeProcess" </rdfs:Class>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessList"/>
   </daml:Restriction>
 </daml:intersectionOf>
</rdfs: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.  -->

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

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

<rdfs:Class rdf:ID="Parallel">
  <daml:sameClassAs rdf:resource="#Split"/>
</rdfs: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)
-->

<rdfs:Class rdf:ID="Split+Join">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <rdfs:Class> rdf:about ="#CompositeProcess" </rdfs:Class>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</rdfs:Class>

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

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

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

<!-- end Split + Join  -->

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

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

<rdfs:Class rdf:ID="Any-Order">
  <daml:sameClassAs rdf:resource="#Unordered"/>
</rdfs: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|).
-->

<rdfs:Class rdf:ID="Choice">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <rdfs:Class> rdf:about ="#CompositeProcess" </rdfs:Class>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</rdfs: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 ="#CompositeProcess"/>
</rdf:Property>

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

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

<rdfs:Class rdf:ID="Alternative">
  <daml:sameClassAs rdf:resource="#Choice"/>
</rdfs: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.. -->

<rdfs:Class rdf:ID="Condition">
  <rdfs:subClassOf rdf:resource="#Process"/>
</rdfs: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
-->

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

<!-- end condition Class -->

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

<rdfs:Class rdf:ID="If-Then-Else">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <rdfs:Class> rdf:about ="#CompositeProcess" </rdfs:Class>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessBag"/>
   </daml:Restriction>
 </daml:intersectionOf>
</rdfs: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="#CompositeProcess"/>
</rdf:Property>

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

<!-- NOTE: Is this legal? 

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

-->

<rdfs:Class rdf:ID="Iterate">
 <daml:intersectionOf rdf:parseType="daml:collection">
   <rdfs:Class> rdf:about ="#CompositeProcess" </rdfs:Class>
   <daml:Restriction>
     <daml:onProperty rdf:resource="#components"/>
     <daml:toClass rdf:resource="#ProcessBag"/>
   </daml:Restriction>
   <daml:Restriction>
    <daml:onProperty rdf:resource="#nextProcess"/>
    <daml:samePropertyAs rdf:resource="#currentProcess"/>
   </daml:Restriction>
 </daml:intersectionOf>
</rdfs:Class>

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

<!-- 
The Repeat-While class specializes the CompositeProcess 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="#CompositeProcess"/>
</rdf:Property>

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

<!-- 
The Repeat-Until class specializes the CompositeProcess 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="#CompositeProcess"/>
</rdf:Property>


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

<!-- 
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>


<rdfs: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>
</rdfs:Class>


</rdf:RDF>