Process.owl
type: Ontology
version info: $Id: Process.owl,v 1.139 2005/05/18 21:50:34 martin Exp $
comment: Upper-level OWL ontology for Processes. Part of the DAML-S/OWL-S effort; see http://www.daml.org/services/owl-s/.
imports: Expression.owl
imports: Service.owl
imports: ObjectList.owl

Parameter
type: Class
subclass of: Restriction
  on property: parameterType
  cardinality: 1
comment: This is the simplest way to relate parameters to SWRL (and DRS) variables.
subclass of: Variable

parameterValue
type: DatatypeProperty
comment: If an Input parameter has a constant value, or (as in the case of Output) is a description in terms of of some other process parameters, then supply it here. Note that it must be interpreted after reading it as an XMLLiteral. In future, the interpretation of this literal may be extended to allow more flexibility, such as functional expressions.
domain: Parameter
range: XMLLiteral

Local
type: Class
comment: A Local parameter is a variable other than an input that is bound in a precondition of an Atomic Process for use in a result condition or effect expression (or output expression) THEY CANNOT BE USED IN COMPOSITE PROCESSES AT ALL. This avoids problems associated with state sharing among asynchronously related sub processes.
subclass of: Parameter

Result
type: Class

hasResultVar
type: ObjectProperty
domain: Result
range: ResultVar

inCondition
type: ObjectProperty
domain: Result
range: Condition

hasEffect
type: ObjectProperty
domain: Result
range: Expression

withOutput
type: ObjectProperty
domain: Result
range: OutputBinding

Binding
type: Class
subclass of: Restriction
  on property: toParam
  cardinality: 1
subclass of: Restriction
  on property: valueSource
  max cardinality: 1
subclass of: Restriction
  on property: valueSpecifier
  max cardinality: 1
subclass of: Restriction
  on property: valueData
  max cardinality: 1

valueSpecifier
type: DatatypeProperty
domain: Binding

valueForm
type: DatatypeProperty
comment: valueForm is to be used to specify an pseudo-OWL description that is legal OWL except that variables (including process parameters) and ValueOf forms can appear as the object of properties where those things violate the range of the property. The intent is that this be interpreted as a pattern indicating the actual value of the binding after the variables have been substituted for. A similar notation is used with valueFunction to indicate the application of a locally (to the client) available function to convert data (specified by variables or ValueOf) to a correct form.
sub property of: valueSpecifier
domain: Binding
range: XMLLiteral

valueFunction
type: DatatypeProperty
sub property of: valueSpecifier
domain: Binding
range: XMLLiteral

valueSource
type: ObjectProperty
comment: This is the simplest kind of data flow
domain: Binding
range: ValueOf

valueType
type: DatatypeProperty
sub property of: valueSpecifier
domain: Binding
range: anyURI

valueData
type: DatatypeProperty
comment: valueData is for specifying constant (XML) data to be bound to a parameter. Ideally, the valueData property would also be a subproperty of valueSpecifier so that it would be one of the three possible properties used to specify a value for a Binding. But as we cannot do that, we treat it separately, but note that if it is used, the others should not be. For now, its range is any XML datatype.
domain: Binding

ValueOf
type: Class
comment: Within a value form, or when using valueSource, references to parameters of other processes require a tuple of (perform-ref, param-ref, which we represent with ValueOf
subclass of: Restriction
  on property: theVar
  cardinality: 1
comment: We allow for the possibility that another parameter of the same process is referenced, in which case this property is optional (hence maxCard)
subclass of: Restriction
  on property: fromProcess
  max cardinality: 1

OutputBinding
type: Class
intersection of: Binding
intersection of: Restriction
  on property: toParam
  all values from: Output
comment: The subClassOf element is redundant, but we keep it because it is helpful to some tools
subclass of: Binding

InputBinding
type: Class
intersection of: Binding
intersection of: Restriction
  on property: toParam
  all values from: Input
comment: The subClassOf element is redundant, but we keep it because it is helpful to some tools
subclass of: Binding

Process
type: Class
comment: The most general class of processes
subclass of: ServiceModel
union of: AtomicProcess
union of: SimpleProcess
union of: CompositeProcess
comment: A Process can have at most one name, but names need not be unique.
subclass of: Restriction
  on property: name
  max cardinality: 1

CompositeProcess
type: Class
subclass of: Process
disjoint with: AtomicProcess
disjoint with: SimpleProcess
comment: A CompositeProcess must have exactly 1 composedOf property.
intersection of: Process
intersection of: Restriction
  on property: composedOf
  cardinality: 1
comment: A CompositeProcess can have at most one invocable property. Similarly for computedInput, computedOutput, computedEffect, and computedPrecondition.
subclass of: Restriction
  on property: invocable
  max cardinality: 1
subclass of: Restriction
  on property: computedInput
  max cardinality: 1
subclass of: Restriction
  on property: computedOutput
  max cardinality: 1
subclass of: Restriction
  on property: computedEffect
  max cardinality: 1
subclass of: Restriction
  on property: computedPrecondition
  max cardinality: 1

hasResult
type: ObjectProperty
domain: Process
range: Result

Perform
type: Class
comment: The PERFORM construct is how one references a process in a composite process. This is analogous to a function call in a program body. The inputs to the PERFORM are described using the hasDataFrom property.
subclass of: ControlConstruct
subclass of: Restriction
  on property: process
  cardinality: 1

hasDataFrom
type: ObjectProperty
comment: This property has as range a Binding object, which may either indicate constants or values that are derived from the parameters (typically outputs) of other performs in the SAME COMPOSITE PROCESS.
domain: Perform
range: Binding

TheParentPerform
type: Perform
comment: A special-purpose object, used to refer, at runtime, to the execution instance of the enclosing composite process definition.

ThisPerform
type: Perform
comment: A special-purpose object, used to refer, at runtime, to the execution instance of the enclosing atomic process definition.

invocable
type: DatatypeProperty
comment: Invocable is a flag that tells whether the CompositeProcess bottoms out in atomic processes. (If so, it is "invocable".)
domain: CompositeProcess
range: boolean

computedInput
type: ObjectProperty
comment: A computed input is a single expression that characterizes the inputs required by a composite process, and the conditions under which they are required. This expression may, if needed, tie together 2 or more inputs; for example, "either a credit card number, or a bank account number must be given", or "if product id starts with 'M', no shipping method need be given". Additionally, this expression may refer to things other than inputs; for example; "if user's credit rating is 'excellent' or better, Social Security number is not required", or "if product weight is less than 1 lb., no shipping myth did need be given". A "computed" input is so named because it is meant to be computed automatically by some tool, by inspecting the makeup of the composite process. The language used to represent a computed input is not specified here, and will be the subject of future work; hence, the use of Thing as range. It will require expressiveness greater than that of OWL.
domain: CompositeProcess
range: Expression

computedOutput
type: ObjectProperty
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.
domain: CompositeProcess
range: Expression

computedPrecondition
type: ObjectProperty
comment: A computed precondition is a single expression that characterizes the preconditions of a composite process, based on the preconditions of its sub processes.
domain: CompositeProcess
range: Expression

computedEffect
type: ObjectProperty
comment: A computed effect is a single expression that characterizes the effects of a composite process, based on the effects of its sub processes. This is not well defined for conditional effects at present.
domain: CompositeProcess
range: Expression

ControlConstruct
type: Class
comment: A ControlConstruct can have at most one instance of timeout.
subclass of: Restriction
  max cardinality: 1
  on property: timeout

components
type: ObjectProperty
comment: The components propery of selected control construct subclasses holds a specific arrangement of subprocesses or control constructs. The range is declared at each relevant subclass of ControlConstruct.
domain: Class
  union of: Sequence
  union of: Split
  union of: Split-Join
  union of: Any-Order
  union of: Choice

Sequence
type: Class
comment: Sequence is defined as having a list of component processes that specify the body. The Preconditions, parameters and effects of the sequence are not defined in the minimal version. An obvious extension would be to define the effect of the sequence to be the union of the effect of the individual members, and the parameters of the sequence to be the union of the parameters of individual members. However, some implementations may decide to use the last event's effects as the effect of the sequence, etc.
subclass of: ControlConstruct
subclass of: Restriction
  on property: components
  all values from: ControlConstructList
subclass of: Restriction
  on property: components
  cardinality: 1

Split
type: Class
comment: Here the process consists of concurrent execution of a bunch of sub-processes. No further specification about waiting, synchronization, etc. Similar to other ontologies' use of "Concurrent" or "Parallel".
subclass of: ControlConstruct
subclass of: Restriction
  on property: components
  all values from: ControlConstructBag
subclass of: Restriction
  on property: components
  cardinality: 1

Split-Join
type: Class
comment: Here the process consists of concurrent execution of a bunch of sub-processes. with barrier synchroniztion. With Split and Split and Join, we can define processes which have partial synchronization (ex. split all and join some subset).
subclass of: ControlConstruct
subclass of: Restriction
  on property: components
  all values from: ControlConstructBag

Any-Order
type: Class
comment: Allows the process components (specified as a bag) to be executed in some unspecified order but not concurrently. Execution and completion of all components is required. The execution of processes in an "Any-Order" construct cannot overlap, i.e.atomic processes cannot be executed concurrently and composite processes cannot be interleaved.
subclass of: ControlConstruct
subclass of: Restriction
  on property: components
  all values from: ControlConstructBag
subclass of: Restriction
  on property: components
  cardinality: 1

Choice
type: Class
comment: Choice calls for the execution of a single control construct from a given bag of control constructs (given by the components property). Any of the given control constructs may be chosen for execution.
subclass of: ControlConstruct
subclass of: Restriction
  on property: components
  all values from: ControlConstructBag
subclass of: Restriction
  on property: components
  cardinality: 1

ControlConstructBag
type: Class
comment: A multiset of control constructs
subclass of: List
subclass of: Restriction
  on property: first
  all values from: ControlConstruct
subclass of: Restriction
  on property: rest
  all values from: ControlConstructBag

ControlConstructList
type: Class
comment: OWL does not make any distinction between bags and lists. We redefine the ControlConstructList class, rather than use equivalentClass, so as to make that distinction.
subclass of: List
subclass of: Restriction
  on property: first
  all values from: ControlConstruct
subclass of: Restriction
  on property: rest
  all values from: ControlConstructList

If-Then-Else
type: Class
comment: If-Then-Else Class is a ControlConstruct that consists of a Condition, a then and an optional else process.
subclass of: ControlConstruct
subclass of: Restriction
  on property: ifCondition
  cardinality: 1
subclass of: Restriction
  on property: then
  cardinality: 1
subclass of: Restriction
  on property: else
  max cardinality: 1

ifCondition
type: ObjectProperty
comment: The if condition of an if-then-else
domain: If-Then-Else
range: Condition

Iterate
type: Class
comment: Iterate is an "abstract" class, in the sense that it's not detailed enough to be instantiated in a process model. It's here to serve as the common superclass of Repeat-While, Repeat-Until, and potentially other specific iteration constructs that might be needed in the future.
subclass of: ControlConstruct

Repeat-While
type: Class
comment: The Repeat-While class specializes the ControlConstruct class where the with properties "whileCondition" (range of type Condition) and ``whileProcess'' (range of type Repeat). Repeat-While tests for the condition, exits if it is false and does the operation if the condition is true, then loops.
subclass of: Iterate
subclass of: Restriction
  on property: whileCondition
  cardinality: 1
subclass of: Restriction
  on property: whileProcess
  cardinality: 1

Repeat-Until
type: Class
comment: The Repeat-Until class specializes the ControlConstruct class where the with properties "untilCondition" (range of type Condition) and "untilProcess" (range of type Reapeat). Repeat-Until does the operation, tests for the condition, exits if it is true, and otherwise loops.
subclass of: Iterate
subclass of: Restriction
  on property: untilCondition
  cardinality: 1
subclass of: Restriction
  on property: untilProcess
  cardinality: 1

timeout
type: ObjectProperty
comment: Interval of time allowed for completion of the process component (relative to the start of process component execution).
domain: ControlConstruct
range: IntervalThing