Source: Project Team of the CEN/ISSS eGovernment Focus Group

Title: Draft Final Report of the Project Team of the CEN/ISSS

Status: Draft Final Report for Presentation to the Open

Chairman: Peter Brown (Pensive)

Secretariat: Gertjan van den Akker (NEN)

Editors: Marc Wilhelm Küster (University of Applied Sciences Worms), Makx Dekkers (Independent), Graham Moore (Networked Planet)

pdf (definitive version): report.pdf

Contents

  1. Executive Summary and Recommendations
    1. Executive Summary
    2. Recommendations
      1. Resource Description and Sharing
      2. Organizational and policy recommendations
      3. Service Units, Multilinguality and Multiculturalism
      4. Interfaces to Services and Data
  2. Introduction
    1. eGovernment
    2. Organizational Background
      1. The role of CEN
      2. CEN's role in eServices
      3. The CEN/ISSS eGovernment Focus Group
    3. Scope of the Report
    4. Guiding Principles
  3. Key Definitions
  4. Ontology for Standards and Standardization Initiatives
    1. Resource Sharing in eGovernment
    2. Not another project
    3. Added Value through Visibility and Transparency
    4. Labelling Resources
    5. Creation of the Ontology
      1. Classification of Standards
        1. Semantic standards
        2. Technical standards
        3. Process standards
      2. Description of standards
      3. Description of Standards Initiatives
      4. Standards Ontology
        1. Standard
        2. Public Authority
        3. Standards Initiative
    6. Recommendations
  5. Harvesting of Standards and Standardization Bodies
    1. Methodology
    2. Technical Infrastructure for Harvesting
    3. Major Players in eGovernment Standardization
    4. Interpretation relating to Standards Initiatives
    5. Results of the harvesting on standards
      1. Policy differences between mandates
      2. Technical comparison of interoperability frameworks
      3. Conflicts between the Interoperability Frameworks
      4. Standard Classifications
      5. Web Service Standards
      6. Role of Registries
      7. Multimedia formats
      8. Document formats
    6. Services
    7. Multilinguality and Multiculturalism
    8. Summary of Key Conclusions
      1. The Role of formal Standards Organizations
      2. Web Service Standards
      3. Role of Registries
      4. Services
      5. Multilinguality and Multiculturalism
  6. Potential of Standards
    1. Criteria for the determination of the potential of the use of standards for the provision and management of services in eGovernment
      1. Objective
      2. Possible perspectives
      3. Services perspective
      4. Standards perspective
    2. Areas of Maximal Impact
  7. Challenges in Current eGovernment Standardization
    1. Gap Analysis
    2. Maintenance of Standards
      1. Role of Standards Organizations
      2. eGRN
    3. Policy Issues
  8. European eGovernment Resource Network (eGRN)
    1. The Role of Registries
    2. The Role of Topic Maps
    3. Data Capture and Data Presentation
    4. The Presentation Interface
    5. Data Capture
    6. Linking Registries
    7. Organizational Framework
  9. References and Bibliography
  10. Rendering of the Topic Map on Standards
  11. Terms of Reference
    1. Vision and mission
    2. Background
    3. Scope
    4. Objectives
    5. Membership
    6. Working methods
  12. Disposition of Comments

1. Executive Summary and Recommendations

1.1. Executive Summary

When people interact with government, they want to do so on their own terms. They want high quality services which are accessible, convenient and secure. They do not necessarily want to have to understand how government is organized, or to know which department or agency does what, or whether a function is exercised by central and local government.

There are therefore both real opportunities and important drivers for public administrations to use Information technologies in order to deliver their core mission: fundamental improvement in the efficiency, convenience and quality of services delivered and transformation in the ways that government organise mainstream delivery. These approaches require technical policies and specifications that encourage interoperability between agencies and heterogeneous information systems across the public sector.

The key to interoperability however lies not primarily in centralization and harmonisation around a single, common core of agreed standards. Our Focus Group’s mandate includes that we should "determine the role that standards should play in eGovernment and to "identify what measures are required to achieve this goal. Our strong conviction is that a clear distinction needs to be made between the facilitating role of standards and the ultimate goal of interoperability. In many areas of human activity, we are surrounded by multiple standards (think simply of the 110V electrical standard in the US compared with the 230V European equivalent). Standards are, of themselves, important because they lay a foundation for predictable behaviour and enable interoperability because of that predictability. When there are different standards for the same problem (like converting 110V to 230V), interoperability is concerned with finding a suitable interface between them (the adapter/transformer). In many cases, standards have grown up alongside each other, managed by and under the governance of different authorities. These authorities may have different motives to establish their own standards: infrastructure constraints, public policy, differing assessments of what issues are relevant, market pressures and – occasionally – a deliberate policy to isolate oneself (as happened in 1850’s Spain, where a different railway gauge was chosen deliberately to prevent foreign invasion by rail with severe economic consequences in the post-Franco era).

It is not realistic for us as a Focus group to recommend that the European Commission and EU member States harmonize around a common set of standards for eGovernment: for better or worse, every actor has been and will continue to be in many initiatives that are advancing specific standards to address particular problems, notwithstanding that there are many areas of gratuitous incompatibilities that can and should be overcome. Far better, we feel, to provide practical support to help agencies further interoperability through the use of (sometime different standards). To this end, our recommendations focus on gaining support and buy-in for three related themes:

We are therefore interested not only in the interoperability of standards, but in agreeing standards of interoperability.

1.2. Recommendations

1.2.1. Resource Description and Sharing

In recognition of public administrations' desire to maintain autonomy and decentralization in the management of eGovernment resources we recommend a distributed approach based on common protocols for such decentralized information exchange. In particular we recommend:

  1. to revisit the standards ontology in a more formal consensus process, specifically in the context of UnivAc workshop and in cooperation with other parties such as the European Commission, OASIS and W3C

Note: The Workshop on the sharing of eGovernment resources is scheduled to start on February 20th, 2008.

  1. to elaborate and stabilize the current, ATOM-based exchange format for a eGRN in a future CWA in the UnivAc context

  2. to develop a suitable and sustainable model for an organizational framework in which the eGRN can operate including process rules for the mechanisms of entering and updating data
  3. to elucidate the concept of service units as a means to describe and classify services

1.2.2. Organizational and policy recommendations

  1. Develop registries in response to the needs of individual business cases, but build them out of existing, standardized technologies
  2. Involve both European and national standardization activities more stringently in the development and maintenance of eGovernment standards

Work at the European level can be beneficial to harmonize approaches across borders

  1. Look specifically into gaps in the area of semantic and process standards. Especially, process standards seem to have been largely out of focus in the eGovernment domain so far

1.2.3. Service Units, Multilinguality and Multiculturalism

  1. Elaborate the concept of service units in more detail and to continue the work of linking services to the standards which they leverage. More input from national administrations is, however, needed to successfully conclude this task.
  2. Support the progress of the SEMIC project and to liaise closely with standardization activities and the eGovernment Resource Network
  3. Collaborate closely with the CDFG with regards to cultural diversity issues.

1.2.4. Interfaces to Services and Data

  1. Offer multiple ways of accessing data and services wherever feasible, e.g. through offering documents and other information resources in a variety of dataformats or through providing both SOAP and RESTful service interfaces
  2. Develop best practices on Web Service interoperability for pan-European eGovernment services, building on work by the WS-I and in close collaboration with international fora
  3. Develop best practices for the interoperability of RESTful web services for eGovernment applications
  4. Formulate best practices on workflow standards in cross-organizational eGovernment applications
  5. Support test-beds for interoperability testing of eGovernment applications, both between eGovernment applications and between eGovernment and external (e.g. eBusiness) applications

2. Introduction

2.1. eGovernment

Electronic Government or eGovernment deals with "the use of information and communication technology [ICT] to support and improve public policies and government operations, engage citizens, and provide comprehensive and timely government services, to use the widely accepted definition in the mission statement of the European eGovernment Society [eGovSoc], or "the use of ICT in public administrations combined with organizational change and new skills<<Footnote(The term "new skills" should be seen in the context of the European Commission's [on eSkills for the 21st Century]. )>>, in order to improve public services and democratic processes, and strengthen support to public policies, to quote the European Commission.

The term eGovernment itself is of comparatively recent origin and even the oldest dedicated eGovernment policies and events only date from the late 1990s and early 2000s. However, the practice behind it is much older and goes back to the first, mainframe-centred wave of data processing in the public sector in the 1960s and 1970s that frequently continues to shape existing IT infrastructures.

eGovernment is widely considered to comprise a variety of specializations. Their exact natures, however, are less definitive and include, depending on the viewpoint, areas such as access to public sector information, administrative computer science, eDemocracy, eParticipation and eJustice. The concrete specificities of these areas and indeed their delineations differ widely from country to country and often even from region to region, reflecting their respective legal, administrative and cultural traditions and choices.

2.2. Organizational Background

2.2.1. The role of CEN

CEN is one of the three official European Standardization Bodies (with ETSI for telecommunications and CENELEC for electrical engineering) chartered by the [European directive 98/34] to produce official European standards. Within CEN its “Information Society Standardization System” (ISSS) provides market players with a comprehensive and integrated range of standardization services and products, in order to contribute to the success of the Information Society in Europe. CEN/ISSS was created in mid-1997 by as the focus for CEN's ICT (Information and Communications Technologies) activities.

At the request of numerous public authorities and other entities, CEN/ISSS has created a Focus Group to map the various activities in the field of eGovernment standardization and to discuss a roadmap for the future, especially regarding barriers to cooperation in building cross-border solutions in the eGovernment domain. A focus group in CEN is an open forum for open discussion and consensus building that reports to CEN's ICT coordination body, the CEN/ISSS Forum. Formal standardization is out of scope for the group, but its work can lead on to more formal standardization activities.

2.2.2. CEN's role in eServices

Amongst many other activities, CEN/ISSS is a well-established forum for various aspects of eBusiness standardization. Its eCommerce Workshop (1998-2003) was a pioneering activity that led the way for many, especially also in the field of Web Services. Likewise, the workshop on a European Network for Administrative Nomenclature (ADNOM, 2005-2006) popularized aspects of the concepts of linked registries that are also at the heart of this report's recommendations.

Current eBusiness-related activities in CEN include:

In this, CEN/ISSS is formally the European Entry Point to the United Nations eBusiness standardization activities, and is a user signatory to the ISO/IEC/ITU/UN-ECE Memorandum of Understanding on eBusiness standardization. The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and OASIS coordinate many of these activities on the international level.

The Core Component Technical Specification is a cornerstone of the UN/CEFACT standardization eBusiness activities envisioning simple, transparent and effective processes for global commerce. Its focus is on the machine-to-machine exchange of business documents, e. g. relating to orders, invoicing, taxation etc. The ultimate goal is to develop a shared set of semantic building blocks for general types of business data (cf. also [SIMReport]).

Core Components can and should play an important role in the design also of eGovernment-related business documents to maximize interoperability between government and business applications.

2.2.3. The CEN/ISSS eGovernment Focus Group

In a first project phase, funded by Sun Microsystems, pursued a project idea linked to the Focus Group work. During this phase the project team developped an Initial ontology for describing government services and the use of relevant standards was developed and expressed as a topic map (cf. below, p. [[Ontology]]). The integration of the ontology into a Topic Map system was then demonstrated to the focus group in a plenary meeting on April 26th, 2006.

In the second phase, the Focus Group has obtained partial funding support from the European Commission and EFTA. In addition to this eGovernment standards report the project team has produced a small prototypical network of eGovernment Resource nodes (cf. below). The draft report was presented to the group in its plenary meeting on December 11th, 2007 in Brussels and then publicly circulated for comments. The full disposition of comments is available in annex C. With the presentation of this report to the Open Meeting on February 19th, 2008 in Brussels the group successfully completes its work programme.

The group's terms of reference are reproduced in full starting on page [[TermsOfReference]].

2.3. Scope of the Report

By the project team's terms of reference, the report of the eGovernment Focus Group should aim to address the role of standards both in:

2.4. Guiding Principles

While the concept of eGovernment is wider and can, as we have seen, encompass both front and backoffice activities, many of the current eGovernment projects and discussions centre on operations that transcend organizational boundaries, either by reaching out to citizens, by connecting with businesses or by interacting with other government bodies. These operations usually build on internet and specifically web standards and use the normal Internet. However, application specific value added networks (VANs) continue to be used in many scenarios, especially when security and privacy are of prime concern.

This report focusses on services provided by governments through standard internet technology. Specific topics such as eProcurement where the government acts primarily as the recipient of services are not covered, especially since the standardization perspective of many of these topics have already been studied in depth in other fora. The report thus concentrates on interfaces between public bodies and other entities, be those other entities citizens (Government to Citizen, G2C), companies (Government to Business, G2B) or other public bodies (Government to Government / G2G) or, indeed, other stakeholders (departments, individuals etc.) within the very same public body. Information on the inner workings of governmental ICT systems is only rarely required (or even available) for this.

The focus on interfaces between stakeholders that together strive to achieve certain goals is one of the key characteristics of Service Oriented Architectures (SOAs) as defined in the SOA Reference Model [SOAReferenceModel] to which the report refers in the remainder of this section. It revolves around the concept of a service as a "mechanism by which needs [of a potential service consumer] and capabilities [of a service provider] are brought together. Note that neither a service consumer --- "[a]n entity which seeks to satisfy a particular need through the use capabilities offered by means of a service (p. 29) --- and a service provider --- "[a]n entity (person or organization) that offers the use of capabilities by means of a service (p. 29) --- are necessarily machines nor that the data returned by a service must always be machine processable, even though for Service Oriented Architectures (SOA) in a narrower sense that may often be the more interesting case.

Service providers and service consumers are linked through visibility which helps to join the service's capabilities and the consumer's particular needs in order to interact for a desired real world effect. Visibility of resources can be achieved through various means including special purpose resource registries, the approach proposed in this report.

Key tenets of Service Oriented Architectures are guiding principles for this report. This is not to be understood in the sense of promoting SOAs over alternative approaches or of assuming that existing architectures in the public sector necessarily conform to SOA principles, but that SOA concepts offer valuable and widely shared definitions for the description of existing eGovernment resources and their potential interplay across service boundaries.

3. Key Definitions

The report inherits a few key definitions from [SOAReferenceModel]. For the convenience of the reader, they are here reproduced and marked accordingly.

Note: This concept of service differs substantially from that used in the context of the General Agreement on Trade in Services (GATS) . Services in this report are electronic constructs that by themselves or in combination with other such services can (but not necessarily have to) be the basis of electronically supplied services in the GATS sense.

Note: In the context of this report, a service provider is always either a public authority or an entity of whatever juridic form acting on behalf of a public authority. However, a service so provided might in turn use or be composed of commercial service offerings, e.g. in mashups.

4. Ontology for Standards and Standardization Initiatives

In the process of collecting data on standards, standardization initiatives for further analysis we have opted to capture the data according to an ontology that is further expounded in this section. In this way we have also added resources that will continue to be available for further reuse in view of better resource sharing amongst eGovernment stakeholders. In this, the project helps to lay foundations for the nascent eGovernment Resource Network.

Several organisations, public and private sector, have indicated that they will continue to work with the output from the Focus Group, in particular the work that delivered the draft Ontology of eGovernment services and using that ontology in pilot implementations and demonstrators. Some of them will provide feedback from their experiences as input to the new CEN/ISSS Workshop UnivAc.

4.1. Resource Sharing in eGovernment

During the course of the decades of ICT use in public authorities a large number of eGovernment services came into being on the European, national, regional and local levels. Those services may directly address citizens (e. g. registration of a car, filing of a tax declaration) or companies (e. g. VAT declarations, social security information) and other types of organizations. In the most frequent case, however, they are directed at government bodies, be it as an internal service within an agency, be it cross-agency or, indeed, cross-administration. A large number of other types of eGovernment resources, ranging from specifications over mandates to organizational information, complement them.

Almost all of these services came into being as a direct or indirect response to legal requirements, the latter here understood in a loose sense to encompass many types of normative documents. The number of services operated by European public authorities is not even approximately known; its number is certainly far in five, probably far in the six digits. Very often, there are a large number of different implementations for functionally similar or, indeed, identical services, the number of which is likely to be much smaller. Clarity over their origin promises both very significant savings and quality improvements through re-use and continuous improvement of existing solutions where feasible and in line with government policies rather than futile duplications. Only a uniform description of services and other eGovernment resources across Europe will permit to make eGovernment retrievable across Europe and will, hence, play an important part in realizing an ecosystem of national and pan-European government services.

Resource sharing hence aims towards a reuse of existing resources or collaborative work towards creating new ones. A key prerequisite for resource sharing is of an organizational and cultural nature, namely to foster a general “reflex for collaboration”, an understanding that resource sharing is of mutual benefit.

Resource sharing, we maintain,

Resource sharing in turn needs

However, even given a general reflex for collaboration the ability to share resources directly depends on their respective visibilities, very much in the sense of [SOAReferenceModel]. Hence, the main objective for the eGovernment Resource Network (eGRN) is to enable better visibility for and better use of existing eGovernment resources and solutions.

4.2. Not another project

The traditional way towards visibility would be a centralized repository which hosts the services or at least their proxies. In this, it will stand alongside many other existing and valuable resources. There are already plenty of resources out there that are difficult enough to find even today. Such an idea to centralize information would lead to yet another project and is likely to bring more disadvantages than benefit, adding to the already high dispersion and complexity in the field.

Indeed, also in other domains there is rarely a single central registry for any given area of interest. To use a metaphor for the library world: each individual library normally maintains its own catalogue for the publications it owns. This is sensible also beyond historic contingencies: it is the individual library that knows best about is specific needs, can best manage its new acquisitions and changes. Restated on a more abstract level, the best knowledge about individual resources usually resides with the maintainers of those very resources themselves. It is something inherently decentral.

That said, there is also dire need for centrality, or, more exactly, central interfaces. To keep with the library example, from a users’ point of view it is often relevant to know about the existence of a book beyond an individual library’s stock – federated or aggregated library catalogues are of help.

4.3. Added Value through Visibility and Transparency

The same considerations also apply to eGovernment resources. A much better solution than a central repository, yet with the benefits of a central interface hence is to link up existing resources by labeling and identifying them. This requires again not a drastically new technical solution, but primarily the reflex for cooperation that drives the eGRN.

Figure 1: The eGRN is a virtual network (Source: [by Peter Brown, Pensive], with kind permission)

Of course, no possible design of the eGRN can solve all the problems by itself. However, it does make them:

and it provides high-level oversight over the current situation.

Maybe most importantly, since it is not in opposition with existing projects, but rather joining them up it can build on the results from existing (national or sub-national) eGovernment projects as well as those of EU funded undertakings, as long as it provides a common model for the description of resources and a common collaboration methodology.

4.4. Labelling Resources

Figure 2: Labelling resources (Source: [by Peter Brown, Pensive], with kind permission)

In the eGRN the prototypical ontology (cf. below) is primarily a means to label resources so that they become visible in a virtual resource network. Instead of being centrally held, they are “just” visible through a federated registry using standard Internet technologies that points to the actual resources that continue to be held decentrally.

In this network labeled resources are bound together by a common eGovernment information model and a common eGovernment collaboration model. The information model formalizes the description of those eGovernment resources, whereas the collaboration model defines rules for the creation, maintenance and exchange of the information.

4.5. Creation of the Ontology

The ontology for standards and standardization initiatives together with the service ontology developed in the first, Sun Microsystems sponsored phase of the project team's work structures the internal and external representations of our results.<<Footnote(The version presented here is the result of several updates in the second project phase. )>>

For the purpose of this report the two key entities of the ontology are service and standard. They are shown here with their most important relations to other entities of the ontology. Those entities as well as additional data relating to them is captured during the harvesting period.

With the approval of the Focus Group in its plenary meeting of April 27th, 2007 the project team decided at the beginning of the project to use Topic Maps [ISO13250] and in particular its XML-based XTM exchange format to express the results. Topic Maps are particularly suitable to formalize the eGovernment information model in a standardized manner and to exchange corresponding information (cf. section 8).

All harvested standards and services are in the process assigned unique Published Subject Indicators (PSIs) in the format , e. g. .

Figure 3: Entity service with its key relationships to other entities

Figure 4: Entity standard with its key relationships to other entities

This chapter of the report zooms in on the entity "Standard" in the eGovernment service ontology. It first proposes a classification of the types of standards that are relevant for eGovernment services and then considers all entities in the eGovernment service ontology to see what types of standards may have relevance for each of the entities. After that analysis we define a first classification of Standards Initiatives.

The standards ontology refers to the result of an earlier CEN project that defined a draft ontology of entities related to eGovernment services. Please note that the examples against the entities in this chapter are purely illustrative – the full set of examples is reproduced separately (cf. page [[XTM]]).

This chapter reflects the conclusions of PT meeting on 2007-06-28

4.5.1. Classification of Standards

We classify standards and standards initiatives in three categories that are further described in this subsection:

  1. Semantic standards

  2. Technical standards

  3. Process standards

All three categories are subclasses of the class "standard" within the standards ontology. Thus they share the same attributes and associations.

4.5.1.1. Semantic standards

This type of standards and initiatives are concerned with the meaning of entities, for example enabling statements that a document is in PDF format and that the language it is written in is English.

Three sub-types of standards in this category can be identified:

  1. Description framework standards that define methodologies to describe entities, such as [Resource Description Framework], [Topic Maps], [11179 Metadata registries], general or specific metadata standards such as [Core], http://www.editeur.org/ONIX%20International%20FAQ.htmlONIX, or [Learning Object Metadata]

  2. Classification scheme standards that provide pre-defined sets of values in the form of controlled vocabularies, theseauri, ontologies or code lists such as the Eurovoc or NACE terminologies and ISO code lists for the names of courties and languages

  3. Identifier scheme standards that provide mechanisms to identify people, organizations, documents and other types of objects, e.g. URI, ISBN, DOI identifier schemes

4.5.1.2. Technical standards

These standards are concerned with the more technical issues, such as data formats, protocols and system configurations, including

  1. Data encoding standards, such as http://www.w3.org/XML/XML, http://www.w3.org/MarkUp/HTML, http://www.adobe.com/devnet/pdf/pdf_reference.htmlPDF, http://www.itu.int/rec/T-REC-X.509-200508-IX.509

  2. Data exchange standards, including protocols such as http://www.w3.org/Protocols/HTTP, http://www.w3.org/TR/soap/SOAP

  3. System standards, such as operating system (Unix, Windows) and database standards (SQL)

4.5.1.3. Process standards

These are the standards that govern the way process and policies are implemented. These standards cover a wide range of issues, e.g.:

Process standards may in turn rely on semantic and technical standards for their implementation.

4.5.2. Description of standards

Standards are described using, amongst others, descriptive data elements from [WD 24706 (Information technology-Metadata for technical standards and specifications documents)].

Descriptive elements to be used:

Relations with other entities in the ontology are listed below.

4.5.3. Description of Standards Initiatives

Descriptive elements to be used

Standards Initiatives include a range of organizations that are involved in setting or developing standards, and include formal standardisation bodies such as the International Organization for Standardization (ISO), industry consortia such as OASIS, co-operations between companies, government agencies and informal associations of individuals. The “openness” of the processes that govern the development and maintenance of standards varies between Standards Initiatives, and can be gathered from the descriptions of the standards concerned. This report aims to describe the standards without value judgements, as it is the intention that the readers of this report can make their own judgements on the basis of the information provided. Relations with other entities in the ontology are listed below.

4.5.4. Standards Ontology

4.5.4.1. Standard

4.5.4.2. Public Authority

4.5.4.3. Standards Initiative

4.6. Recommendations

The preliminary ontology used in this projects has proved to be suited for the description of standards, standards initiatives and services. However, it still lacks wider validation with stakeholders and more thorough analysis.

The report therefore recommends to revisit the ontology in a more formal consensus process, specifically in the context of UnivAc workshop and in cooperation with other parties such as the European Commission, OASIS and W3C.

5. Harvesting of Standards and Standardization Bodies

The harvesting continues to progress along the lines specified below ("Methodology"). The project aims to find and classify ca. 200 standards and 100 services during the course of its existence. The current data is available in XTM Topic map format via http://psi.egovpt.org/xtm and continues to be enhanced.

Note: While the harvesting is continuing, we currently have reached well over 160 standards linked to selected interoperability frameworks and mandates. The number continues to grow.

5.1. Methodology

The harvesting starts out from existing lists of standards as the basis for further research. In particular, it utilizes national and European interoperability frameworks, procurement mandates and existing taxonomies and lists of standards such as EPSINet's standard map, the remainders of the DIFFUSE project and an overview over common and less common Web Services specifications http://www.ws-universe.com/.

Special priority is given to standards which are nationally mandated and / or prescribed in interoperability frameworks. It describes the standards against the ontology including their relevant associations with other classes such as service, standards initiative or mandate.

Given that with the allocated resources it is impossible to comprehensively or even partially cover the national frameworks of all 27 EU member states, let alone the very large number of regionally or even locally mandated ones, the project team in cooperation with the Focus Group agreed upon the following national list of frameworks to start out with:

Note: While SAGA 4 is under preparation, it is not yet finalized.

At the present selected frameworks such as SAGA, eGIF, OIO, and the Cadre Commun d’Interopérabilité are widely covered<<Footnote(Not completely, though – the OIO alone references more than 600 standards and specifications. )>>, the others only partially. The reason for this is purely pragmatic. The dynamic nature of data capture means that coverage is being enhanced over the remainder of the project duration and beyond. However, these findings are not captured in this report.

Many national frameworks have recommendations with varying degrees of compulsion (or, indeed, repulsion). The Danish OIO catalogue , for example, uses the following six categories:

Quite similar categories exist in all reviewed frameworks.

The ontology currently captures these different degrees of compulsion in four categories. Standards that are clearly true recommendations – Approved and Recommended in this case – are marked as being "approved, recommended or mandated". Standards that are marked as being of potential interest for future use and that are hence subject to further research ("emerging" in OIO terminology) are classified as being "under observation". Standards that are marked as being acceptable, but clearly not favoured ("de facto" and "sustained" in OIO terminology) are subsumed under "permitted by". Standards that are explicitly gray- or blacklisted – "migrate from" in OIO terminology – are marked as being "discouraged" by a given framework. Standards that are not being mentioned in a given framework could (in many cases correctly) be seen as being implicitly discouraged. This, however, is not explicitly marked and left to the interpretation of the reader.

Where necessary, the harvesting continues from these standards to cover other standards they in turn refer or that otherwise seem relevant.

5.2. Technical Infrastructure for Harvesting

A major challenge within the project was the initial lack of a technical infrastructure for actually carry out the harvesting. Such an infrastructure for data entry was established under http://psi.egovpt.org building on the newly developed Py4TM software by the University of Applied Sciences Worms. It was then configured to reflect the preliminary standards ontology (cf. above). Suitable data entry forms were written.

The harvested data is publicly available in an established, XML-based exchange format (the Topic Map XTM format).

The technical infrastructure is described in more detail on page [[DataCapture]].

5.3. Major Players in eGovernment Standardization

When looking at major players in eGovernment standardization, we have looked at all standards organization that create specifications in the field, especially, but not exclusively, when these specifications are referred to in interoperability frameworks. Priority is thus given to producers of specifications that have a demonstrable impact on the European eGovernment landscape.

The current results from the harvesting have identified standards and other types of specifications from the following 33 formal and informal standardization activities:

Note: This table will be updated for the final version with the then current results of the harvesting.

3GPP project

0

0

1

ATSC

0

0

1

CEN

0

2

0

CNIPA

0

2

0

DCMI

0

1

0

DIN

0

1

0

DS: Dansk Standard

1

0

0

Danish Government

0

0

3

Ecma international

0

0

4

IEC

0

0

1

IEEE

0

1

0

IETF

0

0

18

ISO

3

5

23

ITU-T

0

0

2

Individual Company

0

0

22

Java Community Process

0

0

11

Joint Photographic Expert Group

0

0

2

Moving Picture Experts Group

0

0

1

NIST

0

0

1

OASIS

1

1

10

OGC

0

0

4

OMG

1

0

1

OSCI Leitstelle

1

4

1

Office for Official Publications of the European Communities

0

1

0

Other / Informal

0

0

2

RSA Labs

0

0

1

The Open Group

0

0

1

Unknown

1

2

4

Unnamed Industry Consortium

0

0

2

W3C

1

1

22

WS-I

0

0

3

Xiph.Org Foundation

0

0

3

Figure 5: Visualization of the frequency of specifications developed by standards organization

sdos.pdf

Some specifications are developed by two or more organizations, either (in rather rare cases) by directly collaborating on cross-organizational documents or (by far more frequently) by a document from one organization being post-processed in other fora. A typical scenario would be for a consortium-developed specification to be fast-tracked through a formal standards organizations such as ISO. This is the reason that the sum of standards in this table is higher than the total number standards covered.

The list is not complete, nor is it restricted be standards referred to in eGovernment-related mandates. The list of standards organizations explicitly endorsed or reviewed in those mandates would be somewhat, but not fundamentally, different.

5.4. Interpretation relating to Standards Initiatives

Even a cursory look at the results of eGovernment specifications by standards initiative reveals a few clear, but somewhat astonishing trends:

This is all the more interesting as national and European standard bodies with their expertise in formal consensus processes, their wide coverage of interested parties also beyond administrations and their ability to coordinate with other national, European and international activities would look like the perfect fit for developing national and pan-European eGovernment standards.

This picture would be more pronounced still if the national semantic interchange standards e.g. in the legal domain were still fully covered in the harvesting. They, however, are often not explicitly covered in the national interoperability framework.

5.5. Results of the harvesting on standards

5.5.1. Policy differences between mandates

The choice of prescribed and / or prohibited standards in national interoperability frameworks follows policies that differ substantially across member states. Some interoperability frameworks such as Belgif explicitly discourage standards "not recognised by a standard organisation<<Footnote(Cf. http://www.belgif.be/index.php/File_type_and_document_formats, consulted on 2007-12-01. Interestingly, this also extends to the extremely popular pdf (as opposed to pdf/A) format that is discouraged in Belgif – in most other frameworks pdf is either mandatory, recommended or, at the very least, permitted. )>> Others such as Denmark's OIO and Germany's SAGA clearly favour standards by well-respected standards organizations, yet also include approve other specifications if no obvious choice blessed by a standards organization is visible. A third group, notably the British eGIF, seems hardly influenced at all by the provenance of a given specification.

These differences are mirrored in the different understandings of the nature of standards – and in particular so-called "open standards" – in different member countries.<<Footnote(http://en.wikipedia.org/wiki/Open_standard, consulted on 2007-12-01, gives a good overview of the open standard definitions in place in many European legislations. )>> While the definition of the European Interoperability Framework in its version 1 includes open consensus processes as one of the key defining criteria of an open standard, many countries rather follow the somewhat laxer French understanding that does not take the provenance of specifications into account and only concentrates on the right to freely to access, use and implement them (an approach that is itself disputed):

On entend par standard ouvert tout protocole de communication, d'interconnexion ou d'échange et tout format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en oeuvre.<<Footnote([n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique], §4. Translation: "One understands by open standard all protocols of communication, interconnection or exchange and all interoperable software formats of which the technical specifications are public and which can be accessed or implemented without restriction" (my translation). )>>

In this sense, the term “open standard” may be confusing because it is used to mean different things. As the term is widely used in eGovernment context including pertinent laws, it is difficult to avoid the term altogether. However, this report takes neither a stance on the issue as to what constitutes an open standard nor does it weigh open standards against other types of specifications.

Rather than trying to measure the “openness” of a standard, this report looks at three criteria related to the standards: (a) the width of adoption; (b) whether there is a stable maintenance process and (c) how open participation in the development and maintenance of the standard is. This again does not intend to be a value judgement of the standard but instead give the users of the results of this work sufficient information to enable them to make their own judgement.

5.5.2. Technical comparison of interoperability frameworks

The level of detail and sophistication of the national interoperability frameworks differs substantially. This is not correlated to country's size - a country Denmark has one of the most elaborate frameworks if measured by the number of treated standards and specifications (609), France a much more condensed one (about a quarter in size). These differences may or may not be reflections of policy decisions.

Most frameworks concentrate on technical standards, in particular on interface standards, protocols and data format. The standards span a wide area ranging from Web Service standards over security to web design to document formats to multimedia formats. Web service standards and document formats are discussed in more detail below.

As an aside, often (but by no means always) interoperability frameworks do not identify the version of a given standard that is to be used. Unless the lack of version number is to be interpreted consistently as meaning either the newest version or the current version at the moment of the standard's introduction to the framework this can be the source of serious interoperability problems.

Only a few frameworks – notably Germany's SAGA – actually discuss and prescribe specific programming frameworks and programming language. SAGA actually mandates the use of the Java 2 Enterprise Edition (J2EE) 1.4 and / or the Java 2 Standard Edition (J2SE) 1.5 with the corresponding Java Web Start mechanism for large projects<<Footnote(Two more frameworks, J2EE 1.5 and .NET 2.0 are under observation. )>> and PHP 5 for smaller ones, while explicitly discouraging other programming languages and frameworks such as Python and Perl (and implicitly all other ones other than Java and PHP).

5.5.3. Conflicts between the Interoperability Frameworks

Interestingly, nine standards are mandated or approved in one member state while being explicitly discouraged in others. Examples include document formats such as the MS Word .doc format that are discussed in more detail below, pdf (in contrast to pdf/A), and multimedia formats such as Quicktime, MPEG Audio or WAV. They also include fundamental web service standards.

Direct conflicts between interoperability frameworks are particularly irksome to implementers and potentially also to users. The eGRN even in this very preliminary state allows to spot incompatibilities and thus forms the basis for to resolve them – ideally, before they hit implementers in the field.

5.5.4. Standard Classifications

When looking at the distribution of weights between the different types of standards that we have covered during the harvesting, it strikes that the great majority (133 or more than 80%) of them are technical standards.<<Footnote(The percentages here given are deliberately very rough – any coverage in more detail would suggest a level of precision that the current harvesting process itself does not permit. In fact, if the interoperability frameworks were fully covered, the percentage would likely be more dominant still, since semantic and process standards were selected with priority during the data entry. )>>

Only a bit more than 5% of the standards are process standards, the majority of them in turn standards relating to pure either notations of processes such as the Business Process Execution Language (BPEL) or the Business Process Modelling Notation (BPMN) or to (soft- and hardware) accessibility guidelines such as the WAI guidelines or ISO 9241-400:2007 on the Principles and requirements for physical input devices, hence to very important, but rather technical aspects of processes.

The remainder – the 20 semantic standards – are on the one hand international base standards for semantic descriptions such as the Topic Map standard and RDF, typically originating from ISO or W3C. On the other hand stand, they are a selection of concrete XML schemata for various administrative, legal and geographic documents, e.g. for the identification and encoding of laws and for documents relating to specific administrative processes. Examples for such processes would be the handling of requests for building permits or of regulatory reporting.

Most of the latter stem, as has been mentioned above, from government agencies or government-sponsored projects and are specified without any formal and open consensus process outside the administrations themselves. Most of them are closed groups in the sense that no outside stakeholder can participate in the consensus finding. Interestingly, thus, most of the semantic eGovernment specifications do not, themselves, follow the definition of open standards included in the European Interoperability Framework 1.0.

5.5.5. Web Service Standards

Web Service standards play an particularly important part in interoperability frameworks, especially in view of future pan-European eGovernment services. Web services – here as in the 2003 eBusiness report and recommendations understood as XML over the wire and hence emphatically not constrained to SOAP-based Web services – are the means by which both services and data can be accessed across organizational boundaries. Hence they are key enablers both for service oriented architectures (SOAs)<<Footnote(As OASIS' SOA reference model rightly treats SOA concepts as technology neutral. They can be (and, in fact, have been) implemented with the help of a considerable number of underlying technologies including binary protocols like CORBA, remote procedure calls or other formats such as JSON. On a national, let alone pan-European level web services will be the only viable option. )>> and resource-oriented architectures (ROAs). As [Gartner07] rightly recommends:

To enable cross-border public services, national governments should make their basic public services available as web-services, hence taking all the legal, organizational, process, semantic and technical measures necessary to do so ([Gartner07], p. 5)

As stated, making public services available as Web services encompasses much more than the technical web service stack. However, it crucially depends on interoperability on that level – and especially SOAP-based web service interoperability across software framework is notoriously shaky, in particular when non-trivial data structures are involved. These problems on the transport layer can become even bigger if different SOAP and WSDL versions are involved. They can become unsurmountable if the prescribed choice of the plethora of accompanying standards of the Web service stack (frequently called WS-*) is incompatible. This is often the case even for different profiles of the same standard, WS-Security being a good case in point.

The importance of Web services is to different degrees reflected in the interoperability frameworks. All frameworks prescribe the use of WSDL and SOAP, but even at this basic level there is disagreement. eGIF already recommends SOAP 1.2, whereas the other frameworks still opt for SOAP 1.1. While this may sound like a technical detail, it is in itself already likely to be the cause of massive and essentially futile interoperability problems for cross-border services involving both SOAP 1.1 and SOAP 1.2.

There is even less agreement on the WS-* standards. Most of them are classified as being "under observation" in most of the frameworks, though the details of choice and coverage differ drastically. The exception is WS-Security which is mandated by most frameworks, but with different (or undefined) profiles.

The Web Service Interoperability (WS-I) consortium has been created to overcome these issues by defining common profiles at least for SOAP and WS-Security. The WS-I Basic Profile for fundamental SOAP interoperability is, indeed, mandated in two of the frameworks (eGIF and OIO), but in two different versions (1.0 and 1.1 respectively). The WS-I Basic Security Profile is only approved in eGIF and under observation in OIO. Under these auspices interoperability difficulties are guaranteed.

Some of the problems are inherent in the development process of the WS-* standards themselves which are handled by a host of different groups, ranging from ad-hoc consortia of major US companies for specifications such as WS-Transaction to consortia such as OASIS and W3C. Coordination between those groups is attempted, amongst others, in the Management Group of the Memorandum of Understanding (MoU/MG) between different standards organizations. However, is difficult to achieve at best and the situation is in constant flux with new specifications appearing and others being obsoleted in rather short timeframes.<<Footnote(An example for this is WS-Routing that had been recommended in eGIF, but is now discouraged in favour of WS-Addressing. )>> It is unlikely, though, that this situation will improve in the near future.

At present, the frameworks do not mention RESTful architectures at all. However, [Gartner07] rightly identifies the need for dual SOAP- and RESTful web service interfaces for eGovernment services as a future requirement for cross-border and, indeed, cross-organizational services. Little guidance exists on the design of transformers / adaptors for the provision of such multiple interfaces.

No clear testing strategies are at present visible for cross-organizational services for either SOAP-based or RESTful web services.

5.5.6. Role of Registries

Looking beyond specific web service standards, the aforementioned OASIS Reference Model for Service Oriented Architectures looks at the idea of a service as a “the mechanism by which needs and capabilities are brought together”. Concepts such as interaction of services, their service descriptions and their visibility and reachability, all grounded in the willingness to collaborate with the goal of achieving a real-world effect, are needed to make the service idea work.

Rightly, service descriptions are seen as one of the defining characteristics of SOAs. Such descriptions transcend syntactical interface descriptions and include both information about the organizational prerequisites – the foundations for what the European Interoperability Framework terms organizational interoperability – and a depiction of the service’s semantics, required for semantic interoperability. Registries are key to achieving this type of visibility.

Given the importance of registries for the SOA vision, it is striking that only eGIF actually recommends the use of specific registry standards (UDDI in that case). All other interoperability fora only observe relevant standards without committing to any specific course of action.

Much of this caution certainly is grounded in the inherent weaknesses of UDDI. This topic is discussed in more detail in section 8.

5.5.7. Multimedia formats

The interoperability frameworks reference a considerable number of specifications relating to multimedia, especially images, sound and movie formats. Concretely, 8 of the specifications deal with images, 11 with sound formats, and 13 with movies.

The impact of multimedia formats for cross-border interoperability seems at present limited.

5.5.8. Document formats

A particularly sensitive issue – and one of directly conflicting conclusions between national interoperability frameworks – are document formats. This topic has resulted in rather extensive discussions in national and European administrations, in the public and, last but not least, in the standardization domain itself.

At present, contenders for common document formats are sometimes seen to be ISO/IEC 26300, the OASIS Open Document Format for Office Applications as well as ECMA standard 376 Office Open XML . The former has been endorsed in Belgif and is under observation in SAGA, OIO and the Cadre Commun d'Interoperabilité, the latter is similarly being observed in several frameworks. However, neither figures in eGIF amongst the permitted document formats. In contrast, the binary MS Word .doc format is permitted by eGIF, while being explicitly discouraged in the frameworks of Belgium and Denmark. The situation is quite similar for spreadsheet and presentation formats.

The pan-European eGovernment eGovernment Services Committee (PEGSO) has formulated on December 6th, 2006 a number of [and recommendations on Open Document Formats]. It states directly that "document formats continue to be high on the policy agenda of the public sector (4.1). This document looks at the current situation and comes to a number of recommendations that merit to be quoted verbatim:

* 6.1 To make maximal use of internationally standardized open document exchange and storage formats for internal and external communication; * 6.2. To use only formats that can be handled by a variety of products, avoiding in this way to force the use of specific products on their correspondents. When the usage of proprietary formats is unavoidable, alternative, internationally standardized open formats shall be provided in addition to proprietary formats; * 6.3. To adapt, where appropriate, national guidelines and regulations, taking into account the arrival of international standards in this area; * 6.4. To consider the definition of minimum requirements in regard to the functionalities of open document exchange formats in view of pursuing the compatibility of applications; * 6.5. To create guidelines for the use of revisable and non-revisable document exchange and storage formats for different purposes. Industry, industry consortia and international standardisation bodies are invited: * 6.6. To work together towards one international open document standard, acceptable to all, for revisable and non-revisable documents respectively; * 6.7. To develop, applications that can handle all relevant international standards, leaving the choice to their customers as to what format will be used "by default"; * 6.8. To avoid invalidating the purpose of open document exchange and storage formats by offering extensions to the relevant international standards as default formats. [...] * 6.10. To continue to improve the existing standards, also taking into account additional needs such as electronically signed documents.

5.6. Services

For services the work starts out with a preliminary list of services that is available through national eGovernment portals:

The project concentrates again on a selection of services from the same seven countries that are used for the harvesting of standards. It may cover services from other countries if the time permits.

For the internal classification of services, the reports builds on existing lists of so-called service units, in particular:

These formalized process classification are all mono-hierarchical, which is certainly at least in part due to technical restrictions. They also differ in depth: two level in the Swiss, three levels in Austria and Germany.

Based on these classifications the DIN project on Standards for integrated eGovernment networks , funded by the German ministry of economy, has proposed the following classification for service units that we intend to reuse in our context:

Figure 6: Consolidated Taxonomy of eGovernment processes and service types ("service units"). Source: DIN project on Standards for integrated eGovernment networks

5.7. Multilinguality and Multiculturalism

The impact of Europe's multiculturalism on eGovernment standardization is manifold, even pervasive and begins at the policy level. Many of the policy differences explicated above (p. [[PolicyDifferences]]) also reflect (at least to a degree) different cultural traditions between member states. This is not only inevitable, but positive as it encourages a fruitful coexistence and cross fertilization between approaches.

That said, many of the preferences for different technical infrastructure standards e.g. for Web services are gratuitous and can severely impact pan-European interoperability without any corresponding benefits. In these areas identified above, common approaches are needed.

Semantic standards differ significantly across countries. Many of the XML schemata for specific administrative acts reflect national or regional legal, cultural, or linguistic traditions – in fact, many of the schemata are in the respective national language(s). Even within member states, semantic standards can often be profiled to meet specific regional requirements, XBau, the German standard for the application for building permits, being a case in point. And, again, this plurality is not only inevitable, but desirable as different national and regional administrative traditions can bring with them a healthy diversity of ideas and methodologies.

IDABC has already embraced this necessary multiplicity of approaches in their XML clearing house concept which ideally complements with the eGRN concept and is in the spirit of subsidiarity. XML-based semantic standards are collected and mapping rules between corresponding entities defined to allow, e.g., for interoperability across different XML schemata for (partially or wholly) corresponding administrative documents. The XML clearing house idea has further developped into the http://www.semic.euSEMIC project that "is a EU-Project to support the data exchange for pan-European eGovernment services. It aims to create a repository for interoperability assets that can be used by eGovernment projects and their stakeholders. It goal is to further the reuse of syntactic (e.g. XML schemas) and semantic assets (e.g. ontologies) needed for semantic interoperability. As such it is highly desirable to collaborate closely between SEMIC and eGRN. We therefore recommend to continue to support the progress of this effort.

Within CEN/ISSS the Cultural Diversity Focus Group (CDFG) has been active for the last six years to emphasize the importance of multiculturalism and multilingualism across all stacks of eService applications. We recommend that new eGovernment standardization activities collaborate closely with the CDFG with regards to cultural diversity issues.

Related to many of the user-facing issues of multiculturalism and multilingualism is the eSkills complex of standards and recommendations. While covering eSkills is out of scope of this report, we recognize it as a very important horizontal strand that is crucial to the large-scale take up of particularly citizen-facing eGovernment services.

5.8. Summary of Key Conclusions

5.8.1. The Role of formal Standards Organizations

The tacit assumption behind the inner-administrative origin of many eGovernment semantic and process standards may be that governments are the only stakeholders in this field. This assumption, while Rawley explicated, is however hardly true, at least not in the general case.

Firstly government agencies are often providers of public sector information and as such are encouraged under the European Directive on Public Sector Information (PSI) to provide that information to third parties, e.g. from the private sector (not necessarily for free, though). Other stakeholders are manifold – users of geographic information systems, law publishers, etc. It is desirable to involve these stakeholders already in the definition phase especially for XML schemata relating to public sector information.

Secondly, governments frequently are not their own IT service providers. They procure systems and services from other providers, normally from the private sector. Again, it is desirable to involve the expertise of those providers early on in the definition process.

Thirdly, private partners are often involved in the administrative processes themselves, either as data providers (e.g. in the fields of taxation or social security) or in other places of the process chains themselves.

Fourthly, pan-European eGovernment services can often profit from clearly documented consensus finding processes that allow for input also from outside of the purely national perspective.

In conclusion, there is in many cases a dire need for more formal consensus processes leading to eGovernment standards – even if those standards are seemingly inter-administrative only. Formal national and European standards bodies are predestined to play an important role in this, provided they can meet stringent time-to-market requirements.

We therefore recommend to involve both European and national standardization activities more stringently in the development and maintenance of eGovernment standards.

5.8.2. Web Service Standards

For functioning pan-European eGovernment services, it is paramount that the member states define best practices and ideally also a consistent approach towards the interoperability of SOAP-based web services. This must be based on work by the WS-I, but profiled (and possibly extended to meet the specifically European eGovernment requirements. Industry involvement in this consensus process is essential. CEN is well positioned to provide the organizational background in the form of a CEN workshop. We recommend to develop such best practices in a CEN workshop in collaboration with pertinent international fora such as OASIS.

Similar issues exist for RESTful web services. [Gartner07] rightly recommends the dual use of both SOAP-based and RESTful web services for eGovernment services wherever possible, a position we support. However, no recommendations are presently out there that deal with the interoperability for RESTful web service including issues such as authentication. We recommend that clear steps be undertaken to define best-practices.

Standards such as the workflow execution language BPEL are equally important to the SOA vision beyond pure technical interoperability. However, at present workflow-related specifications only are under observation in the interoperability frameworks, if, indeed, they are mentioned at all. Given that cross-organizational business processes are key to pan-European services, we recommend that best practices be developed for the use of workflow standards.

In order to improve testing of cross-organizational eGovernment applications we recommend to support test-beds for interoperability testing of eGovernment applications, both between eGovernment applications and between eGovernment and external (e.g. eBusiness) applications.

5.8.3. Role of Registries

The role of registries and key conclusions from it are elucidated in more detail in section 8.

5.8.4. Services

The project team recommends to elaborate the concept of service units in more detail and to continue the work of linking services to the standards which they leverage. More input from national administrations is, however, needed to successfully conclude this task.

5.8.5. Multilinguality and Multiculturalism

The project team recommends to support the progress of the SEMIC project and to liaise closely with standardization activities and the eGovernment Resource Network.

It also recommends that new eGovernment standardization activities collaborate closely with the CDFG with regards to cultural diversity issues.

6. Potential of Standards

6.1. Criteria for the determination of the potential of the use of standards for the provision and management of services in eGovernment

6.1.1. Objective

The current section contains the approach towards measuring the usefulness of standards in order to be able to "determine the potential of the use of standards for (the provision and management of services in) eGovernment" as specified in the Technical Proposal that forms the basis of this work.

6.1.2. Possible perspectives

There are basically two ways that the sentence "determine the potential of the use of standards for (the provision and management of services in) eGovernment" can be read.

The project team has looked at both perspectives, though with a focus on the standards perspective.

6.1.3. Services perspective

Looking at the issue from the services perspective, we have drawn up a list of eGovernment services and related activities (e.g. the "government" of eGovernment) on a high level (cf. above, [[RoleOfServices]]).

It is possible to identify some areas on this level that could be helped by standards (in the area of process standards, for example quality and security). However, in the mid- to long-term it will be necessary to go to a deeper level and to identify "service units" where standards may be useful. Conceptually similar work has been undertaken by UN/CEFACT's Core Components work when identifying core blocks of information that is related to typical eBusiness processes.

While the concrete execution of this analysis is beyond the scope of this report, an example may illustrate the issue: one of the higher-level services can be "Issue driver's licence". At some point in the provision of this service, a "service unit" identify_Person would be invoked. This "service unit" would be helped if there were a standard for identity management and a standard schema for describing persons. Especially if the service involved the transfer of a foreign licence of an immigrant, it would be useful if there was a standard for this used across national borders.

Now in this perspective, criteria for the usefulness of standards can measure if the use of a standard would have a positive effect on three objectives that are mentioned in the Technical Proposal:

Secondary criteria that work best on the higher levels will look at whether standards contribute to increase in usability/accessibility, quality, performance or accountability, etc.

We recommend to perform this analysis systematically, starting out with a systematic description of usable service units.

6.1.4. Standards perspective

Looking at the standards perspective, there are a number of areas where criteria are defined that can be used to determine the usefulness of the standards themselves. These criteria look at the characteristics of the standards and standards processes, but do not intend to assign an absolute level of usefulness to a standard. Rather, they are criteria that can be considered more or less relevant in different contexts. It is up to the reader to decide which criteria are more important for a particular situation.

These criteria have been applied during the harvesting of data.

  1. Wide adoption, across domains (e.g. public and private usage) and across national borders: this would help both interoperability and economies of scale. This aspect will be measured with three criteria:
  2. the standard is mentioned on Wikipedia (yes/no)
  3. number of hits in Google on reverse lookup of the official or main specification of the standard (numerical scale)
  4. number of hits in citeseer as a measure for research touching on this standard (numerical scale)
  5. Expected stability and professional maintenance: this would manage the longer-term risk of having to change systems if standards change. This aspect will be measured with one criterion:
  6. there is a stable maintenance process for the standard (yes/no)
  7. Openness of process and possibility to influence development: this would enable influence of the eGovernment sector to get specific requirements included in the standards. This aspect is measured by three criteria:
  8. Participation is free for everybody who wants to be involved (yes/no)
  9. Participation is limited to geographically determined representation (yes/no)
  10. Participation is limited to a closed user group (yes/no)

Rather than using these criteria to rank standards that are found in the harvesting activity in this project as "good" or "bad", or even worse, have a global ranking list, these data is provided for guidance only. The focus group strongly underlines that it is up to the user to prioritize these criteria in front of their specific requirements matrix.

6.2. Areas of Maximal Impact

We identify three areas of maximal impact for formal eGovernment standards:

7. Challenges in Current eGovernment Standardization

7.1. Gap Analysis

Even the limited amount of data that we could capture in this project shows the wealth of standards referred to in national interoperability frameworks and mandates is quite overwhelming. This is particularly true for standards relating to technical interoperability – the choice of semantic and especially process standards is, as we have seen, far more restricted.

Given the wide variety of technical standards referred to in those frameworks, we recommend to offer multiple ways of accessing data and services wherever feasible, e.g. through offering documents or other information resources in a variety of dataformats or through providing both SOAP and RESTful interfaces to eGovernment services.

We also reiterate that we see significant gaps in the realization of basic web service interoperability and suitable best practices and recommend to develop them especially in view of pan-European eGovernment standards.

In addition, we also recommend to look specifically into gaps in the area of semantic and process standards. Especially, process standards seem to have been largely out of focus in the eGovernment domain so far.

7.2. Maintenance of Standards

7.2.1. Role of Standards Organizations

We have identified on p. [[RoleOfSDOs]] a number of conclusions and recommendations as to the development of semantic and process eGovernment standards in an open consensus process. Here we shall provide recommendations for processes to maintain and, where necessary, update those standards in rapid response to changing requirements.

We propose to establish a dedicated eGovernment CEN/ISSS workshop in close cooperation with and potentially identical to the workshop UnivAc that is already under preparation. This workshop will work in very close cooperation with existing fora such as the MetaLex Workshop, with IDABC and comprise members from regional, national and European administrations as well as stakeholders from industry and consumer representatives. On the international level it will closely collaborate with consortia active in the eGovernment domain. Notably, OASIS is a suitable partner.

Each group of specifications will be maintained by a working group within the workshop that is responsible for their timely update. Focus will be given to:

National standards bodies should be encouraged to establish corresponding fora especially for semantic and process standards in close cooperation with the respective authorities.

7.2.2. eGRN

The eGRN itself will play a crucial role in the maintenance of standards. It adds the visibility to spot areas of new collaboration and potential fields of conflict without adding new complexity and without by itself imposing any solutions.

7.3. Policy Issues

Regulations and directives of various characters can have direct impact on the options that are available for interoperability. They can obstruct and even thwart the implementation of automated processes even if doing so would be technically easy and all parties involved desire it.

Many regulations directly mandate the use of specific standards, thereby implicitly prohibiting all other, possibly more straightforward approaches. An example of many is the German federal ordinance on the matching of social benefit data, the Sozialhilfedatenabgleichsverordnung (SozhiDAV) , last changed in October 2006. This ordinance prescribes the use of specific types of magnetic tapes for the physical exchange of social benefit data. It does so by stipulating the use of dated versions of pertinent German national standards both for the permissible physical tape formats and for the arrangement of the data on the tape (today also electronic means of transport are permitted for this purpose).

More pernicious than this, however, are indirect impediments to interoperability. In many cases regulations continue to dictate the use of physical signatures or the use of paper forms even when technically equally safe electronic alternatives exist. Doing so can – and usually does – break fully automated exchanges. Media discontinuity can require the printout of electronic data, the physical transport of the paper between stakeholders and subsequently the retyping of that very same information. This leads not only to unnecessarily high costs, it also slows down exchanges and is regularly the source for spurious errors and data inconsistencies.

The analysis of European law from this perspective is well out of the scope of this report. We emphasize, however, the interoperability hazards implied by concrete, media specific requirements in regulations.

8. European eGovernment Resource Network (eGRN)

8.1. The Role of Registries

When online services became en vogue in late 1990s and early 2000s three key considerations were identified to be crucial for the success of the then new paradigm:

These requirements are closely related to those expounded by [SOAReferenceModel], cf. p. [[GuidingPrinciples]]

8.2. The Role of Topic Maps

Topic Maps are a tool to model our knowledge related to a concept or a thing – or, as ISO/IEC 13250:2002 expresses it in its scope statement: “Topic maps enable multiple, concurrent views of sets of information objects. The structural nature of these views is unconstrained [...]. Moreover, an unlimited number of topic maps may be overlaid on a given set of information resources” (p. 1).<<Footnote(This text is partially inspired by [Küster07]. )>>

Topic Maps work with four central constructs:

This can be explained easiest with a simple example. The Deutscher Bundesrat – the German federal upper house – is an organization which can be represented as a topic in a topic map. It may contain references to its occurrences in the real or virtual world (e. g. its URL or its postal address) and be an instance of more generic concepts such as upper house or regional representation. At the same time the topic is associated to other topics such as the regional governments, which under the German constitution delegate its members. It could just as well be associated to other topics yet, e.g. topics representing its sessions, its delegates etc.

Figure 7: Representation of the topic "Deutscher Bundesrat" in a Topic Map. Visualized using TMNav

A variety of standardized exchange formats, most popularly the XML-based XTM format, allow the exchange of topic maps between topic map engines and define the rules for their correct interpretation. The engines in turn permit to store and query topic maps and to integrate those semantic resources into larger systems. Their programmatic interfaces are not standardized.

Many of the findings of this report are internally captured as Topic Maps and stored in XTM format (cf. below).

8.3. Data Capture and Data Presentation

Data capture and data presentation are done in two separate, but linked topic map engines based on two different architectures and hosted in two distinct places:

Py4TM and its template mechanism has been originally created to facilitate the data capture in this project and to experiment with strategies to link topic map engines using standard content syndication.

8.4. The Presentation Interface

The current eGRN prototype enhances the findings of the first, Sun-sponsored project phase, leading them to new applications especially regarding eGovernment standards.

The topic map demonstrator (phase 2) presents the face of the eGRN to the end user:

Figure 8: Screen shot of the eGRN demonstrator under http://demo.egrn.euhttp://demo.egrn.eu

The original demonstrator has been designed with two clear use cases in mind:

Alongside it a knowledge service was written that integrated the search capabilities into a major word processing system. Based on the same data it gives a very different view and a different mode of interaction with the eGRN.

Figure 9: Accessing the eGRN demonstrator from within a major word processing system

While based on a limited number of days and not in itself the key deliverable of this project phase, the development shows that — given substantial further development and operational arrangements — the eGRN has the potential to be a useful tool to disclose and manage resources. In this project phase we shall enhance the demonstrator for the specific requirements of the two types of resources here, standards and services including their respective associations.

A finalization of the demonstrator, operational arrangements with well-defined processes of maintenance and responsibilities, and further refinement of the use cases are out of scope in this project phase.

8.5. Data Capture

For the puropose of data entry a set of data entry masks has been created and is available via http://psi.egovpt.org/. Entry masks exist for most of the key entities of the ontology.

The data that is thus generated can be exported in XTM-format.

Figure 10: Screenshot of the data entry mask for eGovernment standards

8.6. Linking Registries

The fact that the eGRN uses two registry nodes from the start brings with it the need to link them. The topic map standard has a mechanism for merging topics and associations relating to the same subject across two topic maps. However, it can and often needs to be complemented by additional merging mechanisms, a fact explicitly allowed in the standard. However, there is no predefined mechanism for propagating changes across topic map engines defined in ISO/IEC 13250.

Currently, the two registries are linked in an ad-hoc fashion by using an ATOM-based exchange format using the internet as a common service bus:

Figure 11: Interfacing eGovernment Resources. Source: Peter Brown, Pensive

In this model Py4TM and potentially other information providers act as a feed publisher(s) and TMCore as a feed subscriber. The feed contains Topic Map fragments.

Linking up registries is a key requirement for the success of the eGRN vision. We therefore recommend to elaborate and stabilize the current, ATOM-based exchange format in a future CWA in the UnivAc context.

8.7. Organizational Framework

For an operational eGRN more is needed than a functioning and interoperable technical infrastructure, essential though it is. The report recommends to develop a suitable and sustainable model for an organizational framework in which the eGRN can operate including process rules for the mechanisms of entering and updating data. Such rules can partially be molded on work done in the Workshop on Administrative Nomenclature as captured in CWA 15526:2006.

While registries in general serve the visibility of resources, they build on the often unspoken assumption that there is already a willingness to collaborate and share those resources in a given context. To leave this core assumption unspoken and unexplored is characteristic for much of the ongoing activities, notable exceptions being e. g. CWA 15526:2006.

There is neither a generic business case for registries nor does the one size fits all approach work. Each individual registry must justify its raison d’être and set its organizational goals and procedures. We therefore recommend to develop registries in response to the needs of individual business cases, but build them out of existing, standardized technologies

9. References and Bibliography

[eGovSoc] European eGovernment Society: 'Mission Statement of the European eGovernment Society'. consulted: 2007-07-30. Source: http://www.uni-koblenz.de/FB4/Contrib/EGOVS/Mission

[Gartner07] Gartner: 'Preparation for Update European Interoperability Framework 2.0 - FINAL REPORT'. 04-06 2007.

[ISO13250] ISO/IEC: 'ISO/IEC 13250:2002: Topic Maps'. 2002-05-19.

[Küster07] :

[SIMReport] NorStella: 'The SIM Report'. 2007-11-08.

[SOAReferenceModel] OASIS: 'Reference Model for Service Oriented Architecture 1.0'. 2006-08-02.

10. Rendering of the Topic Map on Standards

The full list of current standards is available online through the demonstrator and is rendered in the attached pdf.

11. Terms of Reference

11.1. Vision and mission

The Focus Group is to determine the role that standards should play in eGovernment, in particular as an important means of achieving interoperability at all levels of public administration throughout the European Union, including at national, regional and local levels. The Group will identify what measures are required to achieve this goal and contribute to the debate on how to ensure a permanent framework concerning standards in relation to eGovernment at a pan-European level, in a way that is as harmonised as possible with ICT standards of general application.

The Focus Group is established to prepare proposals and/or recommendations to CEN and other standardization bodies, the European Commission and its agencies, national administrations and industry and other market players concerning standardization issues in the field of eGovernment.

11.2. Background

'eGovernment' is defined by the European Commission as "the use of ICT in public administrations combined with organizational change and new skills, in order to improve public services and democratic processes, and strengthen support to public policies". eGovernment is an enabler to realise a better and more efficient administration. The use of standards has been recognised as an important pre-requisite of the success of eGovernment. The use of standards is particularly important in areas such as interoperability, one-stop government, joined-up government, accessibility/usability for and by citizens, etc. As a result, most national administrations in Europe now have some authority in place, seeking to establish, maintain and, sometimes, enforce the use of ICTs in eGovernment.

However, some initiatives are backed by a legal framework, this is relatively rare. Furthermore, authorities are noticeably absent at the trans-national and pan-European levels, with one or two exceptions such as the European Commission's IDABC programme, despite the growing demand for the supply of trans-national eServices. IDABC deliverables to date will provide a valuable input and starting point for the Group's work.

Not all the issues are purely standards-related of course, there are legal or administrative matters, for example. It is not the task of the Focus Group to seek to address these as such, although it should identify such issues where they constitute barriers to effective standards adoption.

At national and even regional or local levels, there is no shortage of eGovernment initiatives or projects that either aim at determining 'standards' or encourage their use. In addition, a wide range of specifications, recommendations and guidelines are proposed by interested parties through formal standards organizations (for example, UN/CEFACT) or consortia, (for example W3C and OASIS). It should be a general rule that, as far as possible, standards used in eGovernment be the same as those used in the private sector. This will minimise problems for those entities that have dealings with both, even if there will inevitably be additional eGovernment requirements.

However, the wide range of existing initiatives at national, regional or even local level may result in a lack of knowledge of other administrations' work., and lack of understanding and knowledge of the standards actually available or envisaged. This may lead to duplication of effort, and missed opportunities to improve economies of scale. As the use of standards is sometimes implicit, it is unclear what is available or used at present.

At the pan-European level, the main problem areas are:

The European Commission's former IDA (Interchange of Data between Administrations), now IDABC programme (Interoperable Delivery of pan-European E-Government Services to Public Administrations, Businesses and Citizens) has sought a more coherent approach, but does not embrace the full range of activities, since it concentrates on cross-border services. Numbers of public authorities at European and national levels have indicated that they require, and would indeed welcome, help in standardization efforts, some of which are fragmentary. Standardization in any case needs to help by providing coherent advice, and a platform for discussion of these issues and resolution of conflicting approaches.

CEN, standards consortia or other bodies, can build and maintain standards, specifications, rules and guidelines, according to well tried and tested internal processes, but they on the other hand do not have a general mandate to act without support from public authorities.

Furthermore, too little guidance exists at present for administrations to choose among the wide range of standards and specifications, or evaluate the relative authority, validity or sustainability of a particular choice, based on any hierarchy of norms. It should be noted that in the ICT domain, there are many proprietary standards, and often competing solutions, with resulting problems for inter-operability.

11.3. Scope

The first challenge of the Focus Group will be to consider the role of standards in:

Particular attention will be paid to the need to interface the standards issues with the policy requirements emerging from public administrations. The role of a group within the standards environment is to take these requirements and assess what the standards implications are. This role will be given added value particularly given the absence, at an EU level, of any overall authority corresponding to national administrations' CIO or eGovernment policy units.

The Focus Group will need to identify the extent of:

that currently exist, or that are desirable but absent, in the field of eGovernment in Europe.

11.4. Objectives

The objectives of the Focus Group will be to:

11.5. Membership

Membership of eGov shall be open to any interested party with the necessary interests and commitment.

Representatives of key stakeholders in eGovernment will be specifically invited to join. eGov should aim to be inclusive, representative and be able to attract a critical mass of eGovernment stakeholders in order to garner buy-in to its activities from a broad spectrum of interests. eGov will aim to create an impact by attracting the participation and commitment of important relevant actors.

Provided that the Grant request that has been submitted to DG ENTR (in the context of DG ENTR's support to standardization activities in support of eEurope) gets accepted, membership of the eGov Focus Group will be free of charge.

11.6. Working methods

The CEN/ISSS eGov Focus Group shall be formally responsible to the CEN/ISSS Forum, which shall endorse the Terms of Reference and any future amendments to them, and the final report.

The Chair will be nominated by the Group and endorsed by the Forum.

Until such time that it is clear that the Grant request will be accepted/will not be accepted, the Focus Group secretariat will be provided by a CEN/ISSS Staff member. The Secretariat will co-ordinate the administrative duties involved in the organization of the FG including:

The Secretariat shall maintain web pages with appropriate links, an e-mail exploder and an FTP site. Where possible, meeting participation by audio, or web conferences should be enabled.

The Focus Group will also nominate a representative to act as single point of contact to IDABC and its expert groups.

The eGov Focus Group may manage resources in the form of Project Teams, appointed under CEN rules to prepare and edit documents.

12. Disposition of Comments

The Disposition of Comments to the comments received during the commenting phase between December 12th, 2007 and January 12th, 2008 is rendered in the disposition of comments disposition_of_comments.pdf

egovpt_fg: Report (last edited 2008-02-08 07:39:20 by MarcKüster)