The mainstream XML standards for interoperation of web services specify only syntactic interoperability, not the semantic meaning of messages. For example, Web Services Description Language can specify the operations available through a web service and the structure of data sent and received but cannot specify semantic meaning of the data or semantic constraints on the data. This requires programmers to reach specific agreements on the interaction of web services and makes automatic web service composition difficult. Semantic web services are built around universal standards for the interchange of semantic data, which makes it easy for programmers to combine data from different sources and services without losing meaning. Web services can be activated "behind the scenes" when a web browser makes a request to a web server, which then uses various web services to construct a more sophisticated reply than it would have been able to do on its own. Semantic web services can also be used by automatic programs that run without any connection to a web browser. A semantic-web-services platform that uses OWL to allow data and service providers to semantically describe their resources using third-party ontologies is SSWAP: Simple Semantic WebArchitecture and Protocol. SSWAP establishes a lightweight protocol and the concept of a "canonical graph" to enable providers to logically describe a service. A service is essentially a transformation of some, possibly null, input to some, possibly null, output. Services are semantically discoverable based on their subsumption hierarchies as well as their input and outputdata types. SADI is a semantic-web-service initiative that consists of a set of design-practices for semantic-web-service publishing that minimizes the use of non-standard protocols and message structures. SADI Services natively consume data in RDF Resource Description Framework format, where input and output data must be instances of input and output Classes defined in OWL-DL. Unlike canonical Web Services, SADI Services do not use the SOAP messaging protocol, and unlike SSWAP, SADI services have no project-specific messaging scaffold; services are invoked by passing RDF instance data to the Service endpoint through HTTP POST, and multiplexing is achieved by sending more than one OWL Individual in the HTTP POST invocation. SADI imposes a single constraint on the behavior of the Service: that the URI of the output individual must be the same as the URI of the corresponding input individual. In practice, this results in Services that create semantic linkages between the input and output of the service. Thus, chaining SADI services together into a workflow results in an uninterrupted Linked Data graph.
Choreography vs. orchestration
Choreography is concerned with describing the external visible behavior of services, as a set of message exchanges optionally following a Message Exchange Pattern, from the functionality consumer point of view. Orchestration deals with describing how a number of services, two or more, cooperate and communicate with the aim of achieving a common goal.
