Welcome to the CitSciIE web
with the support of
Next Event and calls
Principle 7: Citizen science project data and metadata are made publicly available and where possible, results are published in an open access
Principle 9: Citizen science programs are evaluated for their scientific output, data quality
, participant experience and wider societal or policy impact.
Principle 10: The leaders of citizen science project take into consideration legal and ethical issues surrounding copyright, intellectual property, data sharing agreements
, attribution and the environmental impact of any activities.
During the Kick off meeting the following subgroups emerged:
- V: Vocabularies for organizing Citizen Science projects. There was a discussion on essential variables but also on other kind of practices that can be associated to vocabularies.
- How to publish Vocabularies: PublishingDefs
- List of vocabularies that can be useful to experiment with:
- Working item V.1: A list of the current projects that Wilson Center knows that 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 usually cover.
- Working item V.2: Analysis of data models that contributors in the project can bring in: Air quality (HackAir), Biodiversity (Peter Brenton & Natusfera), Mosquito (CREAF), Land Use (IIASA), Phenology (CREAF), Invasive Alien Species (JRC).
Some additional information on observation vocabularies: ObservedPropertiesRegisterDesign.
- Working item V.3: Consider the COST action metadata model for inclusions as another vocabulary, this may 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)
- Chair: Rob Atkinson
- Main Participants: Anne Bowser, Alison Parker, Ingo Simonis, Rob Atkinson,
- Contributors: Wiebke Herding, Peter Breston, Joan Masó, Christoph Perger, Friederike Klan, Sven Schade, Lucy Bastin
- D: Data sharing using OGC standards such as O&M and SOS
- Working item D.1: A set of instruction on how a CS project can easily setup a SOS service. It will include 52North implementation and might include MiraMon SOS (it will require some work in the implementation). It should address the case of a small project contributing to the Earth Challenge 2020.
- Responsible: Simon Jirka
- Contributors: Lukas Mocek [Lukas@luftdaten.info] (suggested by Sven Schade based on a discussion with Lukas, he might test this by setting up a SOS for luftdaten.info)
- Working item D.2: Create a SOS endpoint for HackAir data with minimum resources
- Responsible: Wiebke Herding
- Working item D.3: Define the requirements for a data provider that will assist Wilson Center in setting up the challenge database. It should consider upload of data into the system. We seem to go for a harvest system instead of a federated system. It will describe a possible architecture to allow the dialog between the central data base and the small contributing projects. It should impose data sharing requirements (services o APIs) on the central database.
- Chair: Simon Jirka
- Main Participants: Wiebke Herding, Joan Masó,
- Contributors: Friederike Klan, Anne Bowser, Alison Parker, Lucy Bastin
- S: Connection between Landsense federation and JRC user system
- Working item S.1: Interoperability test on the integration of LS-SSO and JRC-SSO
- Responsible: Andreas Matheus
- Chair: Andreas Matheus
- Main Participants: Sven Schade, Christoph Perger
- Contributors: Joan Masó
- 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 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.
- Responsible: Joan Masó
- Connection with: D.2
- Working item Q.3: Refine the QualityML vocabulary with new entries considering the work done in Australia (https://github.com/tdwg/bdq)
- Responsible: Joan Masó
- Connection with: D.3
- Working item Q.4: Add new entry point the QualityML for other common vocabulary formats like TTL etc.
- Responsible: Joan Masó
- Connection with: V
- Chair: Joan Masó
- Main Participants: Anne Bowser, Alison Parker, Peter Brenton, Lucy Bastin
- Contributors: Ingo Simonis, Rob Atkinson, Christoph Perger
The primary focus of this experiment is to demonstrate the interoperability of Citizen Science (CS) 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 of these topics will be addressed depending on the participant organizations:
- The use of OGC standards (e.g. SWE4CS ) to support data integration among CS projects, and with other sources, esp. authoritative data;
- The integration of CS projects/campaigns in Single Sign-On system (SSO) federation;
- The relationships between OGC standards and data and metadata standards currently used by CS projects.
The desired outcome of this experiment is to:
- 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 CS projects, and propose a way forward.
- Determine the security considerations and the available tools to support a SSO federation that helps users in participating in several projects by using a single user account.
- Assess the possible relationships of OGC standards (e.g. SensorML) with other existing standards in the field (e.g. Public Participation in Scientific Research (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).
- Satisfy the necessary requirements to integrate CS into GEOSS by using OGC standards.
This experiment is 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. The results of the experiment will be documented in an OGC Engineering Report (ER), be presented in a demonstration event that may result in a video recording, and may result in change requests to OGC standards as appropriate. Participants in the experiment are expected to contribute to the interoperability experiment activities, demonstrations and the ER. This IE may also result in an OGC standardization best practice document or a new extension or profile of current OGC standards. These will be promoted by the Citizen Science Domain Working Group in OGC and the CS activities in the work plan of GEOSS.
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.
On the other hand, the Citizen Science Associations International Working Group on Citizen Science Data and Metadata that developed the (PPSR-Core), the ECSA has a working group that recognizes the value of standardization in the CS activities (supported by the 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 CS can be integrated into 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 CoP3
is about Interoperability of Citizen Science projects. WeObserve
project via its CoP
activities represents an opportunity to promote interoperability experiment in collaboration with the OGC. Such collaboration would address questions raised in the SWE4CS
discussion. In addition, it offers the possibility to directly feed the results into the OGC relevant standards and promotes their usage within GEOSS (as an important user community of OGC standards).
This activity is promoted and endorsed by the OGC Citizen Science Domain Working Group and:
(Old text. We are now using the Earth Challange 2020 as a scenario).
Technically speaking, the approach is applicable to any data type that a CS project may collect. During the kick-off meeting, and depending on the resources provided by the participants, a motivational scenario will be defined.
The scenario should propose the merging of CS projects datasets to cover a larger geographic area or coordinate topics in order to satisfy the needs of GEO in terms of providing data necessary to deal with climate change, measure the progress towards the Sustainable Development Goals (SDGs) and disaster management.
As a guiding example, the following motivational scenario could be inspirational. An outbreak of mosquito carried disease both in Spain and in Italy is detected. There is the need to create a global early warning system to monitor the evolution of the outbreak and prevent the contagious spreading of the disease. In the experiment, we discover the existence of some CS projects and we build an integrated database that is published and available through the GEOSS infrastructure.
(Old text. This needs to be defined on the context of the scenario)
The experiment will attempt to address the following experiments:
- Experiment #1: An expert needs to know the big picture about some topic, such as an outbreak of a mosquito carried disease or invasions of a particular alien species. They know that there is no (or little) authoritative data about the topic available, so they look for alternative CS projects that might provide the required data to analyze the problem at hand.
- Experiment #2: A conflated dataset is built based on local or regional CS projects data.
- Experiment #3: The expert travels to different places to analyze the situation on the ground and then report what they see in two different CS projects apps using the same user account.
The proposed experiment overview is described in this section. Changes to this architecture can be agreed at the beginning of the experiment depending on the participant in-kind resources involved. The intent, however, is to maintain the general concept.
The diagram illustrates an architecture that can support the 3 experiments indicated in the previous section:
In both sides of the upper half of the diagram, we can see several CS projects. Please note that the diagram is a simplification representing two CS projects (in both sides of the picture) but it can be extended to more CS projects. The projects have an API to communicate with its respective App and they also have an OGC SOS service that provides a standardized endpoint to get the data. The CS projects participating in the experiment will need to have or to incorporate a component enabling the SOS protocol and expose their data model following the SWE4CS
recommendations. They will also need to understand the utilization and evaluation of the O&M general model to encode human or machine related observations (as of the application profile provided in the SWE4CS
At the top we see a Single Sign On (SSO) federation component that enables the projects to share the same user account. Both the app and the server need to be connected to the SSO federation for authentication and authorization. In principle, the SSO federation shown in the diagram can be composed by more than one element (e.g. the NextGEOSS
SSO and the LandSense
federation) and this experiment can help determine existing technical barriers if any.
In the middle of the diagram (in orange) we see that a conflated database can be build by harvesting the data from the individual SOS services of the CS projects. This step might require some semantic mediation. This is represented by the fact that both are pointing to the same concepts in the CS-NA. Even if both projects use SOS services, in practice they probably expose different data models characterized by the particularities and objectives of the individual projects. They should have a common ground if the data shares the same data types.
This database can also be exposed as an additional SOS Service and this one is registered in a GEOSS regional data hub that is eventually connected to the GEOSS Platform (not shown in the diagram). The elements that are foreseen as part of the GEOSS Platform are represented in purple in the diagram.
The interoperability experiment will start by agreeing on a common architecture and a set of components inspired by the ones presented in the diagram but conditioned by the resources contributed by the participants in the experiment.
Face to face
Presentations at the OGC TC meetings
How we work?
OGC and WeObserve
have provided us with some resources:
- 28 Feb 2019
Documentation: The following documentation will comprise the deliverables for the project. All artifacts and results associated with the experiment will be made available to OGC members.
- Engineering Report discussing the details and results. The report will include but not be limited to summaries of the activity plan, test plan et al supporting documentation as appropriate.
- Change Requests for OGC Standards as appropriate.
- Candidate OGC CS Best Practices as appropriate.
- An Internet demonstration of all functioning components will be made towards the end of the experiment.
- This demonstration will be made persistent using the resources of OGC Network.
- A video recording of a public demonstration the experiment will be produced.
CitSciIE Web Utilities