Semantic Web Services Initiative
Web-service Functions that Involve Semantics

In order to develop a broad understanding of the architectureal requirements of semantic web services, we have developed the following (draft) list of functions associated with the use of such services. These functions include those that may be performed by a client of such services, those that may be performed by the services themselves in order to fulfill their contract as semantic enabled web services, and those that may be performed by middle agents or other architectural support layers of the general semantic web services architecture. We are focused exclusively on functional elements that
are substantially changed (or only present) in order to take advantage of the flexibility and broadened potential for dynamic interoperability provided by semantically rich communications models.

This list of functions is divided into broad categories as follows:
Note: In the descriptions that follow, we use some terms consistently with their usage in descriptions of OWL-S and DAML-S, the semantic services description ontology created by the DAML-S coalition (See papers and materials at http://www.daml.org/services). In particular, a service description is a set of formula in a formal semantic description language characterizing the function (effects), processes (activities) and data flow associated with a service. A grounding is a mapping between elements of a service process description (in particular, its inputs and outputs) and transport message formats. An atomic process is a process that cannot be further decomposed into sub-processes that have their own groundings.

We have (thus far) identified the following functions that would potentially need to be performed by some part of the architecture to support semantically enabled web services:

Advertising, Matchmaking and Service Selection

Negotiation and Contracting

Process Modeling, Process Model Interpretation, Enactment, Tracking 


Community Support/Management


Service Lifecycle
(May be handled by a lower layer of the architecture that we build on)