Chairs: Steve Battle, David Martin
Nearby:
Call for participation (closed)·
Accepted papers·
Minutes session 1·
Minutes session 2·
Minutes session 3·
Minutes session 4
The W3C held a workshop on June 9-10, 2005 at DERI Innsbruck (Austria), to gather information about potential standardization work on Semantics in Web Services. The Call for Participation covered the background and goals of the workshop, and explained that attendance was limited and position papers were required. A total of 53 papers were accepted by the program committee and a subset was selected for presentation. 82 participants attended the workshop.
The workshop scope included:
In order to meet the workshop goals, in particular reviewing use cases and existing research efforts, finding key domain concepts and essential problems to address (eventually solutions), the program was divided in 4 sessions: domain boundaries and definition, use cases, framework technologies, and concluding discussion.
The goal of the first session was to understand the challenges in Frameworks for Semantics in Web services. Following an Introduction (Carine Bournez), three short presentations: Halpin, O’Sullivan, Lara, provided a rapid overview of these challenges. A full transcript is available at http://www.w3.org/2005/04/FSWS/minutes/session1.html.
Semantics in Web services focus on how to describe and wrap conventional services that communicate in XML (Payne). This should build on the contributions of RDF & OWL; WSDL & XML schema (and even good old UML).
The needs of different kinds of users give rise to different sets of requirements. There is a need for simple abstractions for the "programmer on the street" (Halpin), hiding ontological detail but providing support for integrating Web services into programming languages. Similarly, end-users have their own requirements, to express their goals so they can find the services they need. The need for interoperable tools based on semantic frameworks means that the service ontology needs a clear and unambiguous formal foundation. While OWL is intended for capturing ontologies, there are a number of Web service issues for which it does not provide complete solutions, including descriptions of the "consequences of actions" (McIlraith) and "policy" (Grosof). There are many "simple and well-studied formalisms [that could be used] as a basis for Web services" (Halpin) that may address these issues. Such formalisms may be used in conjunction with OWL to provide a theoretical basis for further research in areas such as composition and verification of services descriptions.
Should the solution be "deployable … beyond the W3C stack?" (Brown) Our second speaker was concerned that "conventional services are being ignored for a purely Web services view" (O’Sullivan). Although they may not have a functional interface, these 'conventional' services have a web presence and are open to discovery. This high-level view of services, the provision of value in some domain, focuses on "business services versus computation-oriented services" (Reitbauer). Similarly, there is a world of business functionality out there that is accessible only via legacy APIs. And, viewing Web services as instances of resources, how much of this work is more widely applicable, maybe "we should be talking about Semantic Resources?" (Cardoso) Semantic Web technology is fundamentally open-world. "It's impossible to describe real world objects completely… the challenge is how to deal with incomplete information within a minimalistic framework" (Sheth). "You may want to express incomplete descriptions, for publishing and discovery purposes" (Hull). On a note of caution, we must "Keep It Semantically Simple (KISS)" (Payne).
Any particular service description will use concepts drawn from many ontologies. A service ontology provides us with a standard upper-ontology capable of being re-used across many application domains. This includes distinct sub-ontologies dealing with functional and non-functional properties. This would be used in conjunction with domain ontologies expressing domain specific concepts. Some didn’t see "domain ontologies converging" (Cardoso) and "believe they should not be standardized on at this point" (Sheth). Alternatively, we should be looking for the 'Dublin Core' of domain ontologies, to put "simple, potentially unambitious things in place to provide things that people can be encouraged to use" (Williams). Ontologies capture consensus, but we should also be mindful of how organizations use them, "in one word: governance; we need not only to have an ontology, but to be able to show their validity" (Brown).
The aim of discovery is to find a service to fulfill a requester’s goal. A service can be identified by the functional capabilities published in its service description. How much of this description is required for discovery purposes? "It's not clear where the line between general and detailed (or non-functional and functional) description is" (Lara). In the WS domain, UDDI supports design-time "service discovery vs. [runtime] service location" (Giangarra) as required in dynamic services composition scenarios.
"The whole concept of composing services is going to need semantic capabilities" (Giangarra). Functional aspects of Web service descriptions include the inputs and outputs of service actions. WSDL operations are described using XML schema, though ontologies may provide us with a richer type system. Many tools support composition on the basis of matching inputs to outputs, ensuring they are compatible not only at the XS data-type level, but also semantically. "For example, take the Dublin Core Date Modified qualified element" (Parsia) which has a specific meaning over and above DC Date. If the inputs and outputs don’t match, mediation of the content may be possible. "What are the side effects on the world of any given action?" (Hull). These side-effects are critical to an understanding of services that have consequences in the real world, and are especially significant in long-running business processes which may involve additional real-world events.
"Non-functional aspects of Web services, including Service Level (SLA) and Quality of Service (QoS) agreements, touch on electronic contracts and policies" (Grosof). Non-functional properties can be metered at runtime, and used to monitor the performance of the service with respect to the contract. Contractual exceptions can be raised as they are detected and remedial action taken. The Semantic Web angle is that there should be a common understanding of the meaning of a contract. How much of this is generic, built into the service ontology, and how much is covered by domain specific extensions?
Tooling in the Web services world is geared around "using XML and XML Schema … and domain [concepts] mostly represented in UML" (Akkiraju), together with WSDL and SOAP. To work in that world our tools should support the "binding [of] ontologies to XML" (Halpin) and the grounding of actions in WSDL.
The high-level objectives of this use cases session were to understand how SWS technologies are being used, identify important technology requirements, and gather evidence of need for standards activities around them. To this end there were presentations of five position papers presenting projects using SWS technologies. These were selected to represent depth in the existing work and breadth in the scope and domains covered. In the discussion afterwards we focused on distilling requirements and desiderata that have arisen from these uses.
The presentations, by Gandon, Pehle, Qu, Hull and Brown, are available on the workshop's Program page and the corresponding position papers are available on the Accepted Papers page. The full transcript is available at http://www.w3.org/2005/04/FSWS/minutes/session2.html.
A number of position papers and presenters pointed out the limitations associated with the current foundational WS building blocks such as WSDL, SOAP, UDDI --- limitations that are often summarized with the phrase "syntactic interoperability". For example, (Gandon) notes that "compared to agent-based platforms we used before, [Web service] technologies had the disadvantage to remain at the syntactic level while all the [other kinds of] resources we manipulate are described in ontology-based models enabling us to leverage the semantics of descriptions in inferences."
Many of the needs of these use cases are already being met by de facto standards produced by research efforts such as those presented in the technologies session (see below). In particular, there is a number of efforts using such technologies for purposes of service discovery, composition, and enactment. Discovery typically involves the advertisement of semantic service descriptions in registries, followed by the generation of a service request and some kind of matchmaking procedure to find advertized services for the request. In most approaches presented to the workshop advertizements, requests, and matchmaking exploit the features of a knowledge representation scheme such as that embodied in OWL.
In several cases, UDDI has been combined with OWL-S to create a semantic UDDI registry, as discussed by (Gandon) and (Qu). A number of projects have explored (semi-)automated composition of services based on semantic service descriptions. Simple uses of SWS technologies are already enabling "dynamic invocation of services without any prior knowledge of its description" (Gandon). Finally, we note that some projects regard the SWS technologies as the means by which to build agent-based systems, as stated by (Gandon): "Clearly, the evolution of web services towards semantic web services proposes an alternative to agent architectures."
System-building activities and functionalities that can benefit from SWS technologies include managing complexity; supporting semantic interoperability and integration; electronic procurement; providing web-scale identity, compositionality, and data integration; faster system development; management of compliance, contracts, and policies; reaching and maintaining agreements; reducing transaction cost; re-engineering of legacy applications; and change management.
Among the technical requirements that received the most attention (both in papers and in workshop discussion) were: semantic typing of inputs and outputs; data mapping within workflows; expressing effects of services; discovery; mediation; registry capabilities beyond those of UDDI; automatic or semi-automatic generation of simple services composition; reusable composition templates; quality of service; security; and exception-handling mechanisms.
For many organizations, especially business organizations, the primary impetus towards semantic technologies is the ever-present need to support interoperation between separately designed systems. For example, Gandon points out that "Corporate memories not only include information mediums but more generally: information storage services, ... information creation services... computation and inference systems ... information flows management services ... information mediation services ... information presentation services ... All these services may be internal or external to the company yet users want them to interoperate smoothly and, even better, to automatically integrate their workflows at the business layer."
Pehle notes that service description needs are not only concerned with the enablement of interactions. They also require languages (such as OWL) and conventions to enable the in-depth characterization of rich and highly dynamic knowledge sources, in a way that supports discovery in particular. For this and other reasons, most use cases rely heavily on domain ontologies, in addition to the ontologies of service-specific concepts provided by most FSWS approaches.
Although many workshop participants explained the benefits that result from using SWS approaches, only a few specifically addressed the urgency of standardization, or recommended a timetable or roadmap for standardization. We give two examples here. First, Gandon states: "Composition and choreography issues currently are the most symptomatic examples of the need for a standardization consortium to take the lead, and W3C definitively is the best candidate. We are witnessing a multiplication of contributions for each and every stage of the life-cycles of web-services and especially discovery and binding and discovery and composition. There is clearly a need to "homogenize the different approaches before the differences hamper the foundations of Semantic Web Services such as interoperability" (Gandon). Second, Qu states: "We are still lacking a semantic workflow description language in the SWS community. ... From a long-term point of view, the semantic workflow description language needs surely be drawn up by the SW or SWS community."
We are not aware of any commercial efforts to provide tools supporting SWS technologies per se, although some open-source tools are available and have been used by some of the projects described in the workshop position papers. An identification of the common features of the most widely used SWS approaches could be of value in guiding environment and tool builders.
The third session of the workshop was an exposé of a number of representative technologies. How do these technologies serve the use-cases discussed? What key concerns do they address? Five speakers: Domingue, Parsia, Nagarajan, McIlraith, Roshchin, discussed the Web-Service Modelling Ontology (WSMO); the OWL Service ontology (OWL-S); Web-Service Semantics (WSDL-S), the First-Order Ontology for Semantic Web-Services (FLOWS); and Siemens’ Service Description Reference Model (SDRM). These are by no means exclusive; other noted technologies included IRS III and Meteor-S. A full transcript is available at http://www.w3.org/2005/04/FSWS/minutes/session3.html.
WSMO subscribes to the "distinction between service and web-service, the latter being the computational aspects of the former", reflecting a concern for the "goals representing what a user wants to achieve by using web-services" (Domingue). The "OWL-S… profile describes the service at a high level" (Sycara) though this includes both functional and non-functional properties. WSDL-S takes a pragmatic view, including a service "category for publishing to UDDI" but is "agnostic to [the] taxonomy" (Nagarajan). Service descriptions may provide a partial account of the service interface, and could include aspects considered to be behind the service interface. "In some cases internal workings are part of [the] advertisement of the services... sometimes telling people what you do and how you do it is important for the users" (Bernstein).
The WSMO framework considers mediation as a key concept; "Mediators resolve heterogeneity mismatches", another distinguishing feature of WSMO with "mediators as first class citizens" (Domingue). While mediators can be described (i.e. in OWL-S) like any other service, "mediators can be arbitrary web services, they play the role of mediators" (Domingue), WSMO makes the case that they should be considered a (transparent) part of the semantic infrastructure.
The presented technologies share a similar approach to describing individual actions. However, OWL-S places a premium on process composition, "modelled with a process/action paradigm, [with] roots in [the] situation calculus" (Parsia). The grounding in web-services is direct as we can define Atomic Processes, which relate to WSDL operations, and composition … results in a simple sequence of executable actions (Parsia). Composition can focus on simple I/O chaining, though OWL-S can also represent real-world changes using preconditions and effects (Parsia). Similarly, WSMO pre- and post-conditions describe conditions on the inputs and outputs, "assumptions are about things you cannot talk about directly, the state of the external world, and effects describe the real-world effects" (Domingue). WSDL-S supports, but is "agnostic to how you represent the preconditions and effects" (Nagarajan) but provides no explicit composition mechanism.
Is the process model necessary? "If we're interested in automating composition … then the process model is fairly rich" (Parsia). There is a connection with "abstract BPEL, which is… hard to use as a basis for composition", though it is possible to "produce BPEL from the semantic descriptions" (Parsia). However, "people can use programming languages to write services, they don't necessarily need BPEL, the question is how to integrate WS in programming languages" (Parsia).
If the process model describes how to use the service, then its non-functional properties define what the service is about. The OWL-S profile defines a small set of non-functional properties including QoS. WSMO, in addition, recommends use of Dublin Core non-functional properties. Both support extensibility; "non-functional properties in OWL-S and WSMO is an initial set that can be expanded" (Sycara).
Services invocation may be a low-hanging fruit. "WSDL-S started by trying to see what semantic technologies could be directly applied to WSDL" (Akkiraju). The approach is "analogous to [the OWL-S] grounding and profile, but without [the] process model" (Nagarajan). Building on the OWL-S WSDL extensions, "Reuse of interfaces and data types is common... we should annotate those semantically" marking them up using classes drawn from the domain ontology; We need rich mappings between [XML] schemas and semantics (Nagarajan).
There was some debate on formal foundations of each technology framework. "The [OWL-S] process model… lacks formal semantics" (Grosof). The aim of the Semantic Web-Services Framework and FLOWS is to shore up the foundations of service ontologies by providing an "unambiguously computer interpretable description [of] the process model and the effects [...] OWL is not sufficiently expressive" to represent the constraints required by process modelling, a more "expressive language is necessary, we propose FOL, in particular PSL (ISO standard) - process specification language" (McIlraith).
The primary objectives of the final session were to consider what standardization activities (if any) would best serve the community (and in what time frame), to sketch out a possible roadmap towards these activities, and to gauge the current degree of support and likelihood of success of these activities. Following the presentations by Laskey (slides, paper), Williams (slides, paper), and Nottingham (paper), there was a 90-minute discussion period. The full transcript is available at http://www.w3.org/2005/04/FSWS/minutes/session4.html.
There are differing perceptions about the maturity of these technologies, and hence about their readiness for standardization. On the one hand, there is clearly a good deal of "low-hanging fruit", as evidenced by the strong commonality of approach to recurring challenges, across a broad spectrum of system building efforts. For example, many efforts have similar uses of ontologies in creating and classifying service descriptions for purposes of advertising and discovery. Many efforts rely on semantic characterizations of the types of inputs and outputs to arrange for simple automated (or semi-automated) forms of service composition. Many also use these characterizations to arrange for automated mediation between the available outputs of one service and the required inputs of another.
On the other hand, many feel that "the jury is still out" regarding the feasibility of some of the more complex techniques used in research, and there is some uncertainty regarding their generality and the amount of value added by their use. When you get beyond the low-hanging fruit, many feel, there is a lack of clarity about the boundaries of the larger picture, and how all the pieces are supposed to fit together.
For example, while there is recognition of the potential value of using logical expressions to present the preconditions and effects of services, and there has been much valuable research in this area, nevertheless most system building efforts incorporate very little real functionality of this sort. There are many unanswered questions about what expressions can be defined, how the relevant ontologies and knowledge bases are to be managed, how the expressions are to be evaluated, and what language features are most essential and most natural in constructing these expressions. Similarly, there are many unanswered questions about process modeling. (What aspects of processes may need to be exposed to the outside world by a service provider? What kinds of reasoning about processes will be the most valuable, and what kinds can be guaranteed to be tractable for all cases?) There are also questions about whether adequate incentives exist to support ontology development and the availability of tools and education that will make these approaches accessible and productive for large numbers of developers and end users.
These unanswered questions persist in large part due to the overall breadth and complexity of work in this field, and the ambitious, comprehensive vision pursued by many research efforts. As Mischkinsky noted in discussion, before one standardizes, one should be beyond the point of research. Is there a reasonably well-defined platform out there that's ready for general use? If so, do we know enough to cleanly delineate the technologies that are ready for prime time from those that aren't?
In any case, there appears to be a consensus that better connections are needed with the realm of work based on the existing WS stack. The value of semantic technologies needs to be demonstrated more clearly in the context of real-world problems of the sort that WS users and vendors are confronting. Many of the researchers expressed a strong interest in finding opportunities to work on such problems.
Several participants suggested the need for stronger partnerships between the WS and SW communities. For example, Akkiraju suggested that a valuable next step would be for the WS community to provide a characterization of the key "pain points" experienced in developing WS systems, and the SWS community, in turn, to create some demonstrations of how semantic technologies can address these needs. Sheth and others suggested that (semi-)automated service composition might be one such area of need.
It was noted in discussion that most organizations working with semantic service technologies are making only modest investments in research and prototyping activities, rather than large system-building efforts. In addition, to our knowledge there are no vendor organizations that are committed to selling tools to support these technologies. Thus, there are currently missing two factors that are usually significant in creating momentum for standards activities.
There does not appear to be a clear momentum at present towards a W3C recommendation track in this area. Reasons for this include: (1) use of these technologies is primarily in research and/or prototyping efforts at present; (2) lack of vendor commitment to provide tools and other forms of support; and (3) the preference of the WS community for a "go-slow" approach (as expressed by Nottingham). Nevertheless there are some users who feel that standardization would benefit their efforts and the larger community (as noted, for example, in some of the use cases papers). As stated by Reitbauer in discussion, "... customers want to be assured that the technology will be adopted widely - ... please provide an agreed model so we can proceed".
The interest in various forms of pre-standardization work, such as an Incubator Activity or a Characterization work in particular, was considerably stronger. (An Incubator Activity is a new, lightweight process at W3C designed to foster development, on a time scale of a year or less, of innovative ideas for specifications, guidelines, and applications that are not (or not yet) clear candidates for development and more thorough scrutiny under the current W3C Recommendation Track.)
Approximately half of the audience at the end of the session indicated that they think the area is ready for pre-standardization work and three-quarters think that some real scale use case investigation is needed. Two fairly concrete proposals figured prominently in the discussion of possible pre-standardization work. The first, mentioned above, is to elicit some concrete challenges ("pain points") and requirements from the commercial WS community and ask SWS researchers to show clearly how these technologies can address those needs. The second is to bring together the developers of the more comprehensive technology efforts to define simple specifications for the low-hanging fruit that is common to all of their approaches. This common ground would likely include semantic annotations in Web services descriptions (such as typing of inputs and outputs, expression of preconditions and effects of primitive operations), a simple incremental set of extensions to WSDL to indicate references to these elements; hierarchical classification of services for purposes of advertising and discovery; expression of "nonfunctional" properties such as quality-of-service; and possibly simple uses of rules in expressing policies and contractual commitments. There appears to be a good deal of optimism amongst the community that agreement on a common core set of specifications would be feasible.
Steve Battle, David Martin
$Author: cbournez $ $Date: 2005/08/16 12:44:18 $