9. A Conceptual Model for Participants and Activities in Citizen Science Projects

The spectrum of stakeholders (as identified by Göbel et al. 2017) who require reliable information about citizen science projects includes:

The requirements of the stakeholders listed above vary; for example, a certain level of interoperability is essential for government agencies as well as academic and research organisations. However, in the case of community-driven citizen science projects, the stakeholders are participants or informal groups who do not prioritise interoperability but need data to be provided in a user-friendly format.

In this chapter, we define a conceptual model as a representation of a knowledge domain or system, with which people can understand the meaning of its underlying concepts and which can be used by computer software to meaningfully process its related data. There are a variety of conceptual models, ranging from simple mind maps and concept maps (Novak and Cañas 2008) to complex ontologies (Simperl and Luczak-Rösch 2014). Commonly, concepts are described in terms of their definitions and the (labelled) relationships between them. In formal models, concepts are often called classes (e.g. ‘project’), and classes have specific examples, called instances (e.g. ‘OpenStreetMap’). All those elements can be represented visually (for human understanding) and in formal computer language (for data integration). In this chapter, we apply commonly used techniques from ontology engineering and concept map construction.

The core conceptual model elements and associated metadata presented here draw on previous research and existing vocabularies. In particular, they utilise the Public Participation in Scientific Research (PPSR) Common Conceptual Model (described in Bowser et al. 2017) and the core requirements in the associated conceptual model PPSR-Core.

The conceptual model developed in this chapter is intended to fulfil the needs of different stakeholders, as shown in several case studies. To address this requirement, we refined core elements of the PPSR model based on existing case studies; these informed the identification of additional core concepts.

The conceptual model presented is not the only model that suits the field of citizen science, but it provides a view of the technical aspects of the discipline in order to help stakeholders understand the domain and foster interoperability across applications. It is an evolving model that is becoming established via an international consensus process.

A number of models that allow projects to be described in general and scientific projects to be described specifically have been previously developed outside the citizen science community. Those models aim to represent knowledge about a subject domain such as relevant concepts and relationships between those in a very formal way (e.g. in terms of an ontology) or less formally by means of a controlled vocabulary. The following table gives an overview of these models and summarises which facets of projects and their participants they cover. The models listed were carefully considered when designing our conceptual model for the citizen science domain.

We will now summarise the models listed in Table 9.1. FRAPO describes projects and their outputs in terms of publications and datasets. SCoRO models the roles of project participants and their contributions. It allows the linking of individuals’ contributions to project outputs. PROV-O can be used to model projects, their outcomes, and how the outputs are produced and by whom. The Project Description Ontology extends PROV-O and is an attempt to model projects in a domain-agnostic way. FOAF can be used to characterise participants of a citizen science project. The FaBiO model is discussed in the next section.

FaBiO models published or publishable project outcomes such as scientific publications. The Project Documents Ontology (PDO) describes other project-related documents such as minutes and status reports.

A number of models provide descriptive elements for datasets. This includes the World Wide Web Consortium (W3C) Recommendation Data Catalog Vocabulary – Version 2 (DCAT)² that enables the description of datasets and data services in catalogues. More general specifications, such as Dublin Core,³ define elements for the description of arbitrary resources, not just publications.

Several conceptual models have been developed for the formal description of observational data and measurements as common outcomes of scientific projects, for example, in the life sciences and geosciences, but also in citizen science. A number of standards with overlapping semantics have emerged: the Semantic Sensor Network (SSN) Ontology,⁴ a joint standard of Open Geospatial Consortium (OGC) and W3C, that specifies the semantics of sensors and their observations, and its proposed extensions;⁵ the OGC/ISO Observation and Measurement (O&M) conceptual model;⁶ and the W3C Data Cube Vocabulary,⁷ focusing specifically on the representation of multi-dimensional data. The data model of OGC’s SensorThings API⁸ is based on the OGC/ISO O&M model and closely resembles it. Although several ongoing community-driven attempts aim to harmonise the description of observational data in order to facilitate data integration, none of the existing data models have been adopted by a scientific community as a whole. However, attempts have been made to link coexisting models by establishing mappings to align different models, for example, the SSN Ontology offers alignments to the OGC/ISO O&M model. An OGC discussion paper (Simonis and Atkinson 2016) gives a helpful overview of standardised information models with relevance to citizen science data and describes a data model for the exchange of citizen science sampling data based on existing standards.

In parallel, practitioners such as data managers of research data infrastructures have developed their own vocabularies and models that do not rely on existing standards. In the biomedical domain, several domain-specific data models have been developed. Those include the Extensible Observation Ontology (OBOE)⁹ (Madin et al. 2007) and the Biological Collections Ontology.¹⁰ There are hundreds of domain-specific metadata standards and data models facilitating the description of scientific data in specific scientific domains, for example, BioPortal¹¹ currently lists 838 ontologies in the biomedical domain. Finally, the catalogue of the Digital Curation Centre¹² lists numerous disciplinary metadata standards.

The development of the PPSR-Core model was driven by the requirements of the implementations available at the time. As a consequence, it is tied to these implementations, and a conceptual model allowing for better project content representation is still not available. In addition, PPSR-Core still includes some domain-specific properties, especially from the biodiversity domain. Since citizen science activities take place in different disciplines and focus on specific aspects that vary across activities, a model that tries to capture everything in the domain can become complicated and difficult to manage.

In order to exploit the citizen science knowledge encoded in PPSR-Core and, at the same time, overcome the above-mentioned drawbacks, we have developed a modular conceptual model for the representation of citizen science knowledge (see COST Action CA15212 Working Group 5 2018b). This model comprises different modules that are all linked to the Project.Core module that captures essential project information (see Fig. 9.2 for an overview of the structure of our conceptual model). The Project.Core module includes many properties imported from PPSR-Core, like project name, website, start and end date, etc., and unifies the other modules. These modules include:

Due to the wide scope of the main conceptual model for citizen science, it was developed in phases. In this chapter, our attention is focused on participation and participant activities in citizen science projects. Related initiatives from CSA, ECSA, ACSA, and OGC are accounted for and the model is tested with case studies.

Since the role of the citizens as participants is the main difference between citizen science projects and traditional research projects, in the following section, we will discuss the Project.Participant module in more detail.

Together, Table 9.1 and Figs. 9.2 and 9.3 outline all the concepts and relationships in the conceptual model related to the Project.Core and Project.Participant modules. Here, we describe a selection of the concepts; a full list of descriptions is currently under development and available in the model repository.¹³

At the heart of the Project.Participant module lie the relationships between the participants, their activities, their outputs, and the skills, knowledge, and tools required to perform them. A project has one or more activities, and these are performed by participants with a variety of roles and motivations, during a specified time range.

In the model, the Activity concept (see Figs. 9.3 and 9.4) represents activities that belong to a Project. A general activity, such as ‘Collecting data about bird migration’, may contain a number of tasks. A task is an activity with a specific goal and a limited duration (a kind of transaction), such as ‘Taking a picture of a bird and storing it in an image collection’ or ‘Validating a bird identification’. The description of a task includes details of the knowledge, skills, and tools required as well as the training available and its execution plan.

The Agent concept in Fig. 9.3 generalises the idea of participants to groups of people in particular organisations and to machines, such as sensors. An instance of the Agent concept represents a type of agent, for example, ‘registered Zooniverse user’ or ‘mapping agency’.

The Activity description includes its output (e.g. dataset, publication, software) that can be composed of a number of output items. A project may acknowledge the participation of an actor in the production of an output item. In this case, the description of an output item includes a link to the role played by the actor its production. The description of a Project also includes its participant recruitment technique and its privacy protection policy. The dataset as an entity is handled in our model as a specific type of output. Its details are described in a separate module (see Fig. 9.1), and although they are required for interoperability, they are beyond the scope of this chapter. The same holds true for the semantics of a dataset’s content, which is described in the Data Model (Fig. 9.1). Here we make use of existing standards, such as the underlying data models of the SensorThings API (Footnote 8) and the SSN Ontology (Footnote 4).

The concepts depicted in Fig. 9.4 cover participation and its requirements. The model does not claim to be exhaustive, but rather serves as a backbone. Each of the branches, such as tools and skills, can themselves be described by external models. The subclassification is also not exhaustive. Part a (Fig. 9.3) and part b (Fig. 9.4) are connected through the Activity concept.

After providing a short introduction to the four selected citizen science projects, we use our conceptual model as a skeleton for each specific project. Where applicable, the concepts (as depicted in Figs. 9.3 and 9.4) have been instantiated for each project; see Tables 9.2 and 9.3. In other words, a concept is assigned a project-specific value where possible and applicable. This means that specific projects, their activities, participants, data outputs, etc., are described with the help of the conceptual model. Using this common model allows the projects to be compared and combined, thus increasing interoperability between the projects and their elements. It should be emphasised that in the tables only a few examples are provided and that each entry in the table corresponds to a concept in the model, which is more than just a flat table. For example, a project can have multiple participation tasks, each using different tools; and a project can produce multiple, different datasets, and so on. We will now introduce our case studies.

In addition to the basic metadata provision outlined in the previous section, the conceptual model can be used as a structure for project-related activities. Two case studies are provided here.