Semantic based platform for e-Government services

Views: 788

Current trends in e-Government call for services that are simple to use, shaped around and responding to the needs of citizens. On practical grounds, the search for and integration of services are basic requirements of service-oriented systems, which aim at gathering and transforming processesprocesses – needed for a particular user – into one single service and the corresponding back-office practices.

Unfortunately, the domain of e-Government is a perfect example of a domain ridden by semantic problems – barriers in which the lack of interpretation of information meaning is  the key obstacle for networked computer applications in administrative processes and  services. This domain is characterised by its enormous challenge to achieve interoperability, given the manifold semantic differences of interpretation of, for example, law, regulations, citizen services, administrative processes, best-practices, etc. within and across regions.

These semantic differences are related to a great variety of IT solutions currently in operation  (on a local, regional, national, and international level), which will have to be networked.  Semantic barriers of information exchange have a vertical and horizontal dimension (front- to-back and back-to-back interoperability). It is not possible to rely on integrated systems within e-Government services because of the heterogeneity of IT infrastructures in administration and the tendency to operate closed systems and networks. Moreover, each of the local administration has its own understanding of the domain (e.g. of the services to be  provided to citizens and other clients) as well as of the interoperability needs. Domain specific standardisation as well as methods and tools may certainly help, but they will not unify the  perspectives and the (professional) language of the actors involved.

On the other hand, many capabilities, which can be delivered by using semantic technologies,  are applicable in the e-Government area. Some of the capabilities include concept-based search (precise and concept-aware search using knowledge representations  across multiple knowledge sources); semantic data integrator (allowing data to be shared and under-stood across a variety of settings); semantic service discovery and choreography (reuse  of existing services and the dynamic automation of processes); and, consultant services  (understanding of customer goals and offering products and services which can help them  meet those goals).

“Current trends in e-Government call for services that are simple to use, shaped around and responding to the needs of citizens. However, the domain of e-Government has of late become a  domain ridden by semantic problems particularly in terms of achieving interoperability”

Therefore, the combination of the two domains – e-Government and  semantic technologies – seems to be quite natural.From the technical perspective, the main challenges related to these  technologies are to identify the objects, which will need semantic mark-up, and to  provide reasoning capabilities in order to make feasible the invocation, composition,  mediation, and automatic execution of complex services with multiple conditional paths of execution. The semantic technologies can be an ideal platform to achieve the vision of a  knowledge-based, user-centric, distributed, interoperable, and networked e- Government.

Access-eGov project

The European FP6-2004-27020 project Access- eGov (, funded by the  European Commission under the Information Society Technology Framework Programme 6,  started in January 2006, and is expected to last 36 months. Access-eGov aims at the  development of component-based enhancements of existing e-Government infrastructure  based on semantic technologies and distributed architectures (service-oriented and peerto- peer). These components will enable for any (new or already existing) e-service all levels of public administration (local, regional, national, and transnational) to be easily introduced to  the world of e-Government interoperability. Once an e-service is registered, it may be  localised, contracted and used automatically through agents and other IT components. At the same time, more information necessary for the use of traditional (non e-) services will be  provided and thus the “integration” of traditional and e-services into “hybrid scenarios” can  be enabled. And, since not all users feel comfortable when dealing with a myriad of services, a  virtual personal assistant will guide users through these scenarios.

Functionality and benefits of the Access- eGov platform can be summarised as follows – For  e-Government service providers on all levels there should be easy registration of e-services to  the AccesseGov platform; for end users (citizens and businesses), there should be improved accessibility of government services, identification of government services (whether online or  traditional) relevant to the user’s need (life event / business episode) and the context (location  etc.); providing them with a user tailored (personalised) scenario consisting of available  elementary government services (the scenario is either purely electronic in case that all the  necessary government services are available online or “hybrid” – if it is a combination of  traditional and online services); guidance through the designed scenario; and, support of  semantic interoperability across organisational/regional borders and languages (multi- lingual solution) while guaranteeing appropriate level of security for all involved parties.

Conceptual models

The Access-eGov will use three basic ontologies – Life event ontology, Service profile ontology  and Domain ontology. In general, these three ontologies describe several aspects and levels of  the same real world data. All of them denote services (web or traditional) and the way they are used.

Life event denotes a specific situation in the life of a citizen or in a life cycle of an organisation  that requires a set of public services to be accessed and utilised. Life events can be categorised  in groups and may be organised in multiple hierarchies. Generic scenario specifies a generic composition of the goals relevant to a typical complex life event. Goal specifies those objectives  that a client might have when consulting a service, including functionalities that a service  should provide (from the user’s perspective). Goals formalise user needs by specifying the  requested outputs and effects. Goals are logically matched against service capabilities.

Service profile specifies what the service provides, and the way it is used to advertise services.  A service profile consists of non-functional and functional properties. Functional properties  describe inputs, outputs, preconditions and effects of a service. They are specified as logical  expressions, which consist of the terms constraining type and property values of the various  resources required for or provided by the services. Types used to specify functional properties  are defined in the domain specific ontologies. Non-functional properties describe the  semi-structured information intended for requesters to discover services (e.g. information about the service provider and properties which incorporate further requirements for service capability – traditional office hours and office location, quality-of-service, security, trust,  etc.). Structured non-functional properties are specified by domain specific ontologies.

The  domain ontology would be used to describe the lower (i.e. technical) level, whereas other  ontologies would be utilised to denote more abstract system levels. In order to allow  interaction and deduction between the different data models that underlie these ontologies,  several layers of mediation needs to be introduced.

In the process of service discovery, goals  and functional properties of services are semantically matched to select services, which are  able to achieve given goals. Non-functional properties are then used to additionally filter or  reorder the discovered services according to a requester’s preferences. Workflow specifies composed activities (electronic or traditional services), which fulfill goals in the generic scenarios.

Functional overview

The approach taken by the Access-eGov project can be depicted as a pyramid. The pyramid  consists of five layers creating a vertical hierarchy. Each layer can provide services for  external applications (through a set of APPs interfaces) or can be used by the next upper layer in the hierarchy.

Since the project uses semantic technologies to be able to search for appropriate services and to  ensure their semantic interoperability, the omni-presence of ontologies is not too surprising. In order to register a service, it is necessary to provide a semantic annotation of  the service, i.e. information describing the service at several levels. The project takes the  position not to be invasive in existing solutions. This enables to index not only services  currently without any semantic information attached but also services, which were  developed with semantics in mind.

All semantic descriptions are expected to be stored in a decentralised semantic directory  infrastructure. Its role is to serve as ‘yellow pages’ of all the services provided by  governmental organisations. The services can be of three types – automatic services available  electronically (e.g. web services), services accessible electronically, but requiring  manual communication with user (e.g. filling and submitting some form), and services not  accessible electronically (e.g. user has to visit a governmental institution). Information finding and brokering layer serves as a data provider/search agent enabling to benefit from  semantic description infrastructure. It enables to find which service types can be principally offered to a user.

The aim of the service composition layer is to generate a complex plan (workflow) how to cope  with the given life event or a business episode. In order to satisfy a particular need in the  given life event, a plan (containing information like which services should be used, in what  sequence, in what way etc.) will be assembled. The life event (or some business episode) is  represented as a generic scenario, how to meet a goal resulting from the given life-event or  business episode. Execution of the plan is be supervised by the personal assistant. It performs some activities electronically on behalf of the user, but some activities have to be performed  by the user himself. The user is asked to carry out some tasks, e.g. to take the form (delivered  by the assistant), fill it in (some items may be pre-filled by the assistant), print it, sign, send  by post or go to a relevant public administration institution.

Proposed architecture

Implementing web services in conjunction with service oriented peer-to-peer architecture seems to be the most promising approach with regards to interoperability between different types of legacy systems used within public service backend. The result is expected to be a  flexible service-oriented architecture that goes beyond existing e-Government systems and  overcomes restrictions of the existing solutions. Since Access-eGov is envisioned to build a service-oriented platform, it is supposed to be highly modularised and shall be logically composed of a number of components interacting with each other.

The actual services are still hosted under responsibility and on the premises of the  participating public agencies or their respective data centres. They are simply made  available through Access-eGov and thus do not form an integral part of the overall system.  Those are either electronically available (directly via web service interfaces or web forms) or  represent “traditional” office services that may be described and registered within the platform.

The overall platform may be sub-divided into three major component groups – the AeG  Infrastructure itself, the AeG Personal Assistant client and equivalent end user interfaces, and  AeG Administration and Management Tools (e.g. Annotation services), which are not  integral parts of, but affiliated to the Infrastructure. Public agencies are supposed to annotate those services that they are willing to expose to the public. These kinds of service- related  meta-data will be transferred to the persistence layer of the platform. Domain experts may  use a generic Annotation service component that they will find available as web-based  application.

The Personal Assistant accesses functionality of the infrastructure via standardized interfaces  and communicates with executable Core components that are charged with Discovery,  Composition and Execution of registered public services. Apparently, mediators represent the  most complex part of the architecture. Since participating services are mostly in the form of web services (and wrappers of legacy services can simulate this kind of accessing services), a semantic approach to web services is expected to be utilised.

The Access-eGov system will be represented by nodes constituting a peer-to-peer network.  Each node consists of the modules and components as shown above. According to the  functionality needed in a particular node, the actual number of installed optional components  may vary. Public agencies may choose which of the components they wish to  install on their premises or data centres. Such a “local” installation of infrastructure  components is supposed to interact as a peer in the network. The more components are  installed locally (Core + Mediation + Persistence + Discovery + Composition + Execution), the  more functional value a node will bring to the overall system.

Following this aforementioned approach, Access-eGov is to increase the accessibility of public  administration services for citizens and business users by supporting the interoperability  among existing electronic and “traditional” government services, and envisages achieving this in a seamless manner for the endusers, thus contributing to making e-government accessible and transparent for all. This is in full accordance with the European Commission’s  view that clearly states in e.g. its eEurope+ action plan that “eGovernment can improve  public services, making them faster, as well as more accessible and responsive”.

Access-eGov will implement this approach in 3 specific pilots, namely in Slovakia (land-use  planning and processing a request for a building permit), Poland (establishing an enterprise,  taking into account the registration process of a company), and Germany (secure semantic interoperability between national and local governments). In addition, in Egypt, a  challenging test case will be arranged whereby all tasks of an intra- European scenario will be  included, plus additional challenges of language and cultural.

Follow and connect with us on Facebook, Twitter, LinkedIn, Elets video

Eletsonline News

Latest News

To Top