Publication Date: 2020-02-13

Approval Date: 2019-12-25

Submission Date: 2019-11-18

Reference number of this document: OGC 19-083

Reference URI for this document: http://www.opengis.net/doc/PER/CitSciIE-1

Category: Public Engineering Report

Editor: Joan Masó

Title: OGC Citizen Science Interoperability Experiment Engineering Report


OGC Engineering Report

COPYRIGHT

Copyright © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Summary

This Engineering report describes the first phase of the Citizen Science (CS) Interoperability Experiment (IE) organized by the EU H2020 WeObserve project under the OGC Innovation Program and supported by the four H2020 Citizen Observatories projects (SCENT, GROW, LandSense, and GroundTruth 2.0) as well as the EU H2020 NEXTGEOSS project. The activity covered aspects of data sharing architectures for Citizen Science data, data quality, data definitions and user authentication.

The final aim was to propose solutions on how Citizen Science data could be integrated in the Global Earth Observation System of Systems (GEOSS). The solution is necessarily a combination of technical and networking components, being the first ones the focus of this work. The applications of international geospatial standards in current Citizen Science and citizen observatory projects to improve interoperability and foster innovation is one of the main tasks in the IE.

The main result of the activity was to demonstrate that Sensor Observing Services can be used for Citizen Science data (as proposed in the Open Geospatial Consortium (OGC) Sensor Web Enablement for Citizen Science (SWE4CS) Discussion Paper) by implementing SWE4CS in several clients and servers that have been combined to show Citizen Science observations. In addition, an authentication server was used to create a federation between three projects. This federated approach is part of the proposed solution for GEOSS that can be found in the last chapter. Many open issues have been identified and are expected to be addressed in the second phase of the experiment, including the use of a definitions server.

1.1. Requirements & Research Motivation

This experiment was designed to demonstrate how current ICT-based tools can be applied together to allow better citizen participation in CS projects and enable better reuse of the data gathered. Citizen Science is highly transdisciplinary and heterogeneous by nature and current standardization efforts already occur in the OGC (e.g., addressing data model and sharing issues) as well as outside the OGC (primarily addressing project descriptions and dataset metadata). Citizen Science projects might benefit from concrete examples and best practices required to achieve the full benefits of interoperability. OGC is in the ideal position to develop and provide such best practice guidance to the international community. Developed solutions in this IE should be applicable to most Citizen Science projects. Findings from this IE will be generalized as practice examples and might set the basis for additional experimentation in the future.

The FP7 Citizen Observatory Web (COBWEB) project was the first to propose the use of SWE in CS. This work resulted in an OGC public Discussion Paper available on the OGC website (OGC 16-129). The Discussion Paper describes a data model for the standardized exchange of Citizen Science sampling data based on SWE standards. This Discussion Paper was the initial motivation for this IE.

Beyond the work described above, the Citizen Science Association’s International Working Group on Citizen Science Data and Metadata has developed the PPSR-CORE metadata standard and the European Citizen Science Association (ECSA) has a working group that recognizes the value of standardization in the CS activities (supported by a COST Action). However, these activities could benefit from some experimentation that would be able to suggest common best practices while recognizing the particularities and current approaches in different thematic domains, such as biodiversity monitoring. Citizen Science can complement authoritative in-situ observations and fill the information gaps in numerous scientific disciplines that could be essential for informed decision making. In that sense, the way Citizen Science can be integrated into The GEOSS (including GEOSS-Data Core as the pool to promote and share open and free data) is still under investigation.

The Ecosystem of Citizen Observatories (CO) for Environmental Monitoring WeObserve project is a Horizon 2020 funded project focused on improving the coordination between existing COs and related regional, European, and international activities. WeObserve tackles three key challenges that face COs: awareness, acceptability, and sustainability. The WeObserve Community of Practice 3 (CoP3) is about Interoperability of Citizen Science projects. The WeObserve project – via its CoP activities – has represented an opportunity to promote interoperability experimentation in collaboration with the OGC. Such collaboration addresses questions raised in the SWE4CS discussion. In addition, the work offers the possibility to directly feed the results into the relevant OGC standards and promotes their usage within GEOSS (as an important user community of OGC standards).

In anticipation of the 50th Anniversary of Earth Day in 2020, Earth Day Network, the Woodrow Wilson International Center for Scholars, and the U.S. Department of State, through the Eco-Capitals Forum, announce Earth Challenge 2020, a Citizen Science Initiative. This initiative is in collaboration with Connect4Climate – World Bank Group, Conservation X Labs, Hult Prize, National Council for Science and the Environment (NCSE), OGC, Reset, SciStarter, UN Environment, and others to be announced. Earth Challenge 2020 will help engage millions of global citizens in collecting one billion data points in areas including air quality, water quality, biodiversity, pollution, and human health. Earth Change 2020 data will be shared through the GEOSS Portal.

1.2. Prior-After Comparison

This is the first Citizen Science IE conducted by the OGC. Prior to this activity, there was a Discussion Paper on how to apply the SWE standards in Citizen Science (SWE4CS). This experiment positively tested the proposed route using Sensor Observing Services but also has opened the door to future exploration of the SensorThings API.

Also prior this activity, was a H2020 project with a Authentication Service and after the activity, three H2020 efforts formed a bigger federation demonstrating the route to federating and aggregating Citizen Science projects to contribute to GEO objectives.

This work is relevant to the OGC Citizen Science Domain Working Group.

1.3. Recommendations for Future Work

This OGC IE ended on June 2019, but a second IE is foreseen for the following year.

New possible topics for next IE to be discussed among the members include the following.

  • There is a need for clarifying how to coordinate infrastructures for Citizen Science in Europe and adopt standard procedures for data sharing and single sign on. Solving this issue will help in connecting CS to GEO. Steffen Fritz (IIASA) has proposed a side event in the next EuroGEOSS workshop to discuss this coordination with the relevant players. This is emerging as a new activity in the WeObserve Interoperability CoP that is related, but not directly connected, to the IEs.

  • The WMO (World Meteorological Organization) is concerned about the amount of different CS activities that are being organized by meteorological organizations. WMO is looking for ways to take advantage of this new data stream, but problems of standardization of what is measured and how data is being shared arise. WMO has identified the potential of these data streams and would like to harmonize the situations to make data more useful for weather predictions in the future.

  • OGC is promoting a new generation of web services based on OpenAPI. It is unclear how these new web services could impact the use of OGC standards by CS projects but it is seen as an opportunity to make OGC standards more usable and compatible with IT mainstream. A hackathon to develop OGC API specifications occurred on 20-21 June 2019 in London and subsequent hackathons and sprints continue to advance the OGC API standards.

The definition of the follow-up IE started upon completion of this IE.

1.4. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Name Organization

Joan Maso

UAB-CREAF

Andy Cobley

University of Dundee

Valantis Tsiakos

Institute of Communication & Computer Systems (ICCS)

Nikolaos Tousert

Institute of Communication & Computer Systems (ICCS)

Theodoros Theodoropoulos

Institute of Communication & Computer Systems (ICCS)

Simon Jirka

52 North

Sven Schade

European Commission, Joint Research Center (JRC)

Andreas Matheus

Secure Dimensions

Stefano Tamascelli

XTeam Software Solutions

Friederike Klan

Citizen Science Group, Institute of Data Science, DLR

Trupti Padiya

Citizen Science Group, Institute of Data Science, DLR, Friedrich-Schiller-University Jena

Initiators

Organization

Universtat Autònoma de Barcelona - CREAF (UAB-CREAF)

International Institute for Applied Systems Analysis (IIASA)

Joint Research Center (JRC)

European Space Agency (ESA)

Woodrow Wilson International Center for Scholars (Wilson Center)

The WeObserve project has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under grant agreement No. 776740.

This presentation reflects only the editor’s views and the EU Agency is not responsible for any use that may be made of the information it contains.

1.5. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

1.6. Acknowledgements

This report was coordinated and developed with funding from the European Union’s Horizon 2020 research and innovation programme under grant agreements: no 776740 (WeObserve), no 688930 (SCENT), no 689744 (Ground Truth 2.0), no 690199 (GROW Observatory), no 689812 (LandSense) as well as no 730329 (NEXTGEOSS).

2. References

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

  • Citizen Observatory (CO)

    Community-based environmental monitoring and information systems that invite individuals to share observations, typically via mobile phone or the web (from: https://www.weobserve.eu/about/citizen-observatories).
  • Citizen Science (CS)

    The collection and analysis of data relating to the natural world by members of the general public, typically as part of a collaborative project with professional scientists (from: https://www.uen.org/crowdandcloud/citizen.shtml).
  • Citizen Science Association

    A network that seeks to promote and advance citizen science in a region or around the world. Examples are the American Citizen Science Association (CSA), The European Citizen Science Association (ECSA), or the Citizen Science Global Partnership (CSGP).
  • Citizen Science Federation

    A network of Citizen Science that aims to aggregate innovative Earth Observation technologies, mobile devices, community-based environmental monitoring, data collection, interpretation, and information delivery systems to empower communities to monitor and report on their environment. An example of this is the The LandSense Federation.
  • Community of Practice (CoP)

    Community which works to consolidate practice-based knowledge of COs sharing information and resources as well as developing guidelines and toolkits for COs (from: https://www.weobserve.eu/cops/).

3.1. Abbreviated terms

  • CitSciIE Citizen Science Interoperability Experiment

  • CO Citizen Observatory

  • CoP Community of Practice

  • COST European Cooperation in Science and Technology

  • CS Citizen Science

  • CS DWG Citizen Science Domain Working Group

  • CSGP Citizen Science Global Partnership

  • ECSA European Association of Citizen Science

  • EO Earth Observation

  • ICT Information and Communication Technologies

  • IE Interoperability Experiment

  • O&M Observation and Measurements

  • PPSR Public Participation in Scientific Research

  • SOS Sensor Observation Service

  • SSO Single Sign On

  • SWE Sensor Web Enablement

  • SWE4CS Sensor Web Enablement for Citizen Science

  • TC Technical Committee

  • TIE Technology Integration Experiments

  • WPS Web Processing Service

4. Overview

This Engineering Report focuses on the findings of the first phase of the Citizen Science Interoperability Experiment (CitSciIE).

The primary focus of the OGC CitSciIE was to demonstrate the interoperability of Citizen Observatories and Citizen Science projects and the way OGC standards can be applied to Citizen Science, including possible relationships to other relevant standards from the community. In particular, a subset the originally proposed topics were being addressed based on the participant organizations:

  • The use of OGC standards or draft specifications (e.g., SWE or SWE4CS) to support data integration among CS projects, and with other sources, especially authoritative data;

  • The use of ISO standards, OGC publications, and community resources to document data quality aspects (e.g., UncertML, QualityML);

  • The integration of CS projects/campaigns in a Single Sign-On system (SSO) federation; and

  • The relationships between OGC standards and data and metadata standards currently used by Citizen Science projects.

The desired outcome of this experiment was the following.

  1. Successfully demonstrate how OGC standards (e.g., SWE) are applicable to Citizen Science, document available supporting tools, identify the challenges of using OGC SWE standards (or Internet of Things equivalent solutions) within current Citizen Science projects, and propose a way forward. Make recommendations to the Earth Science 2020 initiative on which OGC standards should be utilized to underpin interoperable data collection and sharing.

  2. Successfully demonstrate how to estimate Citizen Science data quality and make the quality indicators and conformity available in the document and in supporting tools and link them to the OGC SWE standards (or Internet of Things equivalent solutions) within current CS projects, as well as propose a way forward.

  3. Determine the security considerations and the available tools to support an SSO federation that helps users in participating in several projects by using a single user account.

  4. Assess the possible relationships of OGC standards (e.g., SensorML) with other existing standards in the field (e.g., PPSR - CORE, the ontology developed by the COST Action on Citizen Science, and the Citizen Science Definition Service (CS-DS) developed in the NextGEOSS project).

  5. Satisfy and document the necessary requirements to integrate Citizen Science into GEOSS by using OGC standards.

This IE has been promoted by the OGC Citizen Science Domain Working Group, the WeObserve and NextGEOSS H2020 projects, and The Earth Challenge 2020 project as supported by National Geographic Society. This IE contributes not only to the interoperability and possibly standardization program of the OGC, but also to the GEOSS. This work is also relevant to the foundational objectives of the Citizen Science Global Partnership (CSGP). Regional and national Citizen Science Associations will equally benefit from the results of this OGC IE.

4.1. Structure of the activities

The official kick-off meeting for the OGC CitSciIE experiment was held on Friday 14th September 2018 at the OGC TC meeting in Stuttgart, Germany. Activities continued until March 2019.

During the kick-off meeting of the IE, the following subgroups emerged.

  • V: Vocabularies for organizing Citizen Science projects. There was a discussion on essential variables but also on other kinds of practices that can be associated to vocabularies, i.e., on how to publish vocabularies (PublishingDefs) or on defining a list of vocabularies that could be useful to experiment with (observations, project descriptions, general glossaries of terms).

    • Working item V.1: A list of the current projects that the Wilson Center knows can align with the Earth Challenge topics (air and water quality, pollution, human health, and eventually biodiversity) and extraction of a common set of variables the projects cover.

    • Working item V.2: Analysis of data models that contributors in the experiment can bring in: Air quality (HackAir), Biodiversity (Atlas of Living Australia & Natusfera), Mosquito (CREAF), Land Use (IIASA), Phenology (CREAF), Invasive Alien Species (JRC).

    • Working item V.3: Consider the COST action metadata model for inclusions as another vocabulary: this might include a set of definitions of phenomena that are being addressed by CS initiatives (based on the inventory of citizen science activities for environment policies).

  • D: Data sharing using OGC standards such as Observations and Measiurements (O&M) and Sensor Observation Service (SOS). A pool of services were identified for participating in an IE, including SOS services and clients and citizen science project databases and APIs.

    • Working item D.1: A set of instructions on how a CS project can easily setup an SOS service. The service could include 52North implementation and might include MiraMon SOS (with some work in the implementation). The service should address the case of a small project contributing to the Earth Challenge 2020.

    • Working item D.2: Create an SOS endpoint for HackAir data with minimum resources.

    • Working item D.3: Define the requirements for a data provider that could assist the Wilson Center in setting up the challenge database. The requirements should consider upload of data into the system. The IE preference was to go for a harvest system instead of a federated system. The working item could describe a possible architecture to allow the dialog between the central database and the small contributing projects and should impose data sharing requirements (services o APIs) on the central database.

  • S: Connection between LandSense federation and JRC user system.

    • Working item S.1: Interoperability test on the integration of LS-SSO and JRC-SSO.

  • Q: Data quality.

    • Working item Q.1: Write a document on perspectives of the different quality aspects: Quality assessment (ISO 19157-QualityML), Quality improvement, Quality plan, Data Management principles (ISO 8001), Quality documentation, Quality communication.

    • Working item Q.2: Perfect the quality measurement system based on Web Processing Service (WPS) and SOS harvest by demonstrating the concept in practice. Also include in the SOS harvesting the possibility to have a query for assessing the quality of "views"/"selections"/"fragments" of a dataset.

      • Connection with: D.2.

    • Working item Q.3: Refine the QualityML vocabulary with new entries considering the work done in Australia.

      • Connection with: D.3.

    • Working item Q.4: Add new entry point the QualityML for other common vocabulary formats like TTL, etc.

      • Connection with: V.

For each of the subgroups a chair and the main participants and contributors were identified. Responsible persons were also assigned to each of the working items.

4.2. Results detailed in the subsequent sections

These are the main activities and outcomes of the interoperability experiment detailed by activity.

Data sharing using OGC standards such as O&M and SOS

This activity has been the most active one. During the IE, the following servers have been deployed: MiraMon SOS server, Grow SOS, DLR istSOS SOS, and 52north SOS. Three clients have also been produced: MiraMon SOS browser, Grow SOS data viewer, and 52north Helgoland. In the last meeting at the EGU, the group was able to demonstrate interoperability by connecting the SOS clients to the SOS services and showing the data on clients, sometimes mixing data form different services and datasets in a single view. This is the most significant result of the experiment and is being extensively documented in this Engineering Report in sections 5, 6 and 7.

Data quality

Two quality vocabularies have been identified: Australian work done by Peter Brenton’s team (https://github.com/tdwg/bdq) and the QualityML vocabulary developed by CREAF in the GeoViQua project. The intent of this IE was to do a comparison of both approaches, but the participants were not able to do so in the timeframe of the first IE. Section 8 describes the current status of the activity. It is foreseen that the second IE will continue what was started here.

Definition server for organizing Citizen Science projects

The objective of this activity was to support the Earth Challenge 2020 research questions. The questions were defined during the first month of the experiment and now it is time to analyze the questions in terms of data needs and thematic vocabularies to be used. Because the analysis has not yet been performed, this activity has not resulted in tangible outputs and will be reintroduced in the second IE. Details of this development are described in section 9.

Connection between LandSense federation and other user systems

Secure Dimensions (Andreas Matheus) was very active in providing demonstrations and information on how the LandSense federation works and how other projects can be included in the federation and use the SSO facility. Unfortunately, no other member of the CoP had the resources to apply the SSO on their services or clients and take advantage of the LandSense offering. The activity resulted in a video demonstration that is publicly available here: https://portal.opengeospatial.org/files/?artifact_id=81550.

Section 11 Details the current status of the activity.

Other

Section 11 summarizes the lessons learned that can be applied to GEOSS.

In addition to these activities, another activity about quality annotating scientific documentation in a standard way was proposed by Lucy Bastin. A video was recorded that summarizes the idea: https://portal.opengeospatial.org/files/?artifact_id=82544.

5. O&M for Cit Sci

In a feature model all characteristics of a feature are considered properties of the feature and are not semantically separated at the abstract level.

The O&M standard ([OGC 10-004r3], Abstract Specification Topic 20: Observations and Measurements) defines a data model for observations where main concepts are separated as represented in the Figure 1.

Observation main concepts
Figure 1. Observation main concepts

For each observation, O&M allows us to document the following characteristics.

  • Where the observation is located: even if the observation was made remotely with a camera or a drone, it is commonly more relevant to know the position of the observed phenomena (the sensor position can also be recorded).

  • When the observation took place and what time period it represents: even if samples were collected and analyzed later, it is commonly more relevant to know the instant or period of the observed phenomenon.

  • How the observation was done: this will describe the procedure and instrument used to capture the phenomenon.

  • Who did the observation: the procedure and instrument used to capture the phenomenon was installed or used on site by someone. In citizen Science, where many observers contribute small pieces of information that together will form a dataset, it is particularly important to record at least an observer identifier.

  • What was measured: this will define the property names and units of measure of the variables observed.

  • What data was collected: this will record the actual values of the properties measured.

  • What is the expected quality of the observation: if an estimation of the quality of the observation was done, it is important to document the quality.

In the O&M data model, the above aspects are clearly separated semantically as shown in Figure 2. This is the main value of the O&M model and its usage SOS (or the SensorThingsAPI that uses a very similar approach to model the data), but it is also the main handicap in applying the standard.

Common Model For Oservations and Measurements
Figure 2. Common Model For Oservations and Measurements
Table 1. Concepts in an observation mapped to the O&M model
Concept O&M type

Where

featureOfInterest

GFI_Feature

When

phenomenonTime, resultTime

How

procedure

OM_Process

Who

procedure

OM_Process

What

observedProperty

GF_PropertyType

Data

result

Any

Quality

resultQuality

Even if the aspects above are separated, the O&M model gives a lot of flexibility in defining the properties and this flexibility can condition interoperability when trying to combine data from different sources. The standard give us freedom to select among the different geometries provided by GML to define the featureOfInterest. The standard gives us even more freedom on the data collected that can have any imaginable structure.

That is the reason why the data model used to represent the data gathered by a Citizen Observatory needs to be carefully considered before even starting the first data collection campaign. Data models can be designed in UML for clarity, but they are later encoded in XML. XML is the only official encoding that O&M references in the OGC website ([OGC 10-025r1] Observations and Measurements - XML Implementation v2.0). Nevertheless, there is a JSON alternative discussed in an OGC Discussion Paper ([OGC 15-100r1] OGC Observations and Measurements – JSON Implementation) that does not represent an official position of the OGC but can be implemented anyway. As it will be discussed latter, the interpretation of long XML files might be to slow in web browsers, and in this case, a JSON encoding is regarded as a good alternative either in O&M or the SensorThings API.

5.1. The GT20 examples

In the Ground Truth 2.0 project, we have been using the MiraMon implementation of O&M. This implementation assumes a simplified situation that considers that each observation can be represented by a single row in a CSV or in a single record of a database table. Coordinates are represented as a single point. In this situation, we select which column names represent the phonomenonTime, the procedure (that actually is including the user name), and the featureOfInterest (the coordinates). The rest of the columns are considered part of the data record that needs to be provided as the result.

Section 8.2.1 of the [OGC 08-094r1] OGC® SWE Common Data Model Encoding Standard v2.0 describes a way to encode a DataRecord as an array of fields that can numbers, strings, dates, etc. In our simplified assumption, this array is ideal to wrap the properties of the observations that cannot be mapped to any other O&M aspect. This practice is consistent with the section 7.2.8 of the SWE4CS discussion paper.

The following is an example of how a water quality observation is represented following the O&M model and encoded in XML.

Example of XML encoding of the water quality observation
<om:OM_Observation gml:id="vatten-fokus_2_1">
        <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation"/>
        <om:procedure xlink:href="http://www.opengis.uab.cat/vatten-fokus/procedure/22655"/>
        <om:observedProperty xlink:href="http://www.opengis.uab.cat/vatten-fokus/observedProperty"/>
        <om:featureOfInterest xlink:href="http://www.opengis.uab.cat/vatten-fokus/featureOfInterest/2"/>
        <om:result xsi:type="swe:DataRecordPropertyType">
                <swe:DataRecord>
                        <swe:field name="CREA_DATE">
                                <swe:Text definition="http://www.opengis.uab.cat/vatten-fokus/field/Creation_Date">
                                        <swe:value>07/12/2018 17:23</swe:value>
                                </swe:Text>
                        </swe:field>
                        <swe:field name="SITE_NAME">
                                <swe:Text definition="http://www.opengis.uab.cat/vatten-fokus/field/Site_name">
                                        <swe:value>Dunkershall. V¤gtrumma uppst¤ms.</swe:value>
                                </swe:Text>
                        </swe:field>
                        <swe:field name="LAND_USE">
                                <swe:Text definition="http://www.opengis.uab.cat/vatten-fokus/field/Land_use_in_the_immediate_surroundings">
                                        <swe:value>Agriculture</swe:value>
                                </swe:Text>
                        </swe:field>
                        <swe:field name="BANK_VEGE">
                                <swe:Text definition="http://www.opengis.uab.cat/vatten-fokus/field/Bank_vegetation">
                                        <swe:value>Grass</swe:value>
                                </swe:Text>
                        </swe:field>
                        <swe:field name="NITRATE">
                                <swe:Quantity definition="http://www.opengis.uab.cat/vatten-fokus/variable/NITRATE">
                                        <swe:uom/>
                                        <swe:value>1.50</swe:value>
                                </swe:Quantity>
                        </swe:field>
                        <swe:field name="PHOSPHATE">
                                <swe:Quantity definition="http://www.opengis.uab.cat/vatten-fokus/variable/PHOSPHATE">
                                        <swe:uom/>
                                        <swe:value>0.075</swe:value>
                                </swe:Quantity>
                        </swe:field>
                        <swe:field name="WATER_COLOR">
                                <swe:Text definition="http://www.opengis.uab.cat/vatten-fokus/field/Estimated_water_colour">
                                        <swe:value>Colourless</swe:value>
                                </swe:Text>
                        </swe:field>
                </swe:DataRecord>
        </om:result>
</om:OM_Observation>

The following is an example of how two air quality observations are represented following the O&M model and encoded in JSON.

Example of encoding of the air quality observation
{
        "id":"meet-mee-mechelen_1_0",
        "type" : "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation",
        "phenomenonTime" : "2017-11-19 17:20:00+01",
        "resultTime" : "2017-11-19 17:20:00+01",
        "procedure" : "http://www.opengis.uab.cat/meet-mee-mechelen/procedure/5",
        "observedProperty" : "http://www.opengis.uab.cat/meet-mee-mechelen/observedProperty",
        "featureOfInterest" : "http://www.opengis.uab.cat/meet-mee-mechelen/featureOfInterest/1",
        "result": {
                "type":"DataRecord",
                "field":[
                        {
                                "name" : "CAMPAIGN",
                                "type" : "Text",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/field/CAMPAIGN",
                                "value" : "Oct-Nov2017"
                        },
                        {
                                "name" : "bc_aggr",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr",
                                "value" : "3155"
                        },
                        {
                                "name" : "bc_aggr_mi",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_mi",
                                "value" : "80"
                        },
                        {
                                "name" : "bc_aggr_ma",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_ma",
                                "value" : "16413"
                        },
                        {
                                "name" : "bc_aggr_st",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_st",
                                "value" : "3398"
                        },
                        {
                                "name" : "uncertaint",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/uncertaint",
                                "value" : "0.50"
                        }
                ]
        }
},
{
        "id":"meet-mee-mechelen_2_1",
        "type" : "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation",
        "phenomenonTime" : "2017-11-19 17:20:06+01",
        "resultTime" : "2017-11-19 17:20:06+01",
        "procedure" : "http://www.opengis.uab.cat/meet-mee-mechelen/procedure/5",
        "observedProperty" : "http://www.opengis.uab.cat/meet-mee-mechelen/observedProperty",
        "featureOfInterest" : "http://www.opengis.uab.cat/meet-mee-mechelen/featureOfInterest/2",
        "result": {
                "type":"DataRecord",
                "field":[
                        {
                                "name" : "CAMPAIGN",
                                "type" : "Text",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/field/CAMPAIGN",
                                "value" : "Oct-Nov2017"
                        },
                        {
                                "name" : "time_first",
                                "type" : "Text",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/field/time_first",
                                "value" : "2017-11-06 08:00:18+01"
                        },
                        {
                                "name" : "bc_aggr",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr",
                                "value" : "3382"
                        },
                        {
                                "name" : "bc_aggr_mi",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_mi",
                                "value" : "80"
                        },
                        {
                                "name" : "bc_aggr_ma",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_ma",
                                "value" : "17256"
                        },
                        {
                                "name" : "bc_aggr_st",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/bc_aggr_st",
                                "value" : "3663"
                        },
                        {
                                "name" : "number_of_",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/number_of_",
                                "value" : "25"
                        },
                        {
                                "name" : "number_o_1",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/number_o_1",
                                "value" : "13"
                        },
                        {
                                "name" : "mean_numbe",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/mean_numbe",
                                "value" : "7"
                        },
                        {
                                "name" : "uncertaint",
                                "type" : "Quantity",
                                "definition" :"http://www.opengis.uab.cat/meet-mee-mechelen/variable/uncertaint",
                                "value" : "0.50"
                        }
                ]
        }
}

These examples were produced by SOS requests to this URL: http://www.ogc3.uab.cat/cgi-bin/CitSci/MiraMon.cgi?. A client connecting to this service can be found here: http://www.ogc3.uab.cat/gt20/.

5.2. HackAir examples

To illustrate the flexibility of the O&M, we have included this air quality report that shows how HackAir data is presented by a 52North SOS implementation. In this case the result presents a single numerical value while the other information is provided as parameters. This approach is consistent with section 7.2.2.5 of the O&M standard.

Example of encoding of the water quality observation
<om:OM_Observation gml:id="o_499">
        <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement"/>
        <om:phenomenonTime>
                <gml:TimeInstant gml:id="phenomenonTime_499">
                        <gml:timePosition>2019-01-01T00:00:12.000Z</gml:timePosition>
                </gml:TimeInstant>
        </om:phenomenonTime>
        <om:resultTime xlink:href="#phenomenonTime_499"/>
        <om:procedure xlink:href="sensors_arduino_1000"/>
        <om:parameter>
                <om:NamedValue>
                        <om:name xlink:href="PM2.5_AirPollutantIndex"/>
                        <om:value xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">bad</om:value>
                </om:NamedValue>
        </om:parameter>
        <om:parameter>
                <om:NamedValue>
                        <om:name xlink:href="http://www.opengis.net/def/param-name/OGC-OM/2.0/samplingGeometry"/>
                        <om:value xmlns:ns="http://www.opengis.net/gml/3.2" xsi:type="ns:GeometryPropertyType">
                                <ns:Point ns:id="Point_sp_45C0E376C40E98E8EC0D48C05F7558C2FFD15245">
                                        <ns:pos srsName="http://www.opengis.net/def/crs/EPSG/0/4326">52.063269625917 4.5077472925186</ns:pos>
                                </ns:Point>
                        </om:value>
                </om:NamedValue>
        </om:parameter>
        <om:parameter>
                <om:NamedValue>
                        <om:name xlink:href="source"/>
                        <om:value xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">sensors_arduino</om:value>
                </om:NamedValue>
        </om:parameter>
        <om:parameter>
                <om:NamedValue>
                        <om:name xlink:href="user"/>
                        <om:value xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">sID :1000</om:value>
                </om:NamedValue>
        </om:parameter>
        <om:observedProperty xlink:href="PM2.5_AirPollutantValue" xlink:title="PM2.5_AirPollutantValue"/>
        <om:featureOfInterest xlink:href="sensors_arduino_1000"/>
        <om:result xmlns:ns="http://www.opengis.net/gml/3.2" uom="μg/m3" xsi:type="ns:MeasureType">130.67</om:result>
</om:OM_Observation>

A service producing this type of results can be seen here: https://nexos.demo.52north.org/52n-sos-hackair-webapp/service.

5.3. GROW example

In the GROW project the SME Hydrologic has developed a SOS service that uses an O&M observation. In this case, a single number is provided as the result of the observation and additional parameters are transported.

<OM_Observation xmlns="http://www.opengis.net/om/2.0">
        <type gml:remoteSchema="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement" />
        <phenomenonTime>
                <gml:TimePeriod>
                        <gml:beginPosition>2018-09-03T09:01:38.000Z</gml:beginPosition>
                        <gml:endPosition>2018-09-03T09:01:38.000Z</gml:endPosition>
                </gml:TimePeriod>
        </phenomenonTime>
        <resultTime>
                <gml:TimeInstant>
                        <gml:timePosition>2018-09-03T09:01:38.000Z</gml:timePosition>
                </gml:TimeInstant>
        </resultTime>
        <procedure>Grow.Thingful.Sensors_je47sfac</procedure>
        <observedProperty nilReason="Thingful.Connectors.GROWSensors.AirTemperature" />
        <featureOfInterest nilReason="je47sfac" />
        <result>20.64</result>
</OM_Observation>

5.4. Future work

So far we have seen 3 servers using 2 different approaches to represent the result. That is not a problem for a web service (that only outputs data), but it is not the best situation to ensure interoperability at the client side where an integrated client will need to react to any possible encoding variation and deliver the best result.

5.4.1. How to encode the procedure.

The SWE4CS Discussion Paper suggest that we use an approach to encode the procedure that takes into account a recommendation extracted from section 6.18.1 of the Timeseries Profile of Observations and Measurements standard [OGC 15-042r5] that suggests an encoding for both the observation process and the operator of the sensor (the citizen doing Citizen Science) that is based on ISO metadata. This approach will ensure a uniform way to report on these two important aspects of the observation.

Note
This approach has not been implemented during the IE but it is considered something we can experiment with in the future. An example of this procedure is provided in the SWE4CS document and reproduced here for convenience.
Example of encoding of the procedure (including process and operator) extracted from the SWE4CS document
<om:procedure>
  <tsml:ObservationProcess gml:id="op1">
    <!-- processType defines observation performed by human with sensor -->
    <tsml:processType
xlink:href="http://www.opengis.net/def/waterml/2.0/processType/Sensor"/>
    <!-- processReference defines sampling protocol -->
    <tsml:processReference
xlink:href="https://dyfi.cobwebproject.eu/skos/JapaneseKnotweedSamplingProtocol"/>
    <!-- if a sensor is used, provide the link to the sensor definition here. Use
SensorML if possible -->
    <tsml:parameter>
      <om:NamedValue>
        <om:name xlink:href="http://www.opengis.net/def/property/OGC/0/SensorType"/>
        <om:value>http://www.motorola.com/XT1068</om:value>
      </om:NamedValue>
    </tsml:parameter>
    <!-- operator defines the citizen scientist producing this observation -->
    <tsml:operator>
      <gmd:CI_ResponsibleParty>
        <gmd:individualName>
          <gco:CharacterString>Ingo Simonis</gco:CharacterString>
        </gmd:individualName>
        <gmd:organisationName>
          <gco:CharacterString>OGC</gco:CharacterString>
        </gmd:organisationName>
        <gmd:role>
          <gmd:CI_RoleCode
    codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml"
    codeListValue="resourceProvider"/>
        </gmd:role>
      </gmd:CI_ResponsibleParty>
    </tsml:operator>
  </tsml:ObservationProcess>
</om:procedure>

The result is quite verbose, which might affect performance when many data is transmitted.

5.4.2. Avoiding verbosity by defining a data stream

An approach based on providing a comma-separated recordset that is described only once at the beginning should be more compact and efficient to parse.

Section 8.4.3 of the [OGC 08-094r1] OGC® SWE Common Data Model Encoding Standard v2.0 describes a way to encode a DataStream only once and then send the data directly as a CSV format using HTTP of other protocol. A similar solution could be worth to be tested in the future to increase performance.

6. SOS architectures

In this chapter, we describe three architectures tested in the IE that demonstrate end-to-end architectures as well as interoperability among servers and clients.

6.1. Architecture 1: SOS services integrated in a SOS client

MiraMon SOS Architechture
Figure 3. MiraMon SOS Architechture

In this architecture ([MiraMonSOSArchit]), the client access directly two different SOS services. It formulates a GetFeatureOfInterest to determine the positions of the individual observations and a GetObservation each time it needs to show a complete description of a single point (the user triggers this event by clicking on an icon) or if it needs to represent different icons as a function of the value of the observation. In this case, interoperability happens directly in the client. Since the SOS requests are communicated to the Internet, this client is exposing requests and response, allowing people to explore the SOS protocol with both the map browser console as well as the browser developer tools.