www.elsevier.com/locate/ecra

Electronic Commerce Research and Applications 6 (2007) 113–124

A knowledge-based approach for developing multi-channele-government services

C. Vassilakis a,*, G. Lepouras a, C. Halatsis b

a Department of Computer Science and Technology, University of Peloponnese, Terma Karaiskaki, Tripolis 22100, Greeceb Department of Informatics, University of Athens, Athens 15784, Greece

Received 8 September 2005; received in revised form 9 February 2006; accepted 2 July 2006Available online 4 October 2006

Abstract

Having realised the benefits resulting from delivering on-line public services in the context of electronic government, administrationsstrive to extend the spectrum of services offered to citizens and enterprises, as well as to engage multiple communication channels in ser-vice delivery, in order to increase the target audience and, consequently, the service effectiveness. Insofar, however, only the web channelhas been sufficiently used for service delivery, whereas other channels have not been adequately exploited. One of the main reasons of thislag is the cost incurred for the development and maintenance of multiple versions of an electronic service, each version targeted to adifferent platform. In this paper, we present an approach and the associated tools for developing and maintaining electronic services thatallows the automated production of different versions of the electronic service, each targeted to a specific platform.� 2006 Elsevier B.V. All rights reserved.

Keywords: e-Government; Electronic services; Multi-channel service delivery; Forms design for eServices

1. Introduction

According to the European Commission, electronic gov-ernment can be defined as an ever-increasing and pervasiveuse of information and communication technologies in thecontext of the Information Society, which more and moreaffects the public sector; the importance of this develop-ment is increasingly acknowledged in many countriesaround the world and experiments are being conducted atall levels of government – local, regional, national andEuropean – to improve the functioning of public servicesconcerned and to extend their interaction with the outsideworld [1]. This interaction is mainly performed in order toachieve three goals: providing public services, improvingmanagerial effectiveness and promoting democracy [2].For public services provision in particular, benchmarkshave been defined [3] and studies have been conducted

1567-4223/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.elerap.2006.07.004

* Corresponding author. Tel.: +30 2710372203; fax: +30 2710372160.E-mail addresses: costas@uop.gr, gl@uop.gr (C. Vassilakis), halat-

sis@di.uoa.gr (C. Halatsis).

regarding the development and sophistication of on-lineservices ([4–6]).

Besides however promoting on-line availability andsophistication of their services, administrations should alsotake into account the channels through which their servicesare delivered. Traditionally, administrations deliver theirservices through the web, while other potential servicedelivery channels (e.g. WAP, i-mode, SMS, phone centres)are not adequately considered in most cases. This policythough introduces additional barriers to the service accep-tance and use by citizens for a number of reasons including:

1. Internet usage: in order to use some service deployedthrough the WWW a citizen should have access to theInternet. Since not all potential service users have accessto the Internet (studies report that Internet usage –either from home or from work – ranges from 66.5%in North America to 31.6% in Europe (in average) [7]),limiting a service to the WWW channel effectivelyexcludes a large portion of the population. Althoughseveral measures can be taken to alleviate this problem,

114 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

including information kiosks [8,9] and access throughlibrary computers, the issue cannot be fully addressed,since it does not only relate to computer availabilitybut computer literacy and other factors as well.

2. Channel penetration and user readiness: some householdsand/or enterprises do not own a computer with an Inter-net connection, but most of them are equipped withfaxes, phones or mobile phones, with some of themencompassing WAP or i-mode capabilities (e.g.[10,11]). This portion of potential service users couldmore readily access a service if it were delivered throughone of the latter channels.

3. Lack of appropriate know-how: computers are morecomplex to learn and use than mobile phones, faxes orinteractive TV; thus delivering services through the‘‘simplest channels’’ broadens the target population.An example of such a case is the issuance of tax clear-ance certificates service, provided by the Greek Ministryof Finance. The service is available via the web and thefax channel, but its target group (which has been limitedto certified governmental agencies, notaries and banksto guarantee the confidentiality of taxation data) showsa strong preference towards the fax channel ([12,13]).

4. Channel appropriateness for specific services: some ser-vices are inherently more appropriate for deliverythrough mobile channels (e.g. paying tolls, reservingparking places, etc.) since citizens mainly use these ser-vices on the move, and consequently have limited orno Internet access. On the other hand, a number of com-plex services may not be appropriate for all platforms,e.g. filling in a tax return form using SMS technologyis clearly impractical and should not be considered.For determining whether a service should be deliveredthrough multiple channels (and which these channelsare), a six-step methodology is presented in [14]. Accord-ing to this methodology, firstly the features of the avail-able channels are rated; this is a service-independent stepand can be performed only once for all services. Subse-quently, service provision requirements for each serviceare rated and channel features are matched against ser-vice provision requirements. Channels meeting all therequirements for a specific service are short-listed. Theshort list is then filtered, ruling out channels (a) notcommonly used by the service target group, (b) techni-cally or organisationally unsuitable for the service and(c) not being cost-effective. In the rest of this paper wewill only consider services which will be deliveredthrough multiple channels, although the presented mod-elling and development approach can be applied to ser-vices that will be delivered through a single channelonly.

We should note here that in some cases multi-channelcharacteristics are needed to effectively deliver a servicethrough a single channel. This situation may occur if thecapabilities of the client devices used to access the servicediffer significantly. For example, in the case that a service

involving 15 fields is delivered through the web, these fieldsmay be conveniently placed on a single form, if the clientdevice will be a PC with screen resolution 1024 · 768; how-ever, multiple forms might be needed if the client devicewere a handheld computer with a screen resolution of240 · 320 pixels. Similar considerations may hold for theinput device capabilities (e.g. a limited keyboard makesthe choice from a closed list more appropriate than typing,such as the case reported for ISDN card phones [15] ormobile phones [16]), support of active features (e.g. Java-Script and particular versions of it) and so forth.

An additional incentive for organisations to adoptmulti-channel service delivery (besides lifting the user-related barriers listed above) is that multi-channel deliverybears a number of benefits for the delivering organisation[17].

A particularly important reason for limiting the servicedelivery channels to the web can be traced to the costs asso-ciated with developing and maintaining multiple versionsof the same service. Indeed, the development of a servicethat will be delivered through multiple channels is usuallyaddressed as a number of distinct projects, with each pro-ject developing the service for a specific channel. Each suchproject is undertaken by a different development team(with channel-specific expertise), thus the service develop-ment cost increases significantly when multiple dissemina-tion channels are used. Similar issues are faced with themaintenance procedure, where modifications to the service(due to legislation changes, modification of procedures orfeedback from the service users) must be reflected to eachdistinct implementation. This approach is illustrated inFig. 1.

Note that for an optimal delivery of electronic govern-ment services, structural reforms, and the adoption of acustomer-centric model are required [18], which incur addi-tional costs; these costs, however, are (largely) independentof the number of channels through which services are dis-seminated and will be undertaken by the organisation evenif only a single channel is employed.

In this paper we present a knowledge-based approachfor developing and maintaining electronic services, whichenables the automated production of service versions thatare tailored for specific delivery channels. According to thisapproach, the (channel-independent) business logic is sepa-rated from the (channel-dependent) presentation issues foreach delivery channel, allowing for the modelling the busi-ness logic to be performed only once. Finally, generation

engines are employed to produce executable service imagesfor the selected delivery channels.

Through re-using the modelling of the services’ businesslogic and automating the error-prone task of platform-spe-cific code generation, this approach minimises the time andresources needed for multi-channel service development.Maintenance activities are also facilitated, since changesto the services’ business logic need to be performed onlyonce, without the risk of inconsistencies. The approachhas been complemented with appropriate tools, which

Requirementsanalysis Design Operation Evaluation

Implementationof business logic

Implementationof access mechanism

Fig. 1. Service delivery phases, repeated for each dissemination channel.

C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124 115

enable the electronic service stakeholders to perform therelated tasks, i.e. modelling of the service’s business logic,creation of the channel-specific presentation schemes and,finally, the generation of executable service images.

The rest of this paper is organised as follows: Section 2surveys related work regarding multi-channel delivery ofelectronic services. Section 3 describes the modellingapproach, while Section 4 presents the related tools.Finally, Section 5 concludes the paper and outlines futurework.

2. Related work

The need for multi-channel service delivery has beenrecognised by the research community, industry and stan-dards organisation alike. Ref. [19] attempts to determinethe feasibility of a component-based approach, which willtackle the issue of highly fragmented ICT-architecture. Thiswork argues that current ICT installations and know-howhas been vertically organized around departments with littleor not at all common horizontal functionality, hinderingthus the development of multi-channel services. A numberof e-government architectures that have been proposedinsofar, namely the European one-stop government (EOSG[20,21]), the Federal Enterprise Architecture (FEA [22]) andthe extended Enterprise Application Integration ([23,24])include multi-channel access to e-services as core function-ality of the delivery platform. Finally, in [25] a more holisticview for service access is undertaken, attending to thespecifics of users, uses, organisational capacity, data charac-teristics, and technology, surveying among other featuresthe multi-channel delivery of services.

In the industry sector, numerous software products haveemerged in the past few years that facilitate the provisionof services through multiple channels. The eGain servicesuite [26] incorporates a web, email, fax, letter manage-ment, and a contact centre, however, the actual servicesare only provided through the web channel using the webself-service module and other channels play only a support-ive role for communication and limited browsing. Thesame approach is also followed by Oracle MultichannelCustomer Service [27], which integrates the web-self servicemodule into the organisational service workflow.

Another approach that has been employed to accommo-date more dissemination channels in service delivery withminimal development is the use of gateways. Under thisapproach, a service is developed and deployed for some pri-

mary channel (e.g. the web channel) and gateways are

attached to the remaining channels (e.g. WAP, i-mode,etc.). When a gateway receives a request from the channelit is attached to, it arranges to retrieve the relevant contentas encoded for the primary channel and employs a dynamic

translator to re-encode this content into a form suitable forthe channel it is attached to. Examples of such convertersexist both in commercial products (e.g. [28,29]) and in theopen-source/shareware domain ([30,31]). XSLT technology[32] can also be used to dynamically formulate content tar-geted to a specific dissemination channel, by providing anappropriate transformation description, which will beapplied by the gateways to some XML-compatible repre-sentation of the content. This representation may be eithertailored to some specific delivery channel (e.g. the web), orbe written in a more ‘‘abstract’’, semantics-oriented form(e.g. XML). Regardless of the specific technique used, how-ever, gateways do not satisfactorily address the issue ofdiverse capabilities of client access devices, either withinthe same or across different dissemination channel, whiletheir dynamic nature introduces processing overhead,which can prove overwhelming for heavily used sites.

In the standards area, XForms [33] is a considerabledevelopment that may be used to some extent for support-ing multi-channel services. XForms provide a new plat-form-independent mark-up language for onlineinteraction between an XForms Processor and a remoteuser agent. The basic feature of XForms that facilitatesmulti-channel service delivery is the separation of the model

(form logic) from the view (channel/device dependent pre-sentation), a provision that is in line with the approachdirections outlined in Section 1. This separation enablesthe client access devices to use the most appropriate con-trols to render the form, augmenting thus multiple devicesupport and accessibility [34]. The extent however to whichan XForms-based application can be customised remainslimited, since for instance placement of elements on formsis rigidly defined and cannot be dynamically formulatedbased on the channel and/or client access device character-istics. Another issue hindering the adoption of the XFormsstandard is the lack of support for it within the Internetbrowsing program community. Indeed, only recently betareleases of software for incorporating XForms support intothe Internet Explorer and Mozzila/Firefox browsers havebeen announced [33], although working drafts and testsuites for XForms have been available for more than twoyears. Some other implementations have been released inthe past, but have proven unstable and/or with very limitedfunctionality. Server-side implementations of XForms also

116 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

exist (e.g. [35]), where the XForms model is stored on theserver but it is translated to an appropriate representationbefore it is sent to the client, but still customisation capabil-ities remain limited.

3. A knowledge-based approach for modelling multi-channelelectronic services

The proposed electronic service modelling approachuses high levels of abstraction for describing electronic ser-vice aspects rather than focusing on the software elementsused for implementing them. Service modelling under thisapproach is divided into five stages, four of which, namelymodelling of service purpose, content, business logic andevaluation criteria are channel-independent and need beto performed only once for each service, whereas the fifthstage, namely modelling of user access and visual layouts,is channel-dependent and needs to be performed for everydelivery channel. These stages are described in the follow-ing paragraphs.

3.1. Modelling service purpose

To start with, each service has a specific purpose, e.g. itissues birth certificates or it allows for electronic submis-sions of tax return forms. The electronic service purposenormally stems from the organisation’s mission statementand/or its operational framework. Typically, this stage isperformed by managers, who have a high-level view ofthe organisation’s mission statement.

3.2. Modelling service content

Another aspect of the electronic service that needs to bemodelled is the actual service content, usually defined via aregulatory framework (laws, directives, regulations, etc.).This regulatory framework can be exploited in the contextof describing an electronic service in three ways:

1. The actual data that need to be collected by the service are

defined: for instance, the regulations pertaining to abirth certificate service may state that the requesting cit-izen should present some proof of identity (e.g. an iden-tity card, a passport, a driver’s license, etc.) and statehis/her current address of residence. This implicitlystates that an electronic service (or even a paper-basedone) should provide the service user with some spaceto fill in the identity card number (or passport/socialsecurity number and so on) and some space in whichthe residence address will be provided. For more com-plex services (e.g. tax return forms), the list of inputsmay extend to a few hundreds of input fields. Each pieceof data is usually complemented with some metadata,defining the field’s description, labels for presentationetc. For the electronic versions of services, in particular,certain requirements may originate from the electronic

nature of the service, e.g. requirement for presentationof an user name and a password, which will be givento the user after a registration process etc.

2. Validation checks that need to be performed for the user

input: in the simplest case, such checks will designatemandatory items that must be entered, as opposed toprovisional items. For instance, providing a value forthe proof of identity field is mandatory in a birth certifi-cate electronic service, while entering the zip code of theaddress can be considered to be provisional. Type andrange checks are another class of validation checks thatshould be modelled. Note that such checks may notalways be expressly included within the regulatoryframework but are known to domain experts, constitut-ing thus tacit knowledge [36]. For instance, the regula-tory framework of the tax return form submission maynot expressly state that the number of children in thevalue entered in the expenses field should be a positivereal number with two decimal digits, but domain expertsdo know that such a restriction should hold. Finally,another class of validation checks may involve multipleinput fields within a single validation check, such as ‘‘if avalue is provided for field A, then a value should be pro-vided for field B as well’’ (e.g. if expenses for house ren-tal are declared the landlord VAT number should beprovided as well), algebraic relationships between valuesin different fields (e.g. the gross profit minus expendi-tures should equal the net profit, the interests cannotexceed the 10% of the capital, etc.). Again, such valida-tion checks may either be stated within the service’s reg-ulatory framework or exist as tacit knowledge possessedby domain experts.

3. Explanations, examples and instructions: regulatoryframeworks often contain detailed explanations andexamples regarding the service content, especially forcomplicated items and notions (e.g. which expenses areconsidered deductible, how is the interest for overduepayments computed). Often, clarification documentsare issued by administrations in order to give instruc-tions, explanations or examples both to service end-users and to public authority employees, in regard tohow certain aspects of the service should be handled.All these informational items can actually constituteparts of an electronic service, playing the role of help

items or detailed help items that are available to usersupon request. A help item may be associated with a sin-gle field (e.g. if a field accepts a VAT registration num-ber, it may be associated with a help item exemplifyingthe required format of the VAT registration number),a group of fields (e.g. describing how an address fieldshould be filled in) or even a validation check (forinstance, exemplifying how values should be entered soas not to clash with the validation check).

Since the regulatory framework of electronic services isbest known to the delivering organisation’s domainexperts, they are considered as the most suitable stakehold-

C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124 117

ers to provide the information regarding the service contentto the development process. Note again that all these con-cepts are expressed in a high level of abstraction, thusdomain experts can directly enter the relevant informationto the development platform, without any interventionfrom IT staff.

We point out that the high level of abstraction is coupledwith strict rules for concept expression: e.g. the fact thatsome data item is mandatory is designated through anappropriate check box, not by some verbal expression; sim-ilarly, appropriate user interfaces have been defined forentering validation checks [37], which are then translatedinto XML specifications [38,39]. For instance, in order toexpress that the value of field A should be greater thatthe value of field B, the stakeholder first selects that ‘‘a fieldcomparison validation check’’ is required, and subse-quently selects ‘‘Field A’’ from a list presenting all availablefields; afterwards the comparison operator ‘‘greater than’’is selected, and the definition is finalized by selecting ‘‘FieldB’’ from a list of fields. These rules for concept expressionguarantee that the service specification will be free ofvagueness or ambiguity, and can thus be mechanicallyprocessed to automatically generate code, as discussed inSection 4.

3.3. Modelling service business logic

Once the service purpose and the service content havebeen defined, the service’s business logic can be comple-mented by defining the processing that the submitted datawill undergo. This task is normally undertaken by staff withIT expertise within the organisation, or outsourced to ITspecialists. Specification of the processing may be per-formed using one of the following two methods:

1. Direct provision of the code that will process the data:under this scheme, the IT staff supplies code that willbe invoked whenever a new submission is made throughthe electronic service. Upon invocation, the code is pro-vided with an XML document containing all the datasubmitted by the user plus meta-information regardingthe submission, including the credentials used by theuser to validate him/herself to the submission platform,the time that the submission was initiated and the timethe submission was concluded, a pointer to the XMLschema that the document adheres to and so forth.The code should extract the data from the XML docu-ment, process it accordingly (possibly including interac-tion with organisational repositories, execution ofexternal programs or other pertinent actions) and returna specifically formatted XML document, containing anindication whether processing was successful or not,and a reply to the user, in HTML format. This optioncorresponds to synchronous request processing.

2. Incorporation of the submission into the organisational

workflow: in many cases submissions cannot be directlyprocessed for a number of reasons (physical inspections

may be required, production of physical objects – suchas passports – may be necessary, formulation of thereply may be computationally expensive, etc.). In thesecases, the submitted data may be incorporated into theorganisational workflow, from where it will be extractedand processed – similarly to requests arriving from ‘‘tra-ditional’’ channels, such as the counter. Incorporationof the request into the organisational workflow is typi-cally performed by inserting the relevant data into arepository (database) or by executing an external pro-gram (part of the workflow management system) whichshould be provided with a suitably formatted file con-taining the task information. In these cases, the IT staffshould provide the code that will populate the repositoryor place the submission data into a file and invoke theappropriate program. Again, this code is invoked uponeach submission to the service and is provided with anXML document containing submission data and meta-information, as in the previous case.

For more information on the data processing specifica-tion scheme, the interested reader is referred to [40]. Dueto its code-oriented nature, this part of the service model-ling and development process has no visual interface andthus has no corresponding module within the platform pre-sented in the following section.

3.4. Modelling user access and visual layouts

The next step for completing the modelling of a servicethat will be delivered to multiple platforms is thespecification of the service delivery environment (e.g.Web, WAP, etc.) and the provision of the service visual lay-out for each of the platforms. It is possible to define multi-

ple visual layouts for a single service delivery channel, inorder to cater for client access devices with radically differ-ent capabilities (e.g. screen resolutions, input methods andso forth).

Effectively, a visual layout is a set of forms in a represen-tation appropriate for the channel to which the form setpertains (for instance HTML/XHTML for the web,WML for WAP, cHTML for i-mode and so forth). Thevisual layouts are linked to elements of the service content(fields and help items) by injecting proper mark-up tags

within the form representation.The procedure of mark-up injection can be either per-

formed manually, or by means of suitably extended visualediting tools, e.g. Macromedia DreamWeavere. Figs. 2and 3 illustrate how such links may be established in theenvironment of Macromedia DreamWeaver MXe. InFig. 2, the user selects the visual layout to be linked, whilein Fig. 3 the user employs the tag chooser tool of Dream-Weaver to select the corresponding element of the servicecontent. The list of service content elements presentedwithin the tag chooser tool is automatically created by atool that retrieves the descriptions of service content ele-ments and formats them suitably for DreamWeaver MXe.

Fig. 2. Selecting the visual layout component to be linked.

118 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

Note that only field-type and instruction/example-typeelements may be linked through this procedure: validationchecks are automatically associated with the form on whichthe pertinent fields appear and are conducted when the formis submitted (if the client environment permits, some checkscan be also conducted upon entering the field value, forexample by using JavaScript in a browser). If the pertinentfields appear on different forms, then the validation check isautomatically associated with the service as a whole, andthey are conducted upon the final submission, when all fieldvalues are available. The code generation module uses thesemark-ups to insert appropriate widgets and/or links for theservice content elements, taking to account the require-ments of the service dissemination channel and the formspecification language that is used. The algorithm used forgenerating executable versions of the service based on theservice description is presented in Section 4.

3.5. Modelling of the service evaluation criteria andprocedures

Each service is also evaluated using specific criteria,which can be quantified via statistical measures. For exam-

Fig. 3. Selecting the service content item to b

ple, the impact of the service can be quantified via the dailynumber of service users; service response time can be mea-sured in absolute terms by computing the time between theservice invocation and the delivery of the result to the ser-vice user, while the perceived service response time can bederived from the service users’ replies to a specific question-naire item ‘‘Please rate the service responsiveness (1 = low,9 = high)’’. These criteria and statistical measures will beused by managers to assess various aspects of the service.Note that the abstraction level of these information itemsis adequately high to enable managers and domain expertsto directly specify them to a modelling environment with-out any intermediation of systems analysts or IT personnel.

4. The knowledge-based multi-channel electronic services

modelling platform

The tools necessary for supporting the methodologicalsteps described in the previous section have been imple-mented in the context of the SmartGov project [41] as anintegrated platform for developing e-government services.The overall platform architecture is illustrated in Fig. 4.Electronic service development stakeholders use the six firstmodules (service purpose definition, field definition, valida-tion checks definition, instructions definition, visual ele-ment definition and evaluation metric definition) todescribe the relevant aspects of the service. The visual ele-ments definition module is employed to provide the appro-priate service visual layout per target delivery channel andclient device access capability set. Besides the ‘‘service pur-pose definition’’, which should commence first, nosequence requirements are imposed for the other modules,e.g. it is not required to complete the definition of all fields

e linked to the visual layout component.

TSE management

TSE group management

TS forms management

Linking/Browsing

TS management

Searching

Reusable

Instruction management

TSE management

Service purpose definition

Field definition

Validation check definition

Linking/Browsing

Instructions etc definition

Searching

Knowledgebase

(servicecomponentrepository)

Visual element definition

Code generator

Plugins I-Mode

WAP

Web

Evaluation metric definition

Fig. 4. Overall platform architecture.

C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124 119

before moving on to defining validation checks or instruc-tions. Any validation check can be defined as soon as thefields involved in it have been defined, whereas instructionsand help texts can be created even before the items theypertain to have been defined, and may be linked to themafterwards.

The service development procedure starts off by employ-ing the ‘‘service purpose definition’’ module, illustrated inFig. 5. Besides the purpose of the service a number of otherparameters may be entered here, including the deadline forsubmitting documents through the service (if applicable),whether service users are allowed to delete or edit alreadysubmitted documents, authentication requirements, etc.

Once the service purpose is defined, service content def-inition may commence, employing the field definition, val-idation check definition and instructions and help textsdefinition modules.

The field definition module (Fig. 6) allows the domainexperts to define the data that need to be collected by theservice, entering all pertinent parameters, including multi-lingual labels, basic properties of the user input (e.g.whether texts, numeric inputs, dates, etc. are expected,whether input is mandatory or not, if the values are for dis-play only or the user may modify them and so forth).

Fig. 5. Service purpose

User input is further verified using validation checks,which are defined through the validation check module(Fig. 7). In this screenshot we may see that for a validationcheck the user should provide a description, the messagethat should appear if the condition is violated and the con-dition itself. A number of standard condition types areavailable modelling the most common checks, while formore complex ones the ability to use a specifically designedmacro language or even native code (Java and JavaScript)is provided. If a validation check references a specific field,then it automatically appears under the ‘‘Validation rules’’section in the field definition module (Fig. 6) when the spe-cific field is edited, allowing domain experts to easily viewwhich validation rules are applied to each piece of data.

The third task within the content definition phase is thespecification of instruction and documentation for the elec-tronic service. This task is facilitated by the instructionsmodule (Fig. 8), which permits domain experts to enterany information necessary for (a) helping the end-usersto efficiently use the service and (b) internally documentthe project. To this end, when a domain expert enters somepiece of instructions through the instructions module, he/she specifies the user groups to which it is addressed (man-agers, domain experts, IT staff and end-users). Only

definition module.

Fig. 6. Field definition module.

Fig. 7. Validation check definition module.

120 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

instructions listed as addressed to end-users may beincluded in the running version of the service; service devel-opment stakeholders may view a piece of instructions if it isaddressed to the specific stakeholder group. Typical items

that are entered as project documentation but are not madeavailable to service users include the legislation on whichthe service or portions of it are based, internal evaluationsor quality check procedures, instructions for other service

Fig. 8. Instructions definition module.

C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124 121

stakeholders that will re-use a specific component inanother project and so on.

Each piece of instructions may be associated with one ormore elements (fields, validation checks, visual layouts,etc.) – for instance, a piece of instructions describing howaddresses should be entered will be linked to all formsand/or fields related to addresses, which may belong to dif-ferent electronic services.

The content specified using the previous three modulesmust then be associated with visual layouts, one for eachintended dissemination channel and/or client device capa-bility set. This can be accomplished through the visual ele-ment definition module (Fig. 9), where the targetdissemination platforms are defined and for each one, aset of forms (prepared as described in Section 3.4) isdefined. In the example presented in Fig. 9, two target dis-semination channels are defined, namely the web channeland i-mode. The web channel employs only two forms(header and detail), whereas the i-mode channel needsthree (the second one has been split into two parts) sincethe client devices used for accessing it typically have smallerscreens. Moreover, the first form for the i-mode channel is‘‘compacted’’, i.e. only the absolutely necessary informa-tion is included to save bandwidth. This provision doesnot only apply to screen dimensions, but may include con-tent types, quality or any other aspect that may be differen-tiated across platforms. For instance, help videos may be

Fig. 9. Visual element

provided for interactive TV and broadband Internet con-nections, but not be available through WAP; audibleinstructions may be given for phone centres and interactiveTV, whereas equivalent textual representations may beused for WAP and web; The forms used for the web chan-nel may include artwork for aesthetic purposes, which maybe missing from other channels so as to improve accesstime and so forth. In this respect, the modelling schemeallows to tailor the interface for each specific disseminationchannel to use the features and content considered as‘‘most appropriate’’.

The final element that should be defined for services isthe evaluation metrics and statistics. These are specifiedusing the corresponding module. The platform offers anumber of pre-defined metrics which can be enabled or dis-abled (Fig. 10), while a sub-module enabling definition anddeployment of questionnaires is also available. Some tech-nical statistics are also available, such as execution time forvalidation rules, memory consumption, etc., enabling ITstaff to profile and optimise the service.

All the elements defined by the transaction service devel-opment stakeholders are stored into the knowledge base,which is effectively a service component repository comple-mented with a network of semantic links interconnectingthe different elements. Element linkage may be performedautomatically (as is the case of validation checks beinglinked to the fields they are associated with), semi-automat-

definition module.

Fig. 11. Using taxonomies for organising and locating components.

Fig. 10. Evaluation metric definition module.

122 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

ically (the system may propose instructions and documen-tation to be linked to fields, based on textual similarity ofdescriptions and content) or manually (e.g. fields are linkedmanually to the visual layouts, as explained in Section 3.4).The link network can be exploited in a number of ways.First, it allows transaction service stakeholders to navigatebetween interrelated components during the developmentprocess and thus easily locate elements of interest. Second,it promotes consistency by allowing the system to performa number of checks; if, for instance, a field is deleted, thenthe system may raise an alert notifying the stakeholder thatthe validation check has a dangling field reference. Anotherimportant use of the link network is to help identify ele-ments that need to undergo maintenance activities due tolegislation changes: if a piece of legislation has been modi-fied, then the respective documentation item is located andthe links from it are exploited to locate components thatare based on it. These fields can then be modified in accor-dance to the updated legislation.

The platform offers two more means to transaction ser-vice stakeholders for locating components, namely taxono-mies and searching. Taxonomies are used to classifyelements according to pre-determined systems, and stake-holders subsequently traverse these classifications to locateelements pertinent to a specific branch of the classification.The platform presented in this paper allows for multipletaxonomies to be used (e.g. in Fig. 11 two taxonomiesare defined, one for taxation and one for customs), andany element may be linked to any number of taxonomiesand/or in multiple branches of the same taxonomy. Thisis useful for elements used in multiple contexts, e.g. the‘‘Tax payer’s personal details’’ element is used in all ser-vices related to taxation and all services related to customs.

The search mechanisms incorporated into the platformaccept search patterns that include free text search, specifi-cation of whether the match is required to be within a spe-cific attribute of the element (label, description,documentation, validation rules, etc.) or in any of themand the element type of the result (field, purpose, visual lay-out, etc.). Another option of the search mechanism is toextend the search to directly linked components, to addressthe issue of information being scattered between variouselements. For instance, if the user enters as a search crite-rion the string surname address phone, there may not be asingle element containing these words, but a personal detailform contains direct links to fields whose texts collectively

satisfy the search criterion. The ability to locate existingcomponents has proven to be valuable for promoting re-usage of already developed components in new services [42].

Once all aspects of a service have been defined, the code

generator module is executed to automatically produce theexecutable service images for the various platforms. Thecode generator module extracts the pertinent definitionsfrom the repository, and then employs appropriate plug-

ins to produce platform-specific code for each element. Aseparate plug-in is required for each target disseminationchannel, e.g. a web code generator plug-in is needed to pro-duce executable service images for the web disseminationchannel, a WAP code generation plug-in will create execut-able service images for the WAP channel and so forth. Eachplug-in encompasses the knowledge on how the high-levelconstructs of the service repository components will betranslated into corresponding low-level elements, asrequired by the platform. For example, in the web environ-ment, each user interaction form will constitute a differentpage, and the user will move between the pages using Æinput

type = ‘‘submit’’æ form elements; in the WAP environment,forms will be modelled as separate cards within a deck,and the navigational controls between the pages will beimplemented using a Ædo type = ‘‘accept’’ label = ‘‘Next

form’’æ tag, with an appropriate Æ goæ tag content. Similarly,modelling active behaviour within the client access device(this includes validation checks and confirmation dialogswith the user) will be coded in JavaScript for the web envi-ronment and in WMLScript [43] for the WAP channel.

In brief, the executable service image generation algo-rithm proceeds as follows:

1. For each visual description of the service, the appropriatetarget channel is selected (as indicated by the stake-holder that provided the visual description) and the rel-evant code generator plug-in is loaded.

C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124 123

2. For each form within the visual description, the appro-priate element is created (e.g. HTML page, WML card)and elements that are linked to the form (through thetag injection procedure) are fetched from the repository.Input elements are translated to controls suitable for theplatform and navigation controls enabling the serviceuser to move between the forms are inserted. The ele-ment is finalised by inserting active behaviour modellingthe validation checks that involve only input elementsbelonging to the form being processed. Validationchecks involving elements on different forms are handledseparately (explained below).

In addition to the code described above which is sent tothe client access devices, the code generator additionallyemits code that runs on the server side while the service isbeing accessed. This code encompasses the followingfunctionality:

1. Intercepts the form submissions made by the user andperforms the validation checks on the provided data.Re-checking the values at the server is considered com-pulsory, since clients are presupposed to be untrustwor-thy (e.g. a web browser may have the JavaScript enginedisabled or a malicious client may deliberately submiterroneous values).

2. Arranges so that the correct client code stub is sent tothe client access device when navigation activities takeplace.

3. Runs validation checks for fields that appear on differ-ent forms. This action is associated with the event ofthe ‘‘final submission’’ (triggered by selecting an appro-priate button on the last form), since all input values areavailable at this stage. If any of these validation checksfail, the final submission is not accepted and the user isprompted to correct the given values.

4. Provides hooks for the IT staff to integrate custom codethat will run upon invocation of the service by a user,and code that will run after the final submission (pro-vided that all validation checks have been successful).Typically, startup code will validate user credentials(such as user names and passwords) and will fetch fromorganisational repositories data that need to appear aspre-filled in (e.g. once an user has been authenticatedvia the user name and the password, the user’s personaldetails [name, surname, address, etc.] can be retrievedfrom such a repository); code that runs after the finalsubmission usually arranges for storing the submittedvalues to organisational repositories, so as to be pro-cessed by the appropriate organisational workflowchain.

The server-side code emitted by the code generation isbundled in appropriate JSP files, which are assembledalong with client-side files (generated files plus imagesand stylesheets, if applicable) and runtime libraries into aWAR package, suitable for deployment to a JSP container,

such as Tomcat [44] and BEA Weblogic [45]. The WAR fileshould then be deployed to a JSP container that is con-nected to the pertinent dissemination channel. Note thatin the current version of the platform, the case that multi-ple versions of the same service have been produced for thesame channel (e.g. two versions for the web channel, onetargeted to PC-based environments with high screen reso-lutions and one targeted to PDAs with small screen resolu-tions), these versions will be deployed as separate services,without any linkage between them or directions to theusers. Site administrators are expected to create a (trivial)initial page for the service that will present the existingalternatives so that the users may choose. More sophisti-cated versions of such pages may auto-detect the capabili-ties of the client access device and select transparently theservice version that best matches the profile of the clientaccess device.

5. Conclusions

In this paper we have presented a knowledge-basedapproach for developing e-government services, whichcan be delivered through multiple dissemination channels.This approach separates the service’s business logic fromthe presentation issues, avoiding thus duplication of workthat will be incurred if each delivery channel is addressedin isolation. Using high levels of abstraction, the approachfacilitates the direct modelling of services by managers anddomain experts, minimising thus the involvement of ITstaff, which is usually a scarce resource in organisations.The modelling approach is complemented with a develop-ment environment in which electronic services can be mod-elled and a code generator, which reads the service modelsand automatically produces executable server images forthe pertinent platforms. Future work will focus on the inte-gration of multiple services into life events, adopting thus acitizen-centric model for the platform. Reverse engineeringof existing electronic services into the knowledge-basedplatform in order to minimise both the service maintenancecosts and enable the multi-channel delivery of existing ser-vices with the minimal possible cost will be also investi-gated. Finally, the automatic production of initial pages

that will guide users to the correct version of the electronicservice and the provision of facilities to use multiple chan-nels within the same service session (e.g. completing someforms using an i-mode browser and then switching to aPC-based environment to complete the work) will beaddressed.

References

[1] European Commission, Public Sector Information: A Key Resourcefor Europe, Green Paper on Public Sector Information in theInformation Society, 1999. Available from: <http://europa.eu.int/ISPO/docs/policy/docs/COM(98)585/>.

[2] Gil-Garcia Ramon, Electronic Government in ISWorld Encyclope-dia, 2004. Accessible at http://ispedia.terry.uga.edu/?title=Elec-tronic_Government (Accessed February 2005).

124 C. Vassilakis et al. / Electronic Commerce Research and Applications 6 (2007) 113–124

[3] e-Europe, Common List of Basic Public Services, 2000. Accessibleat http://europa.eu.int/information_society/eeurope/2002/news_li-brary/documents/basicpublicservices.doc [Accessed February,2005].

[4] Cap Gemini Ernst & Young, Online Availability of Public Services:How is Europe Progressing? 2003.

[5] Cap Gemini Ernst & Young, Online Availability of Public Services:How is Europe Progressing? 2004. Available from: <http://euro-pa.eu.int/information_society/eeurope/2005/doc/highlights/whats_-new/capgemini4.pdf> (Accessed February, 2005).

[6] United Nations, World Public Sector Report 2003: e-Government atthe Crossroads, 2003. Available from: <http://unpan1.un.org/intra-doc/groups/public/documents/un/unpan012733.pdf> (Accessed Feb-ruary, 2005).

[7] Internet World Stats, World Internet Usage And Population Statis-tics, 2005. Available from: <http://www.internetworldstats.com/stats.htm> (Accessed February, 2005).

[8] A. Ya Ni, A. Ho Tat-Kei, Challenges in e-government development:lessons from two information kiosk projects, Gov. Inform. Quart. 22(2005) 58–74.

[9] F. Slack, J. Rowley, Kiosks 21: a new role for information kiosks?Int. J. Inform. Manage. 22 (2002) 67–83.

[10] J. Nurmela, R. Heinonen, P. Ollila, V. Virtanen, Mobile Phones andComputer as Parts of Everyday Life in Finland, 2000. Availablefrom: <http://www.stat.fi/tk/el/stty2r1e.html> (Accessed February,2005).

[11] E-Business Forum, Basic Indicators of ICT Usage in Greece, 2004.Available from: <http://www.ebusinessforum.gr/index.php?op=mod-load&modname=Sitemap&action=sitemapviewpage&pageid=149&language=en> (Accessed February, 2005).

[12] General Secretariat for Information Systems of the Greek Ministry ofFinance, TaxisPhone Usage Statistics, 2003. Available from: <http://194.219.152.68/statistika/phone/statist.htm> (in Greek, accessedFebruary 2005).

[13] General Secretariat for Information Systems of the Greek Ministry ofFinance, Tax Return Form Electronic Submission, 2004. Availablefrom: <http://www.e-oikonomia.gr/allframes.htm> (in Greek,accessed February 2005).

[14] Interchange of Data between Administrations, Multi-channel Deliv-ery of e-Government Services, 2004. Available from: <http://www.cisco.com/global/DE/pdfs/publicsector/ida_07_04.pdf> (AccessedJanuary, 2006).

[15] D. Maroulis, S. Aronis, V. Nassiopoulou, N. Grammenos, C.Vassilakis, A web browser for ISDN card phones, J. InternetTechnol. 5 (3) (2004).

[16] M. Silfverberg, Using mobile keypads with limited visual feedback:implications to handheld and wearabledevices, in: Proceedings ofMobile HCI 2003, 2003, pp. 76–90.

[17] Hiles Terry, The Multi-channel Service Revolution, 2004. Availablefrom <http://www.ebusinessforum.gr/index.php?op=modload&mod-name=Downloads&action=downloadsview&pageid=1113> (AccessedFebruary, 2005).

[18] F. Robben, (Re)-organising for Better Services, eGovernment Con-ference: From Policy to Practice, 29–30 November 2001, Charle-magne, Brussels, 2001. Available from: <http://europa.eu.int/information_society/eeurope/egovconf/documents/ppt/Annex_2_Benchmarking_Robben_presentation_30-11-2001.ppt>.

[19] M. Janssen, R. Wagenaar, J. Beerens, Towards a flexible ICT-architecture for multi-channel e-government service provisioning, in:Proceedings of the 36th Annual Hawaii International Conference onSystem Sciences (HICSS’03), 2003. Available from: <http://csdl2.com-puter.org/comp/proceedings/hicss/2003/1874/05/187450148.pdf>.

[20] M. Wimmer, J. Krenner, An integrated online one-stop governmentplatform: the eGOV project, in: 9th Interdisciplinary InformationManagement Talks, Proceedings, Schriftenreihe Informatik, Univer-sitatsverlag Trauner, Linz, 2001, pp. 329–337.

[21] E. Tambouris, An Integrated Platform for Realising Online One-StopGovernment: The eGOV Project. Proceedings of the DEXA Interna-

tional Workshop ‘‘On the Way to Electronic Government’’, IEEEComputer Society Press, Los Alamitos, CA, 2001.

[22] U.S. Office of Management and Budget, Federal Enterprise Archi-tecture, 2005. Available from: <http://www.whitehouse.gov/omb/egov/a-1-fea.html> (Accessed February, 2005).

[23] L. Avignon, T. Brethes, C. Devaux, P. Pezziardi, Le livre blanc del’EAI I’ntegration des Applications d’Entreprise, Livre blanc, OctoTechnology, 1999.

[24] Mediadev, Pourquoi et comment faire communiquer les applications.Livre blanc, Mediadev, 2002.

[25] S. Dawes, T. Pardo, A. Cresswell, Designing Government Informa-tion Access Programs: A Holistic Approach. Proceedings of the 36thHawaii International Conference on System Sciences (HICSS’03),IEEE Computer Society Press, 2002, http://csdl.computer.org/comp/proceedings/hicss/2003/1874/05/187450146a.pdf.

[26] eGain, Service Suite Product Presentation, 2004. Available from:<http://www.egain.com/products/multichannel_service.asp> (AccessedFebruary, 2005).

[27] Oracle Corporation, Oracle Multichannel Customer Service FAQ,2004. Available from: <http://www.oracle.com/applications/service/faq_mch_1201.pdf> (Accessed February, 2005).

[28] Oracle Corporation, Oracle9iAS Wireless Developer’s Guide Release2 (9.0.2), 2002.

[29] IBM Corporation. WebSphere� Transcoding Publisher productdescription. Available from: <http://www.ibm.com/software/perva-sive/transcoding_publisher/> (Accessed February, 2005).

[30] Sourceforge team, Dynamic HTML Conversion to WML, 2004.Available from: <http://html2wml.sourceforge.net/> (Accessed Feb-ruary, 2005).

[31] Akerman Software, Mobile Converter v. 1.0.3, 2004. Available from:<http://www.akermansoftware.com/> (Accessed February, 2005).

[32] S. Mangano, XSLT Cookbook. O’ Reilly, ISBN: 0596003722, 2002.[33] W3 Consortium, XForms – The Next Generation of Web Forms, 2003.

Available from: <http://www.w3.org/MarkUp/Forms> (AccessedFebruary 2005).

[34] T.V. Raman, XForms – XML Powered Web Forms, 2003. Availablefrom: <http://safariexamples.informit.com/0321154991/book.html>(Accessed February, 2005).

[35] FormFaces, FormFaces Product Description, 2004. Available from:<http://www.formfaces.com/> (Accessed February, 2005).

[36] M. Polanyi, The tacit dimension, in: L. Prusak (Ed.), Knowledge inOrganization, Butterworth-Heinemann, Boston, MA, 1998.

[37] SmartGov Consortium, SmartGov Project Deliverable DeliverableD82: User’s Guide, 2003. Available from: <http://www.smartgov-project.org> (Accessed February, 2005).

[38] SmartGov Consortium, SmartGov Project Deliverable D51-61: Low-level Specifications of SmartGov Services and Applications and theKnowledge-Based Core Platform, 2003. Available from: <http://www.smartgov-project.org> (Accessed February, 2005).

[39] SmartGov Consortium, 2003. SmartGov Project Deliverable D52:Deliverable D52: Implementation of SmartGov Knowledge-BasedCore Platform. Available from http://www.smartgov-project.org[Accessed February, 2005].

[40] C. Vassilakis, G. Lepouras, S. Rouvas, P. Georgiadis, Integrating e-Government Public Transactional Services in the Public AuthorityWorkflowElectronic Government J, 1, Inderscience Publications,2003, pp. 49–60.

[41] SmartGov Consortium, SmartGov Project Web Site, 2004. Availablefrom: <http://www.smartgov-project.org> (Accessed January, 2006).

[42] C. Vassilakis, G. Lepouras, Reusability in electronic services devel-opment, in: Proceedings of the CSITeA 04 Conference, Cairo, Egypt,2004.

[43] Frost Martin, Learning WML & WMLScript, first ed., O’Reilly,2000, ISBN 1565929470.

[44] J. Brittain, I.F. Darwin, Tomcat: The Definitive Guide, O’Reilly,2003, ISBN 0596003188.

[45] J. Zuffoletto, L. Miranda, BEA WebLogic Server Bible, second ed.,Wiley, 2003, ISBN 0764526022.