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.
- Assisted composition: We have built a system for assisted (or "semi-automated") composition, wherein the composition is primarily driven by a person. OWL-S was used to represent the grounded atomic services with hierarchical profiles and extensive non-functional properties. The Composer would do context driven matchmaking based on input/output match, plus additional constraint supplied by the user. Resultant compositions could be executed directly, saved as composite processes (and reused in other compositions), or exported as a SOAP based distributed workflow (for use in dynamic sensor networks). Some of this work made it way into, or inspired aspect of, Fujistu's Task Computing environment. Recently, we started work on a new generation of the Composer based on our OWL-S API which will focus on greater machine initiative, building on some joint work with Fujistu. In that work, certain services were marked as translation services. Instead of presenting those services to the user directly, the system "fuses" translation services to world affecting actions to produce more and better matches for a composition step. Though simple, it is very effective in helping people understand the potential of Semantic Web Services (and, in fact, automates an important, seldom automated function). We plan to extend this to suggesting plan chains and to interactive decomposition oriented planning, somewhat reminiscent of the HiCAP project.
- Task computing: Task Computing is a project from Fujistu Labs of America, College Park which is currently in transition to commercialization. Task Computing, as well the current environments and clients, was built on top of OWL-S and supports end user service discovery, composition, execution, and management by end users in a pervasive environment. Our involvement in OWL-S, and many of our contributions (especially in the area of the Grounding) were driven by Task Computing requirements. Task Computing, as it stands, shows that much of the functionality of OWL-S is not needed in order to do effective work: Task Computing services are all (at the moment) single input and output and have make no use of preconditions or effect descriptions (due to the only recently added support for specifying preconditions and effects in OWL-S; yet, we were able to do a lot without them). Furthermore, current compositions are limited to sequences. Even this limited functionality has proven surprisingly impressive. One lesson we take from this is that we do not need to aim for a comprehensive framework to advance the state of the art and industry.
- The OWL-S API: In support of Task Computing, and our own work, we have developed the OWL-S API, a collection of Java packages for parsing, validating, manipulating, executing, matching, and in general reasoning over OWL-S descriptions. The OWL-S API supports a number of readers and writers to and from various versions of OWL-S as well as other planning and service related formats. We have support for converting WSDL to OWL-S and the API will support the forthcoming mapping of WSDL 2.0 to RDF. The OWL-S API seems to have a large and active user base. Aside from Fujistu, who base their Task Computing environment on the API, there are over 100 people our our mailing list. Since the release of the 1.1.0 beta release of the API on April 13th, 2005, we have had 287 downloads (not controlling for repeats or bots), with an additional 200 downloads of the older release version this month. We've averaged over 300 downloads a month since last November (again, not controlling for duplicates are bots), when the OWL-S submission was published. This indicates a fair bit of interest in OWL-S. Many of the people on the mailing list are researcher and graduate students, so it is hard to gauge the larger use.
- HTN-planning based automated composition: OWL-S has been claimed to have been designed to support HTN planning (although its process model was inspired more by Golog). We have developed a mapping from OWL-S to the SHOP2 HTN formalism and proved it correct with regard to the Golog interpretation of the process model. We have extended SHOP with plan time information gathering and applied this to implementing a complete demonstration of the (in)famous "Scientific American Scenario". More recently, we have developed a SHOP2 flavored HTN formalism (HTN-DL) that completes the OWL-S HTN planning picture with preconditions evaluated against OWL-DL knowledge bases and task selection extended to incorporate OWL-S profile based match making. We have experimented with preliminary implementations and plan to have a public release of the integrated system (with native OWL-S support) early this summer.
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:
- The Grounding still needs work. It is very unclear to us that OWL is a suitable type system for inputs and outputs, especially given the notorious Decker problems. Using XSLT to marshal and unmarshal OWL objects to XML files helps, but is a radically ugly and unfortunate solution. (We can say this, we developed it.) XML Schema is the major type system for Web Services (e.g., it is the only one WSDL 2.0 supports natively), and SWS frameworks must learn to deal with that.
- Encoding more expressive logics in RDF and OWL is not only useless, but counterproductive. A lot of energy was spent trying to shoehorn a rather expressive process model into DAML+OIL and OWL. Don't do that. And ontology of syntax is a waste: it fails to characterize the expressions sufficiently either semantically or syntactically, and the additional classes, properties, and individuals can significantly stress systems (reasoners, networks, editors, etc.) Know the formalism you are using and stick to its limits. We like OWL fine and think it has several useful roles to play but it need not fill every role, including ones it is ill suited to.
- The semantics must be well specified. We spent a lot of time scratching our heads over the semantics of some of the control constructs, issues of data flow and control flow, and so on. OWL-S control constructs do have a situation calculus based semantics but it was never included in the actual specification, or kept up to date, or completed (especially in the light of expressive OWL based preconditions).
- Web Services revolve around messaging and OWL-S is largely silent about messaging (Bijan Parsia has to take some blame for this). There are several ways to incorporate messaging into a OWL-S like framework (we understand that SWSL has worked out at least one of them), but one must deal with WS-Choreography and its rather different approach to specifying distributed state machines.
- OWL-S (in spite of a lot of hue and cry from Bijan) is strongly single agent perspective, that is, oriented to what is now called orchestration. This puts an OWL-S based working group in contention, to some extend with BPEL which might be politically unfeasible. In any case, given the agent heritage of Semantic Web Services, it seems sensible to try to provide some better model of a multi-service perspective work. Unfortunately, this pushes us into the WS-Choreography space. There are both technical and political minefields to be clearer here.
- Effects (especially negative effects) are still a difficult problem (in spite of recent work from the description logic community) in light of OWL's expressiveness.
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.
Possibilities
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.