Semantic Web Services: State of the Art

Editor's Notes

• #2: Good morning and welcome to my presentation. My name is Markus Lanthaler, I’m a PhD student at the University of Technology in Graz in Austria and today I’m going to give you an overview of the state-of-the-art of semantic Web services.
• #3: But first I would like to start with a quote from Rick Cook who once said that “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.” He concluded that “So far, the Universe is winning.”
• #4: Till some years ago that usually meant that idiot is sitting in front of the monitor. The user was normally a human. But that changed with the introduction of service-oriented architectures in the late nineties.
• #5: Typically when someone talks of a SOA he means a system based on Web services built on SOAP, WSDL, and UDDI.
• #6: But unfortunately that approach is fundamentally flawed since SOAP is a RPC-oriented technology which ignores the differences between local and remote computing which means in turn that it is not web-friendly at all. The main reason for this is that RPC-oriented technologies usually don’t support intermediaries for caching, filtering, or, e.g., logging which are must-haves in Internet-scale systems.
• #7: So this lead to a situation where we now have idiots on both sides. The different systems are usually so tightly coupled that even a tiny change such as the change from a 16 bit integer to a 32 bit integer could break the whole communication and would require the recompilation of the other system. Well, this might be acceptable in a controlled enterprise environment but for sure it isn’t for Internet-scale systems.
• #8: So, to solve these and other problems, Roy Thomas Fielding introduced in 2000 REST, a new architectural style which was specifically developed for the Internet. Fielding made some meticulously chosen constraints to enhance performance, scalability, and resource abstraction within distributed hypermedia systems.
• #9: Thus, REST’s approach is fundamentally different from traditional SOAP-based services. I won’t go into details but as you can see on this slide, REST has as lot of advantages. The most fundamental difference is that REST uses HTTP as an application protocol while SOAP abuses it as a pure transport protocol. This makes REST Web-friendly since it adds native support for intermediaries such as caches or proxies which perform their functions based on the semantics associated to the used HTTP verbs. Furthermore REST services are perceived to be simple while SOAP-based services with its gazillion specifications suffer from high complexity which might be one of the reasons why recently almost all developed services follow, at least to some degree, the REST principles. But there are still a lot of problems to be solved.
• #10: So, e.g., till now there exists no agreed standard for a machine readable interface description. So, the usual way to use a RESTful service is to read a textual documentation as the one shown on this slide. This is, of course, an error-prone and tedious task.
• #11: Since the most natural interface description which can be done by using HTML with hyperlinks and forms isn’t expressive enough, a lot of different approaches have been proposed. But most of them, such as WRDL, NSDL, SMEX-D, Resedel, RSWS, and WDL were more or less just ad-hoc inventions designed to solve some particular problems and haven’t been updated for many years. The only regularly updated proposals are hRESTS and WADL. WADL, which stands for Web Appli­cation Description Language, is closely related to WSDL. It uses a monolithic XML-file containing all the information about the service. hRESTS, which stands for HTML for RESTful Services follows a quite different approach. hRESTS’ idea is to enrich the, mostly already existent, human-readable HTML documentation with so called microformats to make it machine-processable. Maybe I should mention that there are controversial discussions if REST even needs an interface description format because its interface variability is almost eliminated by its uniform interface using the HTTP verbs. So, while it is arguable if there is a need for an interface description format,
• #12: it is clear that such a syntactic description will not be enough. Indeed, two services can have exactly the same syntactic definition but perform significantly different functions.
• #13: So what we need is a way to describe the semantics of both, the exchanged data and the behaviour of the service. Again, till now this is normally done in the form of a textual description which is, hopefully, easily understandable by a human being but machines have huge problems to understand such a document.
• #14: So what we need is a semantic description format for Web services. There have been already a lot of proposals and they can be basically classified into general-purpose and domain-specific descriptions formats. So in the next minutes I will talk a bit about the general-purpose description formats and then conclude my talk with some words on the domain-specific formats.
• #15: So let’s start with OWL-S, the Web Ontology Language for Web Services. OWL‑S is an ontology based on the Web Ontology Language which is in turn a World Wide Web Consortium standard. OWL-S consists of three main parts: the Service Profile, the Service Process Model and the Service Grounding. The service profile is primary meant for human reading and is used to describe what the service does. It includes the service name, a description and other information such as quality of service or publisher and contact information. The service process model describes how a client can interact with the service. So it describes the inputs, outputs, pre-conditions and the results of the service execution. Finally, the service grounding provides the needed details about transport protocols to in­voke the service. So, generally speaking, the Service Profile provides the informa­tion needed to discover a service, while the Service Process Model and Grounding, taken together, provide enough information to make use of a service, once found. OWL-S principal aim is thus to describe the service’s offers and needs. The main critique of OWL‑S is its limited expressiveness in practice and that it cannot contain completely unrelated operations as WSDL can. OWL-S allows only the description of static and deterministic aspects and doesn’t cover any notion of time and change, nor uncertainty.
• #16: Another approach to describe Web services semantically is the Web Service Modeling Ontology (WSMO). WSMO offers the four top-level notions: Ontologies, Goals, Service Descriptions and Mediators. The Ontologies define the formalized domain knowledge while the Goals specify objectives that a client might have when consulting a Web service and the Service Descriptions describe the services that are requested or provided. Finally the Mediators are used to enable interoperability and to handle heterogeneity between all these components to allow loose coupling. (Mediation at data (mediation of data structures) and process level (mediation between heterogeneous communication patterns))   So, in contrast to OWL-S, WSMO propagates a goal-based approach. It is particularly designed to allow the search for Web services by formulating the queries in terms of goals. This clearly goes beyond of OWL‑S’ description of the service’s offers and needs.   One of the main critiques of WMO has been that concrete guidelines for developing mediators, which seem to be the essential contribution of WSMO, are missing. Another critique is that its development has been done in isolation of other standards. WSMO defines a conceptual model and a formal language called WSML (Web Service Modeling Language) together with a reference implementation of an execution environment (WSMX; Web Service Execution Environment).
• #17: In fact the only standard is SAWSDL which was published three years ago the World Wide Web Consortium. SAWSDL stands for Semantic Annotations for WSDL and XML Schema and defines three new exten­sibility attributes for WSDL and XML Schema to add semantic annotations to them. The modelReference attribute defines the association between a WSDL or XML Schema com­ponent and a concept in some semantic model. The other two attributes, liftingSchema­Mapping and loweringSchemaMapping, are used in a XML Schema to specify the mappings to the semantic model, i.e., the needed transformations between the service’s native XML format and the semantic model. So to shortly summarize, SAWSDL is the only World Wide Web Consortium standard but, as it just defines extension attributes,  it comes without any formal semantics and it thus needs some kind of “magic mediators” outside the framework to re­solve the semantic heterogeneities. Given that SAWSDL relies on WSDL it mostly addresses SOAP-based services. But there exists a very similar approach for RESTful services,
• #18: namely MicroWSMO. As you already see on the slide it is basically the same as SAWSDL. The only difference is that instead of relying on WSDL, it relies on hRESTS. So, all annotations are made in the HTML documentation of the service in the form of microformats.
• #19: Another very similar approach is SA-REST. Again, it’s basically the same but this time RDFa is used instead of microformats. As a matter of fact, SA-REST was the first approach which reused the already existent HTML documentation. So, what all those three approaches, SAWSDL, MicroWSMO and SA-REST, have in common is that they don’t specify concrete formal semantics for representing the semantic model.
• #20: This is where WSMO-Lite comes into play. WSMO‑Lite is as lightweight service ontology to fill the annotations with concrete semantics. It adopts some ideas of WSMO model but makes its semantics lighter. As you can see on the slide, WSMO‑Lite describes four aspects of a Web service: 1) the Information Model, which de­fines the data model for input, output, and fault messages; 2) the Functional Semantics, which define the functionality, which the service offers; 3) the Behavioral Semantics, which define how a client has to talk to the service; and 4) the Non-functional Descriptions, which define non-functional properties such as quality of service or pricing. So shortly summarized, WSMO-Lite is a lightweight ontology to fill the annotations with concrete service semantics  and it isn’t bound to a particular service description format which is important to highlight since that means that it can be used for example with SAWSDL as well as with MicroWSMO  to create matching stacks for SOAP- and REST-based services. The biggest differences are that WSMO‑Lite treats mediators as infrastructure elements and specifications for user goals as dependent on the particular discovery mechanism used, while WSMO defines formal user goals and mediators. Furthermore, WSMO‑Lite defines the behavior semantics only implicitly. WMO‑Lite also does not exclusively use WSML, as WSMO does, but allows the use of any ontology language with a RDF-syntax.
• #21: So what I mean by matching stacks is shown on this slide. On one side you can have a stack built of WSDL and SAWSDL pointing to the WSMO-Lite ontology for SOAP-based services and on the other side you can have a stack of hRESTS and MicroWSMO for RESTful services. This allows performing tasks such as discovery or composition completely independently from the underlying Web service technology as you operate on a higher semantic level. But unfortunately,  so far none of the presented approaches has managed to break out of its academic confines. In my opinion there is a simple reason for that, at least in regard to RESTful services.
• #22:  The thing is that all of the presented approaches assume that the service follows the RPC-style. But REST is fundamentally different as it is a resource-oriented architecture. So in my opinion all of these approaches are condemned to failure for RESTful services. I think we need something dramatically simpler for RESTful services and I believe that the description of the resource representations, i.e., the transport format, combined with the use of hypermedia should be enough to achieve a high degree of automation for RESTful services without overburdening the developers.
• #23: That’s exactly what some of the most successful domain specific description formats do. I assume you all know Atom feeds and OpenSearch; OpenSearch is the underlying technology of your browser’s search bar. So I won’t describe them. Both formats are widely used and are pretty simple but unfortunately they are restricted to a very specific application domain. That’s exactly the problem we try to address right now. We try to combine those two formats with Linked Data to create a system that is usable for a much broader application domain while still remaining as simple as possible.
• #24: OK, that was all from me, I would like to thank you for your attention.
• #25: I would be glad to answer all of your questions now – even the silly ones.
• #28: One way to do that would be to specify, additionally to the semantics, so called lifting and lowering schemas which are then used to translate from the service’s native data format to the ontology’s data structure, the so called grounding schema. So basically you add another abstraction layer. This added abstraction layer has also the important benefit that it makes the solution scalable because each service provider has to provide then only one lifting and lowering schema pair in contrast to the usual way which requires a mapping between all possible service combinations. But unfortunately it is not always possible to define a complete mapping to the grounding schema; this is a point that needs further research.
• #29: Another important problem that might could be solved with semantic annotation is the data mediation or integration problem - which by the way is still an open problem. So typically when you create a mashup you as developer would go and implement a special mediation layer to translate the data formats between different services. And quite often this layer represents then the major part of the whole code. So what we need is some kind of support to translate between those different data formats automatically. Picture: Further comments on that site note that the tours of this particular castle are given in Czech (cheaply) and in other languages (at high prices).  This sign aims to prevent non-Czech-speakers from signing up for the Czech tour and having someone interpret it for them. The most obvious joke is in the fact that the sign is in violation of itself.  The second is a small in-joke about the differences between translation and interpreting.