A semantic web service, like conventional web services, is the server end of a client–server system for machine-to-machine interaction via the World Wide Web. Semantic services are a component of the semantic web because they use markup which makes data machine-readable in a detailed and sophisticated way (as compared with human-readable HTML which is usually not easily "understood" by computer programs).
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 (WSDL) 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 (Web Ontology Language) to allow data and service providers to semantically describe their resources using third-party ontologies is SSWAP: Simple Semantic Web Architecture and Protocol.[1] SSWAP establishes a lightweight protocol (few OWL classes and predicates; see the SSWAP 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 (or subject) to some, possibly null, output (or object). Services are semantically discoverable based on their subsumption hierarchies as well as their input and output data types.
SADI[2] (Semantic Automated Discovery and Integration) 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 (OWL Individuals 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 is concerned with describing the external visible behavior of services, as a set of message exchanges optionally following a Message Exchange Pattern (MEP), 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.