icegov2012 proceedings

Expert
1. Expert
describes service
3. Dialogue
launched
«subsystem»
Service Representation
Tool
2. Service model
transferred
«subsystem»
Dialogues Presentation
Website
4. Citizen executes
dialogue
End-­‐user
Figure 6. Main Architecture of dialogue-based platforms
More specifically, the platform consists of two sub-systems: a
Service Representation Tool and a Dialogues Presentation
Website.
The platform is used in a 4-step manner. In the first step, an expert
uses the Service Representation Tool in order to describe
(verbally or using a model) the public service. In the second step,
a file describing the service is transferred from the Service
Representation Tool to the Dialogues Presentation Website. In the
third step, the dialogue is automatically created and launched.
Finally, in the last step the end-user (normally citizen or business)
visits the Dialogues Presentation Website, executes the dialogue
and obtains the required information.
By examining the different approaches for the Service
Representation Tool we decided to endorse modeling of public
services since we believe it is more straightforward and widely
used as it can also be based on open standards for process
modeling. RI platform employs ontologies which we believe is
less straightforward than provess modeling. On the other hand,
OneStopGov platform is based on proprietary software and
handles both informative and performative phases thus is more
complicated than needed for our objectives.
Using a diagram for PSP has significant advantages [11]. In our
case, it enables (a) easy representation of PSP IP by domain
experts (usually public servants) without any programming effort,
(b) analysis and better understanding of PSP IP complexity using
a number of indicators, (c) easy management of PSP IP by reusing
and changing diagrams, (d) easy validation of diagrams, (e)
eventually development of better quality public services, (f)
citizens and businesses to obtain personalized information about
public service simply by answering online questions instead of
face-to-face interactions, using a call center etc.
It should be noted here that extensive research has been conducted
in the area of personalized PSP mainly using ontologies and rules,
e.g. [1]. In this paper however we focus on more visual and easyto-use
technologies for the reasons stated above. In addition, the
descriptions of public services in relevant legal documents are
usually detailed hence can easily result in deterministic models
that can be easily verified.
3. NOTATION AND INDICATORS
An important element for the production of personalized
information is the development of a model that will represent the
public service’s dialogue.
In order to model the informative phase of PSP, we developed a
simple modeling notation that allows for the visual representation
135
of the dialogue. We also present the rules that need to be followed
for the resulting model to be valid.
Having represented a public service using a model enables us to
obtain interesting information about the service. In this respect,
we propose a number of indicators to better understand the
modeled public services.
3.1 PSP IP Dialogue Model
The main idea is to model the PSP informative phase (PSP IP) as
a dialogue (or interview) between the public authority and the
visitor (citizen or business). The model thus mainly contains
questions and possible answers. For example, when modeling
public service “issuing a marriage permit”, a possible question is
“what is your marital status?” with possible answers “single”,
“divorced” etc. The model also contains information on input
documents that should be submitted by the citizen for invoking
the public service as well as information on cost or subsidy
depending on the nature of the service.
Using this dialogue model one can quickly and without any
ambiguity determine whether he is eligible for a service or not.
Eligible visitors can further obtain personalized information such
as required documents to be submitted for service invocation and
costs.
3.2 PSP IP Modeling Notation
In Table 1 we present a simple notation proposed for modeling
PSP informative phase. This notation is influenced by BPMN
(http://www.bpmn.org/), graph theory, academic public service
models (e.g. GEA [9]), templates used for describing public
services (e.g. in national portals) as well as templates proposed in
national eGovernment Interoperability Frameworks. The only
reason for proposing a new notation instead of adopting an
existing such as BPMN is simplicity. We aim at a notation with
only a few symbols since our experience suggests simplicity is of
paramount importance if the tool is to be used by public servants.
The diagrams produced using this notation represent the dialogue
between the system and the user. From a technical point of view
each diagram is actually a directed acyclic graph.
The notation is briefly explained now (the term visitor here
represents anyone executing a dialogue).
o Start node. Represents the start of the diagram.
o End node. Represents the completion of a dialogue in the
diagram. It can be one of the following:
-­‐ Eligible. It suggests the visitor is eligible for the
service.
-­‐ Not Eligible. It suggests the visitor is not eligible for
the service.
o Question. Represents a question posed to the visitor e.g.
“Which is your current marital status?”
o Answer. Represents a possible answer to an expressed
Question e.g. “Married”.
o Input Document. Represents a document the visitor should
provide based on a previous answer. For example, a
“Married” answer to a question might lead to a need for
submitting a “marriage certificate” as a required document
for invoking the public service.