This page describes the scenarios that are available in the challenge. Each scenario consists of various problem levels. An up to date overview of all problem levels is shown in the evaluation table on the main page of this wiki. The levels and evaluation criteria used until the Athens Workshop in November 2006 are documented here.
For an up to date overview of the certified solutions to the Challenge's scenarios please refer to the evaluation table on the main page of this wiki. For in-depth information and to access the available technical content of the solutions, please go to the solution overview and documentation page.
Submit a Solution
In order to be certified by the SWS Challenge solutions to the problem scenarios must be submitted to a SWS Challenge Workshop. To start working on the problems request a login for the SWS Challenge Testbed from Srdjan Komazec (srdjan.komazec<at>sti2<dot>at). Solutions are required to solve at least one problem level correctly by communicating with and sending the right SOAP messages to the SWS Challenge testbed. You must demonstrate your solution at a SWS Challenge workshop where your solution code will be peer reviewed and the functional coverage of your solution will then be certified.
Submit a Scenario
The aim of the SWS Challenge is to provide a test bed for applying Semantic Web Service technology to a set of realistic and working Web Services. This test bed serves as well as a benchmark between different approaches, since it provides some objective success criteria for a semantic technology.
Currently this test bed consists of 3 scenarios, one focusing on mediation and two discovery scenarios. In order to make the test bed more comprehensive we want to encourage the submission of new scenarios that will be hosted on sws-challenge.org. To keep a certain level of quality we define a set of conditions you must fulfill:
- A wiki page describing the purpose of the scenario and its details (e.g. Scenario:_Shipment_Discovery). This page has to include details on the evaluation, this can be as in the case of mediation a description of changes (Scenario: Purchase Order Mediation_v2), or as in the case of discovery a description of a set of service requests that have to be made (Scenario:_Shipment_Discovery)
- The scenario must involve some real Web Services. We are offering to host those in case they can be deployed into axis2 or as servlet. MySQL access is possible as well. Please contact us in case of questions!
- A scenario must include some form of means to control objectively if a solution fulfills the scenario description. In the case of moon these are the various status pages in the moon application ([]). For the discovery scenario there is a simple view that allows to check invocation based on the participants IP: []
- A scenario must include a test case that proofs the task can be fulfilled, i.e. a sample solution. This sample solution does not need to have semantic technologies incorporate, instead its purpose is just to check the consistency of the implementation, for a sample look at: []