Frameworks for Semantics in Web Services

Joel Farrell Rama Akkiraju

IBM Software Group IBM Research

Introduction

Business process integration is among the most important challenges facing organizations today. Companies are being forced to be flexible and adaptive to changes in the business conditions and advancements in information technology while controlling IT expenses. Web services provide a foundation for easier system integration by providing a standards-based approach. Usage of Web Services is continuing to grow with Web services forming the basis of integration solutions in many industries. However, integration and process automation projects are often expensive and time consuming even with Web services, and may not result in solutions that are as flexible and reconfigurable as needed to best react to today’s dynamic business environment. At the heart of these issues is the lack of semantic understanding in Web Services (See the scenario in Appendix A for more details on the need for semantics).

Realizing this need for semantics, the semantic Web community has already proposed that the inclusion of semantics in Web services descriptions could promote the (semi) automation of Web services discovery, composition and mediation, both at application development time and, potentially, at execution time. This would promote service reuse and address the cost, time and flexibility issues in application integration. We agree that Web services semantics shows considerable promise in improving the creation and deployment of Web services-based solutions. The questions of how to add semantics to Web services descriptions and then leverage those semantics at the appropriate points in the solution life-cycle should be pursued by the Web services community.

It is our position that before embarking on the formal standardization of a framework for Web services semantics, the community should work with Web services solution implementers to understand how semantic technology could be combined with the current practice and what practical obstacles must be overcome. We need to base our conclusions and specification proposals on firm field experience. We also need to address how to enable the growing deployed base of Web services and service requester applications. This is a significant challenge, since some companies have hundreds of deployed services. It will require an approach that is compatible with the current Web services standards.

In this paper, we will examine the requirements for Web services semantics and present a set of principles that should be followed when defining frameworks in this area. These principles are embodied in a proposed framework that we will briefly describe. This discussion will lead to a set of next steps we think the Web services community should take.

Standards Implications

We recommend that certain principles guide any work to define a framework for Web services semantics. We describe these principles below.

Base the solution on WSDL and other existing Web services standards

The Web services standards are fast becoming a preferred technology for application integration because of the promise of their interoperability. Organizations are deploying significant solutions based on these standards. The consensus that has developed around the Web services standards has enabled the exceptional acceptance and growth of the Web services technology.

IBM’s position is that any approach to adding semantics to Web services should be specified in an upwardly compatible manner so as to not disrupt the existing install-base of Web services.

Support semantic annotation of Web Services whose data types are described in XML schema

A common practice in Web services-based integration is to reuse XML business documents as payloads in Web services interactions. The definition of business documents via XML schema is a wide-spread and successful practice. XML schemas will be an important data definition format for the foreseeable future. The association of semantics with service inputs and outputs must support the annotation of XML schemas.

WSDL 2.0 supports the use of other type systems in addition to XML Schema, so constructs in semantic models, such as classes in OWL [OWL] ontologies, could be used to define the Web service input and output data types. But an approach that does not address XML schema-based types will not be able exploit exiting assets or allow the gradual upgrade of deployed WSDL documents to include semantics.

The mechanism for attaching semantics to Web services descriptions should be independent of the semantic representation language

There are a number of potential languages for representing semantics. OWL, F-Logic and UML are all being discussed in this context. OWL is the choice of OWL-S proposal [OWL-S] that aligns with the Semantic Web. The potential of UML is shown by the OMG which has published a proposal called the Ontology Description Metamodel [ODM]. F-Logic, which is an object-oriented and frame-based approach [FLOGIC], is an alternative to description logic-based approaches like OWL. It is favored by the Web Services Modeling Ontology [WSMO] effort. Other candidates can be found in the knowledge representation literature.

Our position is that it is not necessary to tie the Web services standards to a particular semantic representation language. This is consistent with the proposal by Sivashanmugam et al [Sivashanmugam]. In the next section, we will show a way such independence can be achieved. By keeping the semantic annotation mechanism separate from the representation of the semantic descriptions, the Web services standards can exploit the best of semantic modeling.

Provide rich mapping mechanisms between XML schemas and ontologies

Given our position on the central importance of XML schemas in Web service descriptions, attention should be given to the problem of how to map XML schema complex types to ontological concepts. Again, an agnostic approach to the selection of schema mapping languages is called for. For example, if the domain model is represented in OWL, the mapping between WSDL XSD elements and OWL concepts can be represented in any language of user’s choice such as: XSLT, XQuery, RDF/S, OWL or any other arbitrary language as long its reference is fully qualified with its own namespace.

An Approach for Semantic Annotation

IBM and the University of Georgia have collaboratively defined a framework for Web services semantics The Web Services Semantics –WSDL-S technical note [WSSEM] defines a mechanism for associating semantic annotations to Web services. It is a refinement of the original WSDL-S proposal [METEOR-S, WSDL-S,]. In this approach, the underlying concepts used to semantically annotate a service can be defined in an external semantic model. The Web Services Semantics – WSDL-S technical note provides a mechanism to annotate inputs and outputs of Web Services with semantic concepts referenced from such a semantic model. Also, learning from OWL-S, it provides for the annotation of operations to capture service invocation preconditions and effects. These preconditions and effects together with the semantic annotations of inputs and outputs form a complete functional-level semantic description of Web services.

The Web Services Semantics – WSDL-S technical note uses WSDL extensibility elements and attributes to annotate Web services with semantics. These annotations are references to concepts in a semantic model, such as a UML or OWL document. The concepts are attached to input, output and fault message definitions and to operations. Using this approach, the function of the service and the meaning of its parameters can be described in a WSDL document in an evolutionary and compatible way. Since this approach uses standard extensibility features of WSDL2.0, it does not affect those who do not exploit semantics (support for WSDL1.1 is given in the technical note document).

Next Steps for the Web Services Community

Given the momentum of Web services and services-oriented architecture, and the early state of semantics technology and ontology modeling, it is important that we not rush to standardization. We need to explore with implementers of Web services solutions the potential roadblocks to adoption of Web services semantics technology. The creation and use of ontologies by companies and the use of semantics in organizations is still in its infancy. Much work is needed on the creation of ontologies and how existing domain models and enterprise models can be reused as ontologies or how they can at least be used to as starting points for more complete semantic models. We also need to experiment to determine how the business problems can best be addressed and how developer and business process management tools can best exploit semantic descriptions of Web services. Any standardization embarked upon by the Web services community should be based on experience in applying semantics to solve real-world integration problems.

References

[FLOGIC] Kifer, M., Lausen, G., Wu, J., Logical Foundations or Object Oriented and Frame Based Languages, Journal of the ACM 1995, Vol 42, p. 741-843, http://www.informatik.uni-freiburg.de/~dbis/Publications/95/flogic-jacm.html

[METEOR-S] METEOR-S: Semantic Web Services and Processes, http://lsdis.cs.uga.edu/Projects/METEOR-S/

[ODM] Ontology Definition Metamodel. Revised Submission to OMG/RFP ad/2003-03-40, Jan. 2005, http://www.omg.org/docs/ad/05-01-01.pdf

[OWL] OWL Web Ontology Language Overview, http:w3.org/TR/owl-features/

[OWL-S] Web Ontology Language for Web Services, http://www.daml.org/services

[Sivashanmugam] K. Sivashanmugam, K. Verma, A. Sheth, J. Miller Adding Semantics to Web Services Standards, http://lsdis.cs.uga.edu/library/download/SVSM03-ICWS-final.pdf

[WSDL-S] WSDL-S: Adding Semantics to WSDL – White paper, http://lsdis.cs.uga.edu/projects/WSDL-S/wsdl-s.pdf

[WSMO] Web Services Modeling Ontology, http://www.wsmo.org

[WSSEM] Akkiraju, R. et al Web Services Semantics – WSDL-S Technical Note. April 2005, http://www.alphaworks.ibm.com/g/g.nsf/img/semanticsdocs/$file/wssemantic_annotations.pdf and http://lsdis.cs.uga.edu/Projects/METEOR-S/WSDL-S

Appendix A: A Motivating Scenario

In this section, we present a scenario to illustrate how semantically annotating Web Services can help in service discovery and discuss how annotating WSDL documents with semantics in an upwardly compatible manner (the approach presented in this paper) can facilitate the adoption of semantically enabled Web services.

Say that company ABC is an electronic parts supplier to company XYZ and that they both have implemented service-oriented architectures and have made the interfaces of their applications available as Web Services. Say that in an order management scenario, company XYZ would like to check the availability of an electronic part from supplier ABC. Figure 1a shows an extract of a WSDL description of an inventory checking service, QueryItemAvailabilityServiceRequest, of electronics company XYZ. It lists the requested item’s part number, delivery date and the requested quantity as inputs and expects the quantity available to be delivered on the requested date as output. We ignore preconditions and effects, account information, access control and security related issues for simplicity. The operation tag lists the inputs and outputs the service takes. The actual inputs and outputs are expanded in QueryAvailabilityServiceRequest and QueryAvailabilityServiceResponse message tags. Figure 2b, shows the inventory check Web service offered by ABC Inc.. ABC calls it CheckInventoryService and its inputs and outputs look different from the ones offered by XYZ company’s QueryAvailabilityService. ABC’s service requires a Universal Product Code (UPC) instead of a manufacture’s part number. The term dueDate is used rather than deliveryDate and numItems is used rather than qty. Also, ABC’s service returns an itemAvailabilityConfirmation, which is true if the requested quantity is available and false otherwise. On the other hand, XYZ’s service requires to know how much of the quantity requested is available along with the confirmation. As can be seen, there are differences in the interfaces of the services. However, if the objective is to find a service that gives information about the availability of a given part, semantically, both services should be matched. This type of match cannot be determined using word similarity approaches alone. Domain-specific information is needed to interpret the relationships. For example, in this domain due date and delivery date are synonyms, UPC expands to Universal Product Code, a UPC and a manufacturer’s part number are both unique identifiers for a product, and UPC is a subset of EAN Code. A domain specific ontology, such as the one shown in figure 2, is required to record and resolve such relationships.

.<message name="QueryAvailabilityServiceRequest">

</message>

</message>

</operation>

</portType>

Fig 1 (a) Company XYZ’s request WSDL description for checking the availability of inventory of a part.

</message>

</message>

</operation>

</portType>

……..

Fig 1 (b) Company ABC’s WSDL description of a service that allows business partners such as company XYZ to check the availability of an electronic part.

Figure 1. Illustration of the need for modeling of domain-specific information for finding relationships between services.

Figure 2. A pictorial representation of a simple electronics domain ontology modeled in OWL.

This example demonstrates the need for capturing domain specific information to infer relationships among terms used in Web Services interfaces in order to discover suitable services. The question is how to describe these Web Services with the semantic information such as the one captured on ontology shown in fig 2. in a way that makes it easy for adoption by the developer community.

Approaches prescribed by the semantic Web community such as OWL-S provide a way to specify semantics for Web Services. While semantic service modeling approaches such as OWL-S are sound approaches, they require the creation of additional models on top of WSDL to describe semantics. For example, in OWL-S, developers of Web Services have to create OWL-S profile model separately along with WSDL documents. While the profile model is meant to address the semantics of services, it requires inputs and outputs of a service to be defined again in the profile model. This poses maintenance burden on developers. When the interfaces change, they have to remember to reflect those changes in multiple models (WSDL and OWL-S model). The objective of the argument is not to undermine the significant contributions that OWL-S and other semantic markup languages such as WSML make to semantic Web Services but to propose an approach that is consistent with their conceptual underpinnings and yet is practical and easily adoptable by the developer community. We believe that based on the guiding principles described in ‘Standards Implications’ section, the same conceptual underpinnings of OWL-S can be implemented in a way that makes the adoption of semantic Web Services easier for the developer community. Below, in Figure 3a and 3b we describe how the Web Services of companies XYZ and ABC, discussed in order management scenario, can be annotated with semantics in an upwardly compatible manner using our approach [WSSEM]. As mentioned earlier in the paper, since these semantic annotations are added to WSDL documents using the extensibility elements of WSDL specification, any standard WSDL parser would be able to parse the semantic annotations and the developers could begin the matching and discovery process relatively easily.

</message>

</message>

</operation>

</portType>

Figure 3a. An excerpt of a semantically annotated WSDL for inventory checking service in figure 1a.

<xmlns:wssem=" http://www.ibm.com/schemas/2004/wssem"

xmlns:ElectronicsOntology="http://www.standards.com/ontologies/ElectronicsDomain.owl" >

</message>

</message>

Figure 3b. An excerpt of a semantically annotated WSDL for inventory checking service in figure 1b.