|
Workpackages and SWING Components
The work performed in SWING is structured into 6 technical work packages, as well as a Dissemination work package and a Management work package. Each of the technical work packages is lead by one of the SWING partners, and develops one particular component that forms part of the environment developed in SWING.
Workpackage 1: MiMS (BRGM)
This workpackage is lead by BRGM. It develops the Application prototype, called MiMS. This prototype will show dynamic discovery, composition and invocation of geospatial web services within the domain of sustainable exploitation of natural resources. Parts of the application prototype will be developed using the Development Environment. At run-time, the application prototype will utilise the Semantic Discovery and Execution component.
Workpackage 2: WSMX (NUIG)
This workpackage is lead by National University of Ireland Galway. It develops the Semantic Discovery & Execution component, which provides the basic Semantic Web Service infrastructure. It will be based on the WSMX technology developed in the DIP project, adapted to the geospatial domain. It consists of a repository of semantically described web services and a set of inference tools for discovery and dynamic invocation of the services.
Workpackage 3: ONTO (UOM)
This workpackage is lead by IFGI, Westfälische Wilhelms-Universität Münster. We are responsible for the Geospatial Ontology component, including an ontology maintenance strategy which ensures consistent and high-quality ontologies for all SWING componentsThe ontologies are central for semi-automatic annotation, semantic discovery, and composition of geospatial web services within the domain of natural-resource decision-support tasks.
Workpackage 4: ANNOT (JSI)
This workpackage is lead by Institut Jozef Stefan. It develops the Semantic Annotation component, which utilises information acquisition technology to analyse the semi-structured data descriptions of existing geospatial web services, in order to generate Semantic Web Service descriptions. These may be registered in the Semantic Discovery & Execution component in order to extend the number of semantically described web services.
Workpackage 5: CAT (IONIC)
This workpackage is lead by IONIC Software SA. It develops the Catalogue component, which provides a standard web service registry interface storing entries to classical geospatial and non-spatial services. In addition, it utilises the underlying components to provide semantically enhanced discovery functionality.
Workpackage 6: DEV (SINTEF)
This workpackage is lead by SINTEF (Stiftelsen for industriell og teknisk forskning ved Norges Tekniske Høgskole). It develops the Development Environment component, which is based on IBM's Open Source Eclipse Development Environment. It consists of a number of plug-ins that integrates and hides the complexity of the other components. Application and service developers can use the Development Environment to discover both semantic and non-semantic services, to semantically describe their services and to compose multiple services.
Workpackage 7
This workpackage, concerned with Dissemination and Exploitation, is lead by Leopold-Franzens-Universität Innsbruck. It takes care of activities such as maintaining the public web site and disseminating the SWING results both in the relevant academic and industrial communities. In particular, SWING takes active part in several standardisation efforts related to the Geospatial domain and Semantic Web Services. Further, the final results of SWING will be provides as a book, and intermediate results will be disseminated through the organisation of workshops at academic and user venues.
Workpackage 8
This workpackage, concerned with Project Management and Quality Assurance, is lead by SINTEF (Stiftelsen for industriell og teknisk forskning ved Norges Tekniske Høgskole). It takes care of the day-to-day management of the work performed in the project, of reporting activities, of quality assurance, and of risk management.
SWING Architecture Overview
The graphic below provides an overview of how the components developed in the technical workpackages interact in the SWING architecture. The graphic shows the main actors of the SWING environment, namely MiMS, DEV, CAT, WSMX, and ANNOT, as explained above. The ontologies, ONTO, are accessible for every component, so they simply form the background of the graphic. Further, the graphic shows three additional components that will be established to make the environment work: Query Annot, Service Annot, and WFS Wrapper. To distinguish these additional components from the others, we will call them tools from now on. The tools encapsulate the key functionalities that must be implemented at the interfaces of the components.
Let us consider the graphic in a little more detail, starting at the user environments. The domain expert using MiMS mainly wants to formulate what sort of service she desires, and then pose these queries to a discovery interface. Formulating the queries is done in interaction with Query Annot, which guides the user through possible OGC queries and WSMO annotations. Once the query is submitted, Query Annot forwards the annotated query to CAT, which interacts with WSMX to obtain the discovery result (more on this below). The discovery result is forwarded back to the user through Query Annot. If the discovery result is empty, then the MiMS user contacts the developer, with a natural language request to compose a suitable web service in DEV.
The developer in DEV needs to discover the services that will form part of the composition. This is done using the same functionality as explained above. The discovered services are composed as a UML diagram in DEV. One the composition is completed, it is automatically translated into an abstract state machine (ASM). The ASM can be executed by WSMX, for testing purposes. Once testing is completed, the developer uses Service Annot to annotate the service; once that is completed, Service Annot registers the annotated service in both CAT and WSMX. The domain expert in MiMS can now access the composed service just like any other service. To execute the composed service, however, an additional interface tool is needed to convert the parameter formats. Namely, the composed service is exposed in MiMS as a standard OGC service. The OGC parameter values are transformed by WFS Wrapper to the ontological format needed internally by WSMX to execute the ASM; the result of the ASM execution is translated by WFS Wrapper back into the OGC format needed for MiMS.
ANNOT takes a textual description of a service, and annotates it with a WSMO description in the formal vocabulary provided by ONTO. The basis of the annotation process are AI techniques such as text mining. Since such a process is bound to yield several alternatives (and probably not only good ones), the overall annotation process is semi-automatic, interacting with the user to make sure that the chosen annotation makes sense. Service Annot is the tool overseeing this interactive process. It is used in DEV to annotate new composed services; it is used in MiMS to annotate legacy services, and possibly new non-annotated services that are registered.
The interaction between CAT and WSMX proceeds as follows. CAT provides an interface (to Query Annot) for queries in both OGC and WSMO format. The services are stored inside CAT, where they are accessed both by CAT-internal and by WSMX functions; the services in CAT's repository are semantically annotated. The discovery itself is performed by sophisticated combinations of CAT's and WSMX's capabilities, e.g., using CAT's methods to match bounding boxes and polygons of query and provided service, and WSMX's methods to match the semantics of the data content as desired by the query and provided service.
|