dataesr/scientific-paragraphs-categorization huggingface dataset:
, 2006). As discussed in more detail in Chapter 2  (See et al. , 2017) , VGI can be collected either actively or passively. While in active projects users collect data in a conscious way, passive data collection happens when contributions are gathered without any active engagement  (Haklay, 2013). Similarly,  Harvey (2013)  has made a distinction between truly volunteered versus contributed geographic information (CGI). While the former refers to data that are collected with permission (such as an edit in the OSM database), the latter refers to data collected as part of an automated, open-ended or uncontrollable process (such as the tracking of mobile phones). Information contributed to a passive VGI project typically demands much more processing to result in meaningful information. It is possible to impose a set of protocols in active VGI, but this is usually not possible when using passive VGI or CGI, where the data volumes are often larger than in active sources and hence the data need to be filtered if they are to be used.
Updating and Collecting New Thematic Information in a Topographic Building Database In this example, an NMA is interested in exploiting crowdsourced vector data to improve their topographic building database. This improvement includes enriching and updating existing building objects (their geometry and thematic information) and capturing new building objects and associated thematic information. Buildings are typically very well mapped by NMAs, but the rapid pace of urban change can mean that keeping their database up-to-date is challenging in terms of resources. Additionally, the thematic information within these databases is often very poor. Typical information which is often missing includes: the function of the building, the number of floors in the building, cultural heritage information related to the building, the entrance(s), etc.
As an additional challenge and motivation for VGI contributors, the NMA seeks to create a new layer from scratch to represent the entrances to buildings. This will be a multi-point layer, since a building might have more than one entrance. In this example, the NMA decides to develop a Web-based application to allow citizens to collect data. The implementation and presence of a protocol for this application will greatly assist in reducing the potential submission of lowquality data. Specifically, the Web-based application will use digitisation and field surveys as the means of collecting vector data. The application will present contributors with three layers: a base layer consisting of up-to-date orthoimagery of the region represented in the database; an overlay layer of the existing topographic building object database; and a layer for the entrances to buildings.
The five steps of the protocol workflow outlined in Section 2 are applied to this example as follows: Initialisation -Citizens will need to register themselves on the Webbased application to use it and contribute vector data and information. Before collecting data, every contributor will need to complete all of the steps in a tutorial demonstration to understand which tasks are required and to familiarise themselves with the processes and tasks in general and with what the goals and objectives of the project are. Depending on the resources available, the NMA may develop a protected 'sandbox' version of the application, where contributors can test out the functionality of the application on a small subset of the topographic buildings database without actually making changes to the real database.
In the first mode, participants can take photographs at any location, so the geotagged photographs will be useful for creating LULC training datasets; in the second mode, participants will be sent to specific locations, or 'quests' in the form of photograph-caching, which can be used to satisfy the sampling needs of the NMA for LULC map validation and reduce the spatial bias that is common in geotagged photographs from social media photograph-sharing sites. As much as possible, elements of the protocol will be hidden or incorporated seamlessly into the workflow of the application through technology. In other cases, the protocol will be implemented via elements of gamification, which will be added to maintain, if not grow, the pool of participants and to create a certain level of competition among them, particularly for the photo-caching mode of the application.
g. Antoniou et al. , 2016) , this example is still largely hypothetical. However, a similar protocol for collecting geotagged photographs for LULC-related purposes is currently being tested by the FotoQuest Europe student campaign 7. This initiative asks volunteers to survey specific locations with the purpose of validating the official EU LULC datasets derived from the Land Use and Coverage Area frame Survey (LUCAS) performed by EUROSTAT 8. For more information on what geotagged photographs can offer, see Chapter 4  (Touya et al. , 2017)  on using geotagged photographs for examining OSM quality and for verifying the applicability and suitability of various cartographic processes.
Each of these datasets is generated/collected for an intended purpose (i. e. , to deliver some value for a beneficiary), and is dealt with in a particular way. In other words, it is 'managed' in one way or another -independently of the availability of any form of data management plan. The approaches by which data in general, and VGI in particular, are managed diverge greatly, and are highly dependent on the context of generation and use. For example, data collected locally in a field trip to teach a small group of students about digital cartography might be kept on an SD card, be copied to several desktop computers at the university and be deleted as soon as the course ends. By contrast, worldwide observations about species occurrences might be fed into a well networked structure in order to contribute to a global collection effort which will curate those data for generations of scientists and environmental organisations.
Although it might be debatable whether every single collected dataset should be preserved for potential future use, sharing of volunteer-generated data is a part of the unspoken contract with the original contributors that underlies citizen science, and can be crucial in maintaining the commitment of volunteers. Bearden (2007)  records how, in the absence of feedback on their mapping efforts, volunteer USGS contributors '… would become alienated when they realized that their meticulous work would not be used in the foreseeable future …'. In a broader context, if data are likely to be usable for science, then, following recent moves towards reproducibility, they must be made reusable. These requirements for repeatability, transparency and independent evaluation inevitably suggest a need to curate and preserve data collections.
Organising Data One of the very first challenges is the organisation of the data themselves. Before even considering the concrete storage format and structure used, it has to be decided at some point which items are considered data in an 'atomic' form, and how these items might be packaged. As we will see later in the chapter, these early decisions will impact other areas, such as the provision of (persistent) identifiers or the granularity of metadata (data about data). In the context of airborne imagery, the decision could be whether to make accessible as one unit a whole series of images from airborne imagery gathered in a single flight or whether to treat each single scene (image) as a single dataset. Analogously, a species observation could be put into a collection that unites all data relating to a particular day, person, sensor type (e.
Persistent Identifiers Data can only be unambiguously recognised -especially when they are shared with other people -if they can be uniquely and persistently identified. In other words, the data need to be branded in some way that does not change over time. If the data are to be accessible, it must also be possible to resolve that persistent and unique identifier into an appropriate data request. Without going into too much detail about the meaning of uniqueness and identity, it obviously makes a difference whether a persistent and unique identifier is assigned to every 'atomic' data item or to collections that apply any of the criteria listed above. The meaning of persistency also has to be challenged: which authorities can guarantee the persistency and uniqueness of identifiers? What if identifiers contain the names of institutions or groups that disappear in real life? Who can guarantee a service that resolves certain identifiers in order to retrieve the actual dataset? Furthermore, it has to be noted that in cases where unique and persistent identifiers are allocated to a data stream, for example one generated by a person or a sensor, the retrieved data will change over time.
Data Documentation Are we able to use a dataset that we created ourselves? Can we use it again a few years after we collected it? How are others supposed to find that dataset, understand what it really encapsulates (and assess if it might be valuable for their work), access it and provide their experiences and impressions about it? The answer to all of these questions lies in metadata, or, in other words, the appropriate documentation of data -an answer which is more easily given than implemented. Documentation is required for a wide range of purposes (e. g. discovery, evaluation and use), and therefore possible forms of documentation vary greatly. Here, again, the packaging of VGI is one determining factor, since one might document a range of possible 'entities' , for example: a single observation; observations from one person (including also a description of that person); and VGI collected for a particular area (including also documentation about the area).
A dataset stored as a collection of individual observations or measurements might include information about the accuracy of each single value; it has to be determined how this accuracy information is then propagated to a collection of measurements in order to achieve an overall quality measure for the dataset. If a user is filtering this dataset for potential use in an analysis and their fitnessfor-purpose criteria include accuracy, then, in theory, this aggregate measure of quality should be recalculated for each candidate set of observations -a considerable challenge for the architecture within which the data are being curated and made accessible for discovery. To give another example, in a VGI dataset where observations can be attributed to an individual, the documentation might include the reputation of this individual in the context of a particular activity or community; but how should such values be propagated when talking about a group of people? At the time of writing, accessible and robust tools for this type of aggregation are lacking.
Another important feature of documentation is the semantics used to describe what is actually being measured. Terms and units that are implicit in one domain are often taken for granted, and not necessarily well recorded for communication with potential users in other fields. For example, the choice of code list, (i. e. determined terminologies of a particular community) to constrain keywords about a data collection might hinder others in finding the data collection because they use other words to say the same thing, or might confuse people expecting something completely different because they use the same word to say something else. Only where semantic mappings between code lists are available can these cross-domain discoveries be made possible and reliable. Such 'cross-walking' initiatives are very valuable, because, by contrast to free text, which is complicated and laborious to parse and mine, code lists and restricted vocabularies are extremely valuable ways to speed up the filtering and fitness-for-purpose assessment of datasets.
Natural language processing is powerful and becoming more so, as can be seen from the increasing support for automated systems such as chatbots. However, these systems model primarily social contexts, and are not yet coupled to the kind of semantic matching and inference that are needed to distinguish the correct context in which a word is being used to describe an indicator, unit of measure or phenomenon across different scientific fields. For example, if a user is searching globally for datasets that include numerical estimates of uncertainty or variability, they could search for free text descriptions that include terms such as 'variance', 'standard deviation', 'ecart-type' or 'intervalo de confianza'. However, the presence of such words does not guarantee that variability is indeed mathematically described within the dataset, since, for example, the word 'variance' can also be used in a qualitative sense.
By contrast, a URI 6 identifies, via the vocabulary server of the UK's National Environmental Research Council, a definition of 'variance' that is explicitly mathematical and that can be related to other defined statistical concepts, across spoken languages and scientific domains. A similar clarification of terms such as 'sea level' can be seen at the SeaDataNet vocabulary server 7. For this reason, many classic metadata elements allow free text only for titles and descriptions but require selection from code lists for everything else. We will consider some examples of this practice below, in the section relating to standards. However, there are times when there is no substitute for humanreadable material such as manuals and descriptions of research methods, and so methods for adding or linking these to VGI datasets as annotations must be considered.
Such documentation can encourage the dissemination of a dataset and might raise the reputation of those who created it -see, for example, the first publication within the newly established geospatial dataset description section of the International Journal of Spatial Data Infrastructures Research 8 , or the recently launched Data in Brief journal 9. Such documents can convey organisational priorities that are hard to capture otherwise: they can help others to understand the deeper intentions behind why a dataset has been collected, and the reasons for organisational decisions, thereby contributing to the understanding of the overall purpose and potential reusability of a dataset. Last but not least, it should be considered whether feedback can be collected on the dataset (at whatever level of granularity the packaging allows).
Sharing -With Whom? The management and curation of datasets not only is an exercise for those gathering and hosting data, but also benefits the users, whether those are the originally-intended beneficiaries or new user groups that find value in reusing a dataset for their own purposes. Access and use conditions may vary -e. g. depending on privacy and legal issues (see also  Chapter 6, Mooney and Minghini, 2017  on privacy, legal issues and ethics), commercial interests, or an organisation's commitment to Open Science. However, VGI can only be exploited to its full potential if these conditions are clearly articulated and, ideally, accompanied by the relevant licences. The decision to integrate or split VGI into collections will have an impact here, since permissions on different elements of a VGI dataset could be different, meaning that different consumers would access different collections of records.
Having persistent identifiers and a minimum set of documentation (including contributors, title and release date) in place also enables proper data citation -an element that should not be underestimated. On the one hand, citable VGI allows clear reuse, since reference can now be made not only to other scientific articles, but also unambiguously to data used within a particular activity. On the other hand, data citation also provides a means of acknowledging the source -thereby contributing to the recognition of the data contributors and owners and providing an incentive for the provision of metadata and curation of VGI. It is likely that new metrics for scientific reputation (altmetrics) will very soon take these achievements into account; the cross-referencing of datasets and the numbers of citations will become essential measures of impact.
Persistent identifiers are unique strings of numbers and/or characters that are assigned to a digital resource (e. g. datasets, documents, images) in order to allow long-term, reliable access to that specific item. Persistent identifiers should ideally be managed separately from the physical location of the resource, ensuring the continued accessibility and discoverability of the resource 'no matter how many times the object moves to different servers or property rights owners' (USGS, 2017). Actionable persistent identifiers permit access to the resource via a link, which should remain resolvable for the long term. An example that is widely used in the scientific domain is the Digital Object Identifier (DOI; ISO standard 26324:2012) 13 , which allows published documents and datasets to be tracked and cited, and which is assigned to journal publications (or prepublications) by CrossRef 14 , Figshare 15 , Zenodo 16 and other platforms.
Recent moves towards data DOIs have been hugely supported by initiatives such as DataCite 17 , NOAA's EZID 18 , or DryadLab 19 , which enable a data producer to mint a DOI and, in some cases, register associated metadata. An example current practice for VGI is the ability of the GBIF website to produce and maintain a DataCite DOI for a specific user request, guaranteeing that this request can be reliably repeated at a future date. Different query filters (date, type of record, species' scientific name, country, etc. ) are collated and stamped with a DOI, which is supplied to the user to ensure future retrieval of records according to the same filters. A DOI can be allocated at a level of granularity specified by the user, but the maintenance of relationships (e. g. hierarchical 'nestings' of DOIs) is the responsibility of the resource owner, and can be challenging.
The ability to discover related datasets in this way is extremely powerful, and can support the Linked Data approach described more fully in the next section. Attention to versioning is also important: a DOI may represent the final version of a resource, approved for release; an extension or annotation of a resource; or a model/algorithm version used in a reproducible workflow (in this context, a github or subversion version ID can be adapted to fulfil at least some of the role of a DOI). However, there are cases where a DOI will always return 'the latest version' of a resource, and, here, scientific reproducibility is not guaranteed. GBIF DOIs are a good example: the data underlying a query are regularly improved and updated, and historical records may be retrospectively added, meaning that the exact same set of records is not guaranteed to be returned when a DOI is used at a later date.
It is possible to embed dataset identifiers within metadata using existing geospatial metadata standards, such as ISO 19115 20 , which offers a CI_Citation element that allows an identifier such as a DOI to be supplied in a structured manner and to be associated with a namespace that can help to ensure the uniqueness of the identifier. However, the real-world practice is less consistent, as evidenced when exploring records in the GEOSS Common Infrastructure (GCI): here, metadata and data identifiers are found in a wide variety of locations within catalogued metadata documents, and are sometimes completely absent. This problem is more cultural than technical: because ISO 19115:2003 is not completely clear about the difference between data and metadata identifiers, and lacks a clear recommendation on the use of Unique and Universal Identifiers (UUIDs), profilers have generated a variety of different identifiers (if they have generated them at all in the first place) and have located these identifiers in at least four different locations within metadata documents  (Maso, 2013).
I3. (meta)data include qualified references to other (meta)data R1. 2. (meta)data are associated with detailed provenance In the above section, we described potential ways in which the identifier of a dataset can be embedded in a traditional geospatial metadata document. However, an important consideration in the context of VGI is the rather complex and laborious nature of generating such 'traditional' metadata documents, which require a significant investment of time and effort. Geospatial metadata standards such as  ISO 19115/19157  and FGDC offer a rich and expressive range of descriptive elements, but the reality is that many VGI initiatives are unlikely to generate such detailed documentation. In the face of this reality, other, more lightweight alternatives are likely to be taken up.
The standard and schema implementations of ISO 19115/19157 allow for a series of such ProcessSteps to be combined to generate a highly detailed, and, to some extent, machine-readable description of a dataset's provenance. However, in practice, the rich array of available elements are rarely used as intended, and it is far more common, if a lineage statement is provided at all, to see a single ProcessStep with a long and descriptive text account of the means by which the data were produced. This is in part because of the basic nature of many editing tools for ISO metadata and the lack of best-practice examples, but it is also evidence of the investment required to generate detailed metadata compliant to standards, and of the fact that this investment is not always budgeted into research projects -especially not citizen science projects.
0 came with an encoding in the Resource Description Framework (RDF) -can be adapted to include provenance information on a dataset. This strategy is of particular interest because it could be used to improve or enrich data documentation after data are published, or when they are reused for a different purpose than the original intended use case. For example, user reviews, reports of usage, discovered issues relating to particular observations, spatial regions or observers could be attached, post-hoc, to a published dataset and used in filtering and assessing fitness-for-purpose. Initial research along these lines can be seen in the outputs of the CHARMe project 23 , which adapted the proposed OGC Geospatial User Feedback standard  (Maso and Bastin, 2015)  to permit lightweight annotations to be added to climate data in order to document quality issues, anomalies and user opinions on the value of the data.
Another promising approach is the use Namespaces and XML-specific formatting have been removed for clarity. of the W3C PROV specifications in combination with RDF triples to create queryable databases representing the steps by which a dataset has been generated. A particular advantage of this approach is its amenability to extension when products are derived by some process which needs to be documented. In particular, the documentation of uncertainty introduced by data processing has been explored by  Car et al. (2015) , who combined UncertML  (Williams et al. , 2009)  -a model and schema for documenting probabilistic uncertainty -with the PROV-O provenance ontology in such a way that quality issues in multi-part datasets can be encoded, and automated uncertainty propagation is made much more feasible.
Most of the 'biodiversity standards' are being developed in the context of the Taxonomic Databases Working Group (TDWG) 38. The principal workflow within the GBIF (2011) infrastructure is described as follows: 1. Digitization: The initial capturing of information in electronic form, through imaging, databasing, maintaining spreadsheets etc. 2. Publishing: The act of making data sources available in a well known format (standard) and with appropriate metadata for access on the internet. 3. Integration: The process of aggregating published datasets, applying consistent quality control routines and normalizing formats. 4. Discovery and access: By building network wide indexes, discovery services are offered for users through portals and for machines by extensive web service APIs (GBIF, 2011).