http://www.daml.org/services/owl-s/1.0/Process.owl
oXPDL: a Process Model Exchange Ontology
WorkFlowOntology
http://code.google.com/p/baetle/wiki/WorkFlowOntology
WorkFlowOntology
Tim Berners Lee's Workflow Ontology
Tim Berners Lee wrote a Workflow ontology, that could be useful for us. Bugs are tasks that are in certain states. Fixing bugs is transition their state to a terminal state. In order to get a quick overview of it I drew up a UML diagram:
Depends on a license related "doc" ontology http://www.w3.org/2000/10/swap/pim/doc also created by Tim Berners Lee: Workflow ontology uses doc:Work
The "doc" depends on a "contact" ontology http://www.w3.org/2000/10/swap/pim/contact still by TBL: "doc" ontology depends on contact:SocialEntity (which subsumes contact:Person).
Todo:
- explain N3 Work Flow rules
- draw diagrams of the other two ontologies?
- how does this compare to the Plans ontology (the rdf for that is broken btw)
Relation to Plans.owl
Rendered using manchester syntax for convenience
http://www.deri.ie/fileadmin/documents/DERI-TR-2008-03-28.pdf
www.m3pe.org/deliverables/process-ontology.pdf
www.geneontology.org/ontology/process.ontology
http://ksi.cpsc.ucalgary.ca/KAW/KAW96/borst/node8.html
Process Ontology
Our physical process ontology specifies the behavioural view on physical systems. In the general case it is quite difficult to formalize what the notion of a dynamic process precisely entails. Fortunately, for a certain part of physics this has been done to a level where one can define really primitive process concepts. The approach we take here is known in engineering as system dynamics theory, which also forms the theoretical background of the bond graph method [Karnopp et al., 1990]. The basic idea behind this theory is that the dynamics of a system can always be captured by looking at the change of different kinds of stuff. This change of stuff is also called flow. For instance, in electrical systems, dynamic behaviour consists of the change of electrical charge, i.e. electrical current. Likewise, in the mechanical domain the stuff is called location and change of location is velocity. The thing required to bring about a flow is called effort. Table 1 lists the types of stuff, flow and effort of some of the physical domains defined in the ontology.
Table 1: Some examples of physical domains. In each domain, dynamic behaviour is described as flow, i.e. change of stuff. Effort is that what is required to bring about a flow.
The interesting aspect about this table is that the product of a flow with its related effort has the dimension energy / time, i.e. such a pair defines an energy flow. Physical behaviour can therefore be defined in terms of energy flows. The process ontology introduces physical mechanisms which are applications of physical laws or principles to one or more energy flows. An important feature of these mechanisms is that they exploit in detail the analogies that exist between different physical domains. For example, the principle of conservation of momentum in mechanics is analogous to induction in the electrical domain. Many more of these analogies exist. This approach is valid for standard classical, deterministic physics, covering such diverse fields as mechanics, electricity and magnetism, hydraulics, acoustics, and thermodynamics.
Figure 7: Excerpt from the process ontology. This ontology formalizes a large part of physics. It defines how process descriptions can be formed by making a network of domain-independent mechanisms and energy flows. The ontology is relatively simple because systems theory is used for the definition of the networks.
Complex process descriptions can be formed by making a network of mechanisms, linked by energy flows. This abstraction is used to construct the process ontology. The process ontology includes systems theory and specializes the system theoretic concepts to processes. Just like the component ontology, the process ontology defines relatively simple concepts and relations onto which the system ontology is projected. This can be seen in Figure 7. Mechanisms are defined as simple mereological individuals. Energy flows, which have a certain direction, flow from one mechanism to another. The projection is performed by stating that an energy flow is a topological connection that connects the two mechanisms. A process description can now simply be defined as a system of mechanisms. The definition of physical domains as depicted in Table 1 is not shown in Figure 7.
Figure 8: The taxonomy of physical mechanisms. The properties discriminating between the classes after branching are printed above the branch points. The classes on the right give some examples of mechanisms in the electrical and mechanical domain.
Figure 8 shows the taxonomy of mechanisms as defined in the process ontology. The classes in the figure are present as classes in the ontology and class-subclass relations are defined for every line in the figure. The discriminating properties used to construct this taxonomy are the number of energy flows linked by a mechanism (connectivity), the mechanism type, whether effort or flow plays the most important role with respect to the mechanism type and the physical domain (e.g. mechanics, electricity, hydraulics, thermodynamics). Note that some discriminating properties are not useful for certain types of mechanisms.
The order in which the discriminating properties are applied here is the opposite of the order used in the typical engineering education. There, the distinction between physical domains is made first: there are separate courses in mechanics, electrical engineering and thermodynamics. Only when students have mastered all courses, they are able to see the analogies between the domains that makes the process ontology as compact and elegant as it is.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE uridef (View Source for full doctype...)>
- <!--
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
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#
"
xmlns:rdfs
="
http://www.w3.org/2000/01/rdf-schema#
"
xmlns:owl
="
http://www.w3.org/2002/07/owl#
"
xmlns:xsd
="
http://www.w3.org/2001/XMLSchema#
"
xmlns:service
="
http://www.daml.org/services/owl-s/1.0/Service.owl#
"
xmlns:process
="
http://www.daml.org/services/owl-s/1.0/Process.owl#
"
xmlns:grounding
="
http://www.daml.org/services/owl-s/1.0/Grounding.owl#
"
xmlns
="
http://www.daml.org/services/owl-s/1.0/Process.owl#
">
- <!--
MODIFICATION NOTES Monika/24/09/03 -replaced sameClassAs :equivalentClass Monika/24/09/03 -replaced samePropertyAs :equivalentProperty Monika/24/09/03 -replaced rdfs:domain :rdfs:domain Monika/24/09/03 -replaced rdfs:range :rdfs:range Monika/24/09/03 -replaced rdfs:subClassOf :rdfs:subClassOf Monika/24/09/03 -replaced rdfs:comment :rdfs:comment-->
<
owl:versionInfo
>
$Id: Process.owl,v 1.53 2004/05/07 22:43:08 martin Exp $
</
owl:versionInfo
>
<
rdfs:comment
>
Upper-level OWL ontology for Processes. Part of the DAML-S/OWL-S effort; see http://www.daml.org/services/.
</
rdfs:comment
>
<
owl:imports
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl
" />
<
owl:imports
rdf:resource
="
http://www.daml.org/services/owl-s/1.0/Service.owl
" />
</
owl:Ontology
>
- <!--
###################################################### Preliminaries ######################################################-->
<
rdfs:comment
>
This is a "place-holder" for now, which awaits further work from the DAML/OWL 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 OWL extension allowing for logical expressions.
</
rdfs:comment
>
</
owl:Class
>
<
rdfs:comment
>
This is a "place-holder" for now, which awaits further work from the DAML/OWL community. An instance of Effect is a logical formula that evaluates to true or false. Eventually we expect this to be defined elsewhere, as part of a OWL extension allowing for logical expressions.
</
rdfs:comment
>
</
owl:Class
>
- <!--
###################################################### Input / Output / Precondition / Effect ######################################################-->
- <!--
IOPE structure: * class Parameter - properties: - parameterType (minCard=1) - subclasses: - Input - ConditionalOutput -properties: coCondition (range Condition) - subclass: UnConditionalOutput (maxCard=0 on coCondition) * class Precondition - properties: - preCondition(range Condition) * class ConditionalEffect - properties - ceCondition(range Condition) - ceEffect - subclass: UnConditionalEffect (maxCard=0 on ceCondition) * Use rdf:ID and/or rdf:label to assign unique names to instances of the above classes.-->
<
rdfs:domain
rdf:resource
="
#Parameter
" />
<
rdfs:comment
>
Range is left unspecified currently, to allow for both OWL classes and XSD datatypes. (However, this is subject to revision in the next release.)
</
rdfs:comment
>
</
rdf:Property
>
<
rdfs:subClassOf
rdf:resource
="
#Parameter
" />
</
owl:Class
>
<
rdfs:subClassOf
rdf:resource
="
#Parameter
" />
</
owl:Class
>
<
rdfs:comment
>
The condition of a conditional output
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#ConditionalOutput
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
An UnConditionalOutput has no condition.
</
rdfs:comment
>
<
owl:Class
rdf:about
="
#ConditionalOutput
" />
<
owl:onProperty
rdf:resource
="
#coCondition
" />
</
owl:Restriction
>
</
owl:intersectionOf
>
</
owl:Class
>
<
owl:Class
rdf:ID
="
Precondition
" />
- <!--
* class ConditionalEffect A conditional effect is an effect that only occurs when a condition is true. In the book-buying 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 assumed to be true. Currently, we represent this by having *no* condition.-->
<
rdfs:domain
rdf:resource
="
#Precondition
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
owl:ObjectProperty
>
<
owl:Class
rdf:ID
="
ConditionalEffect
" />
<
rdfs:comment
>
The condition of a conditional effect.
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#ConditionalEffect
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
The effect of a conditional effect.
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#ConditionalEffect
" />
<
rdfs:range
rdf:resource
="
#Effect
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
An UnConditionalEffect has no condition.
</
rdfs:comment
>
<
owl:Class
rdf:about
="
#ConditionalEffect
" />
<
owl:onProperty
rdf:resource
="
#ceCondition
" />
</
owl:Restriction
>
</
owl:intersectionOf
>
</
owl:Class
>
<
owl:disjointWith
rdf:resource
="
#ConditionalOutput
" />
</
rdf:Description
>
- <!--
###################################################### Connection to upper level Service ontology ######################################################-->
<
rdfs:comment
>
A ServiceModel describes how a Service works, and a ProcessModel is a type of ServiceModel (the only type being defined for OWL-S). See also the introductory comments to Service.daml.
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
http://www.daml.org/services/owl-s/1.0/Service.owl#ServiceModel
" />
</
owl:Class
>
<
rdfs:comment
>
In the case of a composite process, indicates the top-level process class.
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#ProcessModel
" />
<
rdfs:range
rdf:resource
="
#Process
" />
</
owl:ObjectProperty
>
<
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 OWL-S.
</
rdfs:comment
>
</
owl:Class
>
<
rdfs:domain
rdf:resource
="
#ProcessModel
" />
<
rdfs:range
rdf:resource
="
#ProcessControlModel
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
A ProcessModel can have at most one Process and one ProcessControlModel.
</
rdfs:comment
>
<
owl:onProperty
rdf:resource
="
#hasProcess
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#hasControlModel
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
</
owl:Class
>
- <!--
###################################################### Processes ######################################################-->
<
rdfs:comment
>
The most general class of processes
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#IntervalEvent
" />
<
owl:Class
rdf:about
="
#AtomicProcess
" />
<
owl:Class
rdf:about
="
#SimpleProcess
" />
<
owl:Class
rdf:about
="
#CompositeProcess
" />
</
owl:unionOf
>
</
owl:Class
>
- <!--
Processes can have a name, parameters, preconditions, and (conditional) effects. Input, (conditional) output, and participant are parameters. 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).-->
<
rdfs:domain
rdf:resource
="
#Process
" />
<
rdfs:range
rdf:resource
="
http://www.w3.org/2000/01/rdf-schema#Literal
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#Process
" />
<
rdfs:range
rdf:resource
="
#Parameter
" />
</
owl:ObjectProperty
>
<
rdfs:subPropertyOf
rdf:resource
="
#hasParameter
" />
<
rdfs:range
rdf:resource
="
#Input
" />
</
owl:ObjectProperty
>
<
rdfs:subPropertyOf
rdf:resource
="
#hasParameter
" />
<
rdfs:range
rdf:resource
="
#ConditionalOutput
" />
</
owl:ObjectProperty
>
- <!--
hasPrecondition is a property of Process. Specific processes will instantiate this property with specific instances of Condition, indicating such things as knowledge preconditions (agent knows credit card number) or world preconditions (baud rate > 56Kb).-->
<
rdfs:domain
rdf:resource
="
#Process
" />
<
rdfs:range
rdf:resource
="
#Precondition
" />
</
owl:ObjectProperty
>
- <!--
hasEffect is a property of Process, having the range ConditionalEffect. Processes can 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.-->
<
rdfs:domain
rdf:resource
="
#Process
" />
<
rdfs:range
rdf:resource
="
#ConditionalEffect
" />
</
owl:ObjectProperty
>
- <!--
A participant is also a type of parameter. 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.-->
<
rdfs:subPropertyOf
rdf:resource
="
#hasParameter
" />
</
rdf: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.-->
<
rdfs:subClassOf
rdf:resource
="
#Process
" />
</
owl: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.-->
<
rdfs:subClassOf
rdf:resource
="
#Process
" />
<
owl:disjointWith
rdf:resource
="
#AtomicProcess
" />
</
owl:Class
>
<
rdfs:domain
rdf:resource
="
#SimpleProcess
" />
<
rdfs:range
rdf:resource
="
#AtomicProcess
" />
<
owl:inverseOf
rdf:resource
="
#realizes
" />
</
owl:ObjectProperty
>
<
rdfs:domain
rdf:resource
="
#AtomicProcess
" />
<
rdfs:range
rdf:resource
="
#SimpleProcess
" />
<
owl:inverseOf
rdf:resource
="
#realizedBy
" />
</
owl: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).-->
<
rdfs:domain
rdf:resource
="
#SimpleProcess
" />
<
rdfs:range
rdf:resource
="
#CompositeProcess
" />
<
owl:inverseOf
rdf:resource
="
#collapsesTo
" />
</
owl:ObjectProperty
>
<
rdfs:domain
rdf:resource
="
#CompositeProcess
" />
<
rdfs:range
rdf:resource
="
#SimpleProcess
" />
<
owl:inverseOf
rdf:resource
="
#expandsTo
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
This is a deprecated usage; expandsTo is preferred.
</
rdfs:comment
>
<
owl:equivalentProperty
rdf:resource
="
#expandsTo
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
This is a deprecated usage; collapsesTo is preferred.
</
rdfs:comment
>
<
owl:equivalentProperty
rdf:resource
="
#collapsesTo
" />
</
owl: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.-->
<
rdfs:subClassOf
rdf:resource
="
#Process
" />
<
owl:disjointWith
rdf:resource
="
#AtomicProcess
" />
<
owl:disjointWith
rdf:resource
="
#SimpleProcess
" />
<
rdfs:comment
>
A CompositeProcess must have exactly 1 composedOf property.
</
rdfs:comment
>
<
owl:Class
rdf:about
="
#Process
" />
<
owl:onProperty
rdf:resource
="
#composedOf
" />
</
owl:Restriction
>
</
owl:intersectionOf
>
</
owl:Class
>
<
rdfs:domain
rdf:resource
="
#CompositeProcess
" />
<
rdfs:range
rdf:resource
="
#ControlConstruct
" />
</
owl:ObjectProperty
>
<
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/2001/XMLSchema#boolean
" />
</
owl:DatatypeProperty
>
<
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 OWL.
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#CompositeProcess
" />
<
rdfs:range
rdf:resource
="
http://www.w3.org/2002/07/owl#Thing
" />
</
rdf:Property
>
<
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.w3.org/2002/07/owl#Thing
" />
</
rdf:Property
>
<
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.w3.org/2002/07/owl#Thing
" />
</
rdf:Property
>
<
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.w3.org/2002/07/owl#Thing
" />
</
rdf:Property
>
<
rdfs:comment
>
A CompositeProcess can have at most one invocable property. Similarly for computedInput, computedOutput, computedEffect, and computedPrecondition.
</
rdfs:comment
>
<
owl:onProperty
rdf:resource
="
#invocable
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#computedInput
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#computedOutput
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#computedEffect
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#computedPrecondition
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
</
owl: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.-->
<
rdfs:subClassOf
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#IntervalEvent
" />
</
owl:Class
>
<
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
" />
</
rdf:Property
>
<
rdfs:comment
>
A ProcessComponent is either a Process or a ControlConstruct.
</
rdfs:comment
>
<
owl:Class
rdf:about
="
#Process
" />
<
owl:Class
rdf:about
="
#ControlConstruct
" />
</
owl:unionOf
>
</
owl:Class
>
<
rdfs:comment
>
A multiset of ProcessComponents
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#List
" />
<
owl:onProperty
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#first
" />
<
owl:allValuesFrom
rdf:resource
="
#ProcessComponent
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#rest
" />
<
owl:allValuesFrom
rdf:resource
="
#ProcessComponentBag
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
</
owl:Class
>
- <!--
Daml does not make any distinction between bags and lists. We redefine the ProcessComponentList class, rather than use equivalentClass, so as to make that distinction.-->
<
rdfs:comment
>
A list of ProcessComponents
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#List
" />
<
owl:onProperty
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#first
" />
<
owl:allValuesFrom
rdf:resource
="
#ProcessComponent
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#rest
" />
<
owl:allValuesFrom
rdf:resource
="
#ProcessComponentList
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
</
owl:Class
>
- <!--
The various control constructs that can be used for specfifying and composing processes. The minimal initial set are Sequence, Split, Split + 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.-->
- <!--
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 "Concurrent" or "Parallel".-->
- <!--
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)-->
- <!--
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.-->
- <!--
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|).-->
- <!--
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 :)-->
<
rdfs:domain
rdf:resource
="
#Choice
" />
<
rdfs:range
rdf:resource
="
#ProcessComponentBag
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#Choice
" />
<
rdfs:range
rdf:resource
="
#ProcessComponent
" />
</
rdf:Property
>
- <!--
IF then Else Class is a ControlConstruct that consists of a Condition, a then and an else process-->
<
rdfs:comment
>
The if condition of an if-then-else
</
rdfs:comment
>
<
rdfs:domain
rdf:resource
="
#If-Then-Else
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#If-Then-Else
" />
<
rdfs:range
rdf:resource
="
#ProcessComponent
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#If-Then-Else
" />
<
rdfs:range
rdf:resource
="
#ProcessComponent
" />
</
rdf:Property
>
- <!--
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.-->
<
rdfs:domain
rdf:resource
="
#Repeat-While
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#Repeat-While
" />
<
rdfs:range
rdf:resource
="
#ProcessComponent
" />
</
rdf:Property
>
<
rdfs:comment
>
The repeat while construct
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
#ControlConstruct
" />
</
owl: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.-->
<
rdfs:domain
rdf:resource
="
#Repeat-Until
" />
<
rdfs:range
rdf:resource
="
#Condition
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#Repeat-Until
" />
<
rdfs:range
rdf:resource
="
#ProcessComponent
" />
</
rdf:Property
>
<
rdfs:comment
>
The repeat until process
</
rdfs:comment
>
<
rdfs:subClassOf
rdf:resource
="
#ControlConstruct
" />
</
owl:Class
>
- <!--
###################################################### Argument Bindings ######################################################-->
- <!--
Property "sameValues" and Class "ValueOf" are used to denote that two or more parameters of (potentially, different subprocesses of) a ProcessComponent should have the same values when the process is realized. For instance, these are used to state that the input to one subprocess should be the output of the previous one within a sequence.-->
<
rdfs:domain
rdf:resource
="
#ProcessComponent
" />
<
rdfs:comment
>
The range is to be a list of ValueOf.
</
rdfs:comment
>
<
rdfs:range
rdf:resource
="
http://www.w3.org/1999/02/22-rdf-syntax-ns#List
" />
</
rdf:Property
>
<
owl:Class
rdf:ID
="
ValueOf
" />
<
rdfs:domain
rdf:resource
="
#ValueOf
" />
<
rdfs:range
rdf:resource
="
#Process
" />
</
rdf:Property
>
<
rdfs:domain
rdf:resource
="
#ValueOf
" />
<
rdfs:range
rdf:resource
="
#Parameter
" />
</
rdf:Property
>
- <!--
###################################################### Temporal Aspects ######################################################-->
- <!--
Since Process and ControlConstruct are subclasses of time:IntervalEvent, time ontology properties such as begins and ends may be used. We define two additional time-related properties here.-->
<
rdfs:domain
rdf:resource
="
#ProcessComponent
" />
<
rdfs:range
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#IntervalThing
" />
</
owl:ObjectProperty
>
- <!--
We may need absolute timeout (like calender time or timeOfDay, so we allow for the timeoutAbsolute property-->
<
rdfs:domain
rdf:resource
="
#ProcessComponent
" />
<
rdfs:range
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#InstantThing
" />
</
owl:ObjectProperty
>
<
rdfs:comment
>
A ProcessComponent can have at most one of each of the restricted properties.
</
rdfs:comment
>
<
owl:onProperty
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#begins
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
http://www.isi.edu/~pan/damltime/time-entry.owl#ends
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#timeout
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
<
owl:onProperty
rdf:resource
="
#timeoutAbsolute
" />
</
owl:Restriction
>
</
rdfs:subClassOf
>
</
owl:Class
>
</
rdf:RDF
>
808
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
