Upper-level OWL ontology for Processes. Part of the DAML-S/OWL-S effort; see http://www.daml.org/services/owl-s/.
This is the simplest way to relate parameters to SWRL (and DRS) variables.
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.
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.
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.
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.
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
We allow for the possibility that another parameter of the same process is referenced, in which case this property is optional (hence maxCard)
A Process can have at most one name, but names need not be unique.
This is a deprecated usage; expandsTo is preferred.
This is a deprecated usage; collapsesTo is preferred.
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. 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.
A special-purpose object, used to refer, at runtime, to the execution instance of the enclosing composite process definition.
A special-purpose object, used to refer, at runtime, to the execution instance of the enclosing atomic process definition.
A CompositeProcess must have exactly 1 composedOf property.
Invocable is a flag that tells whether the CompositeProcess bottoms out in atomic processes. (If so, it is "invocable".)
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.
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.
A computed precondition is a single expression that characterizes the preconditions of a composite process, based on the preconditions of its sub processes.
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.
A CompositeProcess can have at most one invocable property. Similarly for computedInput, computedOutput, computedEffect, and computedPrecondition.
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.
Deprecated as of v. 1.1. Note: the old concept ProcessComponent is no longer needed. ControlConstruct which includes Perform as a subclass should be used anywhere that ProcessComponent might have been used (which in the OWL-S 1.0 ontology was only in describing the relationship to temporal aspects)
Interval of time allowed for completion of the process component (relative to the start of process component execution).
A ControlConstruct can have at most one instance of timeout.