<?xml version='1.0' encoding='ISO-8859-1'?>

<!DOCTYPE uridef[
  <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns">
  <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema">
  <!ENTITY daml "http://www.daml.org/2001/03/daml+oil">
  <!ENTITY xsd "http://www.w3.org/2000/10/XMLschema.xsd">
  <!ENTITY service "http://www.daml.org/services/daml-s/0.7/Service.daml">
  <!ENTITY grounding "http://www.daml.org/services/daml-s/0.7/Grounding.daml">
  <!ENTITY process "http://www.daml.org/services/daml-s/0.7/Process.daml">
  <!ENTITY DEFAULT "http://www.daml.org/services/daml-s/0.7/Process.daml">
]>

<!--
This document uses entity types as a shorthand for URIs.
For a version with unexpanded entities, try loading this source
into Internet Explorer.
  -->

<rdf:RDF
  xmlns:rdf=	"&rdf;#"
  xmlns:rdfs=	"&rdfs;#"
  xmlns:daml=	"&daml;#"
  xmlns:xsd=	 "&xsd;#"
  xmlns:service= "&service;#"
  xmlns:process= "&process;#"
  xmlns:grounding= "&process;#"
  xmlns=	"&DEFAULT;#">


<daml:Ontology rdf:about="">
  <daml:versionInfo>
    $Id: Process.daml,v 1.23 2003/03/05 00:25:11 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/time/Time.daml"/>
  <daml:imports rdf:resource="http://www.daml.org/services/daml-s/0.7/Service.daml"/>
</daml:Ontology>

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

<daml:Property rdf:ID="sameValuesAs">
  <rdfs:comment>
    -- 0.7: This is deprecated, in favor of sameValues, defined further below.
    -- The remaining comments are retained from the 0.6 release:
    This is a "place-holder" for now, which needs further work.
    The domain and range will be properties.
    "X sameValuesAs Y" is used to indicate that properties X and Y take
    the same values within a given context; that is, within an execution
    instance of some process.  This is used simply to indicate such things
    as the binding of output property X of a subprocess with input property
    Y of a subsequent subprocess, within the same parent process.
  </rdfs:comment>
</daml:Property>

<daml:Property rdf:ID="listOfInstancesOf">
  <rdfs:domain rdf:resource="&daml;#Class"/>
  <rdfs:range rdf:resource="&daml;#List"/>
  <rdfs:comment>
    The range is a list of classes.

    This property is defined similarly to DAML+OIL properties having List
    as range, such as daml:oneOf and daml:intersectionOf, and is meant
    to be used similarly, with parseType=collection.

    "Class listOfInstancesOf X Y Z" (for example) is used to indicate the class
    of lists having an instance of class X as their first member, an instance 
    of class Y as their second member, and an instance of class Z as their
    third member.

    An instance of listOfInstancesOf represents an anonymous class, as 
    explained here:
      http://www.daml.org/services/daml-s/0.7/listOfInstancesOf.html.

    Note that listOfInstancesOf is provided as "syntactic sugar"; that is, 
    it isn't required to express the intended anonymous class definition.  
    It is provided to allow for shorter, more readable expressions in process 
    definitions.

    There are some unresolved concerns about the use of this
    property, which are also explained in the HTML document.
  </rdfs:comment>
</daml:Property>

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

<!-- 

A conditional effect is an effect that only occurs when a condition is
true.  In the buy-book example ceCondition would be something like
"inStock(book)" and the ceEffect would be something like
"purchased(book)".  It is encoded by the class ConditionalEffect.
ConditionalEffect simply bundles a condition and an effect, using two
properties, the condtion (ceCondition) of the conditional effect, and
the effect (ceEffect) of the conditional effect.  

An *un*conditional effect is simply a subclass of a conditional
effect, where the condition is just the value true.

 -->

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


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

<daml:Class rdf:ID="UnConditionalEffect">
  <rdfs:comment>
    An UnConditionalEffect has no condition.
  </rdfs:comment>
  <daml:intersectionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#ConditionalEffect"/>
    <daml:Restriction daml:cardinality="0">
      <daml:onProperty rdf:resource="#ceCondition"/>
    </daml:Restriction>
  </daml:intersectionOf>
</daml:Class>


<!-- 

Similarly to ConditionalEffect, ConditionalOutput bundles 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>


<daml:Class rdf:ID="UnConditionalOutput">
  <rdfs:comment>
    An UnConditionalOutput has no condition.
  </rdfs:comment>
  <daml:intersectionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#ConditionalOutput"/>
    <daml:Restriction daml:cardinality="0">
      <daml:onProperty rdf:resource="#coCondition"/>
    </daml:Restriction>
  </daml:intersectionOf>
</daml:Class>


<!-- Power Sets -->

<daml:Class rdf:ID="ProcessPowerSet">
  <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.  
  </rdfs:comment>
  <daml:sameClassAs>
    <daml:Restriction>
      <daml:onProperty rdf:resource="&rdfs;#subClassOf"/>
      <daml:hasValue rdf:resource="#Process"/>
    </daml:Restriction>
  </daml:sameClassAs>
</daml:Class>

<daml:Class rdf:ID="AtomicProcessPowerSet">
  <rdfs:comment>
    This is the power set of AtomicProcess (defined below); that is, the set
    of all subsets of AtomicProcess.  This class is needed as the range
    of certain properties. 
  </rdfs:comment>
  <daml:sameClassAs>
    <daml:Restriction>
      <daml:onProperty rdf:resource="&rdfs;#subClassOf"/>
      <daml:hasValue rdf:resource="#AtomicProcess"/>
    </daml:Restriction>
  </daml:sameClassAs>
</daml:Class>

<!--######################################################
    Connection 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/0.7/Service.daml#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 ProcessPowerSet (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="#ProcessPowerSet"/>
</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:disjointUnionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#AtomicProcess"/>
    <daml:Class rdf:about="#SimpleProcess"/>
    <daml:Class rdf:about="#CompositeProcess"/>
  </daml:disjointUnionOf>
</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"). 

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

<!--

Parameters are properties of processes.  There are three common and
important subtypes of parameter in the top level ontology: input,
output, and participant, all of which are declared below.

Specific processes will further specialize these properties by
restricting the range appropriately using subPropertyOf.  For example,
the credit card number input 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>

<!-- 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.
An output can be conditional.  For example, in a book buying service,
the output of a LocateBook program would be different depending upon
whether the book is in stock or not. In the trivial case (no
conditions to be distinguished), the range of the output property can
be restricted to the subclass UnConditionalOutput.


-->

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

<!--

Precondition is a property of Process.  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="#Condition"/>
</daml:Property>

<!-- 

Effect is a property of process, having the range ConditionalEffect.
Processes will have conditional effects.  For example, if the book is
in stock (condition), it will be purchased (effect) after executing
the buy-book process.  In the trivial case (no conditions to be
distinguished), the range of the effect property can be restricted
to the subclass UnConditionalEffect.

 -->

<daml:Property rdf:ID="effect">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range  rdf:resource="#ConditionalEffect"/>
</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>

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

-->

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

-->

<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="expandsTo">
  <rdfs:domain rdf:resource="#SimpleProcess"/>
  <rdfs:range rdf:resource="#CompositeProcess"/>
  <daml:inverseOf rdf:resource="#collapsesTo"/>
</daml:ObjectProperty>

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

<daml:ObjectProperty rdf:ID="expand">
  <rdfs:comment>This is a deprecated usage; expandsTo is preferred.</rdfs:comment>
  <daml:samePropertyAs rdf:resource="#expandsTo"/>
</daml:ObjectProperty>

<daml:ObjectProperty rdf:ID="collapse">
  <rdfs:comment>This is a deprecated usage; collapsesTo is preferred.</rdfs:comment>
  <daml:samePropertyAs rdf:resource="#collapsesTo"/>
</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">
  <rdfs:comment>
    A CompositeProcess must have exactly 1 composedOf property.
  </rdfs:comment>
  <daml:intersectionOf rdf:parseType="daml:collection">
      <daml:Class rdf:about="#Process"/>
      <daml:Restriction daml:cardinality="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: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="http://www.w3.org/2000/10/XMLSchema#boolean"/>
</daml:DatatypeProperty>

<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. Similarly for
    computedInput, computedOutput, computedEffect, and
    computedPrecondition.
  </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>

<!-- currentProcessComponent and nextProcessComponent were properties
     defined to explicitly describe the control flow of a composite process.
     These constructs are (virtually) unused in DAML-S 0.7. 
-->     
   

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

<daml:Class rdf:ID="Sequence">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentList"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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  -->

<!-- 

Allows the process components (specified as a bag) to be executed in
some unspecified order, or concurrently.  All components must be
executed.  As with Split+Join, completion of all components is
required.  Note that, while the unordered construct itself gives no
constraints on the order of execution, nevertheless, in some cases,
there may be constraints associated with subcomponents, which must be
respected.

-->

<daml:Class rdf:ID="Unordered">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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="#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-->

<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">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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.  In the future we will constrain it to
say that its currentProcessComponent property has the same unique
range as its nextProcessComponent property, but we leave this out of
DAML-S 0.7.  Note that when we do this, iterate will never
terminate. The termination of such a loop condition could be
specified with a whileCondition or an untilCondition as below.

-->

<daml:Class rdf:ID="Iterate">
  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
  <rdfs:subClassOf>
    <daml:Restriction>
      <daml:onProperty rdf:resource="#components"/>
      <daml:toClass rdf:resource="#ProcessComponentBag"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</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.

Once currentProcessComponent and nextProcessComponent are used to
constrain Iterate, one could create Repeat-While and Repeat-Until as
sublass of Iterate.
-->

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


<!--######################################################
    Argument Bindings
    ######################################################-->

<!--

Property "sameValues" and Class "ValueOf" are used to denote that two
or more properties of (potentially, different subprocesses of) a
ProcessComponent should have the same values when the process is
instantiated.  For instance, these are used to state that the input to
one subprocess should be the output of the previous one within a
sequence, or that some output or effect of an atomic process should
make reference to values that were specified as inputs to that same
process.

-->

<rdf:Property rdf:ID="sameValues">
  <daml:domain rdf:resource="#ProcessComponent"/>
  <rdfs:comment>The range is to be a list of ValueOf.</rdfs:comment> 
  <daml:range rdf:resource="http://www.daml.org/2001/03/daml+oil#List"/>
</rdf:Property>

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

<!-- This property indicates the class (a Process) having the referenced 
     property --> 
<rdf:Property rdf:ID="atClass">
  <rdfs:domain rdf:resource="#ValueOf"/>
  <rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Class"/>
</rdf:Property>

<!-- The property (usually a parameter) whose values are 
     referred to. -->
<rdf:Property rdf:ID="theProperty">
  <rdfs:domain rdf:resource="#ValueOf"/> 
  <rdfs:range  rdf:resource="http://www.daml.org/2001/03/daml+oil#Property"/>
</rdf:Property>

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

<!-- 
Minimal Support for Process Control. We expect the ontology
below to grow significantly to support process control and
execution 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>


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

<daml:ObjectProperty rdf:ID="startTime">   
  <rdfs:comment> Start time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#ProcessComponent"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/time/Time.daml#Instant"/> 
</daml:ObjectProperty>

<daml:ObjectProperty rdf:ID="endTime">
  <rdfs:comment> End time for the Event </rdfs:comment> 
  <rdfs:domain rdf:resource="#ProcessComponent"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/time/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="#ProcessComponent"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/time/Time.daml#Interval"/>
</daml:ObjectProperty>

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

<daml:ObjectProperty rdf:ID="timeout">
  <rdfs:domain rdf:resource="#ProcessComponent"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/time/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:domain rdf:resource="#ProcessComponent"/>
  <rdfs:range rdf:resource="http://www.ai.sri.com/daml/ontologies/time/Time.daml#Interval"/>
</daml:ObjectProperty>

<daml:Class rdf:about="#ProcessComponent">
  <rdfs:comment>
    A ProcessComponent can have at most one of each of the restricted properties.
  </rdfs:comment>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#startTime"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#endTime"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#during"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#timeout"/>
    </daml:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <daml:Restriction daml:maxCardinality="1">
      <daml:onProperty rdf:resource="#timeoutAbsolute"/>
    </daml:Restriction>
  </rdfs:subClassOf>
</daml:Class>

</rdf:RDF>






