Page 1

METHODOLOGY FOR BUILDING MODELS OF LIFE EVENTS FOR ACTIVE PORTALS Ljupčo Todorovski1, Anamarija Leben, Mateja Kunstelj, Domen Cukjati, Mirko Vintar Abstract – Life event is a metaphor used to denote specific situation or event in the life of a citizen that requires a set of public services to be performed. An example of a life-event is “getting married”, which concerns two citizens, who need to perform several public services in order to get married. Integrating public services into life events is an approach to building e-government portals that help users identify and perform public services of interest. While, most of the work on building models of life-events focuses on life-event models that provide FAQ-type of information about public services typically needed to resolve the life event of interest. These do not take into account user's specific circumstances and needs, e.g., a minor or a foreign citizen that wants to get married. In this paper, we propose a framework for building generic life-event models that cover all potential user specific circumstances that can influence the resolution of the life event. Such models allow for building real active e-government portals that perform dialogue with the user in order to identify his/her specific circumstances, and based on these, tailor the generic life-event model to a specific one matching user's specific needs. We illustrate the use of the presented methodology on a case-study of modelling “getting married” life event.

1. Introduction Life event denotes a specific situation or event in the life of a citizen (or a life cycle of an organization) that requires a set of public services to be performed [6]. Life events should help the users (i.e., citizens or organizations) to identify the set of public ser-vices they need at certain stage in life. An example of a life event is “getting married” – it concerns two citizens who want to get married. Target audience for this life event is broad – any individual can face this situation and typically really does at least once in a lifetime. In order for a couple to get married, they need to perform two public services. The first is the service “applying for marriage”, which is necessary in order to check the eligibility of the couple to get married. The second is the “registering the marriage” service, i.e., the marriage ceremony itself. The most common target application of life events is building e-government Web portals [3]. These portals are developed and organized to help people identify which public services they need in a particular situation or event. The basic assumption here is that users can easily identify life events, while most of them do not know which particular public services they need nor which government or public authorities pro-vide them. Once user identifies the appropriate life event, portal should provide him/her with all information necessary to resolve it. However, different e-government portals can provide information of various kinds, both in terms of amount of provided information as well as its quality. Based on the kind of provided 1 University of Ljubljana, Faculty of Administration, Gosarjeva 5, SI-1000 Ljubljana, Slovenia, [email protected]

Page 2

METHODOLOGY FOR BUILDING MODELS OF LIFE EVENTS FOR ACTIVE PORTALS

information, we can classify the portals into two classes [7]. The first is passive portals class. A passive portal typically helps user to identify his/her life-event by organizing them in taxonomy (or more generally in a mesh) of administrative areas and topics. By browsing this space of topics and sub-topics, user identifies his/her life event and finds an FAQ type of information about the set of public services needed to resolve it and, where available, links to appropriate e-services. This kind of information has limited scope. In case of “getting married” life event, it covers the case of typical couple of adult domestic citizens. However, an alien citizen coming from a foreign country (or a minor citizen) would typically need different public services and will typically find provided information insufficient. On the other hand, portals in the second, so-called active, class provide user with a complete guide through the set of necessary public services. The first phase of identifying life event can be the same as for passive portals – the difference comes into play later, when user already identified the appropriate life event. First, active portal performs dialogue with the user to identify all his/her circumstances that can influence the life-event resolution. Based on the dialogue, active portal should provide user with a list of public services tailored to his/her circumstances and needs. For example: a minor citizen should first be guided to a public authority where appropriate marriage permission is to be obtained, an alien citizen should be shown the list of support documents specific to his/her country of origin, he/she needs to attach to the application form in order to get married, etc. Furthermore, active portals should guide users through the set of consecutive life events or public services, needed after the marriage due to the last name or residence address change. For the purpose of building passive portals, one needs simple life-event models that include life-event description that allows for user identification, a list of public services corresponding to the life event, and a description of each public service from the list. The description can be informal and free-text, since the passive portal directly presents it to the user with no or minor representational change. GovML recommendation for describing public services and life events [5] provides a solid framework for building such models. Also, most of the existing literature on life events and portals based on them focus on this kind of models. In this paper, we aim at building model models for active portals. These models are more complex and general. In addition to information provided in the GovML-based models, include formal description of all potential user circumstances that can influence life-event resolution as well as the formal description of the influence, which can be two fold. First, the set of public services needed as well as the time plan for their execution depends on the specific circumstances (e.g., obtaining a permission for a minor to get married). Second, the set of support documents that have to be attached to the application form needed to initiate the execution of each public service depends on the user specific circumstances (e.g., an alien citizen needs a certificate that he/she is a single issued in the country of origin). Provided such formal description, active portal is able to match the general life-event model with the information obtained from the dialogue with the user and build a specific life-event model tailored to his/her specific circumstances and needs. This specific life-event model is effectively a plan or a guide for life-event resolution. In this paper, we introduce a framework for building life-event models for active portals. Section 2 discusses related work. We define life-event models and classify them based on the level of details included within in Section 3. Section 4 introduces a methodology for building models and illustrates its use on an example of “getting married” life event. Finally, Section 5 concludes the paper and provides directions for further research.

Error! Reference source not found.

Page 3

2. Related Work The framework we propose here is related to Governmental Markup Language (GovML) [5] that specifies data structures (or vocabularies) for governmental data and meta-data. GovML is a modified XML format that specifies three data vocabularies: (1) a declarative vocabulary for describing life events, (2) a generic procedural vocabulary for describing public services at national level, and (3) a specific procedural vocabulary for describing public services as performed at individual service providers (public authorities). Note that the GovML data vocabularies as well as the approaches taken within the eGOV platform do not include support for formalizing specific user circumstances and needs that can substantially influence the life-event resolution in the description of life events and public services. While this information can be included in GovML elements of the public events data vocabulary, such as procedure description or attention, and thus, models based on GovML can not be directly used for implementing active portals. Another approach related to creation a top-level description for the public administration domain is Governance Enterprise Architecture (GEA). GEA consists of a family of data and process models describing the overall governance system in a generic fashion [4]. GEA consists of a set of models and serves as a top-level generic Enterprise Architecture for the overall governance domain. The models include: GEA mega-process model, GEA interaction model, GEA public policy formulation object model, GEA service provision object model, and GEA object model for the overall governance system. The most related concept from GEA is the orchestrator component, which deals with the internal logic and the details of the execution workflow for each public e-service – it invokes, manages and terminates workflow throughout the service execution. The workflow can be, in principle, dynamic and tailored to user specific circumstances and needs. However, GEA does not really explore this possibility and it also focuses on individual public services rather than life events. Thus, GEA currently does not support for developing active portals based on life events. Finally, note that architecture of an active e-government portal based on life events has been already proposed in [2]. There, knowledge base that consists of life-event models is one of the most important components in the architecture. In this paper, we focus on the knowledge base itself, i.e., present a methodology for analysis and modelling of life events to be used within the proposed architecture.

3. Typology of Life-Event Models A model of a life event (or LE model) is a formal description of the life event. LE models can be detailed at different levels. From analysis of the existing approaches to building LE models, we can identify four abstraction levels presented in Figure 1. At the first (identification) level, the life-event model consists of a brief life-event description that should allow users to easily identify which life-event corresponds to their current life situation. LE models at this level usually take a form of a (somewhat informal) free-text description. Beside this brief description they also include further specifications that can make the process of user identification easier. Examples of these are LE administrative area or topic (such as, taxes, healthcare, education, etc.) and LE target audience. GovML data vocabulary for life events [5] is an example of a comprehensive standard template for building LE models at this first identification level. LE models at the second (specification) include information from the identification level as well as information about all the public services corresponding to the life event. Information about individual public services typically focuses on facts important to users that need to

Page 4

METHODOLOGY FOR BUILDING MODELS OF LIFE EVENTS FOR ACTIVE PORTALS

perform those public services. It typically includes a brief informal free-text description of the service, who is the service provider, a list of documents that are necessary to request the service from the provider (i.e., application forms and support documents), typical time needed to perform the service, maximal time for performing the service as specified in relevant legal acts, cost of the public service, pointers to legal acts related to the service, etc. GovML data vocabulary for public services is a comprehensive standard template for building LE models at the specification level. LE models on the specification level contain enough information for establishing a passive e-government portal. They provide user with a static list of public services (and links to their electronic counterparts where available) corresponding to the life event of interest as well as static list of application forms (and links to electronic versions thereof where available) and support documents needed to trigger execution of each public service. However, specification level models can not provide user with active guide through necessary services and documents. This is due to the fact that models on the specification level lack formal declaration of different circumstances that can influence the resolution of the life event, and therefore are unable to adapt to user specific needs and interests. Front office

passive

identification level life-event

specification level

active

static list of services and documents

circumstances

interactive level active guide through services and documents

Back office

transaction level

Figure 1. Life-event models at four level of abstraction.

The aim of LE models at the third (interactive) level is to overcome the limitation of descriptive LE models and provide basis the development of real active portals. In order to do this, we should extend LE models with information about all potential user circumstances that can influence the resolution of the life event. The influence is two fold. First, the list of public services needed to resolve a life event depends on user specific circumstances. In our “getting married” example, a minor citizen that wants to get married needs to perform additional public service to get a marriage permission prior to applying for marriage. The second influence of user circumstances is on the list of support documents that have to be attached to an application form for initiating a public service execution. In our “getting married example” a foreign citizen that wants to get married should provide a certificate that he is a single from his/her country of origin. Thus, the interactive LE model covers all the possible user circumstances that can influence the resolution of the marriage life event. Note that all this information is usually part of the LE models on the descriptive level as well, since they usually contain pointers to relevant legal acts that specify all relevant circumstances. The main difference is however that this information is made formal and explicit in the LE models at the interactive level. That means that the active portal software can make use of this formal specification to query user about relevant circumstances and use user responses to tailor the generic LE model to the specific user needs. This tailored LE model provides a guide for the user in terms of (1) a time plan (or a graphical workflow model) that guides user through public services he/she needs; and (2) a tailored list of support documents that user has to attach to the application forms necessary to trigger those services. In the next section, we present a methodology for building generic LE models at interactive level.

Error! Reference source not found.

Page 5

While the LE models on the first three levels provides user (front-office) perspective on the life events, the models at the lowest (transaction) level deal with the service provider (backoffice) perspective. At this level, models include all the necessary information for employees of the service provider on how to perform individual public services. LE models at this level are process models, i.e., models of individual processes performed by the service provider in order to deliver the public service. These LE models are most complex models and are not necessary for building active e-government portals. They are rather used as a basis for building electronic counterparts of public services. As mentioned earlier, in the rest of this paper we will focus on LE models at the third, interactive, level.

Figure 2. The relation between building blocks of life-event models at the first three levels of abstractions.

4. Modelling Life Events for Active Portals In this section, we present a methodology for building life-event models at interactive level that allows for implementing active e-government portals. As we mentioned earlier, life-event models at the third level are not independent from models at the first two levels. In contrary, information necessary for building LE models at the first two levels is crucial for the models at the third level. Figure 2 presents the relation between models at the first three level of abstraction as well as the necessary building blocks. At the first, identification level, the only building block is the life-event description. At the second, declarative, level the life event is related to the set of all public services necessary to resolve the life event. Each public service is provided by a public authority referred to as a service provider. Also, user is required to submit a set of documents in order to initiate a public service. This set of document usually consists of an application form and a number of support documents that have to be attached to it. Finally, the building block at the third, interactive, level is the user circumstance. As shown on the figure, both (1) the set of public services required for a life-event resolution as well as (2) the set of documents necessary for performing individual public services depend on the user circumstances. The main contribution of our methodology is formalization of the user circumstances into the life-event models. The proposed methodology follows the diagram shown in Figure 2. For the purpose of describing life events and public services the presented methodology builds upon corresponding GovML data vocabularies [5]. Therefore, the information gathered following this methodology will correspond to different modelling levels – if it refers to the life event as a whole, this information will be at the first, identification, level, information that refers to individual public services corresponds to the second, descriptive, level and finally, information related to user specific circumstances corresponds to the third level. In order to build an interactive life-event model, we first perform an analysis of a life event, where all necessary information corresponding to the life event of interest is gathered. We organize this information following three GovML-like tabular templates. The first template correspond to life-event descriptions, the second to the description of individual public events,

Page 6

METHODOLOGY FOR BUILDING MODELS OF LIFE EVENTS FOR ACTIVE PORTALS

and the third one to the documents related to individual public services. In the rest of this subsection, we describe these templates in detail and illustrate their use on the example of a “getting married” life-event model. 4.1. Life-Event Description We start the analysis with building a description of the life event, which consists of the five data elements described in detail below. Table 1 presents an example description for the “getting married” life event. Table 1. “Getting Married“ life-event description. Title Brief Description

Getting Married The “getting married” life event concerns a couple that wants to get married. Beside the usual act of marriage, this life event includes also “applying for marriage” public service that should be preceded by other services in specific cases of minors or relatives that want to get married. In many cases marriage act leads to personal data change (such as last name and address), so typically public services related to personal documents change are to be considered as well. Related Legal Acts MFRA – Marriage and Family Relations Act (Official Journal SRS, issues 15/76; 30/86, 20/881-corrected; 1/89; 14/89; Official Journal RS, issue 13/94; 82/94; 29/95; 26/95; 26/99; 70/00; 42/03 – decision of the Constitutional Court, 16/04, 69/04-UPB1) RMC – Rules on Marriage Conclusion, based on 28a/2 of MFRA (Official Journal RS, issues 71/03, 131/04, 73/05) Related Public Services Obtaining marriage permission for close relatives and Life Events Obtaining marriage permission for a minor Obtaining permission for marriage registration outside official premises Applying for marriage Marriage registration (official act of marriage) Personal data change User Circumstances Partners are close relatives A partner is a minor Wish for a marriage registration outside official premises A partner is a foreign (alien) citizen A partner belongs to a national minority

1. Title corresponds to the life-event title that should be as specific and clear as possible, in order to allow potential user an easy identification, i.e., provide he/she with clear association to his/her life situation. 2. Brief Description data element provides a brief free-text description of the life event. Since the title should be self-explanatory, a paragraph with a few sentences usually suffices here and should clearly describe the life event to the user. 3. Related Legal Acts provides a complete list of basic legal and regulation acts that are to be followed to resolve the life event. Note that one can argue that basic legal acts are not relevant for the user at this stage. However, these acts are of crucial importance for further life-event analysis and many other data elements (for both public events and corresponding documents) are depicted from them. 4. Related Public Services and Life Events data element corresponds to the list of public services that correspond to the life event. Sometimes, this list might include other life events that are usually triggered by resolution of the particular life event. 5. User Circumstances data element corresponds to a complete list of all user circumstances that can influence or are important for the resolution of the life event. The influence of user circumstances can be two fold: on the set of the public services that has to be performed or on the set of support documents that need to be attached to the corresponding application forms (and in some cases on both).

4.2. Public Service Description Each public service related to the life event of interest has to be described using the set of ten data element described below. Table 2 presents an example description of the most important public service related to the “getting married” life event. Table 2. Description of the “Applying for Marriage” public service. Title Service Provider Authority Competence Legal Basis

Applying for Marriage Administrative Unit Territorial competence based on where the marriage act (registration of the marriage) will take place. RMC, articles 16 though 27

Error! Reference source not found.

User Circumstances

Page 7

For close relatives – permission for marriage of close relatives needed. For minors – permission for marriage of a minor needed. For marriage registration outside official premises – permission for marriage outside official premises needed. Should be initiated at most 3 months and at least 14 days prior to marriage registration. If partners have a wish (and do not have important reasons) to register marriage outside official premises, should be initiated at least 45 days prior to marriage registration. Partners to be Partners to be tax: 7.650 SIT; if one (or both) of the partners is (are) foreign citizen(s) – additional cost for foreign language interpreters 14 days or less

Time Dependencies Initiator Recipient Cost Info Delivery Time

1. Title corresponds to the official title of the public service as specified in the corresponding legal acts. 2. Service Provider data element specifies the public authority (and in some cases other type of organization) that provides the public service. 3. Authority Competence data element is to be specified in cases when there are many potential service providers in different territorial units of the country – we specify here how the authority competence is determined. Usually, it is a territorial competence based on users’ residence, but in cases when a public service relates to more then one user the territorial competence might also be ambiguous (i.e., which user residence?) and thus it has to be additionally specified. 4. Legal Basis corresponds to a list of legal and regulation acts (using abbreviations defined in Table 1) together with references to specific articles and/or sections thereof that regulate the particular public service. 5. User Circumstances data element, similarly to the life-event description case, specifies the list of potential user circumstances that influence the provision of the public service. In addition, for each circumstance we specify the influence itself from the user perspective, i.e., what a user in these circumstances needs. 6. Time dependencies are specified for a public service that has to be executed prior to the execution of another public service. Sometimes a service execution has to be initiated at least (or at most) so many days before the execution of other services. We also note such dependences as well. This information is important for building graphical workflow models of life events. 7. Initiator specifies who should initiate the public service – the end user or the service provider without user interference. 8. Recipient data element specifies who receives of the results (usually documents) of the public service. 9. Cost Info provides user with information about the cost of the public service that typically consists of an administrative fee and additional expenses. 10.Delivery Time data element specifies how long the delivery of the output of the public service takes. Two time specifications can be included here: (1) maximum time as specified in the legal acts; and (2) expected delivery time (time typically needed by the service provider to deliver the service).

4.3. Public Service Description Finally, in the last step of the life-event analysis, we have to identify documents that are necessary for performing public services related to the life event of interest. For each document we specify five data elements described below. Table 3 provides example descriptions of three (out of 16 documents) necessary for the “marriage application” public service described in Table 2. Table 3. Example descriptions of three documents related to the “Applying for Marriage” public service. Title Marriage application Birth certificate international form Permission marriage

or

Role A on

denial

an SD

Issuer User Circumstances Refers To Administrative Unit Country of Origin One (or both) of the Each partner that is a foreign partners is (are) foreign citizen citizen(s)

of D

1. Title corresponds to the formal title of the document as specified in the corresponding legal acts. 2. Role data element specifies the role that the document has with regard to the public service: (1) an application form that is needed to initiate the service (A), (2) a decision or the outcome of the service (D), and (3) a support document that has to be attached to the application form (SD). 3. Issuer specifies the public authority or other organization that issues the document. If the document is an output document of a public service (i.e., a decision) then the document issuer is the same as service provider. In that case, this field can be left empty.

Page 8

METHODOLOGY FOR BUILDING MODELS OF LIFE EVENTS FOR ACTIVE PORTALS

4. User circumstances data element specifies the circumstances when the document is required as a support document. 5. Refers To data element specifies the user for whom the document is required. Namely, in certain cases, documents referring to third parties are required to be attached to the application form. In those cases, we should specify whom the document refers to (see the example in the table).

5. Conclusion and Further Work In this paper, we first identify a proper level of abstraction for life-event models that would allow for development of active portals. Most of the existing work on modelling life events relate to two other levels of abstraction. Researchers developing front-end integration of public services focus on descriptive life-event models that include basic FAQ-type description of life events and public services and thus allow for implementing passive e-government portals. On the other hand, work related to reengineering of back-office processes related to public services focuses on detailed process models of individual public services that require tedious analysis and modelling work. We argue here that both these levels of abstraction are inappropriate for development of active e-government portals and propose an intermediate “interactive” level. Life-event models at this abstraction level extend descriptive models with formalization of all user circumstances that can influence the resolution of the life event. Finally, we propose a methodology for analysis and modelling of life events that lead to interactive models and illustrate its use on the example of “getting married” life event. The immediate direction for further work is integration of the proposed methodology into an active-portal framework, such as the one proposed in [2] and [7]. Prior to integration, several steps have to be performed. First, we should encode our models into knowledgerepresentation formalism (such as RDF). In turn, standard reasoning engines can be used to match specific user circumstances and infer a specific life-event workflow that is tailored to user’s life situation. Such a specific workflow will provide users with active guide through the process of life-event resolution within a real active e-government portal.

References [1] Apostolou, D., Stojanovic, L., Pariente Lobo T., and Thoenssen B. Towards a Semantically-Driven Software Engineering Environment for eGovernment. In Proceedings of the International Conference on E-Government: Towards Electronic Democracy. Springer-Verlag, Berlin (2005) 157–168. [2] Leben, A. and Bohanec, M. Architecture of an active life-event portal: a knowledge-based approach. In Proceeding of the Fifth Working Conference on Knowledge Management in Electronic Government. Springer-Verlag, Berlin (2004) 131–140. [3] von Lucke, J. Portale für die öffentliche Verwaltung: Governmental Portal, Departmental Portal in LifeEvent Portal. In: Reinermann H. and von Lucke J. (eds.): Portale in der öffentliche Verwaltung. Forschungsinstitute für öffentliche Verwaltung, Speyer (2000). In German. [4] Peristeras, V. and Tarabanis K. A. Providing Pan-European E-Government Services with the Use of Semantic Web Services Technologies: A Generic Process Model. In Proceedings of the Fourth International Conference. Springer-Verlag, Berlin (2005) 226–236. [5] Tambouris, E., Kavadias, G., and Spanos E. The Governmental Markup Language (GovML). Journal of E-Government 1 (2004) 59–70. [6] Vintar, M., Kunstelj, M., and Leben, A. Benchmarking the quality of Slovenian life-event portals. In Improving the Quality of East and West European Public Services. Ashgate, Burlington (2004) 208– 221. [7] Vintar, M. and Leben, A. The Concepts of an Active Life-event Public Portal. In Proceedings of the First International Conference on Electronic Government. Springer-Verlag, Berlin (2002) 383–390.