Figure 3.1: Selected families of process modeling constructs relevant to Web services
Copyright © 2005 retained by the authors.
All Rights Reserved.
This document defines the Semantic Web Services Ontology (SWSO). The ontology is expressed in two forms: FLOWS, the First-order Logic Ontology for Web Services; and ROWS, the Rules Ontology for Web Services, produced by a systematic translation of FLOWS axioms into the SWSL-Rules language. FLOWS has been specified in SWSL-FOL, the first-order logic language developed by SWSO's sister SWSL effort.
This is one of four documents that make up the initial report of the Semantic Web Services Language Committee of the Semantic Web Services Initiative. The report defines the Semantic Web Services Framework (SWSF).
History of publication at http://www.daml.org/services/swsl/report/swso/:
History of publication at http://www.daml.org/services/swsf/swso/:
1 Introduction
2
Service Descriptors
3
Process Model
3.1 FLOWS-Core
3.1.1 Service
3.1.2 Atomic Process
3.1.3 composedOf
3.1.4 Message
3.1.5 Channel
3.2 Control Constraints
3.2.1 Split
3.2.2 Sequence
3.2.3 Unordered
3.2.4 Choice
3.2.5 IfThenElse
3.2.6 Iterate
3.2.7 RepeatUntil
3.3 Ordering constraints
3.3.1 OrderedActivity
3.4 Occurrence constraints
3.4.1 OccActivity
3.5 State constraints
3.5.1 TriggeredActivity
3.6 Exceptions
3.6.1 State-based Exception Handling
3.6.2 Message-based Exception Handling
3.6.3 Extended Exception Handling
4
Grounding a Service Description
4.1 Relationship between SWSL and WSDL
4.2 Mapping between SWSL and WSDL
4.2.1 Message Patterns
4.2.2 Message Type Realization
4.2.3 Mapping SWSO Messages to WSDL Messages
4.2.4 Mapping WSDL Messages to SWSO Messages
4.2.5 Declarative Specification of SWSO-to-WSDL Message Mapping
4.2.6 Declarative Specification of WSDL-to-SWSO Message Mapping
5
Rules Ontology for Web Services (ROWS)
6
Background Materials
6.1 Ontology of the Process Specification Language
6.2 Knowledge Preconditions and Knowledge Effects
7 Glossary
8 References
Appendices
A PSL in SWSL-FOL and SWSL-Rules
B Axiomatization of the FLOWS Process Model
C
Axiomatization of the Process Model in SWSL-Rules
D Reference Grammars
This document also refers to Section 2 in the Application Scenarios document.
This document is part of the technical report of the Semantic Web Services Language (SWSL) Committee of the Semantic Web Services Initiative (SWSI). The overall structure of the report is described in the document titled Semantic Web Services Framework Overview.
This document presents the Semantic Web Services Ontology (SWSO). This includes a description of the conceptual model underlying the ontology, and a description of a first-order logic (FOL) axiomatization which defines the model-theoretic semantics of the ontology. The axiomatization is called "SWSO-FOL" or equivalently, FLOWS -- the First-order Logic Ontology for Web Services -- and is expressed using SWSL-FOL. (The full axiomatization is available in Appendix B.) As noted in Section 5, These same axioms can be expressed (or partially expressed in some cases) in SWSL-Rules. The SWSL-Rules formalization of the axioms, called SWSO-Rules or ROWS, is listed in Appendix C.
The goal of FLOWS is to enable reasoning about the semantics underlying Web (and other eletronic) services, and how they interact with each other and with the "real world". FLOWS does not strive for a complete representation of web services, but rather for an abstract model that is faithful to the semantic aspects of service behavior. (An approach to "grounding" FLOWS specifications into real Web services, e.g., that use WSDL for messaging, is discussed in Section 4). Following the lead of the situation calculii [Reiter01], and in particular the situation calculus semantics [Narayanan02] of OWL-S [OWL-S 1.1], the changing portions of the real world are modeled abstractly using the notion of fluents. These are first-order logic predicates and terms that can change value over time. The FLOWS model provides infrastructure for representing messages between services; the focus here is on the semantic content of a message, rather than, for example, the specifics of how that content is packaged into an XML-based message payload. (Again, Grounding will address these issues.) FLOWS also provides constructs for modeling the internal processing of Web services.
FLOWS is intended to enable reasoning about essential aspects of Web service behavior, for a variety of different purposes and contexts. Some targeted purposes are to support (a) descriptions of Web services that enable automated discovery, composition, and verification, and (b) creation of declarative descriptions of a Web service, that can be mapped (either automatically or through a systematic process) to executable specifications. A variety of contexts can be supported, including: (i) modelling a service as essentially a black box, where only the messaging is observable; (ii) modelling the internal atomic processes that a service performs, along with the impact these processes have on the real world (e.g., inventories, financial accounts, commitments); (iii) modelling many properties of a service, including all message APIs, all or some of the internal processing, and some or all of the internal process and data flows. Of course, the usability of a Web service description may depend on how much or how little information is included.
It is important to note that the specification of the FLOWS ontology in first-order logic does not presuppose that the automated reasoning tasks described above will be realized using a first-order logic theorem prover. We can certainly use FOL to specify solutions to these tasks, using notions of entailment and satisfiability. Nevertheless, while some tasks may naturally be realized through theorem proving, it has been our experience that most AI automated reasoning tasks are addressed by special-purpose reasoners, rather than by general-purpose reasoners such as theorem provers. For example, we anticipate specialized programs being developed to perform Web service discovery, Web service composition and Web service verification. Thus, the role of FLOWS is not necessarily to provide an executable specification, but rather to provide an ontology -- a definition of concepts -- with a well-defined model theoretical semantics that will enable specification of these tasks and that will support the development of specialized reasoners that may be provably correct with respect to these specifications.
FLOWS captures the salient, functional elements of various models of Web services found in the literature and in industrial standards. In FLOWS, an emphasis is placed on enabling the formal representation and study of the following formalisms, among others.
FLOWS represents an attempt to extend on the work of OWL-S, to incorporate a variety of capabilities not within the OWL-S goals. OWL-S was focussed on providing an ontology of Web services that would facilitate automated discovery, enactment and composition of Web services. It was not focused on interoperating with or providing a semantics for (at its outset, nonexistent) industry process modeling formalisms such as BPEL. As such, OWL-S concepts such as messages are abstracted away and only reintroduced in tis grounding to WSDL. A primary difference between FLOWS and OWL-S is the expressive power of the underlying language. FLOWS is based on first-order logic, which means that it can express considerably more than can be expressed using OWL-DL (upon which OWL-S is based). (For example, this immediately includes n-ary predicates and richly quantified sentences.) The use of first-order logic enables a more refined approach than possible in OWL-S to representing different forms of data flow that can arise in Web services. A second difference is that FLOWS strives to explicitly model more aspects of Web services than OWL-S. This includes primarily the fact that FLOWS can readily model (i) process models using a variety of different paradigms; and (ii) data flow between services, which is acheived either through message passing or access to shared fluents (which might also be thought of as shared data). Indeed, FLOWS provides the ability to model, albeit in an abstract, semantically motivated manner, several key Web services standards, including WSDL, BPEL, and WS-Choreography.
A key premise of FLOWS is that an appropriate foundation for formally describing Web services can be built as a family of PSL extensions. PSL -- the Process Specification Language -- is a formally axiomatized ontology [Gruninger03a, Gruninger03b] that has been standardized as ISO 18629. PSL was originally developed to enable sharing of descriptions of manufacturing processes. FLOWS refines aspects of PSL with Web service-specific concepts and extensions. An overview of concepts in the Process Specification Language that are relevant to FLOWS is given in Section 6 below.
A primary goal of FLOWS is to provide a formal basis for accurately specifying "application domains" based broadly on the paradigms of Web services and/or services oriented architecture (SOA). While FLOWS captures key fundamental aspects of the Web services and SOA paradigms, it also strives to remain very flexible, to allow for the multitude of variations already present in these domains and likely to arise in coming years. Another goal of FLOWS is to enable formalization of a diversity of process modeling formalisms within the ontology. As such, FLOWS, like PSL is designed to facilitate interoperation between diverse process modeling formalisms.
In a typical usage of FLOWS, an application domain is created
by combining the FLOWS axioms with additional logical sentences
to form a (first order logic) theory.
Speaking loosely, each sentence in such a theory
can be viewed as a
constraint or restriction on the models (in the sense of
mathematical logic) that satisfy the theory.
In particular, and following the spirit of
Golog [Reiter01]
and similar languages,
even process model constructs such as
while or if-then-else
correspond formally to constraints rather than
procedural elements.
Similarly, the passing of information,
which is often represented using variable assignment
in Web services, is specified in the formal model
in epistemic terms, following the approach taken in
[Scherl03].
Again, the approach taken here is intended to provide maximal
flexibility in terms of formally modeling
the wide range of existing and future web
services and SOA models.
For example, it is possible ot look at data flow
and information sharing at an abstract level based on
what a service "knows", or to specialize
this to models that involve
imperative variable assignment.
Following the high-level structure of OWL-S, FLOWS has three major
components: Service Descriptors,
Process Model,
and
Grounding.
In the formal ontology, these three elements
are associated with services
by representing a formal service as a conceptual
object, and using relations to associate specific
artifacts with the service.
For example,
service-author is a binary relation
that associates an author to a service, and
service-activity is a binary relation
that associates a unique (PSL) "complex activity" to a service;
the complex activity provides a partial or complete specification
of the process model associated with the service.
(See
Section 3)
below for more detail.)
Most domain ontology developers are motivated to provide a logical description of their Web service with a view to some specific set of automations tasks, including perhaps Web service discovery, invocation, composition, verification or monitoring. Each task requires some subset or view of the entire FLOWS ontology. For example, to perform automated Web service discovery, we might need axioms from both the Service Descriptors, and select axioms from the Process Model. For Web service invocation, we might only need the inputs and outputs of atomic processes comprising a service in FLOWS-Core, and so on. To cross cut our three broad subontologies (Service Descriptors, Process Model, and Grounding) and to create ontologies that are task-specific, it is possible to project views onto the FLOWS ontology. The concept of views is not developed in this document, however.
This document is organized as follows. Service Descriptors are described in Section 2. The Process Model portion of the ontology, described in Section 3, represents the most substantial advance over OWL-S. This section is quite extensive, presenting the core ontology (FLOWS-Core), several formal extensions of it, and a more informal discussion concerning the relationship of FLOWS to other service models. The section also includes an intuitive description of the conceptual model underlying FLOWS, and links to a formal axiomatization of FLOWS (in Appendix B). (Also relevant is Appendix A, which shows how to specify key elements of PSL in both SWSL-FOL and SWSL-Rules). Section 4 discusses grounding for FLOWS. As noted above, (most of) FLOWS can be systematically translated into the SWSL-Rules language; this is discussed in Section 5. (An axiomatization for ROWS is presented in Appendix C). Section 6 provides a brief review of PSL and the approach of [Scherl03] for incorporating knowledge into the situation calculus, for readers who have not been exposed to these before. The document closes with a Glossary (Section 7), and References (Section 8).
The description of FLOWS presented in this document also refers to Section 2 of the document Application Scenarios, that forms part of this W3C submission. That section provides some extended examples which illustrate key aspects of the conceptual model underlying FLOWS.
Service descriptors provide basic information about a Web service. This descriptive information may include non-functional meta-information and/or provenance information. Service descriptors are often used to support automated Web service discovery. What follows is an initial set of domain-independent properties. Our intention is that these be expanded as needs dictate. Indeed many of the service descriptors that are most effective for service discovery are domain specific.
The initial list captures basic identifying information including name, authorship, textual description, version, etc. The set of descriptors also includes information describing (potentially subjective) notions of quality of service such as reliability. Note that this is an initial set of properties derived predominantly from the OWL-S Profile [OWL-S 1.1]). The set is expected to be extended with properties that are domain specific such as those contained in the OWL-S appendices and those in WSMO's [Bruijn05] coverage service descriptor (or "non-functional property" as it is called in their proposed specification). The set may also be expanded with properties commonly used in other standards such as those found in Dublin Core. In the following list of properties, those properties derived from OWL-S are so noted. Some of these properties are similar or identical to those included in WSMO's list of non-functional properties.
Following the description of each individual property is a listing of the FLOWS relation that captures the concept within the ontology.
name(service,service_name)
author(service,service_author)
contact(service,contact_info)
contributor(service,service_contributor)
description(service,service_description)
url(service,service_URL)
identifier(service,service_identifier)
version(service,service_version)
releaseDate(service,service_release_date)
language(service,service_language)
trust(service,service_trust)
subject(service,service_subject)
reliability(service,service_reliability)
cost(service,service_cost)
The translation of service descriptors into ROWS can be found here.
Readers may also be interested in the discussion of inputs, (conditional) outputs, preconditions and conditional effects of the complex activity that describes the process model of a service. This is discussed towards the end of Subsection 3.1.2.
Since PSL is a generic ontology for processes, we need to specify extensions to provide concepts that are useful in the context of Web services. In particular, the FLOWS process model adds two fundamental elements to PSL, namely (i) the structured notion of atomic process as found in OWL-S, and (ii) infrastructure for specifying various forms of data flow. (The FLOWS process model relies on constructs already available in PSL for representing basic aspects of process flow, and also provides some extensions for them.)
Following the modular organization of the PSL ontology, the FLOWS process model is layered and partitioned into natural groupings. When specifying an application domain, it is thus easy to incorporate only the ontological building blocks that are needed.
The FLOWS process model is created as a family of extensions of PSL-OuterCore, The fundamental extension of PSL-OuterCore for services is called "FLOWS-Core". As will be seen, this extension is quite minimalist, and provides an abstract representation only for (web) services, their impact "on the world", and the transmission of messages between them.
Figure 3.1 shows various families of process modeling constructs, including PSL-OuterCore, FLOWS-Core, and several others. These include models from standards, such as the process model portion of BPEL (and a refinement of BPEL that incorporates typical assumptions made when using BPEL in practice), and models from the research literature, such as guarded automata. A line between a family F of constructs and a family F' above F indicates that it is natural to view F' as a family that includes most or all of the constructs in F. The OWL-S process model is not shown explicitly in Figure 3.1, because it has been integral in the design of the FLOWS-Core and the Control Constructs extension. Of course, the different families of modeling constructs shown in the figure should not be viewed as comprehensive.
In some cases, it may be useful to create PSL extensions of FLOWS-Core, to formally specify the properties of certain families of constructs shown in Figure 3.1. Indeed, as part of the Process Model of the FLOWS ontology presented below several extensions are specified; these are indicated in the figure by the rectangles above FLOWS-Core. We note that FLOWS-Core can serve as a mathematical foundation for representing several other aspects and models from the Web services and SOA standards and literature, and it seems likely that additional PSL extensions of FLOWS-Core will be created in the future.
Following this methodology, the FLOWS process model ontology is composed of a core set of axioms, referred to as FLOWS-Core, and a set of extension ontologies. FLOWS currently consists of six ontology modules that specify core intuitions about the activities associated with a service together with classes of composite activities that are used to express different constraints on the occurrence of services and their subactivities.
The table below lists the FLOWS ontologies and the concepts defined in those ontologies.
| Module | Major Concepts |
|---|---|
| FLOWS-Core | Service AtomicProcess composedOf message channel |
| Control Constraints | Split Sequence Unordered Choice IfThenElse Iterate RepeatUntil |
| Ordering Constraints | OrderedActivity |
| Occurrence Constraints | OccActivity |
| State Constraints | TriggeredActivity |
| Exception Constraints | Exception |
The specification of concepts in FLOWS is presented using some or all of the following:
After the presentation of FLOWS-Core and its formal extensions, Subsection 3.7 describes some possible additional extensions of FLOWS-Core, corresponding to the entries in Figure 3.1 not enclosed in rectangles.
The FLOWS-Core process model is intended to provide a formal basis for specifying essentially any process model of Web services and service composition that has arisen or might arise in the future. As such, the underlying conceptual process model focuses on the most essential aspects of Web services and their interaction.
The principles guiding the FLOWS-Core process model can be summarized as follows:
service-activity(?s,?a).)
As in PSL, the complex activity A may have
one or more occurrences, each of which corresponds intuitively
to a possible execution of A (subject
to the constraints in the relevant application domain theory).
The notion of 'occurrence' of activity A
here is essentially the same as the notion of
'enactment' of a workflow specification as found in
the workflow literature.)
Speaking intuitively,
in an application domain theory, the complex acivity
A might be specified
completely, or only partially.
We use the phrase service activity
to refer to a PSL complex activity, such as A,
that is associated
to a formal service in some application domain.
FLOWS-Core does not
provide any explicit constructs for the structuring of processing
inside a Web service.
(Some minimal constructs are available in PSL OuterCore,
including primarily the
soo_precedes
predicate,
which indicates that one atomic activity occurrence in a complex
activity occurrence precedes in time another
atomic activity occurrence.)
This is intentional, as there are several models for
the internal processing in the standards and literature
(e.g., BPEL, OWL-S Process Model, Roman model, guarded automata model),
and many other alternatives besides (e.g., rooted in
Petri nets, in process algebras, in workflow models, in telecommunications).
We introduce (possible) extensions of FLOWS-Core to
represent some of these service-internal process models
(e.g., Control Constructs,
Roman model, Guarded automata).
When using FLOWS-Core, it is often useful to model humans (and organizations and other non-service agents) as specialized formal services (or combinations of services, corresponding to the different roles that they might play). We are not proposing that all aspects of human behavior can or should be captured using FLOWS-Core constructs, but rather that a useful abstraction of human (and organization) behaviors, in the context of interaction with Web services, is to focus on the message creation/reading activities that humans perform, and on the knowledge that they can convey to other services or obtain from them (via messages). It is typical to assume that humans cannot directly perform atomic processes for testing or directly impacting domain-specific fluents, but must rather achieve that by invoking standard (web) services. For an abstract representation (H, B) of human H with complex activity B, in some cases it is natural to view occurrences of B as relatively short-lived (e.g., corresponding to one session with an on-line book seller), and in other cases to view occurrences of B as long-lived (e.g., the life-long family of interactions between the human and the on-line bookseller). In some cases it might be natural to model a human as embodying several formal services (H_1, B_1), ..., (H_n, B_n), corresponding to different roles that the human might play at different times.
We note that FLOWS-Core can be used to faithfully represent and study service process models that do not include all of the notions just listed. For example, OWL-S focuses on world-changing atomic processes and largely ignores the variations that can arise in connection with message passing. A given application domain can be represented in FLOWS-Core in such a way that the message passing is essentially transparent, so that it provides a faithful simulation of an OWL-S version of the domain. Alternatively, a domain theory can be specified in FLOWS-Core which essentially ignores the ability of atomic processes to modify facts "in the world". Such theories offer the possibility of faithfully simulating domains defined in terms of standards such as WSDL, BPEL, and WS-Choreography, which focus largely on service I/O signatures, and the process and data flow involved with message passing.
In the remainder of this subsection we provide more detail concerning the major concepts of FLOWS-Core.
A service is an object. Associated with a service are a number of service descriptors, as described in Section 2. Also associated with every service is an activity that specifies the process model of the service. We call these activities service activities. These service activities are PSL activities. A service occurrence is an occurrence of the activity that is associated with the service.
We associate three relations with services:
service(thing) service_activity(service,activity) service_occurrence(service,activity_occurrence)
Readers may also be interested in the discussion of inputs, (conditional) outputs, preconditions and conditional effects of the complex activity that describes the process model of a service. This is discussed towards the end of the next subsection.
A fundamental building block of the FLOWS process model for Web services is the concept of an atomic process. An atomic process is a PSL activity that is generally (but not mandated to be) a subactivity of the activity associated with a service (i.e., the activity referenced in the relation service_activity(service,activity) introduced in Section 3.1.1). An atomic process is directly invocable, has no subprocesses and can be executed in a single step. Such an activity can be used on its own to describe a simple Web service, or it can be composed with other atomic or composite processes (i.e., complex activities) in order to provide a specification of a process workflow. The composition is encoded as ordering constraints on atomic processes using the FLOWS control constructs described in Section 2.2.2. Associated with an atomic process are zero or more parameters that capture the inputs, outputs, preconditions and (conditional) effects (IOPEs) of the atomic process. More on IOPEs in a moment.
Types of Atomic Processes
In FLOWS we use atomic processes to model both the domain-specific activities
associated with a service, such as put_in_cart(book)
or checkout(purchases), but also the atomic processes
associated with producing, reading and destroying the messages that are sent
between Web services. We distinguish these categories of atomic processes
as follows:
In the FLOWS ontology, the message-specific atomic activities are distinguished by the following unary relations.
Produce_Message(atomic_process) Read_Meassage(atomic_process) Destroy_Message(atomic_process)
where atomic_process is an a FLOWS atomic process.
Atomic Process IOPEs
Associated with each atomic process are (multiple) input, output, precondition and (conditional) effect parameters (IOPEs). The inputs and outputs are the inputs and outputs to the program that realizes the atomic process. The preconditions are any conditions that must be true of the world for the atomic process to be executed. In most cases, there will be no precondition parameters since most software (and Web services are generally software) has no physical preconditions for execution, at least at the level at which we are modeling it. Finally, the conditional effects of the atomic process are the side effects of the execution of the atomic process. They are conditions in the world that are true following execution of the process, e.g., that a client's account was debited, or a book sent to a particular address. These effects, may be conditional, since they may be predicated on some state of the world (for example, whether a book is in stock).
In the FLOWS ontology, IOPEs are associated with an atomic process via
the following binary and ternary relation. The inputs and outputs of an
atomic process are represented by functional fluents that take on a
particular value e.g.bookname(book)="Green Eggs and Ham".
We acknowledge that the actual input may be conveyed to the atomic process
(e.g., as a result of a read-message process or via some internal
communication) as rich structured data, but it is ultimately
representable within our ontology as a conjunction of its component
fluent parts. The preconditions and effects of an atomic process are
expressed as
arbitrary first-order logic formulae. Since formulae are not reified
in FLOWS (note that fluents are reified, and further that formulae are
reified in SWSL-Rules), we
must associate a relational fluent with each formula we wish
to represent in our IOPE relations. This fluent is true iff the formula
we associate it with is true. We use this `trick' both for
preconditions, for effects and for the conditions associated with
conditional outputs and conditional effects. In the case where an output
or effect is unconditional, the condition fluent is true.
input(atomic_process, input_fluent) output(atomic_process, cond_formula_fluent, output_fluent) precond(atomic_process, precond_formula_fluent) effect(atomic_process, cond_formula_fluent,effect_formula_fluent)
where
atomic_process is an atomic process, and
input_fluent and output_fluent are
functional fluents, that serves
as the input (output, respectively) for atomic_process.
This functional fluent is
a term in the language of the domain theory.
(Recall that the relation input (respectively
output) might associate multiple input_fluents or
output_fluents with a single atomic process.)
cond_formula_fluent is a relational fluent
that is true if and only if the condition upon which an output
or effect is predicated, is true.
precond_formula_fluent is a relational fluent
that is true if and only if the precondition formula is true.
effect_formula_fluent is a relational fluent
that is true if and only if the effect formula is true.
These relations have also been systematically translated into ROWS, the SWSL-Rules ontology, as described in Section 2.5.
Formal models of software often include the inputs and outputs of the software, but not their side effects. Formal models of processes, such as those used in manufacturing or robotics, generally model physical preconditions and effects, but not inputs and outputs. To relate IOPEs in FLOWS, we intepret the inputs and (conditional) outputs of an atomic process as knowledge preconditions and knowledge effects [Scherl03], respectively, following [McIlraith01], [Narayanan02]. Our axiomatization of atomic processes makes explicit that if a fluent is an input (output, respectively) of an atomic process then it is a knowledge precondition (effect, respectively) of that process. Despite PSL's underpinnings in situation calculus, there is no explicit treatment of epistemic fluents (knowledge fluents). As such, included in the axiomatization of FLOWS-Core are the axioms for epistemic fluents.
Domain-Specific Axioms for Atomic Processes
Earlier in this section, we identified 5 classes of atomic processes. The atomic processes associated with messages and channels are discussed further in subsection sections relating specifically to messages and channels. Here we discuss the axiomatization of domain-specific atomic processes.
Domain-specific atomic processes are domain specific and as such are not part of the FLOWS ontology per se. Nevertheless, FLOWS imposes a syntactic form on the axioms that comprise a domain-specific axiomatization of an atomic process. Below we provide a reference grammar for the axioms associated with inputs, outputs preconditions and effects. In practice, we do not expect users of FLOWS to write these axioms, but rather to provide a specification of salient features of their process IOPEs using a high-level process description syntax that is then compiled into the syntactically correct FLOWS axioms. The syntax we propose is below, followed by the reference grammar.
Process Description Syntax
The IOPEs for atomic processes may be specified using the following presentation syntax. Note that both outputs and effects may be conditional. The BNF grammar below, captures this. A psuedo_state_formula is a state formula whose occurrence argument is suppressed. Non-fluent formulae in psuedo_state_formulas may be differentiated by prefixing the relation name with an asterisk (*).
< atomicprocess_name > {
Atomic
input < input_fluent_name >
output < output_fluent_name > | < psuedo_state_formula >
< output_fluent_name >
precondition < psuedo_state_formula >
effect < psuedo_state_formula > | < psuedo_state_formula >
; < psuedo_state_formula >
}
Reference Grammar
Walking Through an Example
Process Description Syntax
Here is the presentation syntax for an atomic process called simple_buy_book. It has two inputs, client_id and book_name,
and three outputs:
i) a confirmation of the request, ii) the book price, if the book is in stock,
and iii) an order rejection, if the book is out of stock. This simple
atomic process also has one effect. The atomic process will debit the client's
account (assumed to be on file and accessible through the client_id) by
the price of the book, if the book is in stock. Note that as with the majority
of non-device Web services, there are no (physical) preconditions associated
with the execution of that atomic process. The process must merely know
its inputs in order to execute.
simple_buy_book {
Atomic
input client_id
input book_name
output request_confirm(client_id,book_name)
output (name(book,book_name) and in_stock(book)) price(book)
ouptput (name(book,book_name) and not in_stock(book)) reject(client_id,book_name)
effect (name(book,book_name) and in_stock(book)) debit(client_id,price(book))
}
Domain-Specific Axiomatization
The process description syntax is manually or automatically compiled into the
following input and output relations:
input(simple_buy_book, client_id)
input(simple_buy_book, book_name)
output(simple_buy_book, true, request_confirm(client_id,book_name))
output(simple_buy_book, condition1(book_name), price(book))
output(simple_buy_book, condition2(book_name), reject(client_id,book_name))
effect(simple_buy_book, condition1(book_name),debit(client_id,price(book))
In order to avoid reifying formulae, we associate a unique fluent with the condition formula of an output or effect, so that we may talk about it in the relations output and effect.
forall ?occ,?booknm,?book
((condition1(?booknm,?occ) ==> (name(?book,?booknm) and in_stock(?book, ?occ))) and
(name(?book,?booknm) and in_stock(?book,?occ)) ==> condition1(?booknm,?occ))
forall ?occ,?booknm,?book
((condition2(?booknm,?occ) ==> (name(?book,?booknm) and not in_stock(?book,?occ))) and
(name(?book,?booknm) and in_stock(?book,?occ)) ==> condition2(?booknm,?occ))
Following the reference grammar, the IOPEs declared in the presentation syntax are manually and automatically compiled into IOPE axioms according to the reference grammar.
Input Axioms, i.e., Knowledge-Precondition Axioms
Each input fluent becomes a knowledge precondition of the occurrence of the simple_buy_book atomic process. Note that there are no non-knowledge preconditions to the execution of this atomic process.
forall ?occ,?clientid,?booknm,?book
(occurrence_of(?occ,simple_buy_book(?clientid,?booknm)) and legal(?occ)
==>
(holds(Kref(book_name(?s)),?occ) and holds(Kref(client_id(?s)),?occ))
Effect Axiom
The sole effect of execution of this atomic process is that the client's account will be debited, if the book is in stock.
forall ?occ,?clientid,?booknm,?book
(occurrence_of(?occ,simple_buy_book(?clientid,?booknm)) and
name(?book,?booknm) and prior(in_stock(?book,?occ)
==>
holds(debit(?clientid,price(?book,?s,?occ)),?occ)
Output Axioms, i.e., Knowledge-Effect Axioms
A confirmation request is an unconditional output of the simple_buy_book atomic process.
forall ?occ,?clientid,?booknm,?book
occurrence_of(?occ,simple_buy_book(?clientid,?booknm))
==>
holds(Kref(request_confirm(?clientid,?booknm)),?occ)
If the book is in stock, then the price of the book will be an output, i.e., a knowledge effect of the simple_occ_book atomic process.
forall ?occ,?clientid,?booknm,?book
(occurrence_of(?occ,simple_buy_book(?clientid,?booknm)) and
name(?book,?booknm) and prior(in_stock(?book,?occ))
==>
holds(Kref(price(?book)),?occ)
If the book is not in stock, then an order rejection message is output. It is a knowledge effect of the simple_occ_book atomic process.
forall ?occ,?clientid,?booknm,?book
(occurrence_of(?occ,simple_buy_book(?clientid,?booknm)) and
name(?book,?booknm) and not prior(in_stock(?book,?occ)))
==>
holds(Kref(reject(?clientid,?booknm)),?occ)
Building on this introduction, the example in
Section 2.1
of the
Application Scenarios document
describes a simple
hypothetical service that involves several domain-specific and
message-handling atomic processes. Application Scenario
Example 2.1(a)
illustrates, at a high level, how the
sequences of atomic process occurrences in an
occurrence (execution) of the overall system
might be constrained by the FLOWS-Core ontology axioms
and an application domain theory.
Service IOPEs
Service IOPEs, or more accurately, the IOPEs of the complex activity associated with a service, are not formally defined. Inputs, outputs, preconditions and effects are only specified for atomic processes. Nevertheless, for a number of automation tasks, including automated Web service discovery, enactment and composition, it may be compelling to consider the inputs, outputs, preconditions and effects of the complex activity that describes the full process model of the service, service_activity(service,activity). In some cases, these properties may be inferred from the IOPEs of the constituent atomic processes, producing IOPEs conditional on the control constraints defining the service. As an alternative to repeated inference, these computed IOPEs may be added to the representation of the complex activity defining the service.
We provide a means for the axiomatizer to define the IOPEs of a complex activity, using the relations and process description syntax described above for atomic processes. Note that these relations are merely descriptive and though it is desirable, the ontology does not mandate that they reflect the IOPEs of their constituent atomic processes.
The IOPEs for complex activities are systematically translated into ROWS using the SWSL-Rules language. They are commonly used for Web service discovery.
Link to ROWS Axiomatization for IOPEs.
In general, the activity associated with a service can be decomposed into subactivities associated with other services, and constraints can be specified on the ordering and conditional execution of these subactivities. The composedOf relation specifies how one activity is decomposable into other activities.
A key aspect of several Web services standards, including WSDL, BPEL, and WS-Choreography, is the explicit representation and use of messages. This fundamental approach to modeling data flow is largely absent from OWL-S. To enable the direct study of the semantic implications of messages, they are modeled as explicit objects in the FLOWS-Core ontology.
(Although messages are represented as explicit objects, it is nevertheless possible with FLOWS to create an application domain in which the messaging is transparent. This might be done by incorporating specific constraints into the application domain, or by using a views mechanism.)
Associated with messages are message_type and payload (or "body"), and perhaps other attributes and properties. Messages are produced by atomic processes occurrences of kind Produce_Message. Every message has a message_type, which is again an object in the FLOWS ontology. As detailed below, these message types will be associated with one or more (abstract) functional fluents, which, intuitively speaking, will provide information on how the payloads of messages of a given message type impact the knowledge of the service activity occurrences reading the message, and the knowledge pre-conditions of the service attempting to produce the message. FLOWS-Core is agnostic about the form of message type itself. It could be an XML datatype, a database schema, or an OWL-like class description of a complex object.
Information about messages
can be represented in FLOWS-Core
using a 3-ary relation message_info.
message_info(msg, msg_type, payload)
where
An important property of messages, which is captured in the
axiomatization of FLOWS-Core, is that the type and
payload value associated with a message are immutable.
This is suggested by the fact that messages_info
is a relation rather than a fluent -- the tuples in
relation messages_info are not time-varying.
(At first glance, the reader may find this counter-intuitive:
If a message is created and destroyed through time,
then how can information about its payload be
fixed or known "before" and "after" the message's existence?
The answer is that an interpretation of a FLOWS-Core
theory holds information about the full history of the
set of possible occurrences (executions) of the application domain
being modelled.
From that perspective, which is "outside" of the time modeled
in the domain, the relationship between a given message object and
its payload is independent of the creation and destruction
times of the message.)
In FLOWS-Core there are three relations which relate atomic process occurrences to the messages they access or manipulate.
produces(o,msg), reads(o,msg), destroy_message(o,msg)
where
(Additional constraints may apply to these activities if channels are in use. This is considered in the next subsection.)
Since FLOWS-Core does not commit to the form of message types,
but only to the kinds of information that they can convey,
FLOWS-Core includes a 2-ary relation described_by.
described_by(msg_type, io_fluent)
where
described_by
might associate multiple io_fluents with
a single msg_type, corresponding
to the different component fluent parts that can be encoded
into the payloads of messages having this message type.
Intuitively, the association of multiple io_fluents with
a message type should be interepreted as a conjunction,
e.g., saying that a message will hold both an ISBN and
a book title.)
Analogous to the treatment of the inputs and outputs of
domain-specific atomic processes, the io_fluent(s) associated
with message types are constrained by the
domain theory to correspond to appropriate values at
the times when a message of given type is being
produced or read.
In this way,
the relation described_by aids
in defining the knowledge effects of
a Read_Message activity as well as the knowledge pre-conditions
that are present for a
Produce_Message atomic process.
A Produce_Message atomic process occurrence has the effect of creating a message (and possibly its placement on a channel). The payload (or "body") of the message, in many cases, is some or all of the output of some previous atomic process occurrence. Indeed, a knowledge pre-condition for producing a message will be knowing the values needed to populate this payload. This knowledge might be derived from parts or all of the outputs (knowledge effects) of several previous domain-specific and/or read-message atomic process occurrences. In the case of communication between services, reading a message containing particular io_fluent(s), establishes that subsequently this io_fluent is known (to the service occurrence that read the message). As such the io_fluent(s) can be used to establish the knowledge preconditions of another atomic process occurrence. Once again, establishment of knowledge preconditions and effects is domain-specific, and thus is not within the purview of the FLOWS ontology. Rather, we provide a reference grammar for the Produce_Message and Read_Message atomic processes, which is consistent with the reference grammar for Atomic Process.
In many models of Web services found in the standards and the research literuature, if a message is read by some service then it is not available to be read by any other service. Because of the separation of the Read_Message and Destroy_Message atomic processes, FLOWS-Core is more general than those models. In particular, in some application domains, many service activity occurrences can read a message before it is "destroyed".
As noted previously, the example of Section 2.1 (in the Application Scenarios document) illustrates the notions of domain-specific and message-handling atomic processes. Example 2.1(b) there illustrates in particular how constraints on the relationships of domain-specific atomic prcesses can be used to infer, in the context of an occurrence of the overall system, that messages with certain characteristics must have been transmitted. The example of Section 2.2 provides additional illustrations of message-handling atomic processes.
Since messages are read, produced and destroyed via atomic processes, the production, reading and destruction of messages may be explicitly encoded by a domain axiomatizer, as special atomic processes, following the syntax for atomic process axioms described in the Reference Grammar above. Nevertheless, the FLOWS ontology is sufficiently expressive that the existence of necessary activity occurrences related to messages can be inferred from the axiomatization. This illustrates one aspect of the power of the FLOWS ontology.
As noted before, channels are objects in the FLOWS-Core ontology, used as an abstraction related to message-based communication between Web services. Intuitively, a channel holds messages that have been "sent" and may or may not have been "received". In FLOWS-Core, there is no requirement that a message has to be "sent" using a channel. However, it the message is associated with a channel, then it must satisfy a variety of axioms.
The notion of 'channel' is inspired by, but not identical to, the notion of 'channel' found in many process algebras. It is typical in process algebras that the act of transmitting a message m via a channel involves two simultaneous actions, in which one process sends m and another process that receives m. In the basic notion of channels provided in FLOWS-Core there is no requirement for this form of simultaneity.
In FLOWS-Core, messages in transit may be associated with at most one channel (corresponding intuitively to the idea that the message is being sent across that channel). As part of an application domain, a channel might be associated with a single source service and single target service, or might have multiple sources and/or targets.
Channels might be pre-defined, i.e., included in the definition of an application domain. Or channels can be created/destroyed "on the fly" by atomic process occurrences in an application domain. For this reason, fluents are used to hold most of the information about channels.
We now introduce the fluents of FLOWS-Core that are used to hold information about channels and their associated messages. Three of the fluents are
channel_source(c,s), channel_target(o,s'), channel_mtype(o,msg_type)
where
The fourth fluent for channels in FLOWS-Core is
channel_mobject(c,msg)
where
As noted above, FLOWS-Core provides the possibility that channels can be created and destroyed. This might be accomplished by (i) services which correspond to human administrators, (ii) specialized, automated services which have essentially an administrative role, (iii) ordinary Web services, or (iv) atomic processes which are not associated with any service. In any of these cases, the following kinds of atomic processes are supported.
In most cases these have straight-forward semantics. In the case of destroying a channel, all messages on that channel are viewed as simultaneously "destroyed".
An illustration involving the dynamic creation and modification of channels is provided in Section 2.2(d) (in the Application Scenarios document)
Channels are not required to exist; however, if they do exist, then they satisfy the following constraints:
Most Web services cannot be modeled as simple atomic processes. They are better modeled as complex activities that are compositions of other activities (e.g., other complex activities and/or atomic processes). The Control Constraints extension to FLOWS-Core provides a set of workflow or programming language style control constructs (e.g., sequence, if-then-else, iterate, repeat-until, split, choice, unordered) that provide a means of specifying the behavior of Web services as a composition of activities. Control constraints impose constraints on the evolution of the complex activity they characterize. As such, specifications may be partial or complete. Reflecting some of PSL's underpinnings in the situation calculus, and by extension Golog, these control constructs follow the style of Web service modeling of atomic and composite processes presented in [McIlraith01] and [OWL-S 1.1].
The subactivity occurrences of a Split activity are partially ordered, such that every linear extension of the ordering corresponds to a branch of the activity tree for the Split activity.
Link to Reference
Grammar
Process descriptions for Split activities specify the subactivity
occurrences whose ordering is constrained by two relations from the PSL
Ontology: soo_precedes (which imposes a linear ordering on subactivity
occurrences) and strong_parallel (which allows all possible linear
orderings on subactivity occurrences).
Process Description Syntax
< activity_name > {
Split
occurrence < subocc_varname > < subactivity_name >
< subocc_varname1 > soo_precedes < subocc_varname2 >
< subocc_varname1 > strong_parallel < subocc_varname2 >
}
Examples
buy_product(?Buyer) {
Split
occurrence ?occ1 transfer(?Fee,?Buyer,?Broker)
occurrence ?occ2 transfer(?Cost,?Buyer,?Seller)
?occ1 strong_parallel ?occ2
}
forall ?y split(buy_product(?y))
forall ?occ,?Buyer
occurrence_of(?occ,buy_product(?Buyer)) ==>
(exists ?occ1,?occ2,?Fee,?Cost,?broker,?Seller
occurrence_of(?occ1,transfer(?Fee,?Buyer,?Broker)) and
occurrence_of(?occ2 transfer(?Cost,?Buyer,?Seller)) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ) and
strong_parallel(?occ1,?occ2))
The subactivity occurrences of a Sequence activity are totally ordered (that is, the activity tree for the activity contains a unique branch).
Reference
Syntax
Process descriptions for Sequence activities specify the subactivity
occurrences whose ordering is constrained by one relations from the PSL
Ontology: soo_precedes (which imposes a linear ordering on subactivity
occurrences).
Process Description Syntax
< activity_name > {
Sequence
occurrence < subocc_varname > < subactivity_name >
< subocc_varname1 > soo_precedes < subocc_varname2 >
}
Examples
transfer(?Amount,?Account1,?Account2) {
Sequence
occurrence ?occ1 withdraw(?Amount,?Account1)
occurrence ?occ2 withdraw(?Amount,?Account2)
?occ1 soo_precedes ?occ2
}
forall ?x,?y,?z sequence(transfer(?x,?y,?z))
forall ?occ
occurrence_of(?occ,transfer(?Amount,?Account1,?Account2)) ==>
(exists ?occ1,?occ2
occurrence_of(?occ1,withdraw(?Amount,?Account1)) and
occurrence_of(?occ2,deposit(?Amount,?Account2)) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ) and
soo_precedes(?occ1,?occ2,transfer(?Amount,?Account1,?Account2))
The subactivity occurrences of a Split activity are partially ordered, such that all subactivities are incomparable and every linear extension of the ordering corresponds to a branch of the activity tree.
Reference
Syntax
Process descriptions for Unordered activities specify the subactivity
occurrences of the activity.
Process Description Syntax
< activity_name > {
Unordered
occurrence < subocc_varname > < subactivity_name >
}
Examples
ConferenceTravel {
Unordered
occurrence ?occ1 book_flight
occurrence ?occ2 book_hotel
occurrence ?occ3 register
}
Unordered(ConferenceTravel)
forall ?occ
occurrence_of(?occ,ConferenceTravel) ==>
(exists ?occ1,?occ2,?occ3
bag(?occ) and
occurrence_of(?occ1,book_flight) and
occurrence_of(?occ2,book_hotel) and
occurrence_of(?occ3,register) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ) and
subactivity_occurrence(?occ3,?occ))
A Choice activity is a nondeterministic activity in which only one of the subactivities occurs.
Reference
Syntax
Process descriptions for Choice activities specify the subactivity
occurrences of the activity.
Process Description Syntax
< activity_name > {
Choice
occurrence < subocc_varname > < subactivity_name >
}
Examples
travel(?Destination) {
Choice
occurrence ?occ1 book_flight(?Destination)
occurrence ?occ2 book_train(?Destination)
}
forall ?x choice(travel,?x)
forall ?occ,?Destination
occurrence_of(?occ,travel(?Destination)) ==>
((exists ?occ1
occurrence_of(?occ1,(book_flight,?Destination)) and
subactivity_occurrence(?occ1,?occ))
or
(exists ?occ2
occurrence_of(?occ2,(book_train,?Destination)) and
subactivity_occurrence(?occ2,?occ)))
An IfThenElse activity is a nondeterministic activity such that the subactivity which occurs depends on the state condition that holds prior to the activity occurrence.
Reference
Syntax
Process descriptions for IfThenElse activities consist state
constraints on the subactivity occurrences of the activity. Each
constraint specifies a state condition and the subactivity that occurs
when the state condition is satisfied.
Process Description Syntax
< activity_name > {
IfThenElse
if < state_formula > then occurrence < subocc_varname > < subactivity_name >
}
Examples
travel(?Destination, ?Account) {
IfThenElse
if greater(budget_balance(?Account),1000) then occurrence ?occ1 book_deluxe(?Destination)
if greater(1001,budget_balance(?Account)) then occurrence ?occ2 book_economy(?Destination)
}
forall ?x IfThenElse(travel,?x)
forall ?occ,?Destination
(occurrence_of(?occ,travel(?Destination) and
prior(greater(budget_balance(?Account),1000),?occ))
==>
(exists ?occ1
occurrence_of(?occ1,book_deluxe(?Destination)) and
subactivity_occurrence(?occ1,?occ))
forall ?occ,?Destination
(occurrence_of(?occ,travel(?Destination) and
prior(greater(1000,budget_balance(?Account)),?occ))
==>
(exists ?occ2
(occurrence_of(?occ2,book_economy(?Destination)) and
subactivity_occurrence(?occ2,?occ))
An Iterate activity, is composed of a subactivity that occurs an indeterminate number of times.
Reference
Syntax
Process descriptions for Iterate activities specify the subactivity
occurrences of the activity.
Process Description Syntax
< activity_name > {
Iterate
occurrence < subocc_varname > < subactivity_name >
}
Examples
In a RepeatUntil activity, there are repeated occurrences of the subactivity until the state condition holds.
Link to Reference
Syntax
Process descriptions for RepeatUntil activities specify the subactivity
occurrences of the activity, and the state condition that constrains
the end of the occurrence of the activity.
Process Description Syntax
< activity_name > {
Iterate
while < state_formula > then occurrence < subocc_varname > < subactivity_name >
}
Examples
The intent of this extension is to provide a family of simple constraints based on sequencing properties of atomic processes. This enables succinct specification of requirements such as that payment must be received before shipping.
Any branch of the activity tree of an OrderedActivity satisfies the
ordering constraints in the process description.
Note that this is weaker than the Control Constraints, since there may
exist sequences of subactivity occurrences that satisfy the ordering
constraints but which do not correspond to branches of the activity
tree for an OrderedActivity.
Reference
Syntax
Process descriptions for OrderedActivity specify the subactivity
occurrences and sentences using the basic ordering relation min_precedes
that is axiomatized in the PSL Ontology.
Process Description Syntax
The presentation syntax provides three constructs that facilitate the specification of ordering constraints:
< activity_name > {
OrderedActivity
occurrence < subocc_varname > < subactivity_name >
< subocc_varname1 > ; < subocc_varname2 >
< subocc_varname1 > , < subocc_varname2 >
! < subocc_varname >
}
Examples
Activity1 {
OrderedActivity
occurrence ?occ1 a
occurrence ?occ2 b
?occ1 ; ?occ2
}
forall ?occ,?occ1,?occ2
(occurrence_of(?occ,S) and
occurrence_of(?occ1,a) and
occurrence_of(?occ2,b) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ))
==>
min_precedes(?occ1,?occ2,S)
Activity2 {
OrderedActivity
occurrence ?occ1 a
occurrence ?occ2 b
occurrence ?occ3 c
?occ1 ; (?occ2 , ?occ3)
}
forall ?occ,?occ1,?occ2
(occurrence_of(?occ,S) and
occurrence_of(?occ1,a) and
occurrence_of(?occ2,b) and
occurrence_of(?occ2,c) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ))
==>
(min_precedes(?occ1,?occ2,S) and
min_precedes(?occ1,?occ3,?S))
Activity3 {
OrderedActivity
occurrence ?occ1 a
occurrence ?occ2 b
occurrence ?occ3 c
occurrence ?occ2.d
occurrence ?occ5 e
?occ1 ; ?occ2
?occ2 ; ?occ3
?occ1 ; ?occ2.
?occ2.; ?occ5
}
forall ?occ,?occ1,?occ2,?occ3,?occ2.?occ5
(occurrence_of(?occ,S) and
occurrence_of(?occ1,a) and
subactivity_occurrence(?occ1,?occ) and
occurrence_of(?occ2,b) and
subactivity_occurrence(?occ2,?occ) and
occurrence_of(?occ3,c) and
subactivity_occurrence(?occ3,?occ) and
occurrence_of(?occ2.d) and
subactivity_occurrence(?occ2.?occ) and
occurrence_of(?occ5,e) and
subactivity_occurrence(?occ5,?occ))
==> (min_precedes(?occ1,?occ2,S) and
min_precedes(?occ2,?occ3,S) and
min_precedes(?occ1,?occ2.S) and
min_precedes(?occ2.?occ5,S))
Activity5 {
OrderedActivity
occurrence ?occ1 a
occurrence ?occ2 b
?occ1 ; ! ?occ2
}
forall ?occ,?occ1,?occ2
(occurrence_of(?occ,S) and
occurrence_of(?occ1,?a) and
subactivity_occurrence(?occ1,?occ) and
occurrence_of(?occ2,b) and
subactivity_occurrence(?occ2,?occ))
==> (not min_precedes(?occ1,?occ2,S))
The intent of this extension is to make it easy to specify constaints requiring that there are indeed occurrences of certain activities, e.g., payments, or the transmission of certain messages.
Any branch of the activity tree of an OccActivity satisfies the occurrence constraints on subactivities.
Reference
Syntax
Process descriptions for OccActivity are sentences that specify the
existence or nonexistence of subactivity occurrences within occurrences
of the activity.
Process Description Syntax
The presentation syntax provides three constructs that facilitate the
specification of occurrence constraints:
< activity_name > {
OccActivity
occurrence < subocc_varname > < subactivity_name >
< subocc_varname1 > & < subocc_varname2 >
< subocc_varname1 > + < subocc_varname2 >
~ < subocc_varname >
}
Examples
Activity1 {
OccActivity
occurrence ?occ1 a
occurrence ?occ2 b
?occ1 & ?occ2
}
forall ?occ
occurrence_of(?occ,S) ==>
(exists ?occ1,?occ2
occurrence_of(?occ1,a) and
occurrence_of(?occ2,b) and
subactivity_occurrence(?occ1,?occ) and
subactivity_occurrence(?occ2,?occ))
Activity2 {
OccActivity
occurrence ?occ1 a
occurrence ?occ2 b
occurrence ?occ3 c
?occ1 & (?occ2 + ?occ3)
}
forall ?occ
occurrence_of(?occ,S) ==>
(exists ?occ1
occurrence_of(?occ1,a) and
subactivity_occurrence(?occ1,?occ) and
(exists ?occ2
occurrence_of(?occ2,b) and
subactivity_occurrence(?occ2,?occ))
or
(exists ?occ3
occurrence_of(?occ3,c) and
subactivity_occurrence(?occ3,?occ)))
Activity2.{
OccActivity
occurrence ?occ1 b
~ ?occ1
}
forall ?occ
occurrence_of(?occ,S) ==>
(not (exists ?occ1
occurrence_of(?occ1,b) and
subactivity_occurrence(?occ1,?occ)))
Activity5 {
OccActivity
occurrence ?occ1 a
occurrence ?occ2 b
?occ1 & ~ ?occ2
}
forall ?occ
occurrence_of(?occ,S) ==>
(exists ?occ1
occurrence_of(?occ1,?a) and
subactivity_occurrence(?occ1,?occ) and
(not (exists ?occ2
(occurrence_of(?occ2,b) and
subactivity_occurrence(?occ2,?occ) and
min_precedes(?occ1,?occ2 S)))
This extension provides an explicit mechanism for associating triggered activities with states (of an overall system) that satisfy a given condition. A particular use of State Constraints is in exception handling.
A TriggeredActivity is an activity which occurs whenever a state condition is satisfied.
Process descriptions for a TriggeredActivity specifies the state condition that is associated with occurrences of the activity.
Process Description Syntax
< activity_name > {
TriggeredActivity
< state_formula >
}
Examples
Exceptions are central elements of most process modeling languages. For example, BPEL [BPEL 1.1], provides mechanisms based on faults, fault handlers, and compensation, for specifying exceptions and their treatments. FLOWS offers a variety of approaches to model such exceptions, which are presented in the following. The approaches presented below are not prescriptive.
The simplest method for exception handling is to define an exception handler as an activity whose occurrence is triggered by satisfaction of a state constraint.
An exception handler is defined as an activity that gets triggered when a specified (exceptional) state occurs. Consequently, the triggered activity state constraint (see section 2.2.5.1 above) can be used.
Process Description Syntax
< activity_name > {
ExceptionHandlerActivity
< exception_state_formula >
}
Most process modeling approaches and programming languages (such as Java [Gosling96]) require exceptions either to be raised or ("thrown") explicitly by a modeled element (i.e., a process) or by the execution environment. A raised exception is then sequentially passed to exception handler, which have registered for it. Essentially, this approach represents the raising of a "message" which describes the exception and the catching (or consuming) of this message by some type of handler.
We place the term 'message' in quotes because this can be embodied in two ways in the conceptual model presented here. In the first embodiment, these "messages" would be messages between Web services, i.e., messages in the sense described above. In the second embodiment, these "messages" would be internal to a Web service, and would involve the passing of information from one family of activities in the service (intuitively, the main body of the service) to another family of activities in the service (intuitively, the exception-handling or fault-handling portion of the service).
In either case, the creation and transmission of an exception-based "message" can be modeled as a refinement of the notion of state-based exception handling. In particular, if the system is in a state in which an exception condition is satisfied, then an activity that creates or in some other way embodies a "message" transmission is triggered.
Exceptions get raised explicitly as messages to the parent activity. The parent activity can explicitly register an exception handler to listen for the specific exception message to be raised. If no exception handler is registered, then the mechanism "executing" the specification will be informed of the exception and may halt the execution of the overall process.
Process Description Syntax
If the activity raising the exception is not an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Unordered | Split | Sequence | Choice | IfThenElse | Iterate | RepeatUntil
...
occurrence ?occ RaiseException(< exception_name > )
...
}
< exception_raising_activity_name > {
Unordered | Split | Sequence | Choice | IfThenElse | Iterate | RepeatUntil
...
occurrence < subocc_varname > < subactivity_name >
...
raises_exception < exception_name >
}
If the activity raising the exception is an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Atomic
input < input_fluent_name >
output < output_fluent_name > | < psuedo_state_formula >
< output_fluent_name >
precondition < psuedo_state_formula >
effect < psuedo_state_formula > | < psuedo_state_formula >
< psuedo_state_formula >
raises_exception < exception_name >
}
If the activity catching the exception is not an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Unordered | Split | Sequence | Choice | IfThenElse | Iterate | RepeatUntil
...
occurrence < subocc_varname > < subactivity_name >
...
catches_exception < exception_name >
}
If the activity catching the exception is an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Atomic
input < input_fluent_name >
output < output_fluent_name > | < psuedo_state_formula > < output_fluent_name >
precondition < psuedo_state_formula >
effect < psuedo_state_formula > | < psuedo_state_formula >
< psuedo_state_formula >
catches_exception < exception_name >
}
Intended Semantics
The intended semantics for the extended exception handling
mechanism are described in great detail in [Klein 00a, Klein 00b].
Summarized it is the following (see also Figure 2.2):
This setup allows to
develop hierarchy of exception types (similar to Java), where each
exception is associated with a (potentially domain independent)
collection different exception handlers (see [Klein 00a] Figure 7 for an
example).
The various approaches to
exception handling within SWSL are illustrated in the application
scenarios below
Process Description Syntax
The process description for the exception itself satisfies the following syntax:
< exception_name > {
is_handled_by < exception_handling_activity_name >
is_found_by < exception_finding_activity_name >
is_fixed_by < exception_fixing_activity_name >
is_detected_by < exception_detection_activity_name >
is_anticipated_by < exception_anticipation_activity_name >
is_avoided_by < exception_avoidance_activity_name >
is_resolved_by < exception_resolution_activity_name >
}
If the activity raising the exception is not an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Unordered | Split | Sequence | Choice | IfThenElse | Iterate | RepeatUntil
...
occurrence ?occ RaiseException(< exception_name > )
...
}
< exception_raising_activity_name > {
Unordered | Split | Sequence | Choice | IfThenElse | Iterate | RepeatUntil
...
occurrence < subocc_varname > < subactivity_name >
...
raises_exception < exception_name >
}
If the activity raising the exception is an AtomicProcess, then the service description satisfies the following syntax:
< exception_raising_activity_name > {
Atomic
input < input_fluent_name >
output < output_fluent_name > | < psuedo_state_formula > < output_fluent_name >
precondition < psuedo_state_formula >
effect < psuedo_state_formula > | < psuedo_state_formula >
< psuedo_state_formula >
raises_exception < exception_name >
}
This subsection briefly describes some other possible extensions to FLOWS-Core. The intention here is to briefly indicate how FLOWS-Core can indeed serve as a foundation for the formal study of several models and approaches to Web services found in standards and in the literature. This underscores the fact that FLOWS-Core can serve as a common foundation for a unified study of two or more currently disparate Web services models.
This section describes a modeling construct above FLOWS-Core, that could be used as the basis for a PSL extension of FLOWS-Core.
In many models and standards for Web services, including BPEL, the Roman model, the Conversation model, and the Guarded Automata model, it is typical to consider both Web services and the Web servers that run them. In essence, a Web server is an executing process (i.e., an occurrence of some PSL complex activity) that has the ability to "launch" occurrences of one or more kinds of service activities (i.e., that includes atomic processes whose occurrences have the impact of creating service activity occurrences). The extension Meta-Server is intended to capture salient aspects of such frameworks.
In this possible extension, a (Formal) Server is
itself a Formal Service.
There could be a fluent
server_service(Server:activity, Service:activity),
where server_service(R, S) has the
intuitive meaning that Server R is managing Service S.
A Server R will include at least the following kind of service-specific atomic process:
server_service).
Occurrences of activities of this type
will typically include the creation of
a message,
which is read as the first atomic process
occurrence of the newly launched service occurrence.
A Formal Service may have other kinds of atomic processes. For example, it is typical that it would have Read_Message atomic processes. In typical application, a Server would only read messages that are intended to launch new occurrences of a Service that is managed by the Server. It is also natural to include Destroy_Message.
Axioms would enforce that a Server R can
launch occurrences of Service S only if
server_service(R, S) holds.
Furthermore, each Service can be associated with at
most one Server in server_service.
An illustration of a Server is provided in Section 2.2(c) (in the Application Scenarios document)
(In [BPEL 1.1]
(and in BPEL 1.0),
messages which are intended to
launch new occurrences of a service activity, have the value of
special-purpose parameter createInstance set to
"yes"; messages intended for existing service activity occurrences
have this parameter set to "no".
In BPEL 1.1, it is required that the first step
of the newly launched service activity occurrence
is the receiving of the launching message.
In the Meta-Service extension here we have the
Server actually read (in essence, receive) the message.
It is possible to build a theory that builds on Meta-Service
to capture the semantics of Service launching as specified in BPEL 1.1.)
Although not explicitly included in the description of the
potential extension Meta-Server presented here,
it is possible in an application domain to include additional
atomic processes with a server, which intuitively have
the impact of terminating services associated with the server,
or monitoring their execution.
A server may also have atomic processes that
embody administrative actions, such as
creating/destroying channels.
We note that in practice, it will be typical to associate
a family of domain-specific fluents with a server, with
a constraint that only services associated by
server_service with that
server are able to access or update those fluents.
This possible extension provides constructs for explicitly modeling that a Web service has a variable-based local store with imperative commands for assigning and accessing values associated with the variables. The use of a local store is found in [BPEL 1.1], and in theoretical models such as Guarded Automata. These constructs are not included in the FLOWS-Core, to permit the exploration of other forms of information passing (e.g., in the style of functional programming or based on a style inspired by data flow).
This section describes three possible extensions to FLOWS-Core. These may be particularly useful because they capture an approach for managing messages common to many Web service implementations.
The Ordered channels possible extension would include axioms that would enforce, intuitively speaking, that all or some of the channels include an ordering for the message objects that are held in the channel at a given time. This ordering might be total or partial.
The Read & destroy possible extension would include axioms which have the intuitive meaning that whenever a service occurrence reads a message, then in the very next step of execution that occurrence destroys that message. This will imply that each message is read at most once (because it is destroyed immediately thereafter). This restriction corresponds to an assumption made by many Web services models, including, e.g., [BPEL 1.1] and Guarded Automata.
The FIFO message queue possible extension is intended to captures the standard first-in-first-out behavior for channels. This extension would build on top of the Ordered channels and Read & destroy extensions. This would include axioms so that the (relevant) channels have a total ordering on contained message objects, that whenever a message is placed on the channel it has the least position in the ordering; that if a message is read (and destroyed) from the channel then it must have the greatest position in the channel; and that the relative ordering of messages on a channel and that the relative ordering of messages on a channel never changes during their existence.
FLOWS-Core is very general with regards to the types of values that can be used in parameters, both as input or output of domain-specific atomic processes, and as the payload of messages. In some cases, it may be useful to create theories or extensions on top of PSL-Core, that can be used for "encoding" and "decoding" certain kinds of commonly arising payloads. We briefly consider here one way in which a uniform approach can be developed for "encoding" and "decoding" paramater values that are essentially relations, i.e., finite sets of records with uniform type. (Other encodings are possible.)
The basic approach to representing this is illustrated
in
Section 2.2(a)
(in the
Application Scenarios document)
by fluents such as Transport_content_lists. In that
example, an occurrence of the Warehouse_order_fulfillment
service can perform an occurrence o of the
activity send_shipment_from_warehouse using a
parameter transport_content_list_idR as the value
of this parameter for o. Under the intended operation, the
actual contents of the shipment can be obtained from fluent
Transport_content_lists.
by selecting on "transport_content_list_id = R"
and then projecting out the
transport_content_list_id field.
This will give a set of records with signature
item_id:int, quantity:int.
A similar encoding schema can be used for relation-valued
parameters with different signatures,
and an analogous encoding can be formulated for
XML-Valued Parameters.
We briefly describe here several modeling constructs that lie above FLOWS-Core, in order to build up to a representation of the process model aspects of services described using [BPEL 1.1]. We also suggest a refinement of BPEL, called here BPEL++, which incorporates the use of meta-service, and specific design choices on how messages are passed between BPEL services.
All of these possible extensions, along with possible extensions for Local store, Control constructs and Exceptions, can be used in defining a possible extension BPEL(process), which can serve as a formal, declarative specification of essential aspects of some version of BPEL (e.g., [BPEL 1.1]).
The BPEL(process) possible extension in turn might be combined with Meta-service and FIFO Message Queue to create a possible extension BPEL++(process), which can incorporate often made assumptions concerning message passing semantics that are not explicitly mentioned in the BPEL 1.1 specification.
In many approaches to Web services, including [BPEL 1.1], a flowchart-based process model is used to specify the internal process flow of Web services. This approach is also found in OWL-S, and is essentially embodied in the Control Constructs extension of FLOWS-Core. In this section we briefly consider an alternative basis for the internal process model of Web services, based on the use of automata. Of course, there are other process modeling paradigms that may also be considered, including e.g., Petri nets and models, such as some process algebras, with unbounded sub-process spawning (see also the example in Section 2.3 of the Application Scenarios document).
We mention two important automata-based approaches from the literature.
Section 2.2(b) (in the Application Scenarios document) gives a brief illustration of how a guarded automaton can be used to specify the process model of a service.
The preceding material of this section describes FLOWS, the First-Order Logic Ontology for Web Services, which is expressed in SWSL-FOL. To enable implementations in reasoning and execution environments based on logic-programming, we provide, in Appendix C, the Rules Ontology for Web Services (ROWS). ROWS is a (partial) translation of FLOWS into SWSL-Rules. The intent of each ROWS axiom is identical to what is explained above for the corresponding axioms of FLOWS. However, because SWSL-Rules is inherently less expressive than SWSL-FOL, some axioms in ROWS are weakened with respect to the corresponding axiom in SWSL-FOL. The strategies by which the axioms have been translated into SWSL-Rules are summarized in Section 5 below.
ROWS also defines several top-level classes, which correspond to similar
classes in FLOWS. These classes
are Service,
Process,
AtomicProcess,
Message,
and Channel.
Services and service descriptors.
The Service class is defined by its descriptors and the process
associated with the service.
Service descriptors are defined
in Section 2 and processes
in Section 3.1.
prefix xsd = "http://www.w3.org/2001/XMLSchema".
Service[
name *=> xsd#string,
author *=> xsd#string,
contactInformation *=> xsd#string,
contributor *=> xsd#string,
description *=> xsd#string,
url *=> xsd#string,
identifier *=> xsd#string,
version *=> xsd#string,
releaseDate *=> xsd#date,
language *=> xsd#string,
subject *=> xsd#string,
trust *=> xsd#string,
reliability *=> xsd#string,
cost *=> xsd#string
].
Some of the above string-datatypes may be replaced with more
appropriate data types later. For instance, the type of
the cost descriptor may be replaced with a
type that supports currencies and even compelex arrangements such as payment
plans.
Service[
process *=> Process
].
where the Process class has the following attributes:
Process[ precondition *=> Formula, effect *=> Formula, input *=> ProcessInput, output *=> ProcessOutput ].
Here Formula is a built-in class that consists of all
reifications of formulas in SWSL-Rules and ProcessInput and
ProcessOutput are classes that determine the structure of
inputs and outputs of processes. They will be defined in a
future release.
In addition, the AtomicProcess class
of Section 3.1 is defined as a subclass of
Process:
AtomicProcess :: Process.
Messages and channels.
The Message and the Channel classes
are declared as follows:
Message[
type *=> MessageType,
body *=> MessageBody,
producer *=> AtomicProcess
].
Channel[
contents *=> Message,
source *=> Service,
target *=> Service
].
where the classes MessageType and MessageBody,
which are used to specify the ranges of the attributes type and
body in class Message, will be
defined in a future release.
The semantics of concepts in FLOWS is formally axiomatized using ontology of ISO 18629 ( Process Specification Language ) [Gruninger03a], [Gruninger03b]. The complete set of axioms for the PSL Ontology can be found at PSL Ontology .
FLOWS adopts the basic ontological commitments of ISO 18629-11 ( PSL-Core ):
Some key predicates in PSL-Core include
activity(?a) which holds
when the value of ?a is an activity in
a given interpretation, and
occurrence_of(?occ, ?a) which
holds when the value associated with ?occ
is an occurrence (intuitively, an execution) of the
activity associated with ?a.
PSL-Core also provides terms and predicates for describing
chronological time and relating the activity occurrences to time
(e.g., term beginof(?occ) corresponds to the
time point at which ?occ begins, and
predicate before(?t1,?t2) holds if
the value of ?t1 is chronologically before
the value of ?t2).
The axiomatization of FLOWS also requires the extensions in ISO 18629-12 ( PSL Outer-Core ):
The PSL Ontology uses the subactivity relation to
capture the basic intuitions for the composition of activities. This
relation is a discrete partial ordering, in which primitive activities
are the minimal elements.
The primary predicate that is axiomatized in this extension is
subactivity(?a1,?a2),
which holds when activity ?a1
is component activity of
activity ?a2.
The occurrence trees that are axiomatized in this core theory are partially ordered sets of activity occurrences, such that for a given set of activities, all discrete sequences of their occurrences are branches of the tree. An occurrence tree contains all occurrences of all activities; it is not simply the set of occurrences of a particular (possibly complex) activity.
This core theory introduces the notion of state (fluents). Fluents are changed only by the occurrence of activities, and fluents do not change during the occurrence of primitive activities. In addition, activities have preconditions (fluents that must hold before an occurrence) and effects (fluents that always hold after an occurrence).
This core theory axiomatizes intuitions about the concurrent
aggregation of primitive activities. This concurrent aggregation is
represented by the occurrence of concurrent activities, rather than
concurrent activity occurrences.
In particular, occurrences of atomic activities
are non-decomposable (e.g., in the sense of database concurrency)
-- the occurrence is not interleaved with
other activity occurrences, and all aspects of the occurrence
are completed.
This core theory characterizes the relationship between the occurrence of a complex activity and occurrences of its subactivities. Occurrences of complex activities correspond to sets of occurrences of subactivities; in particular, these sets are subtrees of the occurrence tree. An activity tree consists of all possible sequences of atomic subactivity occurrences beginning from a root subactivity occurrence. In a sense, activity trees are a microcosm of the occurrence tree, in which we consider all of the ways in which the world unfolds in the context of an occurrence of the complex activity.
Different subactivities may occur on different branches of the activity tree, so that different occurrences of an activity may have different subactivity occurrences or different orderings on the same subactivity occurrences. In this sense, branches of the activity tree characterize the nondeterminism that arises from different ordering constraints or iteration.
An activity will in general have multiple activity trees within an occurrence tree, and not all activity trees for an activity need be isomorphic. Different activity trees for the same activity can have different subactivity occurrences. Following this intuition, this core theory does not constrain which subactivities occur.
Within the Complex Activity Theory, complex activity occurrences
correspond to activity trees, and consequently occurrences of complex
activities are not elements of the legal occurrence tree. The axioms of
the Activity Occurrences core theory ensure that complex activity
occurrences correspond to branches of activity trees. Each complex
activity occurrence has a unique atomic root occurrence and each finite
complex activity occurrence has a unique atomic leaf occurrence. A
subactivity occurrence corresponds to a sub-branch of the branch
corresponding to the complex activity occurrence.
The primary relation is subactivity_occurrence(?occ1,?occ2),
which holds in an interpretation
when the occurrence ?occ1
(which can be viewed as a set of one or more atomic occurrences
in one branch of the execution tree)
is a subset of the occurrence ?occ2.
In order to characterize the inputs and outputs of Web services as
knowledge preconditions and knowledge effects, FLOWS augments PSL
with a treatment of knowledge. To do so, it appeals to the work of
Scherl and Levesque who provided a means of encoding the knowledge
of an agent in the situation calculus by adapting Moore's
possible-world semantics for knowledge and action
[Scherl03]. Scherl and Levesque
achieve this by adding a K fluent to the situation calculus.
Intuitively,
K(s',s) holds iff when the agent is in situation s, she
considers it possible to be in s'. Thus, a
first-order formula f is known in a situation s if
f holds in every situation that is K-accessible from s.
For notational convenience, the following abbreviations are adopted.
Knows(f,s) is defined to be forall s' K(s',s) ==> f[s'],
and
Knowswhether(f,s) is equivalent to Knows(f,s)
or Knows(not f,s).
To define
properties of the knowledge of agents they define restrictions such as
reflexivity over the K fluent. The FLOWS axiomatization
of these epistemic concepts can be found
here.
Note: We assume f is a situation-suppressed formula (i.e. a situation formula whose situation terms are suppressed). f[s] denotes the formula that restores situation arguments in f by s.