<?xml version='1.0' encoding='ISO-8859-1'?>
<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.daml#"
  xmlns      = "http://www.daml.org/services/daml-s/2001/10/Process.daml#"
>

<daml:Ontology rdf:about="">
  <daml:versionInfo>
    $Id: Process.daml,v 1.19 2002/06/04 06:04:50 martin Exp $
  </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>

<!--######################################################
    Preliminaries
    ######################################################-->

<daml:Class rdf:ID="Condition">
  <rdfs:comment>
    This is a "place-holder" for now, which awaits further work from
    the DAML/OIL community.  An instance of Condition is a logical
    formula that evaluates to true or false.  Eventually we expect
    this to be defined elsewhere, as part of a DAML+OIL extension allowing
    for logical expressions.
  </rdfs:comment>
</daml:Class>

<daml:Class rdf:ID="ProcessClass">
  <rdfs:comment>
    This is the power set of Process (defined below); that is, the set
    of all subsets of Process.  This class is needed as the range
    of certain properties.  It's placed in "preliminaries" because of
    the expectation that a better way of declaring these ranges may be
    developed.
  </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/> 
</daml:Class>

<!--######################################################
    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 also the introductory comments to Service.daml.  
  </rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://www.daml.org/services/daml-s/2001/10/Service#ServiceModel"/> 
</daml:Class>

<daml:ObjectProperty rdf:ID="hasProcess">
  <rdfs:comment>
    It is important to understand that DAML-S conceptualizes a specific process
    as a *class*, each of whose instances is a particular use/invocation of the
    process.  Thus, each specific process (such as BuyBook in Congo.daml) is
    a *subclass*, rather than an instance, of Process.  This is why the range
    of hasProcess is specified as ProcessClass (which is the class of
    all subclasses of Process).
    In the case of a composite process, indicates the top-level process class.
  </rdfs:comment>
  <rdfs:domain rdf:resource="#ProcessModel"/>
  <rdfs:range rdf:resource="#ProcessClass"/>
</daml:ObjectProperty>

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

<daml:ObjectProperty rdf:ID="hasControlModel">
  <rdfs:domain rdf:resource="#ProcessModel"/>
  <rdfs:range rdf:resource="#ProcessControlModel"/>
</daml:ObjectProperty>

<daml:Class rdf:about="#ProcessModel">
  <rdfs:comment>
    A ProcessModel can have at most one Process and one ProcessControlModel.
  </rdfs:comment>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#hasProcess"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#hasControlModel"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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
(conditional) effects.  Input, (conditional) 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.  

Processes can also be at an instant (atTime) or during an interval
(during).

-->

<daml:Property rdf:ID="name">
  <rdfs:domain rdf:resource="#Process"/>
  <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</daml: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) 
-->

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

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

<!-- Effect is a property of process. The top level ontology doesn't
restrict them at all. An effect has the range ConditionalEffect.
Processes will have conditional effects.  For example, if the book is
in stock, it will be purchased after executing the buy-book process.
In the trivial case, the condition is "true" and the effect
unconditionally holds.
 -->

<daml:ObjectProperty rdf:ID="effect">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range  rdf:resource="#ConditionalEffect"/>
</daml:ObjectProperty>

<daml:Class rdf:ID="ConditionalEffect">
  <daml:subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml:Class>

<!-- ConditionalEffect is a thing that consists of a condition, and an
effect thing.  It has two properties, the condtion (ceCondition) of
the conditional effect, and the effect (ceEffect) of the conditional
effect.  In the buy-book example ceCondition would be "inStock(book)"
and the ceEffect would be "purchased(book)".
 -->

<daml:Property rdf:ID="ceCondition">
 <rdfs:comment> The condition of a conditional effect. </rdfs:comment>
  <rdfs:domain rdf:resource="#ConditionalEffect"/>
  <rdfs:range rdf:resource="#Condition"/>
</daml:Property>

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

<!-- We provide three common subtypes of parameters in the top level
ontology.  The types are input, conditionalOutput, 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.
 -->

<daml:Property rdf:ID="input"> 
  <rdfs:subPropertyOf rdf:resource="#parameter"/> 
  <daml:range rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml: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).  Each output may
(optionally) be associated with a Condition.

-->

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

<!-- ConditionalOutput is a thing that consists of a condition, and an
ouput thing. -->

<daml:Class rdf:ID="ConditionalOutput">
  <daml:subClassOf rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml:Class>

<daml:Property rdf:ID="coCondition">
 <rdfs:comment> The condition of a conditional output </rdfs:comment>
  <rdfs:domain rdf:resource="#ConditionalOutput"/>
  <rdfs:range rdf:resource="#Condition"/>
</daml:Property>

<daml:Property rdf:ID="coOutput">
  <rdfs:domain rdf:resource="#ConditionalOutput"/>
  <rdfs:range rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml: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.  -->

<daml:Property rdf:ID="participant">  
  <rdfs:subPropertyOf rdf:resource="#parameter"/>
</daml: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. 
 -->

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

<daml: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"/>
</daml:Property>

<daml: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"/>
</daml:Property>

<daml: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"/>
</daml: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. -->

<daml:ObjectProperty 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"/>
</daml:ObjectProperty>

<daml:ObjectProperty 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"/> 
</daml:ObjectProperty>

<daml:ObjectProperty 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"/>
</daml:ObjectProperty>

<daml:ObjectProperty 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"/>
</daml:ObjectProperty>

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

<daml:ObjectProperty 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"/>
</daml:ObjectProperty>

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

<daml:ObjectProperty 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"/>
</daml: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.  An atomic process is required
to be associated with a Grounding (but Groundings are not covered in
the current DAML-S release).  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).

-->

<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, unlike
atomics, they give additional characterization of how
they work, in terms of other processes (using the "expand" and
"realizedBy" properties).  They may or may not be 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.

-->

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

<daml:ObjectProperty rdf:ID="realizes">
  <rdfs:domain rdf:resource="#AtomicProcess"/>
  <rdfs:range rdf:resource="#SimpleProcess"/>
  <daml:inverseOf rdf:resource="#realizedBy"/>
</daml: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).

-->

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

<daml:ObjectProperty rdf:ID="collapse">
  <rdfs:domain rdf:resource="#CompositeProcess"/>
  <rdfs:range rdf:resource="#SimpleProcess"/>
  <daml:inverseOf rdf:resource="#expand"/>
</daml: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 bottom out in non-composite (atomic and/or
simple) processes.

-->

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

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

<daml: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"/>
</daml:Property>

<daml:Property 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
    DAML+OIL.
  </rdfs:comment>
  <rdfs:domain rdf:resource="#CompositeProcess"/>
  <rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml:Property>

<daml:Property 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="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml:Property>

<daml:Property 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="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml:Property>

<daml:Property 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.
  </rdfs:comment>
  <rdfs:domain rdf:resource="#CompositeProcess"/>
  <rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Thing"/>
</daml: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>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#computedInput"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#computedOutput"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#computedEffect"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#computedPrecondition"/>
    </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>

<daml: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"/>
</daml: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>

<daml: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"/>
</daml:Property>

<daml: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"/>
</daml: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="#ProcessComponent"/>
   </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="#ProcessComponent"/>
   </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 :)
-->

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

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

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

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

<!-- end choice -->

<!-- TestConditions are 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="TestCondition">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</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-->

<daml:ObjectProperty rdf:ID="conditionValue">
  <rdfs:subPropertyOf rdf:resource="#output"/>
   <rdfs:domain rdf:resource="#TestCondition"/>
   <rdfs:range  rdf:resource ="#TestValue"/>
</daml:ObjectProperty>

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

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

<!-- end condition Class -->

<!-- IF then Else Class is a ControlConstruct 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>

<daml: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"/>
</daml:Property>

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

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

<!-- 

Iterate is a ControlConstruct whose currentProcessComponent property
has the same value as its nextProcessComponent property.  Thus iterate
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 Repeat).  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.
-->

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

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

<daml:Class rdf:ID="Repeat-While">
 <rdfs:comment> The repeat while construct</rdfs:comment> 
 <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</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.  
-->

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

<daml:Property rdf:ID="untilProcess">
  <rdfs:domain rdf:resource="#Repeat-Until"/>
  <rdfs:range rdf:resource="#ProcessComponent"/>
</daml: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.

-->

<daml:Property rdf:ID="currentStatus">
  <rdfs:domain rdf:resource="#ProcessComponent"/>
  <rdfs:range rdf:resource="#ProcessControlStatus"/>
</daml: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>






