swing
SWING Project
swing swing swing swing  
Home
Partners
Deliverables
Publications & Links
Demos
Tools & Services
Showcase
Events
Contact
Internal

doap.rdf

swing

 

>  Workpackages and SWING Components

>  SWING Architecture Overview


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 the Jozef Stefan Institute. The main goal is to develop the Annotation Engine which utilizes knowledge discovery techniques to aid the user in the annotation task. The annotation task can be seen as the process of establishing explicit relations between the domain ontology and a Web service schema. Semantically annotated Web services can be registered in the Catalog and in WSMX (WP2 & WP5) to support semantic discovery and execution.

 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

Let us consider the graphic in a little more detail, starting at the user environment. The domain expert using MiMS (left part of the figure) mainly wants to formulate what sort of service he or she desires, and then pose these queries to a discovery interface. Formulating the queries is done in interaction with Vistual OntoBridge (top of the figure, and step 1), which guides the user through possible OGC queries and WSMO annotations. Required ontologies are requested from a Concept Repository (step 2). Once the query is submitted, Vistual OntoBridge forwards the annotated query an OGC Catalogue (step 3), which interacts with WSMX to obtain the discovery result (step 4, more on this below). The discovery result is forwarded back to the MiMS user. 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 the Composition Studio (step 5 and right part of the figure).

The developer in the Composition Studio needs to discover the services that will form part of the composition (step 6). This is done using the same functionality as explained above. The discovered services are composed as a UML diagram in the Composition Studio. Once the composition is completed, it is automatically translated into an abstract state machine. This can be executed by WSMX, for testing purposes (step 7). Once testing is completed, the developer uses Vistual OntoBridge to annotate the service; once that is completed, Vistual OntoBridge registers the annotated service in both CAT and WSMX (step 8). The domain expert in MiMS can now access the composed service just like any other service (step 9). 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 abstract state machine (step 10); the result of the execution is translated by WFS Wrapper back into the OGC format needed for MiMS.



Vistual OntoBridge takes a textual description of a service, and annotates it with a WSMO description in the formal vocabulary provided by the Concept Repository. The basis of the annotation process are techniques fro artificial intelligence, 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. Vistual OntoBridge is the tool overseeing this interactive process. It is used in the Composition studio 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 the OGC Catalogue and WSMX proceeds as follows. The catalogue provides an interface (to Vistual OntoBridge) for queries in both OGC and WSMO format. The services are stored internally, where they are accessed both by catalogue-internal and by WSMX functions; the services in catalogue’s repository are semantically annotated. The discovery itself is performed by sophisticated combinations of the catalogue’s and WSMX's capabilities, e.g., using catalogue’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.