#MyAccount myPersonalInfoLabel = Edit your information userRegistrationLabel = Are you new to the ESPAS platform? Register to participate to the ESPAS platform or gain access to the ESPAS data. myFileDownloadsLabel = Check out your download requests. \ They have a time stamp of the request. Just click on a request to see its progress, \ information about it, and a list of download URLs if it is completed. myDataDownloadsLabel = View all the your data download requests, date/time stamped . Click on each to view more detailed \ information (query, status, progress) as well as a set of possible actions on the data (plots etc.) dataProviderManagementLabel = You have registered and are responsible for managing the following data provider.

\ [Click on a name to edit the source's relevant attributes]

dataRegistrationLabel = View and edit specific information related to your registered data providers #Data Overview summaryMainLabel = summarySecondaryLabel = summaryDataProvidersLabel = browseDataLabel = Navigate in data providers information accessible via ESPAS: \ platforms, projects, instruments, models, collections etc. statisticsLabel = Plots, charts, maps of the ESPAS data #Data Search searchFirstWorkflowLabel = Progressive Search searchFirstWorkflowSmallLabel = Filter your search with different options as you go along (real-time) searchSecondWorkflowLabel = Spatial/temporal Search searchSecondWorkflowSmallLabel = Filter your search by time and location (off-line) assetsTooltip = Assets that acquired/generated these data (instruments, models) timePeriodTooltip = A time period when data were acquired/generated observedPropertiesTooltip = Observed properties that these data measured observationCollectionsTooltip = Observation Collections that contain these data timeLocationTooltip = Time and Location where data were acquired/generated - Under Construction assetsInfoLabel = Select Assets on the right [Filter with available options on the left]\
Assets (and their respective filter options) that are not related to an observation, \ are not displayed in this form. For a complete list of all the Assets (Instrument and Computations), Platforms and \ Projects registered in ESPAS you can visit the Browse -> Metadata section timePeriodInfoLabel = Select a period of the observations [Option: specify the time of day to narrow down your results] observedPropertiesInfoLabel = Select Observed Properties on the right [Filter with available options on the left] observationCollectionsInfoLabel = Select Observation Collections on the right [Filter with \ available options on the left]
Observation Collections that are not related to \ an observation, are not displayed in this form. For a complete list of all the Observation Collections registered in \ ESPAS you can visit the Browse -> Metadata section resultsInfoLabel = Select Download dataset files or data values (observed properties) and go to My Account to monitor their progress timeLocationInfoLabelTime = Select a period of the observations [Option: specify the time of day to narrow down your results] timeLocationInfoLabelLocation = Select the location of the platforms (ground-based observatories and / or satellites) # Support espasDescription =

The ESPAS project is building an e-Infrastructure that will help scientists and engineers to locate \ observational data from ground-based and space borne sensors and from models that can advance studies of the near-Earth \ space environment, and its adverse impact on advanced technologies. This is a very diverse environment extending from \ the upper atmosphere, out into the magnetosphere, and beyond into that part of the solar wind that is flowing past the \ Earth (and that is often depositing significant amounts of energy and momentum into the magnetosphere). This environment \ has many different components including (a) both the neutral and ionised parts of the upper atmosphere, the \ thermosphere and \ ionosphere respectively, which extend upwards \ to around 1000 km altitude, (b) the tenuous extension of the ionosphere out to altitudes of 20000 km (the \ plasmasphere), (c) the regions of high-energy \ particles that surround the Earth (the \ radiation belts), and (d) the \ origins and properties of the hot plasma flowing from the Sun to the Earth (the \ solar wind).This diversity creates a tension \ that ESPAS has sought to resolve: \

Data are spread around many institutes, each specialising in a particular measurement or model, but
The modern focus on inter-disciplinary studies (e.g. coupling between different components) means that individual \ scientists and engineers wish to access many different datasets.

Thus there was a clear need for a system that helps scientists to locate the datasets that they need, and then to \ download those data. This is the core of the problem that ESPAS has addressed.

The immediate aim was to provide a single-point access to a large number of data repositories covering different \ aspects of the near-Earth environment. These repositories are very heterogeneous, including data from both ground- and \ space-based sensors and using a wide variety of measurement techniques, e.g. in-situ and remote sensed measurements. \ This heterogeneity was important as it provided the challenge needed to develop a truly flexible system. So the ESPAS \ Consortium has had to address a number of detailed objectives:\

How can the infrastructure integrate heterogeneous data from multiple providers? To do this, we have established \ a data model that allows us to capture a wide range of metadata about all these data and to do so in a consistent manner. \ It is the breadth and consistency of the metadata that enables us to build a powerful tool for locating data. For this \ reason we regard the data model as a key outcome of ESPAS.
Who can access the data? To build confidence among data providers, the infrastructure regulates access to the data, \ so that users are made aware of policies on the use of the data, and that, where restrictions on access exist, ESPAS can apply them.
How to find the data? The infrastructure must make it straightforward for users to locate data using criteria that \ are suited to the user’s scientific objectives, which we may term a \"scientist-friendly\" approach. To facilitate such \ searches, a number of workflows have been developed for use within the ESPAS portal.
Have we tested ESPAS? The infrastructure is being tested through the application of several test and science cases, \ designed to serve the needs of the wide interdisciplinary users.

espasGlossary =

Acquisition: Corresponds to the process component that interacts with \ the feature of interest / sampling feature to provide a result. It involves the use of an Instrument which is mounted \ on a Platform that may have an Operation (for satellites, aircrafts).

Asset: Corresponds to an Instrument or a numerical Model or other software that \ was used to generate the observation.

Component: For vector properties, it describes which of the three components is \ provided in the data only in those cases when observation does not specify the vector property in full. Typical components \ are X, Y, Z. The Component has to be accompanied by a suitable description of the Coordinate Reference System (Crs). \ It takes values from the Component controlled vocabulary.

Composite Observed Property: Describes the group of simple observed properties \ whose values are estimated in the course of an observation. It takes values from the Composite Observed Property \ controlled vocabulary.

Composite Process: Represents the process that consists of more than one components \ of type Acquisition or Computation.

Compressed Representation: Describes the formalism of compressed representation of \ voluminous or complex 3D, 2D, and 1D data. Typical examples are spherical harmonics for 2D maps on the sphere, truncated \ Fourier transforms (harmonics) for diurnal time series, Empirical Orthogonal Functions (EOF). It takes values from the \ Compressed Representation controlled vocabulary.

Computation: Corresponds to the process component that involves only numerical \ computation (no Instrument is involved), as in the case of Models (e.g. EDAM, SIRMUP) or specific softwares (e.g. ARTIST \ for the autoscaling of the ionograms).

Computation Type: Describes the type of the Computation process (e.g. Mathematical \ model, software). It takes values from the Computation Type controlled vocabulary.

Crs: Corresponds to the Coordinate Reference Systems (e.g. GSE, GSM, ..) used to \ describe a vector Component (observed property definition), the location of a Platform and the geographic extent of an \ Observation. It takes values from the Crs controlled vocabulary.

Data Provider: Corresponds to an authorized Institution, Organisation or Individual \ that provides, at minimum metadata information and at several cases access to data.

Dimensionality Instance: Dimensionality is a compact description of the domain X \ spanned by the independent (input) variables x1, x2, x3 ... of the Observation result (output dependent variable Y):
\ Y = f(x1, x2, x3 ...)
\ The independent variables x1, x2, x3 ... are tested in the course of the Observation to acquire values of the dependent \ variable Y. For example, an Observed Property "NeutralWindVelocity" is a vector field variable with a natural presentation \ as a Vector (magnitude and direction) defined in 3D space (latitude, longitude, altitude).
\ The Dimensionality Instance describes the Single instance of the acquired Y values of the observed property in time \ (time is not included in the list of independent variables) (e.g. 1D.point, 1D.Profile, 2D.Map, 2D.image). It takes \ values from the Dimensionality Instance controlled vocabulary.

Dimensionality Timeline: Dimensionality is a compact description of the domain X \ spanned by the independent (input) variables x1, x2, x3 ... of the Observation result (output dependent variable Y):
\ Y = f(x1, x2, x3 ...)
\ The independent variables x1, x2, x3 ... are tested in the course of the Observation to acquire values of the dependent \ variable Y. For example, an Observed Property "NeutralWindVelocity" is a vector field variable with a natural presentation \ as a Vector (magnitude and direction) defined in 3D space (latitude, longitude, altitude).
\ The Dimensionality Timeline describes the timeline of the acquired Y values of the observed property (time is one of the \ independent variables) (e.g. Timeseries, Animation). It takes values from the Dimensionality Timeline controlled vocabulary.

Feature Of Interest: A real-world object, carrying the properties which are under \ observation. It is the subject of the observation. In ESPAS corresponds to the region of space (e.g. Ionosphere, \ Magnetosphere) of the observed property of the observation. It takes values from the Feature of Interest controlled vocabulary.

Individual: An individual having a particular role associated with a real world object.

Instrument: Designations for the measuring instruments/sensors which interact with \ the feature of interest in order to obtain an estimate of the observed property in an Observation.

Instrument Type: Describes the type of an Instrument (e.g. Radar, Digisonde). It \ takes values from the Instrument Type controlled vocabulary.

Interaction: Describes the interaction between the wave and propagation medium that \ defines the Observed Property (it applies only to wave phenomena). It takes values from the Interaction controlled vocabulary.

Licence: It is the element of an agreement describing the terms under which data registered \ in ESPAS can be used. It takes values from the Licence controlled vocabulary.

Measurand: Describes the measurable quantity of the Observed Property, whose value is \ estimated in the course of an observation. It takes values from the Measurand controlled vocabulary.

Model: Describes the Computation concept of ESPAS Data Model within ESPAS Portal.

Model Type: Describes the Computation Type obtained from ESPAS Ontology within ESPAS Portal.

Observation: The main concept of the ESPAS Data Model: an observation is an act \ that results in the estimation of the value of a feature property using a designated procedure, such as a sensor, \ instrument, algorithm or process chain. An observation is associated with a discrete time instant or period through which \ a number, term or other symbol is assigned to a phenomenon. The result of an observation is an estimate of the value \ of a property of some feature, so the details of the observation are metadata concerning the value of the feature property.

Observation Collection: Corresponds to any set of existing observations. The \ organisation of observations into collections is based on specific criteria, e.g. common observed property, common instrument, \ common process. An observation may be aggregated in more than one observation collections.

Observation Result: Corresponds to the product (numerical artefact) of an Observation. \ ESPAS is not particularly concerned with details of observation result structures, but is aimed at providing the required \ metadata in order to make this result fully understandable and exploitable. Therefore, in ESPAS, observation result is \ regarded the set of metadata for accessing and obtaining the actual values of the observed property obtained by the \ action of observation.

Observed Property: Corresponds to a phenomenon associated with the feature of \ interest for which the observation result provides an estimate of its value. It is the object of the observation (e.g. \ Temperature, Electron Density). It takes values from the Observed Property controlled vocabulary.

Operation: Provides information about a platform operation - e.g. orbit of a \ satellite - which needed for the data acquisition during an observation.

Organisation: Corresponds to a body/organization having a particular role \ associated with a real world object.

Phenomenon: Corresponds to the underlying phenomenon for which the Observation \ provides an estimate of its value (e.g. Particle.Charged.Electron, Field.Electric, Field.Magnetic). It takes values \ from the Phenomenon controlled vocabulary.

Platform: Corresponds to an identifiable object which brings the acquisition \ instrument(s) to the appropriate environment (e.g satellite, ground-based station) in order data to be acquired \ according to the observation objectives.

Platform Type: Describes the type of a Platform (e.g. ground-based station, satellite). \ It takes values from the Platform Type controlled vocabulary.

Process: Corresponds to a designated procedure used by the action of observation \ in order to assign a number, term or other symbol to a phenomenon generating the observation result. A procedure is \ often an instrument or sensor but may be a process chain, human observer, an algorithm, a computation or simulator [ISO 19156]. \ Therefore, a procedure may consist of more than one component. A component shall be either an Acquisition or a Computation.

Process Capability: Describes specific and usually limited capability of the sensing \ instrumentation or models to produce information about the Observed Property.

Project: An identifiable activity/project designed to accomplish a set of \ objectives in order to produce datasets.

Projection: For vector properties, it describes a plane or a line on which the \ vector projection is observed by the Instrument. The Projection is provided in the data only in those cases when Observation \ does not specify the vector property in full. Typical projections are horizontal, line of sight, orbital, perpendicular. \ The Projection has to be accompanied by a suitable description of the Coordinate Reference System (crs). It takes values \ from the Projection controlled vocabulary.

Propagation Mode: Description of the mechanism by which the oscillating physical \ quantity (agent) travels in medium (only for wave pheonomena). It takes values from the Propagation Mode controlled vocabulary.

Qualifier: A common, cross-class attribute that refines the Measurand definition. \ Typical Qualifier examples include Maximum, Vector, Average, Approximation. It takes values from the Qualifier controlled vocabulary.

Region of Space: Describes the Feature of Interest obtained from ESPAS Data Model within ESPAS Portal.

Related Observation Role: Describes the role of the related Observation (e.g. \ location information,...). It takes values from the Related Observation Role controlled vocabulary.

Related Party Role: Describes the role (owner, principal investigator, researcher, \ etc) of a related party for an object (Project, Observation Collection, Instrument etc). It takes values from the Related \ Party Role controlled vocabulary.

Result Accumulation: Describes the frequency with which additions are/were made to \ the Observation's result (e.g. daily, monthly, hourly, ..). It takes values from the Result Accumulation controlled vocabulary.

Result Data Format: Describes the data format of a resulting file of an Observation. \ It takes values from the Result Data Format controlled vocabulary.

Service Function: Describes the function of a service offered by a Data Provider at \ the Observation Result level. So, it specifies whether the Observation Result files (data files) are available for \ download or for view only from the end user. It takes values from the Service Function controlled vocabulary.

Status: Describes the status of a Project, an Observation, an Operation of a Platform \ (e.g. historical, ongoing,..). It takes values from the Status controlled vocabulary.

Unit: Describes the unit of the Observed Property as measured in a specific process \ (e.g. Km, MHz). It takes values from the Unit controlled vocabulary.

\ forDataProvidersFirstPart =

Basically all near-Earth space environment data, that is, measurements of the upper atmosphere, \ magnetosphere and solar wind environment, are suitable for inclusion in ESPAS. In order to include a dataset in ESPAS, \ there is a number of steps that have to be followed. A brief summary follows. In order to set up a working ESPAS data \ system it is necessary to follow the more detailed documentation which can be found in the ESPAS project wiki.

In order to make a dataset accessible through ESPAS, the data must be accessible in a file system or through an SQL \ database and metadata according to the ESPAS standard must be created. The following steps outline the procedure.

Describe your data

The first important step is to describe the data according to the [ESPAS data model]. This implies following the \ [ESPAS Ontology], which is the categorization of measurements and data used by ESPAS. There must be ontology entries \ for your types of instruments, data, and so on. Additions to the ontology must be created if suitable entries are missing.

Create XML entities according to the data model

The actual entries into the ESPAS system are accomplished by inserting valid XML files following the ESPAS standards \ into the system. There are two kinds

Static entries, describing your institute, sites, instruments, data processing, and so on (Individuals, Organisations, \ Platforms, Projects, Instruments, Operations, Computations, Acquisitions, Composite Processes and Observation Collections). \ It is not necessary to explicitly create XML files since these entries can all be created through the ESPAS portal.
Observation entries. These describe each measurement. There are two ways of adding Observations:\
- a static entry, containing information on start of measurements and intervals between measurements
- dynamic observation entries, one for each experiment (e.g. one per day or one for each run in case of irregular \ operation). These are harvested through the ESPAS Catalogue Service Wrapper.

forDataProvidersSecondPart =

Install the catalogue service wrapper

The catalogue service wrapper is a web application written in Java that handles requests from the central ESPAS \ system and sends metadata retrieved from your XML entities. The system has been tested on (Linux, Windows, and Mac) servers

Make sure Java 7 is installed
Install a Java servlet container. Tomcat 7 and Jetty 6 have been tested but other containers may also work.
Install the CSW wrapper by copying the file espas.war to the right directory.
Edit and install the file dnet-override.properties to configure your wrapper
Test that the wrapper is working by browsing to http://:/espas/status
When the wrapper is running, copy your Observation XML files to its input directory and wait for it to insert the \ entries in the database

Make the central system harvest your Observations

Data harvest

When new Observation entries have been added to your local catalogue service, the central system must harvest these. \ This does not happen automatically. The procedure to follow to add new data is

Validate your XML entities and copy to the input directory of the CSW wrapper
Wait until the wrapper has ingested the new entries, or restart the Java servlet container for this to happen faster
Add a harvest ticket to the ESPAS Trac system. The modification times of the first and last added XML entities must \ be included for the harvester to know what entries to search for.

Wrapper upgrade

On upgrades of the ESPAS system the CSW wrappers of all providers must typically also be upgraded. There are two \ types of upgrade:

Backwards-compatible upgrade: Just stop the Java servlet container, copy the new WAR file in place, and restart,
Non backwards compatible update: This means a clean install of the wrapper, so all XML entities must be re-read. \ Therefore each provider should keep an archive of their XML files.

Value-added services

In order to access and retrieve data values from the data provider archives, ESPAS has chosen to implement a minimal \ set of the Sensor Observations Service (SOS) protocol. The catalogue service wrapper handles SOS queries and sends them \ to a backend system for data retrieval. There are several options, such as JDBC database connectivity or to use the \ Helio CXS execution controller for running user-provided software. See the project wiki for more details.

ontologyOverview =

Synopsis

The ESPAS data portal manages a vocabulary of Space Physics keywords that can be used to narrow down data searches \ to observations of specific physical content. Such content-targeted search is provided by ESPAS in addition to the \ commonly practiced selection by time and location. This document is a user guide to the ESPAS data search capabilities \ based on the ESPAS Space Physics concepts.

ESPAS Space Physics Ontology is the cornerstone of the data search functions \ that are specific to ESPAS domain.

Introduction: Data Model versus Domain Ontology

Concepts of Data Model and Ontology are used interchangeably in the eScience community. In ESPAS, we draw a distinction between:

Data Model: ISO-controlled organization of data elements and their relationships in a generic, science-neutral manner;
Domain Ontology: a vocabulary-controlled structured set of physical concepts and relationships specific to a particular domain of science.

In order to describe the domain ontology concepts, custom data elements not in the ISO 91000 standard had to be introduced. \ Additionally, ESPAS Data Model includes new custom data elements of the generic (science-neutral) nature that were \ required to adequately describe available data collections.

Key Elements of ESPAS Space Physics Ontology

In order to simplify navigation through the wealth of ESPAS Space Physics vocabulary terms, the ontology is organized \ in several hierarchies of keywords connected to each other via a “broader-narrower” relationship. Understanding the \ ontology hierarchies is critical for efficient data search and discovery in ESPAS.

dataModelOverview =

The ESPAS data model is built entirely on ISO 19100 series geographic information standards, \ particularly the ISO 19156 Observations and Measurements (O&M) standard. This standardisation facilitates interoperability \ with other information systems and provides freedom to mix and match information system components without compromising \ overall success [ISO 19101:2002].

The general structure of the ESPAS data model gives a central place to the concept of "observation". \ According to [Fowler,1998] an observation is an act that results in the estimation of the value of a feature \ property using a designated procedure, such as a sensor, instrument, algorithm or process chain. An observation is \ associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. \ The result of an observation is an estimate of the value of a property of some feature, so the details of the observation \ are metadata concerning the value of the feature property.

EXAMPLE Measuring (the act of the observation) the F2-layer \ Critical Frequency (foF2) of the Ionosphere above Athens at 1/1/2015 16:00 GMT. The featureOfInterest is the Ionosphere, \ the observedProperty is the foF2, the procedure/process is the acquisition made by the Athens Digisonde \ mounted on NOA platform and the result is 5.2 MHz.

Following this approach the data which ESPAS data model is aimed at describing is always considered as observation \ results and the observation together with its properties provide relevant metadata.

Besides the main concept of Observation, the other related concepts that are used in ESPAS data model are listed below, \ while a high level overview of the relationships among them is presented at Figure 1.

Feature of Interest : a real-world object, carrying the properties which are under observation. It is \ the subject of the observation. In ESPAS corresponds to the region of space (e.g. Ionosphere, Magnetosphere) of the \ observed property of the observation. A controlled vocabulary (Browse -> ESPAS Space Physics Ontology) is used for its values.
Observed Property : a phenomenon associated with the feature of interest for which the observation result \ provides an estimate of its value. It is the object of the observation (e.g. Temperature, Electron Density) and a \ controlled vocabulary (Browse -> ESPAS Space Physics Ontology) is used for its values.
Observation Result : the act of the observation produces a numerical artefact, i.e. the observation result. \ ESPAS is not particularly concerned with details of observation result structures but is aimed at providing the required \ metadata in order to make this result fully understandable and exploitable. Therefore, in ESPAS, observation result is \ regarded the set of metadata for accessing and obtaining the actual values of the observed property obtained by the \ action of observation.
Process : a designated procedure used by the action of observation in order to assign a number, term or other \ symbol to a phenomenon generating the observation result. A procedure is often an instrument or sensor but may be a \ process chain, human observer, an algorithm, a computation or simulator [ISO 19156]. Therefore, a procedure may \ consist of more than one component. A component shall be either an acquisition or a numerical computation \
- An Acquisition process interacts with the feature of interest / sampling feature to provide a result and \ involves the use of an Instrument which is mounted on a Platform that may have an Operation (for satellites, aircrafts).
- A Computation process involves only pure computation (no Instrument is involved), as in the case of Models (e.g. \ EDAM, SIRMUP) or specific softwares (e.g. ARTIST for the autoscaling of the ionograms).
- A Composite process consists of more than one components of type Acquisition or Computation.
Instrument : designations for the measuring instruments/sensors which interact with the feature of interest \ in order to obtain an estimate of the observed property. In ESPAS an instrument is assigned to a specific type of \ Instrument obtained from the relative controlled vocabulary (Browse -> ESPAS Space Physics Ontology).
Platform : an identifiable object which brings the acquisition instrument(s) to the appropriate environment \ (e.g. satellite, ground-based station) in order data to be acquired according to the observation objectives. In ESPAS \ the concept of platform is used to distinguish ground-based from space-based platforms (Browse -> ESPAS Space Physics Ontology).
Operation : Information about a platform operation - e.g. orbit of a satellite - which needed \ for the data acquisition. The concept of platform operation applies only to platforms that are in motion during the \ acquisition e.g. a satellite – geostationary or orbital, an aircraft, a ship and not the operation of a static platform \ such as a ground station.
Project : an identifiable activity/project designed to accomplish a set of objectives in order \ to produce datasets.
Collection : any set of existing observations. The organisation of observations into collections \ is based on specific criteria, e.g. common observed property, common instrument, common process. An observation may be \ aggregated in more than one observation collections.
Organisation : a body/organization having a particular role associated with a real world object.
Individual : an individual having a responsibility regarding a real world object.

One of the main ESPAS extension to the ISO 19156 Observations and Measurements (O&M) model is the definition of the \ Process Capability as a property of a Process. This property has been added in order to describe specific and usually \ limited capability of the sensing instrumentation or models to produce information about the Observed Property. So \ the "capability" in this context is the description of an Observed Property that this Process is capable of measuring \ and its related information: units, dimensionality (instance and timeline), valid minimum, valid maximum, fill value, \ vector representation (crs, component, projection), qualifier, compressed representation, extracted parameter.