Keywords

1 Introduction

Over the last couple of years the application of semantic methodologies and technologies in the e-Government domain has become an important field of research. A significant number of these approaches aim at automatic service discovery and service orchestration [1, 2] by adding and utilizing semantic annotations to web services. In contrast to these approaches it was our idea to use semantic methodologies in a more forward-engineering manner – to create a semantic model first and to use this model e.g. for service selection but also as basis for the automatic generation of “intelligent” web forms. Thus the ontology can be seen as a model that forms the basis of a Model Driven Architecture [3] approach to e-Government. That is why we call it Ontology Driven e-Government.

The principle is rather straightforward. Every public service is semantically modeled and contains references to the required input elements. Any constraints on the service input element – also known as preconditions – can be expressed by semantic rules and evaluated by semantic reasoners. This allows for an automatic creation of (web) forms and interactive plausibility checks of data gathered from the user. Instead of scattering logic over numerous functions and procedures in all possible layers of an application, it is now consistently kept in the semantic model. Another key advantage of this approach is that the knowledge of public services becomes available in a machine processable form which allows for much more than just forms creation. Discovering the citizen’s actual goal is one of these use-cases and is actually a very central and important step.

2 Goal-Oriented e-Government

To ensure that all public services are modeled in a consistent way, a meta-model that acts as a modeling guideline is needed. In our case we chose a model proposed in the Government Enterprise Architecture – Public Administration (GEA-PA) [3] that is formulated technology neutral. Thus, it does not make any assumption about the semantic framework or the nature of the actual implementations of public services, although most often they will be implemented as semantic web services.

One big advantage of semantic web services is their inherent goal orientation. They contain a semantic description of what they do or achieve. Before a user can make use of one (or more) of these services, the following phases have to be passed through [4]:

  • Goal discovery phase: In this phase the actual goal of the user has to be correctly formulated using semantic notations.

  • Semantic web service discovery phase: A set of semantic web services that might fulfill the goal is retrieved.

  • Service selection phase: The web service that will actually be executed is selected from the set of retrieved services.

Formulating the goal using any of the semantic methodologies can become relatively difficult. This is due to the fact that the problem domain itself can be relatively complex and, since this process involves user interaction, a simple and easy to use interface for expressing the goal is needed. In our prototype implementation of ontology driven e-Government we have limited the problem domain to the construction approval process. According to the construction law that has to be applied in this example there are three different categories any construction might fall into:

  • Building development requiring official approval: In this case you have to apply for approval which will trigger a fairly complex process

  • Notifiable building development: In this case you have to notify the responsible public agency providing detailed information about the project. The agency can prohibit the project within 6 weeks. Otherwise approval is granted

  • Building development not requiring official approval: In this case you just have to inform the responsible public agency about when construction work will start and provide some basic information about the project.

Which of these services is needed for a given project depends on the type but also probably the size or extent of the structure.

3 Ontology Modeling

There are currently several competing frameworks for modeling semantic web services submitted to the W3C. Among them is OWL-S [5] and WSMO [6]. We implemented evaluation prototypes based on both approaches and eventually chose WSMO that is based on WSML [7] over OWL-S that is layered on top of OWL [8]. A detailed discussion of the differences between these two approaches can be found in [9] and [10].

As mentioned above, the first services that should be supported by this new approach are construction approval services. These services are governed by a local construction law. Thus this law is an important source for modeling the required ontology since it contains all needed concepts and the logical rules and requirements that form the basis of the public agency’s actions. Even though some attempts to automatically extract semantic information from laws [11, 12] already exist, we conducted this step manually, identifying needed concepts and their interdependencies by carefully analyzing the text. While modeling the ontology for the construction approval domain, it became clear that it is relatively.

However, this still does not unambiguously identify the required service since in this example the required type of service depends on the type and number of motor vehicles that will be parked in the garage. Thus, we would need a more specific goal like

I want to build a garage for three cars!

3.1 Basic Components

The prototype was developed using ESRI ArcSDE software driven by a multiple clients interface developed in Java. This client interface adapts and integrates the mapping and database technologies required to suit the needs of the proposed assurance model. Figure 1 illustrates the basic component view of an application scenario.

Fig. 1
figure 01901

Basic components of prototype architecture

Full size image

It is seen here that the client requests the remote sensing image for visualization. Then the area of interest and year is selected in order to get parameters for selecting appropriate data and then, the Image data showing the area of interesting is visualized. The catalog is used to search and select those data used as source data and target data. In the scenario, the source data is a specific layer of damaged area and the target data could be satellite or aerial photograph data. In theory any type of thematic data layer could be used, but these are the ones we have access to and that are potentially important when assessing earthquake damage. After selection of data a parameter for statistics, which specifies whether statistics should be done per classes or as a whole, is selected by the client.

3.2 Navigation into IQ Data

Using the prototype described in the previous section, information quality experts can improve their knowledge of IQ through the use of different navigation tools. Table 1 illustrates the benefits of such a system through different questions a client may have regarding IQ and the different tools offered by the system to help in answering those questions.

Table 1 Map quality problems
Full size table

Image quality information is communicated through indicators using various color representations (e.g. red, yellow, or green). Quality indicator values can be represented using interactive thematic maps displaying quality values on each feature instance or geometric primitive. Using Geospatial On-Line Analytical Processing (SOLAP) operators, it is then possible to drill the data directly on these maps to access another level of detail of the information.

Based on our previous definitions [6, 7], we define the following quality metrics for a cube C: Accuracy of C, measured as \( {\alpha_C}={{{\left| {{L_A}} \right|}} \left/ {{\left| L \right|}} \right.} \); Inaccuracy of C, measured as \( {\beta_C}={{{\left| {{L_I}} \right|}} \left/ {{\left| L \right|}} \right.}\); Mismembership of C, measured as \( {\gamma_C}={{{\left| {{L_M}} \right|}} \left/ {{\left| L \right|}} \right.} \) and Incompleteness of C, measured as \( {\chi_C}={{{\left| {{L_C}} \right|}} \left/ {{\left( {\left| L \right|-\left| {{L_M}} \right|+\left| {{L_C}} \right|} \right)}} \right.} \).

4 Accessing SOA Backend

In this section we propose a SOA (Service Oriented Architecture) backend for ontology driven e-Government. Thereby it is our intention to implement a so-called grounding for each semantic web service to a concrete web service, which is typically represented by a WSDL file. The WSMX (Web Service Modeling eXecution environment) [13] developed within the WSMO Project [6] represents one promising approach to establish groundings from a semantic web service to a concrete web service. As both, WSMX as well as the semantic web services and ontologies from our prototype implementation are based on WSML [7], the decision to use WSMX as execution framework is obvious.

5 Conclusion

The approach to using semantic technologies in e-Government presented in this paper is a first step towards an ontology based process to implement e-Government services, where modeling the ontology should be one of the first steps. Goal and service discovery is one important part of this type of e-Government solutions. Using semantic reasoners to identify the concepts involved is very powerful and can hide much of the complexity of underlying regulations from citizens. The concept tree used in this example to guide the user in identifying the concept actually involved in her goal is a good basis to start with.