1. Fostering the vision of information sharing in Europe DI Gerald Schimak, DI Ecker Severin, Information Management, ARCS gerald.schimak; ecker.severin@arcs.ac.at EnviroInfo 2008, Lüneburg, Germany 10. September 2008

2. DI Gerald Schimak 2 Overview  SEIS’s challenging tasks and requirements  Technical Approach to a shared information space (Re-use ORCHESTRA)  Benefits  Conclusion

3. DI Gerald Schimak 3 SEIS’s challenging tasks and requirements  Collect data once; Use and share them many times.  Modernisation and simplification of the collection, exchange and use of data and information for the design and implementation of environmental policy  Manage the data at their source level.  Replacement of centralised systems for reporting by systems based on access, sharing and interoperability  Provide accessibility and availability of data (to public authorities) at any time and at all levels, from local to European, to facilitate reporting obligations as well as to inform citizens about the state of the environment.  Improve the quality and availably of information required for environmental policy  Keep administrative burdens to a minimum  Make information available in relevant national languages  Re-use investments (at regional, national, EU) Source: SEC 2008

4. DI Gerald Schimak 4 SEIS’s Technical Approach – Current and Future Source: http://ec.europa.eu/environment/seis/index.htmhttp://ec.europa.eu/environment/seis/index.htm

5. DI Gerald Schimak 5 Sensors Maps Documents Archive Control centre Catalog(s) Knowledge Base(s) ORCHESTRA’s Ambition Thematic data Spatial data Meta- information Analysis Info Centre

6. DI Gerald Schimak 6 ORCHESTRA in a nutshell  ORCHESTRA objectives  To design and implement an open service-oriented architecture (SOA) (e.g. for risk management) in Europe  To develop a set of services that are useful for various environmental (e.g. risk management) applications  To validate the results (i.e. architecture and services) in multi-risk scenarios (pilots)  To improve accessibility and availability of data (e.g.: cross-border)  To enable interoperability between systems by a standards-based IT architecture  To overcome the lack of a common risk management terminology, the diversity of procedures, policies and business models (with the use of semantics).

7. DI Gerald Schimak 7 Problem statement of a Civil Protection or Environmental Agency Source: http://iapf.physik.tu-berlin.de/DZ/dickow/Pyrenaeen/Karte.html How big is the risk of a forest fire in a certain region of the Pyrenees in a given season ? Temporal ref.: Time series and prognostics Spatial ref.: cross-border, cross- administration Thematic ref.: Forest Fire – Vegetation – Geology – Cartography – Meteorology – Settlements – Industry – Traffic -... Conceptual ref.: What is a risk ?

8. DI Gerald Schimak 8 Conceptual & Implementation Architecture Abstract (= platform-neutral) Concrete (= platform-specific) Implementation specs Implementation components Conceptual models Abstract specs: Services Information models Interaction patterns ORCHESTRA Implementation Architecture ORCHESTRA (Conceptual) Architecture open generic

9. DI Gerald Schimak 9  Service Capabilities Interface  Feature Access Service  Map and Diagram Service  Schema Mapping Service  Coordinate Operation Service  Service Chain Access Service  Processing Service Major ORCHESTRA Services/Interfaces  User Management Service  Authorisation Service  Authentication Service Service Monitoring Service resources Access Control Monitoring Search Semantics  Catalogue Service  Ontology Access Service  Inferencing Service  Annotation Service  Sensor Access Service  Sensor Observation Service  Sensor Alert Service  Sensor Planning Service  Web Notification Service  WS-Addressing

10. DI Gerald Schimak 10 Meta-information – establishing Interoperability  Service capabilities  Service capabilities comprise a set of meta-information of a service which can be delivered to a service user as a self-description of the service.  They can be specified by means of an ORCHESTRA Application Schema for Meta-Information (OAS-MI), which can be published in a catalogue and used by clients to discover a service.  Furthermore, it contains all necessary information enabling a client to invoke operations provided by a service.

11. DI Gerald Schimak 11 Meta-information - Service Capabilities

12. DI Gerald Schimak 12 ORCHESTRA catalogue service  Ability to publish, query and retrieve descriptive information (meta- information) for resources (i.e. data and services) of any type. Specific characteristics are described in (Hilbring and Usländer, 2006), such as:  not tied to a particular schema of a meta-information standard (e.g. ISO 19115)  supports application schemas for meta-information designed according to the ORCHESTRA rules  may be used as a data catalogue or a service registry  may be cascaded with OGC catalogues or OASIS UDDI  includes an adapter to Internet search engines (e.g. Yahoo)  includes an extension for ontology-based query expansion and result ranking

13. DI Gerald Schimak 13 ORCHESTRA Service Networks (Pilots) Typsa Pilot Floods and forest fire risk assessment in Tordera basin/Spain BRGM Pilot Risk assessment for roads in the French-Italian border region JRC Pilot Pan-European assessment of natural hazards BMT Pilot Environmental risks caused by ship traffic in the German Bight

14. DI Gerald Schimak 14 Interface ORCHESTRA Catalogue Service ISO ebRIM Semantic Query Expansion Semantic Ranking Option: Semantic Catalogue Typsa Pilot OGC Catalogue BRGM Pilot OGC Catalogue JRC Pilot OGC Catalogue BMT Pilot OGC Catalogue Yahoo API SOAP Web Service cascading ORCHESTRA Catalogue Client Meta- information profiles Federated Pilot – Architecture

15. DI Gerald Schimak 15 Benefits  End users  Flexible and semantically enhanced search of information  Access to all available information  Same understanding (through defined glossaries and ontologies)  Software Developers  It provides a uniform conceptual model of both the information and the service viewpoint and  Tackles the problem of both syntactic and semantic interoperability.  It is specified both on a platform-neutral level and on a platform-specific level.  Investors  Exploit existing investment and experience for your application; enable re-use for other applications  Accelerate developments; reduce development and maintenance costs

16. DI Gerald Schimak 16 Conclusion  SEIS tries to solve numerous problems on various administrative levels in the European Union by defining a new infrastructure with the goal of reducing the number of copies of the same information to a minimum for improved manageability, and maximizing its sharing and accessibility throughout the public authorities and the citizens.  ORCHESTRA worked successfully for about three years to develop a service oriented architecture (including the specification and implementation of services) for an infrastructure as well as to provide a reference model for interoperability and accessibility of data and services cross boundaries.  Certainly ORCHESTRA does not provide an out-of-the-box solution for all SEIS problems and requirements but it can easily be adapted.  It is also noteworthy that the ORCHESTRA architecture is open, which means that every institution and organization can adopt it free of charge.  Most of the services will be licensed under open source.  Thus, “SEIS ready” seems to be a good attribute for ORCHESTRA!

17. DI Gerald Schimak 17 ORCHESTRA – Book  Subscribe the SANY newsletter – to be informed and updated about the project progress, SANY events (up to the end of 2009) & SANY results SANY Project: www.sany-ip.euwww.sany-ip.eu  To read more about the value proposition, underlying concepts and technology, advantage of standards, building ORCHESTRA service networks and – applications. »a MUST have! www.eu-orchestra.org

18. DI Gerald Schimak 18 ORCHESTRA facts  Project start: September 2004  Finished: 29. February 2008  Budget: 13.75 M€ (funding 8.2 M€)  Contract type: Integrated Project