ࡱ>    '` bjbj$$FF&nrziii8i~j &kl":l:l:lAAAy{{{{{{$hb9nA@AAA:l:l111Af:ln:ly1Ay11W|X nϩ:lk :Wi͎ӨE40.B.$ϩϩ".rT!AA1AAAAA+AAAAAAA&&&5\ &&&\r First Meeting of the IODE Steering Group for the IODE Ocean Data Portal Oostende, Belgium 20-22 September 2010 ODP V.2. INTRODUCTION Purpose of the document This document provides the preliminary technical design decisions for the IODE/JCOMM Ocean Data Portal (ODP) v.2 and has the following purposes: provide a foundation of understanding and coordination of ongoing activity to establish the ODP v.2; describe the functional and other basic requirements for ODP v.2; propose the initial ODP v.2 architecture framework on the basis of ISO/OGC standards and taking into account the E2E data management technology possibilities and other existing initiatives through a series of viewpoints. 1. Introduction 1.1. Purpose of the document This document provides the preliminary technical design decisions for the IODE/JCOMM Ocean Data Portal (ODP) and has the following purposes: provide a foundation of understanding and coordination (both internal and external to IODE and JCOMM including WIGOS project) of ongoing activity to establish the ODP; describe the functional and other basic requirements for ODP; propose the initial ODP architecture framework on the basis of ISO/OGC standards and taking into account the E2E data management technology (see Annex A) possibilities and other existing initiatives through a series of viewpoints. 1.2. Document overview This document is structured in terms of the Reference Model for Open Distributed Processing (RMODP, ISO/IEC 10746) defining the overall conceptual framework for building the distributed data/processing systems. RM-ODP defines five standard viewpoints addressing different aspects of distributed system. A summary of the RM-ODP viewpoints concerning with IODE/JCOMM Ocean Data Portal is provided in Table 1: Table 1 RM-ODP for the Ocean Data Portal Viewpoint Name Description of Viewpoint as used hereinEnterpriseHigh-level vision of ODP focusing on goals, scope and policies of ODPInformationSemantic specifics of data and information which will be subjects of the ODP ComputationalFunctional decomposition of ODP into objects that will interact at interfacesEngineeringIdentification of ODP component types and preliminary technical requirements to support distributed interaction between the componentsTechnologyFocuses on the choice of technology.  It is necessary to remark that this document provides the initial ODP architectural decisions. The document does not consider Technology Viewpoint on ODP. The improvement of this document and Technology Viewpoint construction will be accomplished during implementation of the Ocean Data Portal Pilot Project. Within this document 2. The Data/Metadata Framework - Information Viewpoint The information viewpoint of the IODE/JCOMM Ocean Data Portal architecture is focused on semantic modeling of data and metadata which the ODP should integrate and distribute. In this section of the document a brief analysis of marine data specificity is discussed and also modeling approaches to the ODP data exchange framework are considered. 2.1. The semantic specifications of data and metadata The ODP will use and will make available on-line the wide spectrum of data and metadata. 2.1.1. Basic geographical data are the data that are commonly used to present the ODP marine (ocean, marine meteorological and etc.) data on the maps: Topography: data on earth surface; Coastline and bathymetry: data on topography of sea bottom. Administrative boundaries and features: spatial extent of countries, administrative units and their boundaries, towns and etc.; River systems: data on rivers and lakes Infrastructure: data such as ports, ship lanes, roads and railroads, etc. The list of basic geographical information types is not final and under the ODP Pilot Project a specialized technical specification on this geographical information should be prepared including layers and their identifications, projections and scales. These data should serve as the basis of the ODP GIS-server component accessible from the portal via OGC web-services (WFS, WMS and WCS). 2.1.2. Marine data have a number of properties which should be taken into account for the ODP development. Content. The ODP domain should cover oceanography and marine meteorology (main fields) and also other disciplines (biology, geology-geophysics, socio-economic etc. perspective fields). It is estimated, that the ODP will integrate data and information about 300-350 parameters. Representation. ODP tools should take into account that marine data can be presented as: structured al@ha-numeriA data sets (most of the ODP data); thematic spatial data (GIS files and other); images (satellite data and other images); documents (articles and methodical/technical documents). Production. There is a significant number of methods and tools that are used to produce data (platforms of observations, instruments of measurement, methods of computation and modeling) on the one hand, and on the other hand there is a large number of institutes, centres and etc. which produce data or(and) will provide data into the system. Processing level. The data can be classified into observation data, climate, analysis and forecast data. This classification is closely connected with the time period of updating of corresponding data sets. E.g., forecast data are updated daily, and climatic data - much less often. Storage system and format. The IODE Ocean Data Portal should not require data centres to re-format their data, should have tools to understand local data structures (DBMS tables, formats of data files) and translate the required data into the common transport data format or provide web-services to interact with local data systems. Data granularity. The ODP should provide description, query and transfer to users the required peaces of data sets on the basis of feature types and instances resulted from parameter (object) type, spatial/temporal extent and other agreed criteria. Data actuality. The IODE data sets are dynamic and are updated yearly, monthly or even hourly depending on the specificities of the centre activity. In view of this, the ODP should have a mechanism and tools to monitor the status and readiness of data sources, harvesting corresponded metadata as required. Access constraints. The IODE data sets can have constraints for data access and use. The ODP should have a mechanism and tools based on the ODP sharing principles to meet these constrains. Life cycle. The IODE data sets can be produced in various ways. Often an IODE NODC combines the existing data from other data centres to prepare the derived data set. To avoid data duplication and provide transparent understanding about the ODP distributed resources it is necessary to provide data life monitoring on the basis of the unique identification of data sets involved into the system, dates and origin of creation, modification and submission of data. 2.1.3. Metadata are traditionally used for data discovery to support the search by geospatial and temporal extents, parameter keywords and other characteristics. The IODE Ocean Data Portal will be based on the fully metadata-driving approach and metadata are a critical component of the ODP. In this connection, the ODP metadata should provide much greater functionality than data search and much wider scale of their application. Below the basic requirements to the ODP metadata are given: describe how the observation was made (platform, instruments and etc.) and product was generated (method, soft and etc.). Quality control metadata will be important to determine the data that can be used for the particular purposes. reflect the structure of the local data collection (hierarchy, data elements and etc.) and data storage (DBMS, file system, GIS) specifications, local code systems, units and naming of data elements. The ODP should use specific metadata about the local data structures and encoding to provide an access to non-homogenius data sets (desired peaces of data) that are needed; provide the data and service catalogues(registers) to search for data/services and also build the chains of extracting and processing services that meets user needs and requests; support the versioning and lineage of data presented in the ODP by data providers. The metadata should maintain reference information for the data - reference documentation, bibliographic references and citation of the data. Potentially the metadata framework should allow users of the archive to publish findings on the data; provide the data transport and assembly operations by the ODP for support of access to data from the ODP tools and enable time-defined transmission of data to users; support the identification and account information about the ODP users (it can be end-users and external systems, web applications or services) as needed for their authentication and authorization and also for the system reporting; . Additionally, to support machine-to-machine interoperability a distributed access to metadata should be as seamless as an access to the data itself. To facilitate the use of distributed data sources the metadata framework should provide a transparent access to all the metadata fields, including those required to operate with the data in a semantically meaningful way. 2.2. The data/metadata interoperability issues 2.2.1. The background An abstract framework for geographic data modeling has been proposed by ISO TC211 (ISO 19101), and the key element of this framework is a feature and derived from the feature coverage, map and observation. A feature is an object that represents a real phenomena about which data are collected, integrated, and disseminated. A geographical feature is a feature associated with the location on the Earth. Conceptual geographic feature modeling is provided by ISO19101 and ISO19109 and has two levels: instances and types. At the instance level, a geographic feature is represented as a discrete phenomenon that is associated with its geographic and temporal coordinates and may be portrayed by a particular graphic symbol. These individual feature instances are grouped into classes with common characteristics feature types. A catalogue of features is defined as the catalogue containing a set of feature instances for a specific feature type (ISO19110). Specific case of features is a coverage that is associated with positions within a bounded space (its spatial/temporal domain) to identify attribute values (its range). Examples include raster image, polygon overlay, or digital model data (matrix). Commonly used spatial/temporal domains include point sets, grids, collections of closed rectangles, and other collections of geometric objects. An observation is an event with a result which has a value describing some phenomenon. The observation event is modeled as a feature within the context of the ISO 19109. An observation uses a procedure to generate the attribute values of the feature instance, which may involve a sensor or observer, analytical procedure, simulation or other numerical process. A map is a portrayal of geographic information. While a map may be a digital image file suitable for display on a computer screen, it is not the data themselves. Geography Markup Language (GML, OGC) is standardized as ISO 19136 and provides reference XML schemas for a range of conceptual models from the above-mentioned and other ISO standards. A GML application schema describes the logical structure and semantic content of a dataset. Today, the desire to build marine regional or global distributed data systems, aggregating data from multiple sources is increasing. At the international level it is provided through activities of experts groups of IOC/IODE, WMO, GEOSS and at the European level - through the development of INSPIRE (MOTIVE project) and GMES. The MarineXML project that was an initiative under the governance of the IOC/IODE5 of UNESCO (funded by EC) should also be mentioned. This document does not intend to provide the comparative analysis of existing approaches to data modeling based on ISO/OGC standards. Below brief comments are given only for CSML (Climate Science Modeling Language, NERC UK,  HYPERLINK "http://ndg.nerc.ac.uk/csml" http://ndg.nerc.ac.uk/csml), WMO Core Metadata Standard ( HYPERLINK "http://www.wmo.int/pages/prog/www/WDM/Metadata/documents.html" http://www.wmo.int/pages/prog/www/WDM/Metadata/documents.html), MCP (Marine community profile, AODC,  HYPERLINK "http://marinemetadata.org/references/marineprofile19115" http://marinemetadata.org/references/marineprofile19115) and E2EDM (IODE/JCOMM ETDMP, Global XML Schema,  HYPERLINK "http://e2edm.meteo.ru/e2edm/files/resourcesmodule/@random4240448bb69c9/1204531805_E2EDMGlobal.xsd" http://e2edm.meteo.ru/e2edm/files/resourcesmodule/@random4240448bb69c9/1204531805_E2EDMGlobal.xsd), which can be considered as candidates for implementation of ODP information architecture. CSML has been designed for modeling various climate science data types fully based on ISO/OGC standards as well as to provide a wrapper mechanism to encapsulate the representation of those data objects in file based storage systems. CSML includes the agreed principles and definition of ocean/meteo-oriented generic feature types (Table 1). . Table 1. CSML feature types CSML feature typeDescription ExamplesTrajectoryFeatureDiscrete path in time and space of a platform or instrument. ships cruise track, aircrafts flight path PointFeatureSingle point measurementrain-gauge measurement ProfileFeatureSingle profile of some parameter along a directed line in spacewind sounding, XBT, CTD, radiosonde. GridFeatureSingle time-snapshot of a gridded field. gridded analysis fieldPointSeriesFeatureSeries of single datum measurementstide-gauge, rainfall time series ProfileSeriesFeatureSeries of profile-type measurements. vertical or scanning radar, shipborne ADCP, thermistor chain timeseries GridSeriesFeatureTime series of gridded parameter fields. numerical weather prediction, model, ocean general circulation  It should be noted that above-mentioned generic features types are compatible with generic data constructions (point, profile, grid) of E2E technology using to load the extracted data into NetCDF transport data file. WMO Metadata Standard provides a general mechanism for data search and exchange that should be applicable to a wide variety of WMO datasets.. The MCP (Marine Community Profile, AODC) is a subset of the 19115 standard and includes all ISO 19115 core metadata elements. In addition, the MCP has defined four new metadata elements and two new code tables. An XML encoding schema, based on ISO19139, has been developed to describe, validate and exchange MCP metadata. The CDI XML format provides the descriptions of distributed data sets managed by the SeaDataNet (EC project). The ISO19115 schema is used as a reference model for this metadata format. The ISO 19115 standard also provides the interoperability basis for a series of thematic catalogues organizations (UKMO), data sets (EDMED), Cruise Summary Reports (CRS). The E2EDM technology provides data integrity based on series of specifications: XML schemata, metadata and data records, data exchange protocol. These specifications were constructed on a single object-oriented resource model. The E2E technology realizes a mediator/wrapper mechanism to access to diverse local data systems without reprogramming and data reformatting. The wrapper (E2E Data Provider) is used to translate local data formats and codes to the common data model (transport data file structures based on NetCDF constructions) and system codes. The mediator (Integration Server) provides the metadata harvesting and system control functions (resources status and other). From information viewpoint the E2E technology is based on two XML-schemes. The E2E global XML Schema includes elements (more than 100) and element classes (27 classes) which are used to describe the properties (content, space-time characteristics, interfaces, etc.) of local data sets, users (external applications) and other E2EDM objects. This XML-scheme implementation resulted in 11 metadata records to support the discovery, access and use of the data from distributed data sources. The E2E global XML Schema is compatible with ISO 19115 and ISO 19115 has been extended to include additional classes to provide greater detail about marine data and to support the fully metadata driven approach of the E2EDM technology. The conceptual XML Schema comprises descriptions (names, types, etc.) of data elements (marine environment parameters and their derivatives such as mean values, extremes, etc.) that are managed by local data systems connected to the E2EDM system. The conceptual XML Schema can be extended (or replaced by the new one) without changing other components of the E2EDM technology. The Global XML Schema and Conceptual XML Schema are linked through the specific metadata record. As a result of the brief analysis the several outputs which play the important role in the ODP data interoperability are given below: 1. ISO (TC211) standards provide the geographical data model, mechanism and tools for integration, exchange and dissemination of diverse marine data. The way of establishing the ODP data exchange framework can consist of the development of ISO standards profile taking into account the specificity of marine data: XML application scheme (XML schemata for discipline/function categories of ODP), features type modeling and cataloging, specifications of data and metadata, etc. 2. The really operating marine information technology based on ISO/OGC standards does not exist so far and the development of such technology will take considerable time and need considerable funds, in addition close cooperation of developer groups representing various projects and organizations is necesary. 3. The use of ISO19115 standard in WIS, SeaDataNet and etc. shows, that a variety of ISO 19115 implementation practices (interpretation of the elements and classes, rules to fill metadata elements and etc.) is observed. It can create difficulties when the ODP will carry out requests for the data placed in other systems. 4. The specifics of data really managed by the IODE and JCOMM data centres consist in a wide variety of structures, formats and coding systems. The data centers have different levels of technical and technological infrastructure. And it not likely that in a short term the centers will provide XML encoded data/metadata according to the ISO/OGC interoperability arrangements. 2.2.2. The data interoperability principles As a result of Marine XML project several principles of XML-based framework for marine data exchange have been formulated. Below the principles of the ODP data exchange framework are given based on Marine XML outputs and taking into account the progress that was archived in the considered field in recent years. Principle 1. The ODP information architecture will be based on the ISO/OGC models and standards and it will be a long-term task of the ODP establishment. In a short-term scale the use of the E2E XML schema with additional mechanisms and means to provide the compatibility with WMO, MCP and SeaDataNet/ISO 19115 profiles is provided. Principle 2. The ODP should operate on fully-metadata approach. It means that all ODP operation processes should be supported by corresponding metadata. In this connection it is required to use metadata describing discovery, management and use of data. It is offered to use a single XML-scheme for encoding metadata records as it is made in the E2E technology, but on the other hand the approach using separate ISO19115/19136 XML-schemes should also be investigated. Principle 3. Feature types compatibility. The key aspect of the integrated marine data framework is a single feature model, as well as the structures for the feature cataloging and maintenance mechanism. The common generic feature types should be developed taking into account the CSML feature types and with collaboration of key marine organizations - IOC/IODE, WMO, IHO. Principle 5. The marine data interoperability arrangements should provide interchange not only via the spatial and text-based (structured ASCII data sets) marine data/metadata XML files. It is clear that the existing practices of the use of various formats, storage types and codes will continue. The ODP data exchange framework should provide a mediator/wrapper mechanism to encapsulate the representation of such data objects (binary files, DBMS tables and etc in different formats/codes) as it was proposed by the E2E technology and CSML. Principle 6. The standard dictionaries of phenomenon (parameters what was observed or calculated) and measurement units are required to provide data interchange. Also it is required to maintain the standardized metadata sets for organizations, geographical areas, instruments and methods, etc. The access to such accompanying information should be provided through the corresponding web-services. It is possible to offer, that the parameters, units, organizations and other dictionaries as well as tools to access and maintenance, which were developed under the SeaDataNet project and by BODC, will be adopted as the marine community standards. Principle 7. The ODP data interoperability standards should be evaluated and accepted according to IODE/JCOMM Standards Process. 3. The Services Framework - Computational Viewpoint The Computational Viewpoint specifies the services that support the syntactical and semantic interoperability between the high-level operational services for the IODE/JCOMM Ocean Data Portal. The ODP service oriented architecture shall place no restrictions on the granularity of a geospatial service that can be integrated. There can be exceptions in the services approach for provision of the mediator/wrapper mechanism, e.g., direct access to local data system, delivery of binary transport data files on requests and etc. Therefore, there are the two approaches for services classification. In the first, the service grain size can range from small (for example a component that must be combined with others to create a complete business process) to large (for example an application). It is envisaged to support two main categories of services (like as FedEO Pilot): Basic services are limited services running on the data/service providers local infrastructure and the ODP infrastructure. Basic services may be requested (ordered) via the Portal user interface, or from a composite service (or workflow). Composite services are services consisting of a combination of basic services or other composite services provided by one or many different service providers. Another way of dividing services into categories is related to the specific functions performed by the service based on ISO 3-tier model (figure 2). The top tier is the only one with which clients (people or systems) deal directly. It provides the interfaces to describe and use the services offered; The middle tier embodies all the business processes required to respond to requests issued by clients. The services in general embody everything from authentication to complex processing of data sets from various distributed data sources (repositories) and from generation of map views to statistical charts that the client gets back at the end of the process; The lower tier provides read and/or write access to data, whether it is data, accounting records, or catalogue entries stored in any of a dozen different types of registries.  SHAPE \* MERGEFORMAT  Figure 2 - ODP service classification based on the ISO 3-tier model The content for service categories considered below is not final and special technical specifications are required to prepare. 3.1. User interface services 1) End-user interface These services include the end-user interface components templates, logos and other web-forms for end-users of the ODP, also end-user interface adjustment respectively accessible data/services with filtering on criteria (geographic area, time period, and data processing level), data representation forms and etc. 2) external systems (applications) interface services Interactions with external systems (e,g, WIS, SeaDataNet) to provide the metadata(data) from or to the ODP with adjustment on data/services content and filtering, data delivery scheduling, data/metadata format representation and etc.. 3) Portrayal Services Provision of map, table, 2D, 3D -oriented representation of data, metadata about the data delivered. 3.2. Business Process Services: 1) Metadata services Interaction with thematic metadata repositories: codes, parameters, organization, geographical and other dictionaries, and their submission to other services (or services chains). 2) Processing services Provision of the statistical processing of the delivered data and interaction with models to generate value-added products. 3) Data services Decomposition of the request from end-user (or external system) on single requests respectively data/services providers, monitoring of access to distributed data/services, data aggregation from a various data/services providers. 4) AAA (authentication, authorization, accounting of users) services Users (end-users, external systems interacting with ODP) registration and management of their account records, identification and checking of a users role, presentation of information on the user through access to registration repository. 5) Registry services Management of services register, discovery to provide access to the services that operate on datasets and also other objects (ordering, data access and etc.). 6) Catalogue services Search the datasets or products within a distributed marine data system that meet specific search criteria such as time, geographic extent, temporal extent and etc. 7) Orchestration services Composition of basic and composite services using OASIS Business Process Execution Language BPEL2, typically from multiple service providers. The orchestration engine is the service used to execute the resulting composite services. 8) Monitoring services Adjustment of the services execution, access to the information on the data/services status on time scheduling and regularities of their use, ODP statistics, the logging information, measurement of an overall performance of services, etc. 3.3. Data Access Services On-line data access services provide access to distributed datasets through a series methods: URL or FTP (File Transfer Protocol); OGC Web Services for data delivery: Web Coverage Services WCS, Web Feature Services WFS and Web Map Services WMS; services for extraction data from local data systems (like as E2E Data Provider). 4. The Components Types - Engineering Viewpoint The Engineering Viewpoint identifies of component types to support distributed interaction between the components. The components interact based on the services identified in the Computational Viewpoint. Figure 3 provides a summary of the component types organized consistent with the Service Tiers identified in the Computational Viewpoint.  SHAPE \* MERGEFORMAT  Figure 3 ODP components types 4.1. ODP Web-site The IODE/JCOMM Ocean Data Portal web-site provides: information on the ODP project (including the documentation currently included in the E2EDM); assistance users in how to use ODP and how to become ODP data/services providers; link to ODP web-portal. The ODP web-site with link to ODP prototype is available at address:  HYPERLINK "http://www.oceandataportal.org" www.oceandataportal.org 4.2. Web Portal Server Data portal typically is single point of access to the data and services of distributed data system. The ODP Web Portal Server contains a number of services and solutions to search and discover data/services by users, provide data visualization, news and other relevant information to the user community. Portal also provides administrative functions for data/services providers and users using User (end-users, external systems) Catalogue and their account information. The ODP will include the services to define the specific user interface profiles (visible web-forms content, map, accessible data and services, etc.) which will be stored in User Interface Repositories. It is planned that these mechanism and tools will provide the ODP views on requirements of various user groups. 4.3. Workflow Engine The core of the ODP is the Workflow Engine that is the component executing the workflows within a Service-Oriented Architecture. It executes business processes based on the Business Process Execution Language for Web Services (BPEL) standard. The workflow engine provides the management of services chains scenarios through the preparation, up-dating and storing its for workflow persistency. 4.4. Integration Server The Integration Server is intended for management of processes of data exchange and data delivery for Web-Portal Server operations including the exchange with external systems (applications) via services or access to corresponded metadata. The operational data submitted by data providers will be cached basing on rules and time scheduling of corresponding User Interfaces. The Integration Server carries out the maintenance of repositories about distributed data/services and interacts with services of Metadata/Data/GIS Service Providers to realize the user requests coming from User Interfaces layer and also represents the needed information about distributed data sources status ant ancillary metadata and other information for other ODP components. The Integration Server provides the management of thematic metadata (organizations, platforms, methods and etc.) and system metadata codes lists/dictionaries for parameters and other objects, for the data unification processes and other needs. These metadata will be stored in special repositories and metadata actuality will be provided by means interaction with external metadata repositories adopted as standards for ODP. The Integration Server provides the ability to perform distributed search of remote catalogues supported external systems (WIS, SeaDataNet, etc.), harvesting and caching metadata from distributed catalogues of external systems and local data systems. Two anticipated capabilities for access to remote catalogues may include: Distributed search approach: search requests are sent to registered distributed catalogues. For these catalogues the only address for the distributed catalogue is stored in the Service Registry or Data Catalogue. Harvested approach: The Integration Server periodically harvests all metadata from registered distributed catalogues. A user search request is executed against the metadata harvested from the remote catalogues. The Integration Server provides the preparation and representation of ODP data catalogues for access by external systems as it is certain in the corresponding user interface (see, User Interfaces layer). 4.5. Processing Server The Processing Server is intended for maintenance the mathematical (statistical) libraries to provide the preparing the value-added product basin on delivered data. 4.6. GIS Server The GIS Server provides the services corresponded with representation the geographical and thematic data on maps. The following basic functionalities are planned for provide these capabilities: Creation of the thematic geographical information in vector and raster formats using marine data (water temperature, waves, currents, etc.). Operational (real-time) data should be transformed in geographical data by corresponding services of GIS-server; Management of internal geographical data base containing basic (coastal line, country and administrative boundaries, ports, rivers and others features as it is specified in section 3.1.1.) and thematic geographical data, and maintenance of the Feature Catalogues; Interaction with external servers of geographical data (it can be directly through OGC web-services or through Integration Server) for access to geographical data (maps, coverage, features); maintenance of the end-user client through use of the applets downloaded from the GIS Server to present a graphical user interface to the user The GIS Server in the domain of OGC interoperability are related to the use of Web Map Services (WMS) Web Feature Services (WFS) and Web Coverage Services (WCS). Unlike Web Mapping services, which are about publishing "maps", Web Feature and Web Coverage services allow for sharing the geospatial data itself. Web Features services publish geographic features that contain "geometry" (represented by points, lines or polygons), while Web Coverage services give access to grid-like data such as imagery, scanned maps and digital elevation data. End-users will be able to access the information directly via WFS/WMS/WCS-compliant GIS clients. Most GIS software vendors are currently adding this functionality to their packages, this means that end-users can use their traditional GIS software to work with ODP service results, without having to download and convert the data. 4.7. Monitoring Server This component provides the accumulation and representations of the information on the data/services status, ODP statistics, the logging information, etc. 4.8. Data Access Components 4.8.1. Metadata Access Services Web-services to access semantic metadata parameters, units, platforms, organizations, from external repositories. Services and content registered in catalogs to support discovery and access. 4.8.2. Data Access Services Web-services to access the databases, file systems and other data repositories basing on wrapper mechanism or direct loading the XML data files. Services and content registered in catalogs to support discovery and access. 4.8.3. GIS Access Services Services to access geographical data as features, coverage, and maps - WMS, WFS, WCS, SOS, other. Services and content registered in catalogs to support discovery. 5. The Components realization - Technological Viewpoint This viewpoint specifies the technological choices and the standards selected for the IODE/JCOMM Ocean Data Portal architecture and the operational issues of its infrastructure. 5.1. Platforms 5.1.1. W3C Web Services The execution context of the W3C Web Services Platform is defined by the following properties: Transport Protocol and Message Format: SOAP 1.2 HTTP binding as defined in SOAP Part 1: Message Framework, Version 1.2 and Hypertext Transfer Protocol (HTTP), Version 1.1. The message style that shall be used is document/literal non-wrapped since it is the most widely accepted and interoperable message style. Security Session Information: The transport of session information may be accomplished by using platform specific mechanisms, for example the inclusion of a session key in the SOAP header. Encryption: Optional encryption of SOAP messages shall be accomplished by Web Services Security: 4 SOAP Message Security 1.1. 5.1.2. GeoNetwork GeoNetwork opensource is a catalog application to manage spatially referenced resources. Native support for ISO19115/ISO19119/ISO19139/ISO19110 and ISO Profiles, FGDC and Dublin Core formatted metadata. Scheduled harvesting and synchronization of metadata between distributed catalogues (GeoNetwork, CSW, Z39.50, OGC WxS, WebDav, Thredds, Local filesystem, OAI-PMH). Support CSW 2.0.2 ISO Profile, OAI-PMH, Z39.50 protocols Within ODP v.2 GeoNetwork should be used to populate metadata into the other related systems and provide the following return metadata flow. 5.1.3. Thredds The THREDDS Data Server (TDS) is a web server that provides metadata and data access for scientific datasets, using OPeNDAP, OGC WMS and WCS, HTTP, and other remote data access protocols. THREDDS usage in ODP is aimed to provide on-fly NetCDF publishing, OGC-service creation, on-fly graph and maps creation, sub-queries etc. 5.2. ODP v.2 components 5.2.1. Web Portal Server Application Server JBoss Language Java 5.2.2. Portayal services JBoss Portal engine 5.2.3. AAA Application Server JBoss Language Java Authorization and authentication technology JAAS, SSO 5.2.4. Workflow engine Language BPEL (Business Process Execution Language) Language Java Application server JBoss Web-services catalogue - UDDI Communication level SOAP Service interface description - WSDL 5.2.5. GIS Server GeoServer 5.2.6. Data Service Provider ODP Data Provider software 5.2.7 Metadata Service Provider ODP Data Provider, GeoNetwork     PAGE  PAGE 12 Registry Services Data Services Processing Services AAA Services Metadata Services Business Process: - Provide the authentication, authorization, accounting of users - Provide the process (parsing and etc.) and transferring the requests from User Interface level to low layer - Support the business rules to provide the requests, data combining/processing etc. Portrayal Services End-User Interface User Interfaces: - Provide and represent the information to users (external systems and end-users); - Users interact with this layer only; - End-user web-forms to data query and required data representation on maps (tables, plots), data samples saving on the user side, - Search/delivery mechanism via response/request protocol. Catalogue Services Data Access: - Provide the access to data repositories such as DBMS, structured data files, object data files - provide the extraction data from local data system and delivery data to Business Processing level. - Search/delivery mechanism via services interactions and response/request protocol. Data Access Services Orchestration Services Monitoring Services External system (application) Interaction Services User Interfaces ODP web-site Web Portal Server AAA Manager Interface Manager Business Process Workflow Engine Scenarios Catalogue Scenarios Repository Integration Server Services Register atalogue Data Catalogue Users Catalogue Interfaces Catalogue GIS - Server Feature Catalogue ODP Geo database Portrayal Tools Ancillary Tools Monitoring Server Object Catalogue Metrics data base Data Access Metadata (semantic) Service Provider Data Service Provider GIS Service Provider Portal profiles Catalogue Processing Server qr a \]ghz±±±£{bL5b5-h|4hZB*OJQJ^JaJmH phsH +h|4hZ5CJOJQJ^JaJmH sH 0h|4hZ5B*OJQJ^JaJmH phsH -h|4hZB*OJQJ^JaJmH phsH  h|4hZCJOJQJ^JaJh|4hZ5OJQJ^J h|4hjCJOJQJ^JaJ h|4hIYCJOJQJ^JaJ$h|4h ]5B*OJQJ^Jphh|4hc9OJQJ^Jh|4hgOJQJ^JHqr3 s$ 8X (#$@x]a$gdZ 8X (#$@x]gdZ$ & F ,x]^`a$gdIY$ X x]a$gdIY$ 8X (#$@x]a$gdIY$a$gdgd$x`a$gd   x ! ` I a $4\$x$Ifa$gdEl $xa$gdZ $x]a$gdZ$ & F ,x]^`a$gdZ$ X x]a$gdZ \]hiTx$IfgdEl$x$Ifa$gdEl}kd$$Ifl0(4 t0644 laytEz{}    hitu+-./0f{|}켦ռՏռռՏՏ~m~\ h|4h\CJOJQJ^JaJ h|4h6[ CJOJQJ^JaJ h|4hZCJOJQJ^JaJ-h|4hZB*OJQJ^JaJmH phsH +h|4hZ5CJOJQJ^JaJmH sH 0h|4hZ5B*OJQJ^JaJmH phsH -h|4hZB*OJQJ^JaJmH phsH %h|4hZB*OJQJ^JaJph! iTx$IfgdEl$x$Ifa$gdEl}kde$$Ifl0(4 t0644 laytE  hiTx$IfgdEl$x$Ifa$gdEl}kd$$Ifl0(4 t0644 laytEhiuiTx$IfgdEl$x$Ifa$gdEl}kd/$$Ifl0(4 t0644 laytE.iTx$IfgdEl$x$Ifa$gdEl}kd$$Ifl0(4 t0644 laytE./0|} CwiidZSxgd\ $xa$gd\gd\ $x]a$gdZ $xa$gdZ}kd$$Ifl0(4 t0644 laytE}C6W7B"3>XпЕ~ЕlZl~C~lZll,h|4hECJOJPJQJ^JaJnHtH#h|4h\6CJOJQJ^JaJ#h|4h\5CJOJQJ^JaJ,h|4h\CJOJPJQJ^JaJnHtH(h|4h\CJOJQJ^JaJmH sH )h|4h\B*CJOJQJ^JaJph h|4h\CJOJQJ^JaJ1h|4h\B*CJOJQJ^JaJmH phsH ,h|4h\5B*OJQJ^JmH phsH C6[Bb"> ! $xa$gd\ $x]a$gd\$ & F ,x]^`a$gd\xgd\$x7$8$H$a$gd\XY !!x""G$H$W$[$\$2&:&'';(*9+s+--..11.3<344P688ܵppppܜp,h|4h\CJOJPJQJ^JaJnHtH(h|4h\CJOJQJ^JaJmH sH 1h|4h\B*CJOJQJ^JaJmH phsH )h|4h\B*CJOJQJ^JaJph#h|4h\5CJOJQJ^JaJ h|4h\CJOJQJ^JaJ#h|4h\6CJOJQJ^JaJ$!x"G$2&'(J)*9+#,---.1.34;5P68;$x7$8$H$a$gd\ x7$8$H$gd\ $xa$gd\$ & F ,x]^`a$gd\xgd\ $xa$gd\88&9'9(9B9C9b9c9999999:::\:]:^::::::8;ͯxgIg;jh|4h\CJOJPJQJU^JaJnHtH h|4h\CJOJQJ^JaJ;jWh|4h\CJOJPJQJU^JaJnHtH0h|4h\0JCJOJPJQJ^JaJnHtH;j^h|4h\CJOJPJQJU^JaJnHtH,h|4h\CJOJPJQJ^JaJnHtH5jh|4h\CJOJPJQJU^JaJnHtH8;9;:;;;;;P=Q=n=o==x@@ƭƖ~gZgH7 h|4h\CJOJQJ^JaJ#h|4h\5CJOJQJ^JaJh|4h\OJQJ^J,h|4h\CJOJPJQJ^JaJnHtH/h|4h\5CJOJPJQJ^JaJnHtH,h|4h\CJOJPJQJ^JaJnHtH0h|4h\0JCJOJPJQJ^JaJnHtH5jh|4h\CJOJPJQJU^JaJnHtH;jIh|4h\CJOJPJQJU^JaJnHtH ;P=Q=[=n=o=====$$Ifa$gdEl4$a$gd\$a$gd\ 7$8$H$gd\$x7$8$H$a$gd\ ====>mZZZ$IfgdElkd^$$Ifl4F| (#   t06    44 la<ytE>>#><>S>T>n[[[[$IfgdElkd$$IflF| (#   t06    44 la<ytET>U>d>>>>n[[[[$IfgdElkda $$IflF| (#   t06    44 la<ytE>>>??n[[[$IfgdElkd $$IflF| (#   t06    44 la<ytE??.?R?s?t?n[[[[$IfgdElkda $$IflF| (#   t06    44 la<ytEt?u?????n[[[[$IfgdElkd $$IflF| (#   t06    44 la<ytE?? @6@7@w@n[[[[$IfgdElkda $$IflF| (#   t06    44 la<ytEw@x@y@TAA%CDneeWI:$dxa$gd\$x7$8$H$a$gd\ $ pxa$gd\ 7$8$H$gd\kd $$IflF| (#   t06    44 la<ytE@@TAiAsAAAA%C7CzCCDDҼ}eS}B}'4h|4h\5B*CJOJQJ^JaJmH phsH  h|4hECJOJQJ^JaJ#h|4h\5CJOJQJ^JaJ/h|4h\5CJOJPJQJ^JaJnHtH h|4h\CJOJQJ^JaJ0h|4h\CJOJQJ^JaJmH nH sH tH (h|4h\CJOJQJ^JaJmH sH +h|4h\5CJOJQJ^JaJmH sH ,h|4h\CJOJPJQJ^JaJnHtH,h|4hECJOJPJQJ^JaJnHtH DDqEEF!FGG#I$IAI_IJJK@RARѺ{jYj@Y@j+)h|4h\B*CJOJQJ^JaJph1h|4h\B*CJOJQJ^JaJnHphtH h|4hECJOJQJ^JaJ h|4h\CJOJQJ^JaJ%h|4h\B*OJQJ^JaJph(h|4h\B*OJQJ\^JaJph-h|4h\B*OJQJ^JaJnHphtH-h|4h\B*OJQJ^JaJmH phsH (h|4h\CJOJQJ^JaJmH sH 1h|4h\B*CJOJQJ^JaJmH phsH DqEGJKKrLONOP@RnRSTVAXcZ\o]$x7$8$H$a$gd\$x]`a$gd\$x7$8$H$]`a$gd\$x]`a$gd\ $xa$gd\ARnRSSTUVVX+XAXMXcZoZ\\\o]]]]^>^aϷϷϷϠϷϷϷϏlVl@l+h|4hECJOJQJ]^JaJmH sH +h|4hECJOJQJ\^JaJmH sH (h|4hECJOJQJ^JaJmH sH h|4hE5OJQJ^J h|4h\CJOJQJ^JaJ,h|4hv-VCJOJPJQJ^JaJnHtH/h|4h\5CJOJPJQJ^JaJnHtH,h|4h\CJOJPJQJ^JaJnHtH1h|4h\B*CJOJQJ^JaJmH phsH o]]_abb8cc;eefKfLfffg $ex^ea$gdExgdE$a$gdEgdE$ & F ,x]^`a$gdE $ & F ,x]^`a$gdE $xa$gdE 8X (#$@x]gdEaaaua|atbb8ceeffffffffѺѺ}l}U@}l."hCJOJQJ^JaJmH sH )ja h|4hEOJQJU^JmH sH ,jh|4hEOJQJU^JmHnHu h|4hEOJQJ^JmH sH )jh|4hEOJQJU^JmH sH  h|4hECJOJQJ^JaJ,h|4hv-VCJOJPJQJ^JaJnHtH,h|4hECJOJPJQJ^JaJnHtH(h|4hECJOJQJ^JaJmH sH 1h|4hEB*CJOJQJ^JaJmH phsH fffffggggh/h ? @ Y Z [ r s t            Ʊ)hFhFB*CJOJQJ^JaJphh8UhMFh@GCJaJh@GCJaJ hYh@Gh@G5CJaJh@GhVS)h@G5CJaJ+Οϟ  $ % ? @ Z [ s t         $a$gd@'$a$gdEgdETools Catalogue Processing tools Portal profiles Catalogue Portal profiles Catalogue Users info repository Other Tools Dictionaries Interfaces Repository ,1h. A!"R#n$n% za3x!tV$d( c$$If!vh5(54#v(#v4:Vl t65(54ytEc$$If!vh5(54#v(#v4:Vl t65(54ytEc$$If!vh5(54#v(#v4:Vl t65(54ytEc$$If!vh5(54#v(#v4:Vl t65(54ytEc$$If!vh5(54#v(#v4:Vl t65(54ytEc$$If!vh5(54#v(#v4:Vl t65(54ytEDyK http://ndg.nerc.ac.uk/csmlyK Nhttp://ndg.nerc.ac.uk/csmlyX;H,]ą'cDyK >http://www.wmo.int/pages/prog/www/WDM/Metadata/documents.htmlyK http://www.wmo.int/pages/prog/www/WDM/Metadata/documents.htmlyX;H,]ą'cmDyK 8http://marinemetadata.org/references/marineprofile19115yK http://marinemetadata.org/references/marineprofile19115yX;H,]ą'cDyK bhttp://e2edm.meteo.ru/e2edm/files/resourcesmodule/@random4240448bb69c9/1204531805_E2EDMGlobal.xsdyK http://e2edm.meteo.ru/e2edm/files/resourcesmodule/@random4240448bb69c9/1204531805_E2EDMGlobal.xsdyX;H,]ą'c$$If<!vh5 5 5 #v #v #v :Vl4 t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytE~$$If<!vh5 5 5 #v #v #v :Vl t65 5 5 a<ytEDd -D  3 @@"?DdD%&D  3 @@"?DyK www.oceandataportal.orgyK Xhttp://www.oceandataportal.org/yX;H,]ą'cR@R F1KG=K9$CJOJPJQJ_HaJmH sH tH BA@B A=>2=>9 H@8DB 0170F0Xi@X 1KG=0O B01;8F04 l4a .k@. 5B A?8A:0^B@^ ZA=>2=>9 B5:AB!B*CJOJPJQJmH phsH t@t Z !5B:0 B01;8FK7:V0PJ:U@: \ 8?5@AAK;:0 >*B*phVO"V \Default 7$8$H$!B*CJ_HaJmHphsHtHZP@2Z \A=>2=>9 B5:AB 2 dxOJPJQJnHtH>'A> \=0: ?@8<5G0=8OCJaJ\@R\ \"5:AB ?@8<5G0=8OCJOJPJQJaJmH sH JbJ \ "5:AB 2K=>A:8CJOJQJ^JaJJ @rJ f86=89 :>;>=B8BC;  E$4)@4 f><5@ AB@0=8FK#8GZs1G_t#:Qf);N[ $?XetWVUTSRNMLXZ[^_` !"#$%'()*+,-.012346789:;<=>@ABCDEFGH#8GZs1G_t#:Qf);N[ $?Xet      !"#$%&'()*+,-./0123  "& "& "& "& "& "& "& "& "& "& "& "& "& "&0 ;$M4;]KZ^4hkqyaLN2j_ Hqr3x!`Ia$4\]h  hiu . / 0 | } C 6 [ B.\;uD/G !6" #$$$%(+*+8,M-/2M4N4X4k4l4~444444455 595P5Q5R5a555555666+6O6p6q6r666666 73747t7u7v7Q88":;n<> ABBoCLEFG=IkIJKM>O`QSlTTVXXY5ZZ8\\]H]I]]]]<_t_``w```aaa]bpbYccddGe_ef"f g'gh4hhh0iiiikk,k-kMkakkkIlbll mn p9pqqWstvwxqy>zWzz{{|}'GFdGdEa@xyFhpq89Iݍ%@PՎ9^pzҏ*8:O^qŐ3đ@Ē&H^vДޔ(:Q\h}Օ ,@Rerʖ̖ ;Vo|$$$$$s$s$s$p5$G$$$s$s$p5$G$$s$s$sPs\s)Ps\sPs\sPs\sPs\s,Ps\s)$s$s$s$$s$s$s$s$G$G$p5$G$G$s$s$s$s$G$G$G$G$s$s$s$s$s$s$s$s$$ $$s $p5$$s$s$s$s $s$s$s$s$s$s $s$s$$$$v:H v:H v: v:Uv:H v: v:ev:H v: v: v:Uv:H v: v: v:xv:H v: v:ev:H v: v: v: v:H v: v: v: v:H v:H v: v: $s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$$s$s$$p5$s$p5$ $p5$7_$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$G$p5$G$s$s$s$$_W$$s$s$s$ $G$G$s$s$s$s$s$s$s$s$s$s$s$$$s$s$s$s$s$I$s $s $s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$G$G$s$G$s$G$G$G$s$$$$$$$s$s$s$s$s$s $E$E$qEEEjjjjEEjjjjj}ENjNjNjNjI E#EE EE$EEq \ q jEjE[ EHHHEHHH H EHHHCECE\ EHBHEEEEEEESUH EHHUHUHpHDEH HHqr3x!`Ia$4\]h  hiu . / 0 | } C 6 [ B.\;uD/G !6" #$$$%(+*+8,M-/2M4N4X4k4l4~444444455 595P5Q5R5a555555666+6O6p6q6r666666 73747t7u7v7Q88":;n<> ABBoCLEFG=IkIJKM>O`QSlTTVXXY5ZZ8\\]H]I]]]]<_t_``w```aaa]bpbYccddGe_ef"f g'gh4hhh0iiiikk,k-kMkakkkIlbll mn p9pqqWstvwxqy>zWzz{{|}'GFdGdEa@xyFhpq89Iݍ%@PՎ9^pzҏ)*89:NO]^pqŐ3đ@Ē&GH]^uvϔДݔޔ'(9:PQ\gh|}ԕՕ +,?@QRdeqrɖʖ˖̖  :;UVno{|0000000 0 0 0000 0 0 00000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00000000 0 0 0 0  0 0000 0  0  0  000000000 0 0 0 0 0 000000000000000000 00 0 0 0 0 0 0 0 0 00 0 0 0 00 0 0 0 0 0 0 0 00 0 0 0 00 0 0 00 0 0 00000000000000000000000000 0 00 0 0 0000000000000000000000000000000 0 0 0000000000 0 0 000000000000 0  0!00000 0" 0# 0$000000000000000000000000000000000000000000000 0 00 00 0 0 00 0 0 0 0 0 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000Hqr3YccddGe_ef"f g'gh4hh0iiikk,k-kMkakkkIlbll mn p9pqqvwxqy>zWzz{{|}'GFdGdEa@hp89I%@PՎ9^*:O^qhr̖Z00bZ00` 0Z00 VZ00Z00@0*J0`0@0@0@0@ 0@0@ 0@0@ 0@0@0J00 J0k0"l~J0k0!@0J0#0J0o0%J0o0#J0#0J0#0J0#0@0aB00 (B00 B00 B00 B00 @0aJ00 B00 @0aB00@0aB0"0B0,0-B0,0B0,0B0-0@0aB0%0)@0aB020B040B040B040B0506(B0,0@0a@0J0)0)J0+0+,xJ0<0J0+0+J0<0J0+0+0>0?|rJ0#00?000B0Cr0B00B00000H0Is00I0000M0Nڀ0M00M0@0x@0x@0@ 0@ 0@ 0@ 0@ 0@ 0@ 00@0@0@0@0@0@0@0@0@0J0 0 ,YJ00`J00 | J00 J004J001J00  0 %%%(z}X88;@DARaf%o,tT>>?t??w@Do]gpdtt Ο QSTVWXYZ\^abcdefghilnqsuwx{}~ R/$0?0_0001Z111622\\]k'k*klllXXXX__X !(!!l`a,r$3x!tV$di.@JG`(  F  '$$ 3  s"*?  DX99A?10%"  '$$H  #  e'#N  3 Ԕ. R>'WN  3 Ԕ> M %Dz   3  C"?H %  ` ! C ! i  ` " C " i !  ` # C #$  ` $ C $ ! z % 3 %C"?#&B Z   &  `` ' C '  z ( 3 (C"?> |m z ) 3 )C"?| ` * C *3`# z + 3 +C"?w z , 3 ,C"?rw z - 3 -C"?3 b z . 3 .C"?  Z >' / 9&I` 0 C 0>' z 1 3 1C"?H|x" z 2 3  2C"?"|&  ` 3 C !3 % !` 4 C "4 %( "t 9 5# #" I` 6 C #69 #z 7 3 $7C"?C|r $z 8 3 %8C"?| %z 9 3 &9C"?B$J'! &` : C ': s # '` ; C (;s # (` < C )<s ## )z = 3 *=C"?9   *z > 3 +>C"?i! +t 9 ?# #"  3I` @ C ,@9 ,z A 3 -AC"?C|r -z B 3 .BC"?| .z C 3 /CC"?vG" /z D 3 0DC"?X (# 0z E 3 1EC"?3r# 1` F C 2F (& 2z G 3 3GC"?) w 3z H 3 4HC"?u[ 4b   M 'N' I3  s"*?` J c $X99? M 'N'4 K  ?'z L 3  LC"?[ '  ` M C Mv  ` N C NC) H2 O # 6N2 P 3 H6i!4 Q  >'Iz R 3 RC"?MR)' ` S C SC ` T C T-`  ` U C US ` V C V  ` W C W- ` X C  Xr-=  4 Y  @'%z Z 3  ZC"?e&#  ` [ C  [3#2%  H2 \ # IN2 ] 3 I!` ^ C  ^x">'  ` _ C _-&z ` ` C `& B S  ?](kID%&t D%(#t Q[..4 44455R5`555556*6r666666666 748:8w::==yFFFFHHKKSSWX____w w  #-@CEKMT\fċ@GČ6<׍܍ :?pyrz`g0lt;Uu/7!G N 6"="%%N4V47788::<<EEJJKKMMMM>OJO`QlQQSZSSS?_G___a[bpbVcc ddEe"ffxhh0i8iiiIlMl\_a…FJhnΊq:OQ[ӕ Vb::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::HqrIa$4]h iu f } DKN445a5556+6O666 7=IDIlTT]]``h4hiiMkakl m p9pqq>zWzz{FkGNELrՎ(*8:MO\H\^tΔДܔޔ&(8:OQfh{}ӕՕ *,>@PRceprȖ̖  9;TVmoz|'6)*9:NO]^pq ^#)A3zf( q&M*>Ss@Say\fzG>OtQ&h^`OJQJo(hHhee^e`OJQJ^Jo(hHoh5 5 ^5 `OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHhuu^u`OJQJo(hHhEE^E`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh,,^,`OJQJo(hH-h dd^d`o(hH.h4 4 ^4 `OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHhtt^t`OJQJo(hHhDD^D`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH ^#Ss@S3zf(G>Oty\q&M         "$Z.wg.ON^)JT``nqWsz'b,/3hGUr}` "#*,@EHWZ7o{q Q)~=R>W[ cMpt s:KCZ`nz{ A(10 >L?IRW^i1lA$X&3c9 W ] Q$(08j:<[C[DYw]iis f!' 7DuI[| ! \" ( 9 E _ h i m j . 3 4 )5 W j t ox U & X O: : > bG `J 6[ n    ; " m( *- i- +6 ^_ y , % <& . E3 = P )\ \ b m>L^l9zh%%;WX8n%?HlTXgi~q|)(!$BO\_r 8  G*?Xg{iZqrsRw!N6=BV|dV`/30L14KEN |/ 0V[3~8Y9<\c@iikJi  4[y_&4^9HLUPWS|=DH^}?EoS.VOaj!P+53FTMfckL$%'6N!jnp~# (Mex0.l7oNT}^CNRTfvxa|c# < B 4G m 9| %!!'!K)!E@!" "A"D"K"LL"p"###J##&&#H*#l,#n=#J#*fD*dI*U*c*i*2z*0}*L+ +1$+)+I,+d+ ,,Y!,h3,:,?Y,;k,{,t--!-)-g9-E-3R-%W- ...]".Q2."9.<.M.R.%c.jn.// /#/#/}%/#'/W/rz/0c0 020 X0&`06w0_1 1y;1U1d122 22'2,252<2>2Y@2Y2Ie2~2*N3a3d3g3o3Tw3I4444|44;)4:34N4`4^f4j4k45"75E5HI5P5\5h5t5?6C6a$64686@6LY6c6i6i67 77"7P;7<7rG7-8t 8180838P8Q8 U8U8 9K99I9.9}19 ;9@9\9 `9`9m96~9:: :A:D:,P:f:ii:~:`;;; ;0;q;/~;<\?<V<"f<pk<r<"s< = ===/=0=U=b=> >^ >\>L>I>3>?>`>jc>?? ? ??? ?5?7?:?G?dN?V?`?j?Sy?@@TK@Y@ i@Xm@Jt@Ty@AA-AR.A B^ B,#B 2B7B7>B|KB#cBoB[pBIqBCC#C8C9C2jCmwCDP*DaD uDaE["E%E8E AEnEiEiWi'`ivijE&je2jajrhjk,k-k$1kBkx_k{kl@l@lDlqOl[lm0mHm/Mmz[m`mbmmmnn@}\}~<~~P!~$~6~8~Q?~6A~G~O~a~S~~b,+0)40NO Qk8vTz 5fCn~nEEeop: t +,6yKWNbL"#/)|48E^IM&RR]^d}Oqsr_ 111'7!HkHhUjv ;4;PDH[IJS8[ds^x|&f;n@CN\ _hir0/ `h$ F"W|]B 1<.@@9QUcs"y'FJ!v#-11FUbt[7X-9_.tpx .oDrP}A+RrSVd CNrl} %/8^C7cc hMgi^v'.2"?_l~!(;A2LwOIVZi %(LfVqyvMV)K-K Uo|.g0qc:pru/#Z*W6KHPbt>y $QRdy182JY\b]$ko g-+03X|cQg "(t69kAQUsrt4J>d@iEJQ@py|>sO,v25_cckoq~G&+g89ULZss #9+4:+>KReszg~8=?CEYN2PT Z]]bqdZ Y HSX,YiXto ,04<=BV{koOs}=?dA.I~OPzxf"6C#Zj}q7M[ceCoe|2 /4F5S78RBNgXll3'>\Ihady= 5"(+.2019P!azb ev}#0#EF;AMoau Pj+3FJ-mP "$k ?o|~P B/SV` "]// %_0?Bv y:,\0vv$=-.6A[akyz."?e4K#Yeey{M `[5chsM->DFJZ]%p}-qMNW\ } "+29f@HZ_oR \%*4NoqJ< ? 7GH\]oqt\=FPUb  B'v\u@{ZV^a_ /)6,:: = GGNh.zA)_s^vFi u 9)F e}pDst]|pQX<[5:\L^jaqTc$<BEMv[, e j2 3SY]_."?1CCdhkPz'"m,$59>ea8&GN[gy|$9<IgW"Y#aku 9!+s?CRi[j .v0H8InK^jb=t#1InUo|:Ze 41$:WblTn"| !1-.p9IAHLX_#o,t~[G (*Q2_?OU6`|!$5N]|gkhn/=%JPw,%N-Pmer k#*n;bh"m"  N D+@%AAV[uN|B !j&J-APHUu`J NST7WovQ54<;W\g!?&3Gfn}0OZ]7_@ j$<Zz|#: AHMp` \;EAg;x"{3}}-@CJGl_"T()?KSud!x*Z,HHQ^Zw{;k1Tbqy $.=t>@Wivx .6?XAyE]IhIQq!,0-10?e X (2v>DXm9,=8= ]_ab1l y k_ !-2d2>;'AC P`Xxx}zJ$WWjiq>`Mqt%d?Y\fxj&::['IY)j{:`H&DVqu;1DQQ]p QPSJoCS4$66S=IXLYMf~~2&A2c7DO%nKuAz &1=U:VpZc.}5f7-AB0X`Dixz{ YL04c8Lvlnnv3q5:lEEHQkP}?l6vwR ,KPRM^dt%2D`_$M;fglxKjl|-!13 W\Yxg/. 359 ;vEWg1>GSW-anxrIa$4\]h  hiu . / $N4X4l4~44444455 595Q5R5a55555666+6O6q6r66666 747t7u7Q88x%^)89'9Pg|ԕɖ˖  :;3%0}x0Im]?0Imq ))@g4@8@@UnknownG:Ax Times New Roman5Symbol3& :Cx Arial7K@Cambria;(SimSun[SO5& :[`)Tahoma?5 :Cx Courier New;Wingdings"qh馍 V{uzI{uzI!n>4 3qHP ?gGFirst Meeting of the IODE Steering Group for the IODE Ocean Data PortalAdminAdmin$      Oh+'0, <H h t HFirst Meeting of the IODE Steering Group for the IODE Ocean Data PortalAdminNormalAdmin9Microsoft Office Word@=@@T0V@õW{uz՜.+,D՜.+,x4 hp|  I' HFirst Meeting of the IODE Steering Group for the IODE Ocean Data Portal  x 8@ _PID_HLINKSA0}0 http://www.oceandataportal.org/lu bhttp://e2edm.meteo.ru/e2edm/files/resourcesmodule/@random4240448bb69c9/1204531805_E2EDMGlobal.xsd??8http://marinemetadata.org/references/marineprofile19115>http://www.wmo.int/pages/prog/www/WDM/Metadata/documents.htmlo6http://ndg.nerc.ac.uk/csml  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~  Root Entry F@WData 1TableRWordDocumentSummaryInformation(DocumentSummaryInformation8CompObjq  F Microsoft Office Word MSWordDocWord.Document.89q