Global Implementation Plan

Project Issued Date/Version Document type EINRC - EIONET:- Extranet development/SPADE 25.5.2000/0.42 Draft Client Info Reference/ Page EC DG ENTR /B-6 Global Implementation Plan for EIONET 2000-2003 / 1 (37)

GLOBAL IMPLEMENTATION PLAN

e-EIONET

2000-2003 EIONET GIP 2(37)

VERSION HISTORY

Version Date Author Description 0.1 30.11.1999 Kekki First draft for IDA specified GIP 0.15-0.24 2.3. Saarenmaa Second draft for EEA and UG -5.4.2000 suggestions 0.30 19.4.2000 Saarenmaa Third draft with inclusion of comments from EEA and UG 0.40 26.4.2000 Saarenmaa Fourth draft for ETAC, with comments from EEA 0.42 25.5.2000 Saarenmaa Conclusion of ETAC, final version after inclusion of comments

Table of contents 1. INTRODUCTION...... 3 1.1 EIONET...... 3 1.2 Legal basis...... 4 1.3 Sectoral committee / group of experts...... 4 1.4 Responsible service and associated services...... 5 1.5 Participants...... 5 1.6 Context...... 5 1.7 Objectives...... 6 2. TECHNICAL DESCRIPTION OF THE PROJECT...... 7 2.1 Requirements...... 7 2.2 Technical approach...... 9 2.2.1 Network architecture...... 9 2.2.2 Architecture for group collaboration and portal integration...... 10 2.2.3 Architecture for data management and warehousing...... 14 2.3 Development projects...... 16 2.3.1 Telecommunication and EIONET infrastructure development...... 16 2.3.2 Group collaboration services development...... 17 2.3.3 Data management and data flows development...... 20 2.3.4 Data warehousing and related developments...... 22 2.3.5 Portal development...... 24 2.4 Use of IDA generic services...... 25 2.5 Use of standards...... 26 3. PROJECT ORGANISATION...... 26 3.1 Overview of actions...... 26 3.2 Timetable...... 27 3.3 Roles and tasks...... 29 3.3.1 Community’s tasks...... 29 3.3.2 Member Countries’ tasks...... 30 3.4 Expected Benefits...... 31 3.5 Resources and Cost sharing...... 32 4. ANNEXES...... 35 4.1 Definitions, acronyms, and abbreviations...... 35 4.2 Conclusions of the Sectoral Committee...... 37 4.3 References...... 37

______EIONET GIP 3(37)

1. INTRODUCTION

1.1 EIONET

The EIONET is an acronym for the European Environment Information and Observation NETwork. The telematic network of EIONET (e-EIONET) was built with the support of DGIII's IDA Programme, DGIA, and EEA's own budget during 1996-98. The network now consists of 33 installed nodes across at National Focal Points (NFP) of the European Union (and EEA) member countries, those of the Phare (Central and Eastern European) countries and at European Environmental Topic Centres (ETC).

Each e-EIONET node comprises a server that runs the CIRCA groupware on top of the Netscape SuiteSpot application family and some additional services. The CIRCA has been developed by European Dynamics S.A. in a project led by Eurostat and sponsored by IDA. The main capacity of the CIRCA groupware is document management, where lots of functionalities are supported such as user uploads, meta-information, search, interest group formation through open and sophisticated LDAP-based directory services and email notifications. Other functions include NNTP-based newsgroup discussions, meeting announcements, and generic web space platform.

Around the basic CIRCA product, an extended environment that contains mailing lists support, additional directory services, and a generic portal toolkit have been developed. This extended product, whose main function is to integrate the thematic document libraries and databases references, the distributed directory services and the standalone CIRCA servers together is called CIRCLE.

e-EIONET operates as an Extranet where all the servers are on the open Internet within the domain eionet.eu.int. EIONET servers are protected with routers and firewalls. A Network Management Centre (NMC) operates a helpdesk and processes about 100 calls per month. There are about 100 CIRCA Interest Groups on the e-EIONET. The central site at the EEA currently receives about 300 000 web hits per month, about one half of which is to CIRCA.

The organisational EIONET is a collaborative network, where information originally produced by the numerous National Reference Centres (NRC) is in a co-ordinated way collected to the NFPs and merged at the ETCs for publication by the EEA. Besides data collection, EIONET has also other technical uses such as project co-ordination, facilitating documentation for meetings, reducing information overload, and being a generic platform for application development. The EEA also hosts a data warehouse, databases, and extensive web services both for the experts at the e-EIONET Extranet and for the general public at the EIONET's open Internet Web locations.

After its three first years of operation, a strategic study on application development and use of EIONET in 2000-2003 was prepared and released in February 2000 as a Preparatory Report for IDA [1]. The current GIP builds heavily on the new strategy and the purpose of this paper is to technically formulate how the strategy can be implemented.

1.2 LEGAL BASIS

The European Environment Agency (EEA) and its wider network, the European Environment Information and Observation Network (EIONET) was established by Council Regulation 1210/90/EEC, amended by Council Regulation 933/99/EC, to ensure the supply of objective, reliable and comprehensive information at a European level and to ensure that the public is properly informed about the state of the environment.

The amendment promotes the EEA to support the development of Environmental Assessment methodologies and best practices, and to assist the diffusion of information on the results of relevant environmental research.

The new Regulation calls for a reinforced co-operation in the implementation of the EIONET with the Member Countries and an extended mandate for EEA to act as Reference Centre for environmental information.

The new Regulation calls also for closer Member State co-operation on the area of national environment information networks. The amendment reinforces Member Countries to contribute to the work of the EIONET in accordance with the Agency’s work programme by collecting, collating and analysing national data. It also requires that EEA and EIONET use new telematics technologies to achieve their mission. I.e., EIONET’s role as an information society player is anchored in the regulation.

Other regulatory basis to support the e-EIONET infrastructure and service development are:  Exchange of Information Decision, 97/101/EC.  Directive 90/313/EEC on Free Access to Environmental information.  The Århus Convention on Public Access to Information, Public Participation in Decision-Making and Access to Justice in Environmental Matters. The EU Member Countries as well as the European Community are Parties. 1.3 SECTORAL COMMITTEE / GROUP OF EXPERTS

The EIONET Telematics between Administrations Committee (ETAC) was established in February 1999 by the National Focal Points (NFPs) of EIONET to co-ordinate the e- EIONET activities in their respective countries. The NFP representatives of all the 18 EEA Member Countries form the ETAC. The EEA provides the secretariat for the ETAC.

In February 1999, the EEA appointed a Task Force from ETAC members to prepare the strategic plan for application development in EIONET for 2000-2003 that forms the basis of this GIP.

In addition to the above strategic groups, another group called the Information Technology and Telematics Advisory Group (ITTAG) has been established to secure and operate the network, to provide technical expertise for data management, to help specify IT applications, and to help assure a consistent systems approach.

1.4 RESPONSIBLE SERVICE AND ASSOCIATED SERVICES

 European Environment Agency

 Directorate General Enterprise  Directorate General Environment  Directorate General Enlargement 1.5 PARTICIPANTS

Main participants  European Environment Agency.  18 National Focal Points (NFPs) of EIONET.  13 EIONET National Focal Points in the Accession countries.  9 European Topic Centres (ETCs), which are established to execute tasks of the EEA Work Programme, and 5 PHARE Topic links.

Other participants  Other EIONET partners in EEA Member Countries and the Accession Countries, i.e., about 200 active National Reference Centres (NRC).  Contractors of the EEA that are involved in content production.  Other environmental networks such as those of NGOs and industry.

Customers and stakeholders that can utilise the outputs of proposed developments

 Various Commission services (Eurostat, sectoral DGs), Convention secretariats, OECD, UN and other international organisations. 1.6 CONTEXT

The European Environment Agency aims to support sustainable development and to help achieve significant and measurable improvement in Europe's environment through the provision of timely, targeted, relevant and reliable information to policy making agents and the public.

The priority products of the EEA are the regular reports on Europe’s Environment - the comprehensive five-year report and the more frequent indicator based reports. Major users of the Agency’s products and services are the Community institutions and the EEA Member Countries. Public access to EEA products and services is also laid down in the Regulation, thus supporting awareness, scientific use of European information and supporting the public participation process.

The EEA will in the coming years increasingly develop environmental information to support the promotion of sustainable development, in particular the integration of environmental protection into all relevant Union policies, working in collaboration with the DG Environment and the other relevant DGs.

Networking and capacity building is a specific mandate of the EEA. It has become the hub of an extensive operational network for the flow and exchange of data, for improving data through harmonisation and mutual support, and for conducting analysis and aggregation on different environmental topics.

The products and services of the EEA base on the efforts to consolidate the core data and information systems and improve the quality, consistency and timeliness of the required exchange of information with Member Countries. Building and further developing the European Environmental Information Systems with national EIONET partners and with ETCs is a shared responsibility of the EEA and the Member Countries.

EEA is already working outside its 18 Member Countries. Through the support from the Community’s PHARE Programme 13 Central and Eastern countries participate in part of the Agency’s work. Because of the strengthening European integration process there is an increasing need for environmental information targeted to serve accession and enlargement actions in the coming years.

EIONET consists of four main types of nodes. Currently there are about 600 organisations that have been nominated as members. Each National Focal Point (NFP) is typically a small unit in a Member Country environmental administration that coordinates activities in relation to the EEA work programme. There are NFPs in all EU, EFTA, and Phare countries. National Reference Centres (NRC) are major environmental institutes that collaborate with the NFP to provide the information to European databases.

European Topic Centres (ETC) are special contractors of EEA who coordinate activities in their thematic areas. Currently there are ETCs for air quality, air emissions, inland waters, land cover, marine and coast, nature conservation, soil, waste, and cataloguing of data sources. Each ETC has a number of partners. In Phare countries, Phare Topic Links provide the same function and extend the ETCs in five topic areas.

The EIONET also links with a range of Special Interest Networks, such as several regional projects around environmental themes, and collaboration with international institutions on projects such as the Clearing-House of the Convention on Biological Diversity, as well as interaction with private sector organisations around interest group formation and information exchange under EEA’s EnviroWindows services.

Best practices to utilise efficiently the e-EIONET network and the existing applications for the operative monitoring and reporting work have been pioneered by several sites. The network has contributed substantially to improve the data and information flows from national monitoring to European reporting. On the other hand the network has helped to streamline the flow of collected information from the Community institutions towards the stakeholder organisations, environmental professionals and politicians, as well as towards the European citizens. 1.7 OBJECTIVES

As summarised in the e-EIONET’s strategy (see the Preparatory Report), the long-term vision for the EEA/EIONET is to achieve a situation where a fully operational environmental indicator system is available for European countries supported by decentralised - but stratified - data flows from country level to European level. All information production for European environmental reporting will in future be arranged to flow through an unbroken electronic value chain so that manual work can be ______EIONET GIP 7(37)

minimised and incompatibilities avoided, duplicate work eliminated, and data and information stored in proper places in usable form, also for public access.

The e-EIONET will in future contain in its directories and information repositories, sufficient knowledge for the organisational EIONET to seamlessly support users in their functional duties. This will be achieved through interoperable information systems where users voluntarily through e-EIONET contribute to the maintaining and storing of the reusable knowledge.

The main objective of the e-EIONET development is to increase the overall efficiency and productivity of ways the professionals work within the EIONET community: at the EEA, in the thematic topic areas, in the intra- and inter-organisational teams, and even at the personal level.

The new strategy of e-EIONET is targeted to continue infrastructure and service development of the existing e-EIONET Extranet towards the following objectives:  Developing the erected infrastructure towards increased capacity, more reliable connections, as well as better security and manageability.  Developing and implementing for the use of EEA/EIONET community the second generation of collaboration and data exchange applications.  Increasing the productivity of professionals in the EIONET community with modern network and collaboration solutions.  Supporting efficient use and full utilisation of new applications and network tools by spreading best practices.  Achieving shortened monitoring, assessment and reporting cycles.  Offering process owners powerful tools to manage, modify, look after, supervise, and control reporting and other key processes.  Providing a technological platform so that removing duplication and decreasing needless manual work from the information gathering and so decreasing unnecessary reporting burden at Member Countries and at other responsible organisations becomes possible.  Improving and broadening on-line services for different user groups (politicians, authorities, industry sectors, enterprises, interest groups etc), and allowing each of them a flexible linking to all relevant information sources and web sites on EIONET.

2. TECHNICAL DESCRIPTION OF THE PROJECT

2.1 REQUIREMENTS

The major aim of the e-EIONET development is to raise the capacity, services and utilisation of the e-EIONET to the next generation information technology level to efficiently implement modern communication and collaboration technologies. The new regulation requires, inter alia, that the EEA and EIONET ensure the broad dissemination of reliable and comparable environmental information for use by all Europeans by promoting the use of new telematics technology.

A high priority for further e-EIONET development is to support and ensure that obligatory data and information collection duties for European monitoring and reporting purposes can be fulfilled. Development must support the Agency's main collaboration processes like those of integrated analysis of the state of the environment, consultations, and reporting.

An important common requirement is to demonstrate and promote operational use of new telematics technology and networked applications in the EIONET community, and so help to find optimal and cost effective IT solution structure that links EIONET organisations, their business and technology to efficient functioning.

Application1 and infrastructure development should boost the usefulness of e- EIONET and its collaboration services for end users. This development should bring European wide environmental information systems towards more transparent interoperability. Proposed solutions should provide a generic platform for repositories of environmental indicator data and reporting information and offer generic modules to exchange this data from original sources to European databases and information stores.

e-EIONET extensions and services in Central and Eastern European PHARE countries have been built up with the same technologies and systems as the original IDA project. In the future it is also important that those countries can utilise similar technologies and solutions to those of the Member Countries.

Figure 1. Main areas of application development in EIONET.

There are requirements in each of the main elements (Figure 1) of application development in e-EIONET: 1. The telecommunication and hardware infrastructure of the current EIONET (EEA, ETCs, NFPs) must be developed to a higher capacity and appropriate degree of decentralisation.

2. The collaboration services (EEA, ETCs, NFPs, with access to NRCs), including development of workflow management and progress monitoring tools and services will be further developed to better align with the functions and roles within the organisational EIONET.

1 BY APPLICATION DEVELOPMENT WE MEAN ALL AREAS AND LEVELS OF INFORMATION TECHNOLOGY DEVELOPMENT, BE THAT IN INFRASTRUCTURE, GENERIC SERVICES, COMMON TOOLS, OR APPLICATION INTERFACES. THEIR DIFFERENCES ARE EXPLAINED BELOW. ______EIONET GIP 9(37)

3. New generic and shared data management and data flow tools are required to enable and encourage the harmonisation, efficient management and collection of data (EEA, ETCs, NFPs, NRCs, international organisations) so that the reporting burden is decreased in Member Countries.

4. In data warehousing (EEA, ETCs) a new architecture is required that allows ETC databases to interchange data with the EEA Data Warehouse, and thus, make the data publicly available.

5. By portal development, integrate technologies, value chains, and interfaces found in the various online services into a uniform personalised corporate portal (EEA, ETCs, NFPs). These proposed areas of infrastructure and application development form a logical structure. They do not form any single complete system. The main idea, on the contrary, is modularity and gradual needs-driven development of different elements that allows smooth interconnectivity and interoperability between solution components via common/standardised interfaces. The system involved will be accurately sized with regard to data flow and the data processing actually taking place. The systems developed shall also extensively support the needs of ad-hoc flows. 2.2 TECHNICAL APPROACH

2.2.1 Network architecture

Figure 2 illustrates the network architecture of e-EIONET. Basically, it is very similar to the original one chosen in 1996. It is now recommended to use a firewall (and not just router access control lists) for security and place the e-EIONET server in the same or equivalent segment with a public web server.

2.2.1.1 Generic services for networking

Internet remains the carrier of choice for the e-EIONET because of the large number of organisations (hundreds) and enterprises that need access. However, the existing backbones of TESTA-II and TEN-155 will be used where feasible. Those nodes that already are in these high-speed backbones enjoy faster connections, but routing shall be possible between all the nodes.

It shall be made clear that the confidentiality of EIONET data or the needed speed of access alone do not motivate establishment of a TESTA-II connection to any site. Normally, EIONET is a small activity within an existing, often large organisation, whose connection needs is determined by other factors, and public access to data is a key issue. The need for TESTA-II connections must be evaluated in a case-by-case basis, and framed in the specific technical context of the organisations involved and taking into account the financial elements.

______EIONET GIP 10(37)

Phare NRC NFP NFP ETC

Fire- TEN-155 wall TESTA-II Rou- ter Local LAN Internet

Public EIONET server server

General public

Figure 2. The network architecture of e-EIONET. Any node can connect to any of the three backbones as their local needs dictate. A node can even have several connections, and traffic from the e-EIONET server, which is in its own domain eionet.eu.int, is then routed to the appropriate backbone. The backbones route traffic between each other.

2.2.1.2 Common tools for networking

Instead of protecting entire networks, protecting only virtual network services over any existing carriers between the concerned endpoints could be the right approach. There is a need for facilitating a single login to all EIONET servers and services using a central site directory and certification. Encryption of at least usernames and passwords is a necessity. Simple common tools in this area that can then be embedded in applications are required. 2.2.2 Architecture for group collaboration and portal integration

EIONET adopted CIRCA, then known as the IRC, in September 1997. From the beginning it was clear that the basic, standardised CIRCA product would only be able to fulfil a part of EIONET’s needs for group collaboration services. Subsequently, CIRCA has been enhanced at EIONET for its email management and with portal interfaces. This customisation is gradually growing, and the extended product that is integrated across all the sites is known as the EIONET CIRCLE.

______EIONET GIP 11(37)

Figure 3. A mind-map view (decomposition diagram) to the architecture of CIRCLE, the group collaboration service for e-EIONET. Components now available from CIRCA are identified.

Because of these extended needs, it is crucial for EIONET’s use of CIRCA that the architectural issues with regard to modularity and interfaces for developers are clear. EIONET does not expect that the basic CIRCA product would be bloated to cover EIONET’s special needs. EIONET expects, however, that it can make use of the components that make up the CIRCA, and out of these components create a product that fulfils the needs. The alternative, that CIRCA stays as a closed product and features needed by EIONET are totally independent of CIRCA is not appealing. For instance, a workflow tool would be useless if there was no API to access CIRCA document library service and directory of users.

This all is achievable, but requires that the layers of services and components in CIRCA are somewhat re-engineered.

The common tools within CIRCA (Figure 3) shall be made independent of the current CIRCA groupware application. The library tool, for instance, must stand alone so that it can be plugged in another application such as a personal electronic workplace. However, the linkages to other common tools shall be retained and, for instance, a document uploaded to a personal electronic workplace library is also accessible in the groupware. This can be achieved using a common generic service: a document database. The interfaces of each common tool shall be

______EIONET GIP 12(37)

documented publicly. There shall be an application programming interface (API) to each tool. For instance it shall be possible to upload a document to the library from another common tool.

What these components would be is illustrated from one view in Figure 3 and discussed below. It is important to make note that the branches of Figure 3 form matrices with each other so that a certain protocol works with a certain generic service, which in turn facilitates use of a certain common tool that, again, can be packaged to various personalised application interfaces. These matrices are not presented here.

2.2.2.1 Generic services for group collaboration and portal integration

Beyond networking issues covered in the previous section 2.2.1, the next layer contains generic services such as web server, directory server, etc. Because there is a need to distribute EIONET’s solutions to a large number of sites (at this moment 35 nodes), these services should in case of EIONET be all from the public domain and open source. Besides royalties, there are other advantages with this approach. Today’s public domain servers are of no lesser quality compared with commercial tools, and do not leave the user stranded when the support from the original creators ends.

In addition to the current CIRCA engines for web, directory, newsgroups, search, email, there is a need for certificate, database, and application services on the e- EIONET. Replication mechanisms for transporting selected data between nodes are also needed, but these are normally part of the other services. The EIONET software standards, where the currently preferred engines have been named, have been described separately [2].

These generic services require configuration work in order to be used. They are infrastructure components normally embedded to other programs (such as CIRCA). An end user does normally not directly use generic services directly.

2.2.2.2 Common tools for group collaboration and portal integration

When a user interface for achieving one particular function is created for one or several, configured, generic services, we have common tools. These include the popular library tool of CIRCA, some less popular ones, like meetings and newsgroups, and others still at prototype stage or not yet conceived, like workflow and portal management tools. A fairly large number of tools can be envisaged (see Figure 3) and what is required for e-EIONET is described in more detail in below sections on development projects. Here, it is necessary to make the note that these common tools should be possible to be plugged into applications (such as CIRCA or CIRCLE) in a modular fashion. On the e-EIONET, all common tools and user interfaces should run via a standard web browser.

From a software engineering standpoint, it may be useful to see common tools as objects that support certain operations on content held in generic services.

2.2.2.3 Application packaging and personalisation interfaces

The next layer consists of packaging and personalising these tools into functional applications that support EIONET’s work processes. There are four different uses that need to be considered. ______EIONET GIP 13(37)

The first and best-known usage of the tools is through is the CIRCA groupware application. Functionally, CIRCA is a way to package certain common tools for usage by interest groups (or rather, projects). Interest groups can also be grouped into separate instances for various separate purposes. EIONET will continue to use CIRCA this way.

However, in addition to the “group” view to content, also “personal” and “corporate” views are valid depending on the situation. In fact, the network that consists of a hundred interest groups on many servers is so fragmented that it is difficult to know what is happening there. Sharing of content between the groups and awareness of overall situation in the network are major bottlenecks. Therefore, these additional interfaces must be envisaged.

The second application is a personal electronic workplace on the Internet, where these same common tools, but also some new ones, are packaged for use by an individual. This service also includes new tools that are not meaningful in an interest group context, such as a task management interface to workflow. Definitions of expertise, interests, roles, and a public interface as personal home page also belong here. Based on these definitions, a “My-EIONET” view to the content can be created. Obviously, this “personware” application needs to build heavily on personalisation data defined in the site directory.

It should be made clear that all the content, i.e., documents uploaded to a library are shared between the groupware and personware applications, and not uploaded twice for different Interest Groups as today.

The third application is a corporate portal. This is a semi-public interface to the above content on multiple sites. I.e., all content that is not withheld by an interest group or by a person, shall be accessible from this interface. This necessitates that the content is organised by tagging the basic objects by geographic coverage, time, topic, metadata elements, legislative acts, and so on. Based on this information, a corporate view can be created. For instance: “What is new this week (time) on air quality (topic) in the Alps (region)?” The e-EIONET currently has a simple portal like this, but it is manually linked to almost random content that the maintainers have come across with. There is also an automatic scanner that creates a push technology channel the similar way.

The fourth application is that of system administrators that need to monitor the network and multiple content repositories.

2.2.2.4 Developer interfaces for group collaboration and portal integration

Some clever engineering is required to manage the above puzzle. This work entails rewriting parts of the code. The current procedural Perl and C code could probably be augmented with object-oriented languages and developing modules for a public- domain application server such as Zope or Enhydra. Another approach would be to create a suite of corporate business objects (such as Enterprise Java Beans). Third alternative is to continue relying on procedural code and use a database as glue. The approaches cannot be fully freely mixed. Much is dependent on the decisions made in the main CIRCA project during the year 2000.

______EIONET GIP 14(37)

One key requirement is that multiple developer and companies shall be enabled to provide solutions. There needs to be a repository of code where these contributions are stored. A technical committee must then keep an eye on what code goes into the mainstream products and releases. Moreover, the components must be made available as open source. The EEA has recently adopted the Mozilla Public Licence for its contracts to facilitate this.

Another consideration is that content exchange modules must be made clear. These include XML DTDs for data interchange and site descriptions with RSS so that multiple portals can tap into content. All of the above applications must use this approach for content interchange. (A somewhat similar approach is adopted below for data management.) 2.2.3 Architecture for data management and warehousing

Figure 4 illustrates the target architecture for EIONET's data and information management and the related workflow.

2.2.3.1 Generic services for data management

These include a relational database engine for general purposes and a directory server for maintaining information on users and organisations. Also the necessary replication mechanisms have to be provided.

2.2.3.2 Common tools for data management

Tools in this area facilitate management of data through its entire life cycle:  Data definition tool that allows data modelling and maintenance of a data dictionary. It will have to build on ISO 11179 metadata standards, be able to import and export data in XML format, and possibly even to use XML Schema Language for internal representation.  Data storage. This allows manipulating the tables and fields of the database, naturally using the definitions from the data definition tool. Also the content in the database can be monitored, indexed and optimised with the tool.  Data collection, validation and exchange. This includes so called “Data Exchange Modules” (DEM), smart electronic questionnaires that are used typically at Member Countries for organising their deliveries into a harmonised format and validating them. The new DEM tools will be developed as web forms that allow uploading, for instance a standard ASCII data file or an XML document into the database. They can also allow direct input to a form. Validation rules for data must be possible to define and execute. All the formats shall be taken from the definitions created by the data definition tool.  Data visualisation tools for analysis and browsing the content. These allow formulating queries and reports about the content in databases. The possibilities to extend the functions towards analytical capabilities are endless [see the evaluation in 3]. Basic functionalities can be provided by MySQL add-ons, but at some point when more sophisticated analyses are needed commercial statistical tools become viable alternative.

______EIONET GIP 15(37)

 Geographic browsing of data is widely needed and must be supported. EEA’s NATLAN system provides a good basis for developments in this area.

Citizens - Conventions - OECD - EU – EUROSTAT - DGs

Reference DW EDR ROD Centre Reporting request Visualisation, drill-in Dissemination Data definitions definitions

SQL SQL SQL SQL

XML X IW SQL M AE AQ L - CIRCLE

Combine, analyse X D S XML T

data L D D D e e f f i i n n i i t t i i o o

XML XML n n CIRCLE s s Import, select, transfer SQL data IW-DEM AE-DEMAQ-DEM XML Manual input XML XML XML

( d N Collecter/ Airbase- N a a R t t

a Reporter dem i C

o IW s Conversion n o e a u t c l r

c ) e s AE AQ Figure 4. Target architecture for EIONET data management, with examples from three ETCs. Please notice the new EIONET standards for data interchange (XML) and data storage (MySQL).

In all these areas, but especially in data exchange, the architecture heavily builds on XML (extended Mark-up Language). It gives much better possibilities for data sharing and harmonisation than what has been the case in the past. As a part of this development, data modelling in thematic areas could produce proper Data Type Definitions (DTD) that can be implemented as a part of the first generic XML solutions. In future, XML will allow increased independence of vendors and application environments. Simple data visualisation can also be addressed with XML. Also the NATLAN system accepts XML input for geographical browsing of data.

______EIONET GIP 16(37)

2.2.3.3 Applications for data management

Using the above reusable common tools, larger applications for data management and information warehousing can be built. The architecture will be constructed from the following applications at different levels of the EIONET:  The existing Data Warehouse at EEA will be developed towards more versatile Information Warehouse containing European level indicator and reporting data and data series to help users to present, aggregate, visualise and share the required data. Data flows to it will be gradually automated as shown in Figure 4.  An extended Reporting Obligation Database (ROD) provides shared access to a single database for remote users. It has national extensions that allow analysis of the relationship between reporting obligations and monitoring schemes, and monitoring of actual data deliveries.  A new Electronic Data Registry (EDR) is necessary to share the data definitions and enable data harmonisation. The EDR will act as glue to data flows.  At the European level, functioning topic specific databases are required for interoperable data systems that are integrated by XML-based data interchange and use harmonised tools.  At Member Country level, functioning data repositories contain the nationally reported environmental data and information. The coverage of the content can be increased gradually. This service shall also be possible to be virtualised in case the NFP does not want to host such a database physically.  All data exchange in this architecture is handled via XML documents. Even data exchange modules developed in specific projects will be able to input and output XML in the format defined in the EDR. In addition, generic data exchange and storage services are required.

2.3 DEVELOPMENT PROJECTS

This section describes the actions that are taken in order to put the above-described architectures in place and in use. They are basically carried over from the “next steps” and “follow-up steps” identified in the SPADE Strategy (see the Preparatory Report), but some more detail has been provided. 2.3.1 Telecommunication and EIONET infrastructure development

2.3.1.1 New connections

In general no new connections are established, but existing connections are used. Those sites that for their own internal reasons want to join either TESTA II or TEN-155 are encouraged to do so. In many cases the NFP may gain TESTA II access through the national administrative network, or are already part of the national research network and therefore TEN-155. Best use of these opportunities for high-speed connections is made. The EEA will establish connections to both of these networks in 2000-2001.

______EIONET GIP 17(37)

As there may be more needs for high-speed networks in the Phare Countries than within EU, the EEA will actively liase with the relevant authorities in order to pave the way for their participation.

2.3.1.2 Security tools

Security tools for endpoints (end user machines; EIONET servers) are adopted as IDA’s common tools in these areas become available. Such common tools are embedded in EIONET applications, where feasible. EIONET will, however, not assume lead role in this area.

2.3.1.3 New generation of EIONET servers

The current EIONET servers will be kept until the end of their useful lifetime. At that point, which is in 2002-2004, two options will be offered. Those sites that want to virtualise their services will be offered space at NMC or EEA. Other sites will be offered a very low cost Linux-based next generation server. Naturally, all then relevant EIONET software will have to be ported to that platform by then. Preparatory work for both of these possibilities will be done during 2001.

2.3.1.4 Network Management Centre

The services of the NMC are gradually expanded in areas such as providing usage statistics, monitoring of workflow, and replication of content between the nodes.

Long-term continuity will be provided for the training programme.

All site directories will be replicated to the NMC where they will form a central EIONET directory. This work will be carried out in close cooperation with the ETC/CDS and will partly succeed it. 2.3.2 Group collaboration services development

Developments in this area build on the current CIRCA application. A next version of the CIRCA software will be developed in close cooperation with Eurostat and IDA. EIONET-specific (CIRCLE) features will then be built on top of the generic version. In practice this works so that EIONET needs are communicated to the CIRCA project of Eurostat. If they are of general interest, then they may become part of the standard product. If they are of limited interest, or cannot be done in time, then the features can be developed under the e-EIONET project. Such features would of course be available as common tools, if, after all, others would need them. This arrangement should allow flexible cooperation. It would need some formalisation, though.

2.3.2.1 Modularisation of the architecture and generic services within CIRCA

The first, urgent project concerns opening the CIRCA software so that additional developments, also by third parties, become practical. There are two aspects to this: First, the underlying generic services in CIRCA (three Netscape SuiteSpot engines) must be replaced with their public domain open source counterparts. This also facilitates porting to Linux. The source code should be made available for all developers using an appropriate standard license such as the Mozilla Public License.

______EIONET GIP 18(37)

Second, the software itself must be partly rewritten in order to create clear interfaces for intercommunication between various common tools, and to open the ports for third-party developments. For instance, and as will be explained below in section 2.3.3 on data management, there is a need to start storing more content in the MySQL database already embedded in EIONET version of CIRCA. This generic database engine shall be opened for general use by any common tool.

The details of the re-engineering work have been explained above when discussing the architectures.

This all means that there would no longer be a single CIRCA application, but a toolbox from which the needed components can be plugged into various applications. The diversifying code base, however, shall still be maintained by a technically competent company on behalf of the Community institutions. A technical committee shall still decide on features and interfaces of each component. However, it should not be a problem to having even two varieties of the same tool, like the library common tool. On time basis there will be different versions anyway. All these issues have previously been encountered in open source development projects and are well known.

In this project EIONET can only assist Eurostat and IDA with requirements and specifications creation and testing. In other words, EIONET is hardly in a position to get these architectural enhancements done alone. Even if that could be somehow funded, it would lead to maintaining different overlapping applications, which is not desirable.

2.3.2.2 Development of new and improved common tools

There is a fairly long live document [4] on the wanted features in CIRCA on EIONET. The most important ones that have been mentioned in the Strategy are elaborated below. They are presented in order of priority suggested by the NMC CIRCLE User Group in April 2000.

 The directory services shall be made more versatile so that definitions of roles of people and organisations can be stored in it. The full complexity of the EIONET organisation shall be possible to model. An organisation modelling tool for editing and viewing the definitions shall be developed. These tools should allow taking over the EIONET Directory from the Catalogue of Data Sources, which shall be fully integrated into the e- EIONET infrastructure. Address data management shall be enhanced so that the people can be linked to the organisation objects.  After the above enhancements, each EIONET institution will then be responsible of maintaining their own data, in their own server, or at central directory, as they prefer. If the national server is used, it will be replicated in real time to a central directory at the Network Management Centre.  Expertise of people and organisations shall also be possible to store in directory. This will facilitate all kinds of technology transfer and business opportunities for members. (This is prioritised by the EC CHM project.)  Integration with email in the current CIRCA is rudimentary. This functionality has to be expanded very much by dynamic email list support based on the above-described enhancements for managing roles of people and organisations.

______EIONET GIP 19(37)

 Connected to the mailing lists, an automated management of email attachments, making use of CIRCA libraries, can later be developed.  Meeting support and calendar integration across interest groups is needed. The current meeting service in CIRCA will be enhanced so that structured agendas can be maintained there and creation of minutes and their follow-up will be supported. There shall be possible to create personal and corporate views of events from the basic calendar data.  Workflow services for monitoring the consultation process will be developed and integrated with CIRCA document management. A workflow tool would consist of three components: a process definition tool, a process execution engine, and a document repository. The introduction of workflow will also make it necessary to have a task manager tool and a workflow status-monitoring tool. The feasibility of these solutions in the context of data gathering will also be investigated. Co-operation with IDA horizontal actions and projects is foreseen in the workflow project, as it is obvious that a common tool in this area is needed.  In connection with the above steps, automatic routing and replication of individual documents to distributed servers shall be implemented. This requires an API at the CIRCA server.  Dossiers that allow the creation of compound documents are necessary for the workflow tool because it usually is not a single document that is routed.  Discussions shall be possible to view together with documents.  Rich site summaries (RSS) are a standard on how to describe content in a portal for use by other portals. RSS files will be provided for all shareable content areas (including CIRCA) so that they can easily be linked to each other and be made available to portals.  Multi-node functionalities will be developed so that site directories can be integrated with each other, security services provided in a multi-node environment, and individual documents can be mirrored between sites.  Enhanced statistics collection tools will be developed so that it is possible to generate global views of usage.  Password management needs to be enhanced so that users can be reminded in a secure way of their forgotten passwords. Passwords will be harmonised across servers.  Desktop integration. Building closer (e.g., drag and drop) interoperability with MS Office 2000 (and other generally used desktop applications) should be started. This includes functions such as “Save to CIRCA…” in the File menu.

2.3.2.3 Development of application layers for group collaboration

In addition to the current groupware application, three other applications in this area of content management will be built by integrating the above common tools in various ways (Figure 3).

 Corporate portal application allows generating global views to the above content in all sites and interest groups. (More in section 2.3.5.)  Personal electronic workplace application such as a “personal interest group” where the corporate portal view is customised. This application also provides access to those tools that are not meaningful in a group or corporate setting, such as a personal library, task manager, captured email attachments from mailing lists, personal home page and calendar.

______EIONET GIP 20(37)

 Administration application for monitoring usage. Also traffic between the sites needs attention when the workflow usage grows. Replication of directory entries will be a complex issue to tackle as well.

2.3.2.4 Usage of group collaboration services

The above enhancements will be developed in 2000-2002 and introduced gradually in small releases at typically quarterly intervals. After each release, the new functionalities will be tested and reviewed in pilot projects by user groups. After eventual improvements, practices for systematic use across EIONET are developed by the user groups. These practices are discussed at ETAC, which would then adopt a recommendation.

The agreement is especially important for the distributed maintenance of the EIONET Directory Services. It is suggested that each EIONET NFP and ETC take up the responsibility to maintain the official EIONET contact information within its authority, including role definitions in the directory services. This would be done either at the CIRCLE site directory on the NFP or ETC server, or using the central site directory located at the NMC. 2.3.3 Data management and data flows development

Unlike group collaboration activities that have been discussed above, there are no common tools or shared applications in data management currently existing. Therefore entirely new services shall be built. These should, however, build on the e-EIONET infrastructure.

2.3.3.1 Development of generic services for data management

There is an embedded MySQL relational database present in all EIONET CIRCLE installations. This engine will be used as storage of almost all data to be stored at the site. Opening up that database so that it can be used by other tools than those embedded in the current CIRCLE is a priority project.

The original data on people, organisations and roles is not held in the relational database but in directory servers, as explained above in the section 2.3.2.2. This will make interfacing to other applications much easier as currently, because a standard built-in LDAP port can be used for queries. Copies of this directory data can be created dynamically for other purposes such as address database.

2.3.3.2 Development of common tools for data management

The common tools that would be needed have been identified in the discussion on architecture. They will be developed or acquired as follows:

 The data definition tool that allows data modelling and maintenance of a data dictionary will be implemented fast as it will be needed by all other projects. This work is already foreseen under the TERESA project. As a first step in this project a requirements list must be compiled. Technological options will then be evaluated. They include adopting the US EPA electronic data registry tools, adopting some other public domain meta data tool, adopting a commercial CASE (Computer-Assisted Software Engineering) tool, or developing some simple screens ourselves.

______EIONET GIP 21(37)

 The data storage tool will obviously have to be developed from open sources components available from the MySQL user community. There are not too many choices, but an example is the Generic Information Server Toolkit (GIST) of the JRC, which also contains a data definition tool. Again, development begins with a requirements list creation and evaluation.  Data collection tools to provide electronic questionnaires and data upload services will be developed as generic components, but in real world context of one or several ETCs. At this moment, only the air topic centres have operational DEMs, but several others also need them. There are real possibilities to reuse work from other IDA projects, especially STATEL, which will be evaluated in detail. EIONET’s data collection needs are hardly unique, but the intensity and volume are important considerations that probably require a light-weight solution. Moreover, transport of data, which is STATEL’s main domain, is not the main challenge, whereas there are extended needs in the data definition, validation, storage, and reuse.  Data exchange tools will be developed along the same lines as the above. The only difference between data collection and exchange tools is that the former takes input from questionnaire or uploaded data file and then converts it to XML for uploading to a database, whereas the latter handles XML output and input between two databases. There are no available tools in this area, and they must be developed from scratch.  Data browsing and visualisation tools will be developed as part of topic-specific projects, like those underway in TERESA and NATLAN.

2.3.3.3 Development of applications for data management

Applications development for data management is mostly achieved by just configuring the above generic tools for use by projects and topic areas and creating customised user interfaces.

There is no clear view on how the user interfaces above tools would be packaged and customised to produce data management services. In the CIRCA environment, the tools appear as icons at the top of the browser window. This has proven to be a useful approach. Therefore, adding the data management tools described above as icons to the same integrated environment is probably feasible. Alternatively, a separate CIRCA-like application for data management could be devised. However, as document and data management are now integrating with each other through XML, this approach might not be appropriate.

Then it must be considered whether data management is task for individuals, projects, or a corporate matter, and how personalised the data management user interface should be. Login is required to for data manipulation privileges, and hence some personalisation is needed. Project, corporate, and public views for browsing gradually released data are also valid approaches. Therefore, it probably makes most sense to integrate data management with the CIRCLE environment.

2.3.3.4 Usage of data management services

Data harmonisation will begin in selected topic areas by defining data entities, their attributes, and permitted values. All these shall be stored in the unified electronic data registry that can be used — especially in stable indicator areas — to structure and standardise national data inputs to reporting shared by EEA and other organisations.

______EIONET GIP 22(37)

Common metadata components will be defined as part of normal data management activities. The structure, content and encoding methods of commonly used metadata will be agreed upon and metadata registries populated.

After the selection, all new data management projects should document and share their designs using the tool. Older systems will be gradually reverse-engineered and documented using the tool. After the documentation phase, harmonisation of shared data will be done.

National EIONET servers will be developed as transparent information repositories for exchanging the required data with the ETC and EEA servers using generic data exchange modules (DEMs). Such modules can also contain on-line visualisation front ends.

Development of a standard way for streamlined data collection shall be started by utilising XML data presentation formats. This will happen by building generic infrastructure components for national DEMs and for Topic Centre level, using common process definition tools, and developing prototype applications on top of the current e-EIONET infrastructure.

Generic workflow services will function over all organisational levels and link with the data management architecture. Workflow applications help to manage and automate data/information collection processes throughout the whole EIONET MDIAR chain.

The collaboration platform shall integrate closely with the ROD, EDR and DIR in order to provide seamless search and workflow services. 2.3.4 Data warehousing and related developments

The generic services and common tools in this area are those described above. Therefore it is only valid to describe the projects where they will be deployed for use of particular projects and how they are used to provide public access to environmental data. The projects below consider the immediate next steps defined in the SPADE strategy.

The ETCs maintain working databases, holding the datasets flowing as described above, for which the ETC has responsibility plus additional datasets from third parties where necessary (e.g. Eurostat, OECD, FAO). The working databases are for use of ETC partners in carrying out their reporting activities under EEA's work programme.

The ETCs and/or the EEA will also maintain a reference database updated at agreed intervals with clean quality checked EIONET datasets from the working database(s). The reference database must have data aggregated to the appropriate level for EEA reporting.

The reference databases are, per definition (Annex section 4.1), a part of the European Environmental Reference Centre (E2RC). Public access and network access to the reference databases will be provided using the generic services and common tools described above. The development of access tools will integrate the up to now separate development lines for the EEA Data Warehouse (aggregated ______EIONET GIP 23(37)

indicator data), the EEA Geographic Information System (GIS) and the various ETC databases.

2.3.4.1 Development projects around the DIR and ROD

The Reporting Obligation Database (ROD) includes an overview of legally based, obligatory data deliveries and some moral reporting obligations. It should be developed to cover also those data sets that are needed for the periodical or yearly EEA indicator reports, and are thereby loaded to the EEA Data Warehouse.

The Directory of Information Resources (DIR) includes descriptions of the publicly available products of EEA, including publicly available data in the Reference Centre.

Enhanced ROD should be made available through an integrated development of access tools to the DIR and related information resources of the Reference Centre. The enhanced ROD should provide a shared database for the Member Countries (NFPs) to follow what to monitor and report to European level and compare with current monitoring schemes. So-called national extensions to the ROD will be built with the workflow tools described above.

Linkage between the ROD and the metadata registry will be developed. This allows linking the metadata entities with particular questionnaires and directives.

2.3.4.2 Development of the EEA Data Warehouse

In order to prepare for automatic data interchange, the database engine behind the EEA Data Warehouse will be enhanced with a solution that is compatible with overall e-EIONET strategy and Figure 4 architecture. This means replacing the current SAS-based file management with a MySQL engine.

The EEA Data Warehouse will be integrated with the ETC reference databases so that data can automatically be replicated to it from the topic databases. A total integration of the Data Warehouse, ETC reference databases and the EEA Geographic Information System is also foreseen.

The SAS engine will also later be fully replaced with a less expensive data analysis tool. Evaluation of these tool made in the IDA APPLIC project will be revisited and possible open source modules considered. Supporting tools to perform sophisticated analyses, to visualise data, and to model observed trends based on available DW content will be developed and implemented into regular reporting use.

2.3.4.3 Development projects around ETC databases

EEA, EIONET and the public must be able to access the data in the reference databases of the ETCs through the Internet. Users should be able to query on-line and download the datasets. Meta information and supporting documentation must also be readily available to all users.

For new ETC systems, public access will be provided through a MySQL-based data warehouse (a reference database) at each of the ETC EIONET servers and a standard visualisation front-end that is shared with all ETCs and the EEA Data Warehouse. Alternatively the reference database can be maintained at EEA. These ______EIONET GIP 24(37)

systems make use of the common tools described above. The first databases in this new architecture are those of ETC/IW, ETC/W and ETC/NC.

Data will be copied to these data warehouses from the current working database databases of the ETCs. The working databases will be maintained for the time being using the relational database management systems and platforms found to be most relevant to use by respective ETC. 2.3.5 Portal development

2.3.5.1 Development of the generic services underlying portals

Portal services on the e-EIONET link to all other services, as the portal is used as an integrative instrument.

The portal itself shall be maintained by some kind of application server. This is necessary in order to manage the dynamic nature of the content and integration to databases. The Python-based Zope application server from public domain has been chosen for EIONET. There are other alternatives, such as the Java-based Enhydra, Microstate Hamilton and OSAS. However none of these systems enjoy such a large community of developers as Zope.

The Zope application server from public domain was chosen as the platform as it allows dynamic content provision, delegation of authority in content management, XML-support, MySQL database integration, and has a solid approach to modularity and open source. There is a large community of Zope developers that provide simple shareable modules.

2.3.5.2 Development of common tools for portals

A portal toolkit (PTK) has been developed at EEA in 1999-2000 using Zope. This is a common tool that can be used by any site. It has no particular environmental context.

Commercial portal tools were not deemed suitable for EIONET because they had to be deployed across many sites and licensing costs became an issue. Also tapping into content in CIRCA and environmental databases required a customised approach. An XML-based generic solution that would allow exchange of content between sites was desired.

The EIONET PTK allows maintaining a dynamic home page from Zope database. The content is classified using channels, categories, topics and countries. A basic content item can be a link or a CIRCA interest group. Links can be local files or remote URLs.

Future developments include deriving content directly from CIRCA using XML and rich site summaries (RSS). Each author can mark their uploaded document whether it can be released. Also classifications more akin to the European content can be developed, for instance with regard to legislation. Personalisation of the portal will also be implemented.

______EIONET GIP 25(37)

2.3.5.3 Development of portal applications and user interfaces

The EIONET portal toolkit that is already in operation at EEA and NMC will be further developed to allow personalised access to EIONET content. The existing Internet, Extranet and Intranet services will be used as basis for the public and corporate EIONET portal development utilising integrative elements and tools. Personalising, profiling, filtering, tracking etc. services will be implemented with integrated methods. Also new types of on-line services will be maintained and distributed through the portals.

The push-technology search engine that each night collects meta-information on new documents on participating EIONET sites and was created under the APPLIC PUSH project will be integrated with the EIONET portal.

2.3.5.4 Usage of portals

Users are taught to provide and maintain electronic content to on-line portal services. A simple publishing mechanism that is compatible with the EIONET, E2RC, and EEA Intranet will be devised. This will be part of designing an unbroken value chain for EEA/EIONET information products. 2.4 USE OF IDA GENERIC SERVICES

From the above discussion it should be clear that EIONET intends to fully build on IDA’s generic services, and not only build, but also contribute its work into the common pool of reusable components. In fact, EEA is in a way in a similar position to IDA because it has to coordinate and promote a large network with several topic areas (that somewhat correspond to sectors) that do have common needs to be addressed with shared components.

CIRCA development will take place in close co-operation with the various Commission services. The EEA will regularly inform the CIRCA technical committee of its needs as described above in section 2.3.2. The CIRCA contractor will maintain an integrated code base of modules from which applications can be customised to various user groups.

The development of the generic data exchange modules will be done in close cooperation with Eurostat, and build to common tools such as STATEL where feasible. A generic DEM model will be designed for primary data collection, to help data compilation, to meet reporting requirements and to deliver indicators and data to reporting processes. This model shall offer a customisable and flexible solution for broader use in different areas and between different level organisations.

Use of IDA generic services for telecommunication (TESTA II) is not foreseen in wide extent. This is because 1) EIONET has to connect to a large number of organisations and also private companies that already have their Internet services, 2) EIONET is a fairly small activity in these organisations and can not alone motivate network changes, 3) EIONET data is not sensitive, and 4) access times provided by Internet are in general sufficient (especially if replication of individual content elements to the distributed EIONET servers can be implemented) and is improving. This does not exclude using TESTA II where it is available for other

______EIONET GIP 26(37)

reasons. Common embeddable tools for directories, security and authentication at endpoints would be most welcome. 2.5 USE OF STANDARDS

The project documentation will follow IEEE standards.

Internet standards will be utilised throughout.

XML-standard and appropriate data and document structure standards e.g. WEBDAV, XSL, UML, XML Schema Language, and ISO 11179 will be utilised in defining document structures, in document presentation, and as a generic data exchange format.

3. PROJECT ORGANISATION

3.1 OVERVIEW OF ACTIONS

The developments described above will be done in the projects that correspond to the blocks of Figure 1:

1. Telecommunication and infrastructure support and development. This includes establishing new telecommunication lines, creating a new generation of EIONET servers, and expansion of the services of the NMC. 2. Group collaboration services. This includes modularising the CIRCA platform and creating a set of new and enhanced tools for EIONET purposes. 3. Data management. This includes developing a suite of new common tools that implement the new data management architecture. 4. Data warehousing. This includes using the above tools in the different contexts to operate the data flows and to provide public access to EIONET data. 5. Portals. This includes the integrative work done in across all the areas, but especially in the group collaboration. 6. Project and resource management.

The details of these actions have been described above in sections 2.2 (architectures) and 2.3 (development steps) and are summarised in the table in section 3.5 (resources). 3.2 TIMETABLE

There are at least two major approaches to scheduling and organising the process of application development that can be described as the “waterfall model” and the “spiral model”. The former model that can be illustrated as a one-way road from requirements definition to analysis, design, construction, implementation, and deployment, has been used in most IDA projects and is assumed for GIPs. The phases would include:

(UR) Definition of User Requirements including Obligations that set requirements for appropriate processes and for the content; (SR) Definition of Software Requirements including detailed functional and technical specifications for the application/system; ______EIONET GIP 27(37)

(AD) Definition of Architectural Design including subsystem structure, interface design instructions and data transfer principles; (DD) Detailed Design and Production of the code that implements the software components and produces a pilot; (TR) Transfer of software to operations that plans the inauguration phases of the application/system; and (OM) Operations and Maintenance that prepares guidance to run and maintain the application/system.

However, the current project that is based on small incremental steps done simultaneously in several areas and are also dependent on external projects, such as CIRCA, does not well fit in this model, although some indications on deployment and responsibilities through the various phases will be given in the next section.

Therefore, the spiral model is adopted. This means dropping from the table below the above-mentioned phases, but instead identify the timings of the development of the common tools (listed in 2.2 and 2.3).

Action Begin End Deliverable

1. Telecommunication and infrastructure

1.1a. Establish TESTA-II 2000 2001 Service connections 1.1b. Establish TEN-155 2000 2001 Service connection 1.2. Adoption of common 2002 2003 Service security tools 1.3. New generation 2001 2002 Turn-key EIONET servers hardware and software system 1.4. NMC expansion 2000 2003 Service

2. Group collaboration services

2.1. Modularity of CIRCA 2000 2000 Open source software 2.2. New common tools 2000 2002 Open source for CIRCA software 2.3. New personalisation 2002 2003 Open source interfaces to common software tools 2.4. Use of group 2001 Continuous Directory data collaboration services, including EIONET Directory

3. Data management services

______EIONET GIP 28(37)

Action Begin End Deliverable 3.1 Generic services for 2000 2000 Open source data management software 3.2. Common tools for 2000 2002 Open sources data management software 3.3. Applications for data 2001 2002 Open source management software 3.4. Use of data 2002 Continuous Data management services

4. Data warehousing

4.1. ROD and DIR 2000 2001 Open source software 4.2. EEA data warehouse 2000 Continuous Web site 4.3. ETC databases 2000 2003 Web site and open source software

5. Portals

5.1. Generic services for 2000 2001 Open source portals software 5.2. Common tools for 2000 2001 Open source portals (i.e., CIRCA software integration, multi-node communication) 5.3. Applications and user 2001 2002 Open source interfaces for portals software 5.4. Use of portals 2000 Continuous Web site

6. Project management

6.1. Project management 2000 2003 Project Management Plan, Quarterly Reports, Final Report 3.3 ROLES AND TASKS

3.3.1 Community’s tasks

In general the development work foreseen for IDA below can be achieved through specific agreements for EIONET purposes under the EINRC and CIRCA framework contracts. In validation, QA framework contract could be used. Corresponding framework contracts have been established by EEA.

______EIONET GIP 29(37)

The text that follows should be compared against the middle two columns in the table in section 3.5.

3.3.1.1 Development Phase (EEA, IDA)

Developments of project 1 that contains establishing of TESTA-II connections, adoption of common security tools, creating a new generation EIONET servers, and NMC expansion is suggested for IDA funding.

Project 2 requires some serious re-engineering of CIRCA product, which is a task suggested for IDA, but not under EIONET budget line. The development of the common tools is partly suggested for IDA and partly EEA.

Project 3 requires building a new suite of common tools for data management where IDA support is expected. Otherwise, it is EEA responsibility.

Project 4 is mainly about use of results from project 3 and is responsibility of EEA.

Project 5 requires integration of existing CIRCA system with portal and in this area IDA support is expected. Otherwise the development is up to EEA.

3.3.1.2 Validation Phase (EEA, IDA)

Responsibilities in this phase correspond to those of the development phase.

3.3.1.3 Implementation Phase (EEA, IDA)

One year of operational support for the new data management common tools (projects 3 and 4) is expected from IDA. Otherwise they are EEA responsibility. 3.3.2 Member Countries’ tasks

The descriptions that follow should be compared against the rightmost column in the table in section 3.5.

3.3.2.1 Development Phase

Member Countries will, through the ETAC expert group, appoint representatives to the user groups of all development projects. This typically requires 2-4 meetings per year.

The special responsibility of MS representatives is to define the exact ways the new tools will be used in subsequent phases.

3.3.2.2 Validation Phase

As above.

In addition, the validation Phase ends in an expected endorsement of the results by the ETAC sectoral committee. That endorsement would include a decision to use the developed tools in agreed, harmonised ways through the implementation phase.

______EIONET GIP 30(37)

3.3.2.3 Implementation Phase

At the end of the implementation phase, the ETAC sectoral committee will look at the experience and improvements made. If successful, the agreed harmonised ways to use the tools will continue. This would entail storing national deliveries of data to repositories at national EIONET servers (or virtual servers at NMC hardware).

The EIONET Directory that is currently held at ETC/CDS will be moved to the site directories. It would be the responsibility of the NFP and ETC to maintain their own information therein.

At the end of the implementation phase, in 2002, the current EIONET servers would be replaced with the next generation. It is the responsibility of the sites to acquire such a new computer that will not be different from a standard office PC.

The sites will continue to have the system administration responsibility of their EIONET servers. Local users will have to be assisted by the local CIRCA administrator, who in turn will receive 2nd level helpdesk services from the NMC.

In data management, the NFPs, will maintain a repository of the national deliveries of data to the international reporting systems on their EIONET servers (or smilar virtual services at NMC or EEA). This will be done initially in CIRCA libraries, but later increasingly using the data storage tools that will be created.

As the workflow tools become available, the NFPs will use them to orchestrate and monitor the data collection within their countries.

Sites will have to appoint a person or small group to develop the content on the local portal. This content will then be selectively replicated to the EEA EIONET portal. Even though much of the content will be generated automatically from CIRCA and the future data management services, an editor is required. 3.4 EXPECTED BENEFITS

According to IDA’s GIP guidelines, this section is expected to provide:  A detailed description of the expected benefits  Assessment criteria for measuring those benefits beyond the implementation phase.

The benefits and their assessment criteria include the following:

1. The reporting burden in Member Countries will be reduced. Instead of reporting separately and overlapping to each international system, the MS only maintain the information in their EIONET servers from where the international bodies can retrieve it. It is understood that this will require renegotiating of current agreements, which is not a direct responsibility of the e-EIONET project. However, improvement is not achievable unless the new capacities are first technologically demonstrated and for a while run in parallel with the traditional information exchange. Progress can be measured by looking at the trends in numbers of questions and data entries that have to be produced annually at MS, the reuse rates of that data, and the relevance of those data to evaluating effectiveness of EU policies.

______EIONET GIP 31(37)

2. Manual work in moving data from one system to another is reduced and an unbroken automated value chain from data deliveries to reports and dissemination is achieved. This can be measured by looking at the time lags from data delivery to web access. 3. Access to citizens to the reported data. Exposing data about, for instance, polluters, immediately creates pressure to reduce such harmful effects. Success in this area can be measured by looking at the hit rates to the various data warehouses at EEA and ETCs and references made in the public press to these services. 4. Access to citizens to documents becomes easier. Documents that are released are marked so in CIRCA libraries and immediately become available in the portal services. This directly supports transparency and e- Europe goals for electronic government. Success can be measured by hit rates. 5. Knowledge sharing between the partners of the network becomes easier. The structured content repositories in CIRCA will be used as the primary ways of sharing information and experience, i.e., as corporate memory. Because it is fully searchable, browsable and linked with other corporate knowledge management tools such as email, finding information becomes easier and faster. This can be measured by looking at the numbers of documents in the system and their rates of upload and download. 6. Closer collaboration of partners in the network in jointly providing content in the portal services. This can measured by looking at the number of authors and sites that actually provide new content elements. 7. Planning, analysis and monitoring of the reporting in Member Countries becomes easier with the analysis and workflow tools. This can be measured by looking at the use of workflow instances initiated and completed. 8. Maintenance of the address information (EIONET directory) at the source deduces the current classical n-directory problem of overlapping and false information still existing in multiple services. Can be measured by counting complaints. 9. Time to market and cost in IT development projects is reduced with the modularisation and full suite of reusable generic services and common tools. 10. IDA networks become more like each other and reuse of solutions rate can be increased. Spreading of best practice becomes easier as the problems are better understood. I.e., not every network has to reinvent their architectures and solutions.

3.5 RESOURCES AND COST SHARING

This section is also expected to provide a convincing answer to the questions:  What will it cost?  Who will pay for it?  How do we measure this in an appropriate way?

Moreover it is required to have:  A schema, which defines an equitable sharing between the Community and the Member Countries of the operational and maintenance costs of the networks concerned on conclusion of the implementation phase.  An answer to the question on who is going to pay for it once implemented and operational? ______EIONET GIP 32(37)

The following table summarises the actions. The numbering corresponds to the subheadings of section 2.3, for instance, 2.1 in the table corresponds to 2.3.2.1 in the text above.

Action Budget Budget line Member State (1000 Expenditure EUR) (1000 EUR)

1. Telecommunication and infrastructure

1.1a. Establish TESTA-II 100 IDA None to connections acquire and in the first year; For 256 Kbps 10 /each /year afterwards; none if routed via national administrative network 1.1b. Establish TEN-155 50 EEA - connection 1.2. Adoption of common 50 IDA - security tools 1.3. New generation 100 IDA 5 /each to EIONET servers acquire; 5 /each /year to back up and maintain 1.4. NMC expansion 200 /year IDA -

2. Group collaboration services

2.1. Modularity of CIRCA - IDA (costs to - appear in the CIRCA project) 2.2. New common tools 200 IDA - for CIRCA 100 EEA 2.3. New personalisation 200 IDA - interfaces to common tools 2.4. Use of group 50 EEA 15 /each /year collaboration services, to maintain including EIONET content Directory

3. Data management services

3.1 Generic services for 50 EEA

______EIONET GIP 33(37)

Action Budget Budget line Member State (1000 Expenditure EUR) (1000 EUR) data management 3.2. Common tools for 500 IDA (partly data management in TERESA) 3.3. Applications for data 200 EEA management 3.4. Use of data 100 EEA 15 /each /year management services to store national deliveries on EIONET servers

4. Data warehousing

4.1. ROD - IDA (in 15 /each /year TERESA) to orchestrate and monitor data collection activities 4.2. EEA data warehouse 300 EEA 4.3. ETC databases 300 IDA

5. Portals

5.1. Generic services for Done EEA portals 5.2. Common tools for 200 IDA portals (i.e., CIRCA integration, multi-node communication) 5.3. Applications and user 100 EEA interfaces for portals 5.4. Use of portals 50 EEA 15 /each /year to disseminate national environmental content to EIONET portal and E2RC

6. Project management

6.1. Project management

______EIONET GIP 34(37)

Action Budget Budget line Member State (1000 Expenditure EUR) (1000 EUR) IDA EEA 18 MC Sum 2000 294 250 1192 Sum 2001 737 250 1192 Sum 2002 737 250 1192 Sum 2003 737 250 1192

TOTAL 2504 1000 4770

The costs shown above are split evenly over the four years. TESTA connection, which is optional, is not included in totals.

Share of IDA is 2,5 MEUR, which means that EIONET developments would be funded at about the same level than has been the case in 1998-1999. The 2000 figure has been retrieved from IDA Work Programme 2000, and is lower, as there was no GIP when this figure was proposed.

Share of EEA is at the same level that is currently spent to e-EIONET operations.

Share of each Member Country is in the range of 60 KEUR/year for manpower, which means one full time person that would manage the content and also technically take care of the server (about 10% of time). For 18 Member Countries this sums up to about 1,2 MEUR per year. However this is not a totally new expenditure; if a Country has a full-time NFP representative and allocates some support from an ITTAG person for EIONET, this cost is already there. For the 18 NFPs, the one-time cost of acquiring a new generation of servers to all sites totals at about 100 KEUR, and their annual maintenance about 100 KEUR.

4. ANNEXES

4.1 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

API Application Programming Interface

CDS Catalogue of Data Sources

CIRCA Communication and Information Resource Centre Administrator. The software application developed for Eurostat by European Dynamics with the sponsorship of IDA.

CIRCLE The electronic workplace of EIONET consisting of many interlinked, customised installations of CIRCA and other services linked to it, supporting it, and integrated by it. I.e., the software component of e- EIONET

DEM Data Exchange Module, i.e., a tool used to input and validate data for a harmonised data collection scheme.

DIR Directory of Information Resources

______EIONET GIP 35(37)

DTD Data Type Definition, i.e., a definition for a harmonised representation of content in XML and SGML.

DW Data Warehouse; a periodically refreshed copy (snapshot) of the data in a database, created specifically to allow external users to query the database.

E2RC European Environmental Reference Centre. The pool of electronic data and information maintained at EEA and ETCs, and references to other data and information sources in EIONET and to relevant data and information developed from other national and international sources. The data and information in the Reference Centre is made available for the EEA partners and, whenever relevant and possible, for the public.

EDR Electronic Data Registry. A meta database application for maintaining data definitions. A data dictionary.

EEA European Enviroment Agency

EIONET European Environment Information and Observation Network

e-EIONET The electronic network that supports the functioning of the organisational EIONET

ETAC EIONET Telematics between Administrations Committee

ETC European Topic Centre

GIS Geographic Information System

IDA Interchange of Data between Administrations

ITTAG Information Technology and Telematics Advisory Group

HTML Hyper Text Markup Language

HTTP Hyper Text Transport Protocol

LDAP Lightweight Directory Access Protocol

MDIAR Monitoring, Data, Information, Assessment and Reporting value chain of the EIONET.

NATLAN Natural Resources and Land Cover information system of the EEA.

NFP National Focal Point

NMC Network Management Centre

NNTP Network News Transport Protocol

NRC National Reference Centre

ROD Reporting Obligations Database

RSS Rich Site Summary ______EIONET GIP 36(37)

SPADE The project on Strategic Planning of Application Development in EIONET 2000-2003.

SQL Structured Query Language

Telematics An information system that combines telecommunication and information processing

TEN Trans-European Network. TEN-155 is the current backbone of research institutions operating at maximum 155 Mbps and maintained by Dante.net.

TERESA Transparent Environmental data and information Reporting and Exchange System for Administrations. An EEA project for rapid application development in specified areas.

TESTA Trans-European Services for Telematics between Administrations. TESTA II is the backbone of IDA’s IP network.

UML Unified Modelling Language is a standard notation for the modelling of real-world objects as a first step in developing an object-oriented program.

WEBDAV Web-based Distributed Authoring and Versioning. A set of extensions to the HTTP protocol, which allows users to collaboratively edit and manage files on remote web servers.

XML Extensible Markup Language

XSL Extensible Stylesheet Language

4.2 CONCLUSIONS OF THE SECTORAL COMMITTEE

To be done.

Including opinions on:

 Initiation of the project  Definition of project phases  Definition of user requirements (technical and functional)  Implementation 4.3 REFERENCES

1. SPADE: Strategic Planning of Application Development in EIONET 2000-2003. Preparatory Report. EUROPEAN COMMISSION ENTERPRISE DIRECTORATE GENERAL IDA-Programme - Framework Contract No 501 998. 2000. http://eea.eionet.eu.int:8980/Public/irc/eionet-circle/training/library? l=/itstrprepida_20000225/_EN_1.5_&a=i 2. Software Standards of EEA and EIONET http://www.eionet.eu.int/software/swstandards.html

______EIONET GIP 37(37)

3. Development of Statistical User Interface to Intranet Databases. Common Functional and Technical Specifications. Version 0.3 including User Requirements Specifications and Product Evaluations. EUROPEAN COMMISSION DIRECTORATE-GENERAL III – INDUSTRY IDA-Programme -Framework Contract No 500882 – 1998. http://eea.eionet.eu.int:8980/Members/irc/eionet- circle/eionet-telematics/library? l=/applic_projects/statistics/techspecifications/_EN_1.3_&a=i 4. Specification of Enhancements for CIRCA on EIONET. 28 April 2000 Version 2.2. http://eea.eionet.eu.int:8980/irc/DownLoad/9592705059087/circa-spec-22-2000- 04-28.html

______