Appendix C: Axiomatization of the Process Model in SWSL-Rules

Here we give the Rules Ontology for Web Services (ROWS) formulations
of the axioms of the process model, as described in Section 3 of the SWSO
document. ROWS is also known as SWSO-Rules. These formulations
are derived directly from the FLOWS (SWSO-FOL) formulations, as given
in Appendix B, according to the
translation approach described in Section 3 of the SWSL document. They can easily be compared to
the FLOWS axioms by viewing Appendices B and C in two browser
windows side by side.

A service occurrence is an occurrence of the activity that is associated
with the service.

neg service_occurrence(?s,?o) :- occurrence_of(?o,?a) and neg service_activity(?s,?a).
neg occurrence_of(?o,?a) :- service_occurrence(?s,?o) and neg service_activity(?s,?a).
service_activity(?s,?a) :- service_occurrence(?s,?o) and occurrence_of(?o,?a).
Note: The three rules above are the omnidirectional set of rules for
this clause:
neg service_occurrence(?s,?o) or neg occurrence_of(?o,?a) or service_activity(?s,?a).
which is equivalent to this:
service_occurrence(?s,?o) and occurrence_of(?o,?a) ==> service_activity(?s,?a).

AtomicProcess

An AtomicProcess is equivalent to a primitive activity in the PSL
Ontology such that its preconditions and effects depend only on the
fluents that hold prior to the an occurrence of the activity.

If ?iofluent is an output to an activity that is conditional on the fluent ?f,
then the effect of the activity occurrence when ?f holds prior to the activity
occurrence is that the reference of ?iofluent is known.

The K fluent represents the accessibility relation in the
possible-world model of knowledge. An activity occurrence ?s1
is accessible from an activity occurrence ?s if as far as is known
in ?s, ?s1 might have occurred.

Split

A Split activity is equivalent to a strong_poset activity in PSL.
The activity trees all have the same structure and each activity tree
consists of branches that are in one-to-one correspondence with
sequences of subactivity occurrences that satisfy the partial ordering
constraints.

Unordered

An Unordered activity is equivalent to an activity in PSL whose
activity
trees all have the same structure and such that each activity tree is a
bag.
In this case, there is a one-to-one correspondence between branches of
the
activity tree and all permutations of subactivity occurrences.

Choice

A Choice activity is equivalent to an activity in PSL whose
activity
trees all have the same structure and such that each activity tree is
nondeterministic (that is, each branch contains occurrences of
different
subactivities.

Iterate

An Iterate activity is equivalent to an activity in the PSL
Ontology
whose occurrences are repetitive. Activity trees for this activity have
different
structure, depending on the cardinality of the repeated subtrees.

RepeatUntil

A RepeatUntil activity is equivalent to a conditional activity in
the PSL Ontology
whose occurrences are repetitive. Activity trees for this activity have
different
structure, depending on the cardinality of the repeated subtrees.

OrderedActivity

An Ordered activity is equivalent to an activity in PSL whose
activity
trees all have the same structure and such that each activity tree is
ordered
if and only if the branches contain occurrences of the same
subactivities.

OccActivity

An Ordered activity is equivalent to an activity in PSL whose
activity
trees all have the same structure and such that each activity tree is
ordered
if and only if the branches contain occurrences of the same
subactivities.

The relation is_found_by is the restriction of the is_handled_by relation
to exception-finding activities.
The relation is_fixed_by is the restriction of the is_handled_by relation
to exception-fixing activities.

is_handled_by(?e,?a) :- is_found_by(?e,?a) and find_exception(?a).
neg is_found_by(?e,?a) :- neg is_handled_by(?e,?a) and find_exception(?a).
neg find_exception(?a) :- neg is_handled_by(?e,?a) and is_found_by(?e,?a).
is_handled_by(?e,?a) :- is_fixed_by(?e,?a) and fix_exception(?a).
neg is_fixed_by(?e,?a) :- neg is_handled_by(?e,?a) and fix_exception(?a).
neg fix_exception(?a) :- neg is_handled_by(?e,?a) and is_fixed_by(?e,?a).
neg is_handled_by(?e,?a) :- neg is_found_by(?e,?a) and neg is_fixed_by(?e,?a).
is_found_by(?e,?a) :- is_handled_by(?e,?a) and neg is_fixed_by(?e,?a).
is_fixed_by(?e,?a) :- is_handled_by(?e,?a) and neg is_found_by(?e,?a).
neg is_handled_by(?e,?a) :- neg find_exception(?a) and neg is_fixed_by(?e,?a).
find_exception(?a) :- is_handled_by(?e,?a) and neg is_fixed_by(?e,?a).
is_fixed_by(?e,?a) :- is_handled_by(?e,?a) and neg find_exception(?a).
neg is_handled_by(?e,?a) :- neg is_found_by(?e,?a) and neg fix_exception(?a).
is_found_by(?e,?a) :- is_handled_by(?e,?a) and neg fix_exception(?a).
fix_exception(?a) :- is_handled_by(?e,?a) and neg is_found_by(?e,?a).
neg is_handled_by(?e,?a) :- neg find_exception(?a) and neg fix_exception(?a).
find_exception(?a) :- is_handled_by(?e,?a) and neg fix_exception(?a).
fix_exception(?a) :- is_handled_by(?e,?a) and neg find_exception(?a).
Note: The first triplet of rules is the omnidirectional set for this clause:
(a) is_handled_by(?e,?a) or neg is_found_by(?e,?a) or neg find_exception(?a)
The second triplet is the omnidirectional set for this clause:
(b) is_handled_by(?e,?a) or neg is_fixed_by(?e,?a) or neg fix_exception(?a)
The third triplet is the omnidirectional set for this clause:
(c) neg is_handled_by(?e,?a) or is_found_by(?e,?a) or is_fixed_by(?e,?a).
The fourth triplet is the omnidirectional set for this clause:
(d) neg is_handled_by(?e,?a) or find_exception(?a) or is_fixed_by(?e,?a).
The fifth triplet is the omnidirectional set for this clause:
(e) neg is_handled_by(?e,?a) or is_found_by(?e,?a) or fix_exception(?a).
The sixth triplet is the omnidirectional set for this clause:
(f) neg is_handled_by(?e,?a) or find_exception(?a) or fix_exception(?a).
Clauses (a) and (b) are equivalent to the <== direction of the
FLOWS rule.
Clauses (c), (d), (e), and (f) are equivalent to the ==> direction of the
FLOWS rule.

The relation is_detected_by is the restriction of the is_found_by relation
to exception-detecting activities.
The relation is_anticipated_by is the restriction of the is_found_by relation
to exception-anticipating activities.

The relation is_avoided_by is the restriction of the is_fixed_by relation
to exception-avoiding activities.
The relation is_resolved_by is the restriction of the is_fixed_by relation
to exception-resolving activities.