UMCP Mindlab Position Paper on Frameworks for Semantics in Web Services

The OWL-S Experience

OWL-S is a collections of OWL-DL ontologies for describing Web Services. It is the oldest, most mature, and widely used of the current set of coalition developed Semantic Web Services frameworks (SWSI and WSMO being the other contenders). OWL-S is a reasonable starting place for a services framework trying to cover automation of discovery and matchmaking, composition, and execution of Web Services. Different parts of OWL-S could be extracted for a more focused working group (something we think is a good idea).

We have used OWL-S from soup to nuts in a variety of systems and in support of others. From DAML-S 0.7, we have worked with OWL-S on the three core service tasks of matchmaking, composition, and execution, always focusing on the end-to-end experience.

With the implementation of an HTN-DL planner, we believe that a large chunk of OWL-S can claim effective implementation. Companies such as SAIC and Lockheed-Martin have experimented with earlier versions of OWL-S SHOP and have expressed strong interest in HTN-DL. Realistic and real deployment is the biggest missing link in our, and we believe anyone's, OWL-S experience. Implementation experience and experimentation is essential to getting a useful and useable SWS framework that would make a useful basis of a standardization effort. We think we can claim this -- weakly -- for OWL-S. We certianly would not want less experience than we have (and know of) and would be happy with a good deal more. It is essential to have tools that actually take the semantics of the framework seriously. In early prototypes of the Composer, we used a simple rule-based implemenation of an approximation of a fraction of DAML+OIL to reason with DAML-S services. Today, the OWL-S API bundles Pellet, an OWL-DL, tableau based reasoner we have developed.

While we have good reason to believe that OWL-S is a workable basis for a deployable and standardization worthy SWS framework, there are still issues which must be dealt with. For example:

Clearly there is plenty for a working group -- or pre-working group -- to do. The largest and most important task is to develop a clear market for SWS technology. Unless there are some members who plan some realistic chunk of their business around the proposal, we would strongly suggest caution before forming a working group, especially for a comprehensive framework. A failed standards effort is much more damaging than no standard effort.


There is a general argument against a working group focused on comprehensive framework for SWS, that is, something with the scope of OWL-S. The Web Services community, at least the vendors, are generally pursuing a "small and baked" strategy. Even WSDL, which has faced expansionistic tendencies, is and is conceived as narrowly focused. The panoply of WS-Specs show this strategy. In the W3C, WS-Addressing is the first fruit of this fully implemented strategy. Grand plans, especially without a clear market, are going to be a hard sell, especially to a crowd who are constitutionally antagonistic to the Semantic Web. Given the lack of consensus within the Semantic Web Services community, it's worth finding small, clear value things we can pull together quickly out side the W3C, elicit interest from the Web Services vendors, and then push forward.

Policies, constraints, and capabilities

The Constraints and Capabilities workshop ended without consensus and without any buy in from the Web Services community for expressive, logic oriented langauges. However, we recently have produced a mapping from WS-Policy to OWL constructs (not an encoding of the WS-Policy syntax into an OWL ontology) which has met with considerable interested from Web Services vendors we've shown. The advantages: it clarifies the semantics of the language; we can effectively use off the shelf reasoners to do policy checking; those reasoners can also do more extended and interesting policy analysis (e.g., policy containment, incoherence, incompatibilty, etc.); OWL editors, browsers, and debuggers (such as offered by Swoop) give us a powerful Policy IDE; OWL and RDF allow for more expressive assertion sets without having to write custom code to parse and understand extensions. This is compelling. It offers almost no downsides and lots and lots of immediate advantages and it is driven by what the vendors have already said they wanted. It also provides a much better methodology for expansion: OWL is far more expressive than WS-Policy (which is essentially propositional logic), so it provides room to grow in. The Semantic Web Services community should focus on providing similar simple wins.

Extending WSDL

WSDL 2.0 has extensive extensibility mechanisms which we should make use of. Adding preconditions and effects to operations, functional and non-functional properties to operations and services, and adding taxonomic classifiction to operations and services are all relative small but potentially useful extensions to WSDL.

The Case for Discovery

The W3C does not have a discovery story even though dissatisfaction with UDDI is high and UDDI was conceived as being an antidote to the Web, rather than working with the Web:

Publishing your URLs [sic] to the UDDI registry is much more of an exact science that [sic] it is trying to get your Web site's URL inton an Internet search engine. With UDDI, you have complete control over which of your business and service and service address information is published and when. This is because you are the one who publishes it. (p. 4)

The SPARQL query language and protocol can be used to define a better, more Web friendly UDDI. This would be a clear win which avoids stepping on a lot of toes and give the SWS community the experience with standardization it rather desparately needs.

Composition with Templates

Thinking further ahead, there does seem to be room for some sort of automated composition with "templates". BPEL has moved in this direction. WS-Choreography can generate WSDL or BPEL skeletons for endpoints that which to conform to certain roles in a protocol. A simple formalism for specifying Web Service "templates" (think composite process, or HTN methods, or what have you) could be an effective way to build upon the discovery effort. It would be worth the composition communities effort to vigorously explore relatively simple proposals in this area. (We, for example, would certainly concentrate on simplifying HTN-DL.) A contents akin to the ICAPS planning competition could be an effective way to build understanding and interested in automated composition.