Framework for Integration of e-Government Services on a Semantic Basis

1. Framework for Integration of e-Government Services on a Semantic Basis Karol Furdik, Tomas Sabol, Peter Bednar Karol.Furdik@intersoft.sk, {Tomas.Sabol, Peter.Bednar}@tuke.sk Technical University of Kosice, Letna 9, 042 00 Kosice, SlovakiaInterSoft, a.s., Florianska 19, 040 01 Kosice, Slovakia

2. Contents • Motivation: Interoperability of e-Government services • Access-eGov project • Access-eGov system description • Data structure • System ontologies • Architecture and functionality • Technology used • Annotation of governmental services • Web interface of the Annotation tool • Example of annotated service - WSML representation • Current status, lessons learned • Conclusions and future work

3. Motivation: Interoperability & Accessability • Status quo: • eGov services are difficult to find; • Individual e-services are disconnected, not interoperable; • Users (citizens/businesses) have to find several services, going then from one to another. • Project goals: • To improve accessibility and connectivity of gov services for users;  Finding relevant governmental services • To simplify the use of services for users • Creating a integrated hybrid scenario by combining relevant atomic services • Providing guidance to users while implementing the scenario

4. Access-eGov project: Basic facts Full title: Access to e-Government Services Employing Semantic Technologies • Starting date: January 1st, 2006 • Duration: 36 months • EC Funding: 1.983.000 € • Total Budget: 2.279.243 € • Contract No.: FP6-2004-27020 • Consortium: 11 partners, 5 countries (SK, PL, D, GR, Egypt) • Coordinated by the Technical University of Kosice, Slovakia Main goal:To develop and validate a platform for composition of gov services into complex process definitions (life events) enabling semantic interoperability of particular eGov services. • More on: www.accessegov.org

5. Access-eGov project: Pilot applications • Slovakia:Land-use planning and processing a request for a building permit. • Poland:Establishing an enterprise - the process of company registration. • Germany:An upgrade and field test based on the existing good practice “Zustaendigkeitsfinder” ("Responsibility Finder"), by introducing a semantic layer (securing semantic interoperability between national and local governments). Use-case: Getting married. • Egypt (German University of Cairo):Usability testing from outside EU.

6. Access-eGov system: Components • Integration of both traditional (face-to-face)and electronic government services by means of their semantic description and annotation. • Components: • Reference ontology - basic domain knowledge and processes for locating and contracting e-Government services; • Rule-based editorial component to insert a semantic mark-up to e-Government applications by public administrations; • Client tools (agents) for finding and brokering information according to semantic requirements; • A platform for composition of governmental services into complex process definitions (covering life events/business episodes) enabling semantic interoperability of particular services; • A distributed security infrastructure providing multiple security services for authenticating users and protection of data.

7. Access-eGov system: Concepts Basic concepts for modelling the governmental services: • Life event - specific situation in the life of citizen (or in a life cycle of an organisation) requiring a set of governmental services. • Goal - a formalisation of user needs, i. e. the objectives the user may have when consulting a service; expressed by requested inputs, outputs, and effects. • Service - an atomic activity provided by a public administration. It can be either electronic or traditional. • Service profile specifies the „content" of the service, i. e. what the service provides for users. Formally - a logical expression consisting of terms that constrain type and property values of various resources required for or provided by the services. • Composed service - a recursive structure of elementary services. It is specified by logical sequences, if-then-else branching, and iterations - enables to define complex operations and looping execution in a workflow scenario.

8. Access-eGov system: Data structure Structural correlations between the concepts:

9. System ontologies Ontologies - a repository of data structures and a knowledge base for semantic description of the identified concepts: • Life events ontology contains semantic descriptions of possible life events, including its goals and generic scenarios. • Service profiles ontology describes the elementary services by means of functional and non-functional properties for particular service. It contains information on fees, forms, input and output artefacts, responsibility for the service, availability (e.g. opening hours of the office), address and contact information, and physical accessibility constraints. • Domain ontology is used to represent all the relevant information related to the domain of government, including e-Government concepts. It covers such non-functional properties as general and organisational structure of public administration, concepts describing quality of service, security or trust, as well as concepts related to user management and profiling.

10. Example: Service profiles ontology wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-dl" namespace { _"http://www.accessegov.org/ontologies#", dc _"http://purl.org/dc/elements/1.1/", wsmostudio _"http://www.wsmostudio.org#" } ontology webservicenfp nonFunctionalProperties wsmostudio#version hasValue "0.5.4" endNonFunctionalProperties concept webServiceNFP dc#language ofType (1 1) _string //GE-PL-SK dc#title ofType (1 1) _string //name of the service dc#description ofType (0 1) _string dc#relation ofType (0 *) link // any related web dc#rights ofType (0 *) link // law reference responsibleDepartment ofType (1 1) department responsibleOfficial ofType (0 *) person_office avgTimeToDelivery ofType (0 1) _string maxTimeToDelivery ofType (0 1) _string serviceHours ofType (0 1) _string relatedService ofType (0 *) iri serviceAccessibility ofType (0 *) accessibility concept link hlink ofType (1 1) _string //url dc#title ofType (1 1) _string dc#description ofType (0 1) _string type ofType (0 1) _string //always HTTP concept iri irilink ofType (1 1) _iri dc#title ofType (1 1) _string //service name dc#description ofType (0 1) _string • concept department • dc#identifier ofType (0 1 ) _string • dc#title ofType (1 1) _string //name of department • dc#description ofType (0 1) _string • spatialResponsibility ofType (0 1) _string • contactInformation ofType (1 1) contact_office • additionalData ofType link (0 *) • concept contact_office • street ofType (1 1)_string • streetNo ofType (1 1)_string • city ofType (1 1)_string • state ofType (0 1)_string • zipCode ofType (1 1)_string • country ofType (1 1)_string • email ofType (0 1) _string • phone ofType (0 1) _string • cell ofType (0 1) _string • fax ofType (0 1) _string • web ofType (0 1) _string • concept person_office • firstName ofType (1 1) _string • lastName ofType (1 1) _string • title ofType (0 1) _string • roleInDepartment ofType (0 1) _string • roleInService ofType (0 1) _string • availabilityForService ofType (0 1) _string • roomNo ofType (0 1) _string • email ofType (0 1) _string • cell ofType (0 1) _string • phone ofType (0 1) _string • fax ofType (0 1) _string concept accessibility wheelchairAccessible ofType (0 1) _boolean walkwayContoursAvailable ofType (0 1) _boolean webAccessibilityLevel ofType (0 1) _string printedText ofType (0 1) _boolean electronicText ofType (0 1) _boolean braileCodeOutput ofType (0 1) _boolean audioNavigation ofType (0 1) _boolean

11. Access-eGov system: Architecture Web Services + Service-oriented peer-to-peer architecture Three major component groups: • The Access-eGov infrastructure itself; • User clients - Personal Assistant tool and other end-user interfaces; • Administration and management tools (e.g. Annotation service component).

12. Access-eGov system: Structural view Full installation of AeG P2P node: annotation + interface for citizens Limited installation of AeG P2P node: annotation of services No AeG P2P node installed: external annotation of services

13. Technology used Implementation platform: • WSMO (Web Service Modelling Ontology, www.wsmo.org) - conceptual model for the description of ontologies, Semantic Web services, goals, and mediators. • WSMX execution environment - discovery, selection, mediation, and invocation of Semantic Web services. • WSML language - formal description of the WSMO elements. • Java programming language; WSMO4j data model. • Java web technologies: JSF, JSP, Apache Tomcat, Lucene, ... • Peer-to-peer engine: JXTA connectivity framework • Web services: JAX-WS

14. Web interface for semantic annotation http://www.accessegov.org/acegov/semmark/

15. Service properties (1/2)

16. Service properties (2/2)

17. Service annotation: WSML output instance _"http://www.accessegov.org/ontology#RegOfPloen_Contact" memberOf _"http://www.accessegov.org/ontology#contact_office" _"http://www.accessegov.org/ontology#street" hasValue "Burgstr." _"http://www.accessegov.org/ontology#street_no" hasValue "4" _"http://www.accessegov.org/ontology#city" hasValue "Ploen" _"http://www.accessegov.org/ontology#state" hasValue "Schleswig-Holstein" _"http://www.accessegov.org/ontology#zip" hasValue "44444" _"http://www.accessegov.org/ontology#country" hasValue "Germany" _"http://www.accessegov.org/ontology#email" hasValue "" _"http://www.accessegov.org/ontology#phone" hasValue "" _"http://www.accessegov.org/ontology#cell" hasValue "" _"http://www.accessegov.org/ontology#fax" hasValue "" _"http://www.accessegov.org/ontology#web" hasValue "http://" instance _"http://www.accessegov.org/ontology#RegOfPloen" memberOf _"http://www.accessegov.org/ontology#department" dc#identifier hasValue "RegOfPloen" dc#title hasValue "Register office Ploen" dc#description hasValue "" _"http://www.accessegov.org/ontology#spatial_responsibility" hasValue "Ascheberg, Ploen, ..." _"http://www.accessegov.org/ontology#contact_information" hasValue _"http://www.accessegov.org/ontology#RegOfPloen_Contact” namespace { _"http://www.accessegov.org/ontology#”, dc _"http://purl.org/dc/elements/1.1#" } webService _"http://www.accessegov.org/ontology/ws" nonFunctionalProperties dc#title hasValue "Register for marriage" dc#language hasValue "de" responsibleDepartment hasValue RegOfPloen maxTimeToDelivery hasValue "" dc#identifier hasValue "5E75F650-FDDF-B873-BA62-D3A57AEF743C" dc#description hasValue "Before being allowed to get married, each couple has to register at the register office at one of their places of residence." serviceHours hasValue "daily 8-12 and 14-16" avgTimeToDelivery hasValue "" responsibleOfficial hasValue Head_RegOfPloen serviceAccessibility hasValue Access_full dc#creator hasValue "AeG Semantic Markup application v.1.0" endNonFunctionalProperties ontology _"http://www.accessegov.org/ontology" instance _"http://www.accessegov.org/ontology#Access_full" memberOf _"http://www.accessegov.org/ontology#service_accessibility" _"http://www.accessegov.org/ontology#wheelchairAccessible" hasValue "on" _"http://www.accessegov.org/ontology#walkwayContoursAvailable" hasValue "on" _"http://www.accessegov.org/ontology#webAccessibilityLevel" hasValue "3" _"http://www.accessegov.org/ontology#printedText" hasValue "on" _"http://www.accessegov.org/ontology#electronicText" hasValue "on" _"http://www.accessegov.org/ontology#braileCodeOutput" hasValue "on" _"http://www.accessegov.org/ontology#audioNavigation" hasValue "on"

18. Access eGov WSMO extensions (1/2) • workflow based orchestration and choreography model • similar to DIP-Cashew proposal • workflow consists of activity nodes - control nodes (fork, join, decision), communication nodes (send, receive) and composition nodes (achieveGoal, invokeService) • nodes are connected with control links which specify the execution order (it is possible to specify common workflow patterns with sequences, branches, cycles and parallel execution) • dataflow is specified with the dataflow mediators assigned to nodes (similar to perform mediators proposed for WSMO orchestration)

19. Access eGov WSMO extensions (2/2) • dataflow mediators • specify data dependencies between activity nodes • consist of rules in the form: source {?variable} logexpr => target {?variable} logexpr where source and target denotes connected activity nodes and logical expressions and variables select data passed from the source to the target • mediation rules allow to address variables in the capability axioms assigned to goals – dataflow mediators are used to “customize” generic goal for specific case • dataflow mediators assigned to the achieveGoal or invokeService play the role of the WSMO goal-goal, goal-service and service-service mediators, i.e. resolve process and data heterogeneity between goals and services

20. customization receive receive preconditions achieveGoal achieveGoal receive postconditions send Modeling of traditional services

21. Current status, lessons learned Current status: • System ontologies - developed in co-operation with user partners. • Annotation tool for sematic description of governmental services implemented (version 2.0 almost finished). • Template mechanism - designed for description of functional properties of services. WSML templates developed for composed services, goals, and life events. • Personal Assistant client designed, first prototype will be released in September 2007. Lessons learned: • Identification of relevant services, its properties and mutual dependencies within the workflow seems to be the most critical issue. The methodology (incl. diagrams, questionnaires, step-by-step guidelines) was designed by GUC to support this process on the side of Public Administrations will be described in another presentation.

22. Conclusions and future work Access-eGov system - designed as a modular framework for integration of existing electronic and traditional services provided by public administrations. Future work: • First prototype of the Access-eGov system: To finish the implementation of the core Access-eGov system, esp. data repositories and Personal Assistant client. (09/2007) • Pilot applications: To develop and customize the system for particular pilot applications. (10/2007) • Testing, evaluation of the first trial (12/2007)

23. Thank you for your attention! www.accessegov.org Questions?