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 (www.access-egov.org), 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.
Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter, Instagram.
