dataesr/scientific-paragraphs-categorization huggingface dataset:
This leads to relevant cost savings due to the low number of sensors to be installed and the management costs related to the sensor network. In this way, it is possible to reach a significant compromise between an extensive instrumentation of cities and the availability of information at any time and everywhere. The advantages of HybridIoT over the state of the art are the heterogeneity, openness and scalability. Heterogeneity enables to integrate different types of devices that could perceive different types of information. Openness enables sensing devices to enter or leave the system without the need for any re-configuration. Cooperation enables agents to exploit the data acquired from a multitude of devices to estimate missing information. We carried out experimentations using both homogeneous and heterogeneous information of a real weather dataset, and compared the results of endogenous estimation to state of the art techniques.
After identifying initial themes from the coding process, the ways in which the themes connected were considered. Axial coding revealed a transactional relationship between themes  [75]. The research team met and discussed the data to decide how the themes related to each other. Through this discussion, the themes of social and institutional resources were found to interact with the daily life demands in such a way as to support or inhibit the mother's desired infant care practices. Descriptive statistics were run in SPSS (Version 25; IBM Corporation, Armonk, NY, USA, 2017).
The field survey This study was conducted within the framework of the larger ongoing i-Share cohort study (Internet-Based Students Health Research Enterprise, www. i-share. fr), a French nationwide Web-based survey on the health and well-being of university students, whose principal investigators and operational staff are based at the University of Bordeaux  (Montagni, Qchiqach, Pereira, Tully, & Tzourio, 2018). The field survey consisted in a paper questionnaire administered face-to-face by five undergraduate students (interviewers) who had been trained to take notes, fill in the questionnaire and describe the app to respondents. Interviewers approached their peers in the halls, canteen, courtyards, library and study rooms at the health sciences campus of the University of Bordeaux. The collection of the data started on September 25 th 2020 and ended on October 16 th 2020.
The field survey was approved by the University of Bordeaux. The oral informed consent reassured students of the anonymous format of the survey and use of collected data for research purposes only. All data from the paper questionnaires were entered by the student interviewers in a digital database through the EpiData® software version 3. 1. A descriptive analysis was performed, presenting all variables and measures in the form of numbers and percentages for qualitative variables and mean and standard deviation (SD) for quantitative variables. Chi2 or exact Fisher frequency comparison tests were used to identify statistically significant differences by age, gender, field and year of study, modified, if necessary, to binary variables. Statistical significance was defined with a p-value < 0.
Principal findings and interpretation One student out of five had never heard about the StopCovid app: this rate is surprisingly high considering that students in the health domain should be informed of existing tools to limit the spread of coronavirus. Of the students having heard about the app, mostly through the media, 15% had actually downloaded the app and, in the whole sample, only about 5% were still using it at the time of the survey. These percentages confirm the low uptake of the StopCovid app as reported by national statistics. Main reasons for not downloading the app were that it was deemed poorly interesting and ineffective since very few people were using it. False beliefs were also present: one student out of six had not downloaded the app for fear of being geo-located and that personal data could be collected and shared.
Differences between the results of our study and those of the multicountry study might be explained by the study population (general population vs young people) and the fact that the app presented in the multicountry study was hypothetical vs a real app. Furthermore, in the multicountry study, concerns about cybersecurity and privacy, together with a lack of trust in the government, were mentioned as the main barriers to adoption. Distrust in data security and fear of being geo-located were also reported by our sample, even if not as the principle reason not to use the app. The main reason for not using the app was its potential lack of effectiveness. Controlling Covid-19 requires a high population uptake of automated contact-tracing apps (estimates from 56% to 95%)  (Braithwaite et al. , 2020).
ACKNOWLEDGEMENTS The project is led by the  University of Bordeaux , in close collaboration with the  University Hospital (CHU) of Bordeaux , the  Regional Health Authority (ARS) , and the  National Institute for Research in Digital Science and Technology (Inria). The authors wish to thank the i-Share team (www. i-share. fr)for managing and conducting the study and for revising the questionnaire:  Julie Arsandaux ,  Fadi El Khoury ,  Shérazade Kinouani ,  Mélissa Macalli ,  Elena Milesi ,  Marie Mougin ,  Garance Perret  and  Clothilde Pollet. Within the i-Share team , the authors wish to thank especially  Edwige Pereira  and  Aude Pouymayou  for their support for statistical analysis. The authors are also indebted to the student ambassadors that carried out the field survey:  Idriss Boukili ,  Justine Char ,  Jade Giacosa ,  Oleg Hounkpatin ,  Jeanne Langlois  and  Marie Lanneluc.
Funding statement The i-Share team is currently supported by an unrestricted grant of the Nouvelle-Aquitaine Regional Council (Conseil Régional Nouvelle-Aquitaine) (grant N° 4370420) and by the Bordeaux 'Initiatives d'excellence' (IdEx) program of the University of Bordeaux (ANR-10-IDEX-03-02). The team has also received grants from Public Health France (Santé Publique France, contract N° 19DPPP023-0) and the Nouvelle-Aquitaine Regional Health Agency (Agence Régionale de Santé Nouvelle-Aquitaine). The funding bodies were neither involved in the study design, or in the collection, analysis, or interpretation of the data.
A catalogue that includes online training material for journalists would be useful. In earlier work, we designed and implemented a prototype catalogue for geospatial OERs, aimed at a target audience in higher education, such as universities, and members of the International Society for Photogrammetry and Remote Sensing (ISPRS) or GeoForAll. Requirements for the catalogue were collected by qualitatively reviewing our needs as educators. The prototype catalogue (https://isprs. education/) was developed using the latest web application technology. Once the basic functionalities were available, approximately 100 geospatial educational resources were identified and added to the catalogue  (Rautenbach et al. , 2019). The success of search and discovery in any catalogue relies heavily on the metadata about the educational resources.
Metadata Educational resources can only be 'discovered' and reused if there are accurate descriptions about them, i. e. , metadata is required  (Roy et al. , 2010). Roy et al. , (2020)  reviewed several metadata standards for describing e-learning material, including Dublin Core  (ISO 2009) , the IEEE Learning Object Model (LOM)  (IEEE, 2002)  and metadata standards developed by the IMS Global Learning Consortium (http://www. imsglobal. org/), Advance Distributed Learning Initiative (http://www. adlnet. org) and CanCore Learning Resource Metadata Initiative (http://www. cancore. ca/). They found that most learning object repositories at the time implemented IEEE LOM. Metadata provides a description of data or objects and is often maintained in catalogues where it can be searched and filtered.
Over the years, several schemas have been proposed as blueprints for metadata. Such a schema specifies metadata elements and relationships between them. In the paragraphs that follow we briefly introduce the metadata schemas included in the usability assessment describe in this paper. Dublin Core (ISO 2009) is a widely used general-purpose metadata schema than can be used for both digital and physical objects. It contains 15 well-defined elements for describing any digital or physical object, but it does not cater for the pedagogical aspects of educational resources  (Roy et al. 2010). We included Dublin Core because it is widely used in all kinds of online catalogues. The IEEE Learning Object Model (LOM)  (IEEE, 2002)  is a metadata schema developed for the purpose of describing objects used for learning, education or training.
It comprises nine categories of metadata, and each category consists of several metadata elements that help to describe pedagogical aspects of the object, such as learning resource type, interactivity level and intended end user. The IEEE LOM schema is rather extensive, providing metadata elements to describe every possible aspect of a learning object, but sometimes a simpler schema is easier to maintain. In this study, we only included those IEEE LOM elements that were implemented in the prototype catalogue  (Rautenbach et al. , 2019)  ISO 19115:2003, Geographic information -Metadata, defines a schema for describing geographic information and services. It contains metadata elements to describe the "identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data"  (ISO 19115:2003).
We included  ISO 19115:2003  in this study because of the lack of geospatially related metadata elements in the Dublin Core and IEEE LOM metadata schemas. The ISO 19115 standard is widely used in the geospatial community to describe geospatial data and services  (Brodeur et al. , 2019). For example, Research Data Australia (RDA https://researchdata. ands. org. au/) provides access to metadata for more than 140,000 data collections across various domains and the Australian Urban Research Infrastructure provides access to over 5,000 datasets described according to ISO 19115 metadata elements  (Delaney and Pettit, 2014; Pettit et al. , 2015; Pettit et al. , 2020; Sinnott et al. , 2014). One example of an AURIN data hub is CityData (https://citydata. be. unsw. edu. au/), comprising approximately 50 researcher-created datasets (as of 1st May 2020), an important digital asset to support city planning  (Goodspeed et al.
Prototype catalogue for geospatial OERs For the prototype, we reviewed the two well-known metadata schemas, Dublin Core and IEEE LOM, and decided to work with a subset of 20 of the 60 metadata elements from the IEEE LOM. We evaluated various existing applications, including Islandora, ePrints, AtoM, Zenodo and DSpace, for implementation of the catalogue. Although all of the evaluated applications had useful characteristics, two requirements were not fulfilled in any of these: the implementation of a profile of IEEE Standard for Learning Object Metadata  (IEEE, 2002) ; and creating a metadata record without the need to upload a file. Strictly speaking, the majority of these applications are implementations for a repository (a place where things are deposited or stored) and not for implementing a catalogue (a list of descriptions of things).
This motivated the design and development of a custom catalogue. The prototype was built on Google's Firebase platform, a backend-as-a-service (BaaS). Firebase was selected as it would handle the data storage (as JSON objects), authentication (with OAuth2), and hosting of static files. An advantage of this configuration is also that our needs do not exceed what is offered on the free tier (Spark Plan) and this contributes to the long-term sustainability of the catalogue. The front end of the prototype was developed in the React JavaScript Framework. React selected as it not only improves the development speed with reusable components but also improves the performance with optimized rendering algorithms. The JavaScript library for creating user interfaces allows the developer to break up the interface into components that can be updated without updating the entire page.
Additionally, React also made it possible to create responsive interfaces that automatically adjust to the resolution of the device they are viewed on. At the moment, the prototype is functional and allows any user to search for and view a resource in the catalogue. For the prototype, only users who sign-in with a Google account can add new resources. This is an interim security measure put in place to prevent bots from adding spam to the catalogue. In the final version of the catalogue we intend to add a user management feature where people can sign up with their institutional emails, or other email accounts of their choosing. In the prototype, all metadata attributes are required (mandatory) when adding a The user is assisted with tooltips that provide hints, based on the IEEE LOM standard, to explain how some of the attributes should be populated.
METHOD To find out which metadata attributes (elements) are useful for describing and/or searching for educational resources, we asked each co-author to do the following: 1. Write down a description of a geospatial educational resource that you could use for one of your modules/courses. 2. Use one of the search engines (Google, Bing, etc. ) to search for such a geospatial educational resource. a. Write down the keywords that you used. b. Once you have found a resource, record the URL and write down the information (concepts / descriptors / keywords) that made you decide whether to use it or not. 3. Add metadata according to Dublin Core, OER Commons, and IEEE LOM elements used in the prototype and ISO 19115 for two or three geospatial educational resources. For each, explain which attributes were useful, which were obsolete, and which were difficult to fill in.
Using search engines to find educational resources The kind of educational resources that participants searched for included tutorials, datasets, case studies, software and online courses. Most participants included a keyword related to education, e. g. , 'training', 'tutorial', 'course' and 'teaching', when searching for an educational resource, but not all of them. As web searches go, the first list of results was not necessarily what participants were looking for, and they followed different strategies to iteratively refine the search until they found what they were looking for.
Dublin Core: Contributor (entity responsible for making contributions to the resource): There was confusion between this attribute and the creator attribute. In most cases, participants assigned the same value to both. Coverage (spatial or temporal topic of the resource, spatial applicability of the resource, or jurisdiction under which the resource is relevant): Participants used this attribute to specify a spatial coverage (e. g. , 'Australia') or topics covered (e. g. , 'spatial database management'), and in some cases, this attribute was irrelevant (e. g. , for technical educational material on mobile data collection, where a specific area is not relevant). Creator (entity primarily responsible for making the resource): As indicated above, this attribute was confused with the Contributor attribute.
Source (related resource from which the described resource is derived): In most cases, this attribute was not used. Subject (topic of the resource): Together with the Type and Description attributes, this attribute was used by all participants to help describe the purpose or intent of the educational resources, e. g. , 'using spatial databases and SQL to analyse the data' and 'User studies in the field of geoinformatics'. Title (name given to the resource): All participants used this attribute. Type Subject Areas (Applied Science, Arts and Humanities, etc. ): All participants used this attribute. However, in some cases more than one value was required to describe the resource, and the values ranged from very specific (e. g. , user studies) to very broad (e. g. , urban geography). Such information could be included equally well in a set of tags or keywords.
IEEE LOM elements used in the prototype: The following attributes are identical to the Dublin Core attributes: Title, Description, Language; and these attributes were used in the same way as corresponding attributes in Dublin Core: Authors, Copyright. The following attributes were used similarly to how they were used in the same way as corresponding attributes in OER Commons: End User (Author, Learner, Manager, Teacher), Keywords. They are therefore not further discussed here. Date: All participants used this attribute, some for a year, others for a specific date, or for an update cycle (e. g. , 'monthly'). Date added or updated: All participants filled this attribute with the date of adding the information, and in the prototype the data is automatically added. Duration: All participants used this attribute, although some could only estimate the duration.
ISO 19115: The following attributes are identical to the Dublin Core attributes: Title, Language; and these attributes were used in the same way as corresponding attributes in Dublin Core: Abstract, Distribution Format, Responsible Part. These attributes were used similarly to how they were used in the same way as corresponding attributes in OER Commons: Metadata datestamp, and these similar to how they are used in the prototype: Online resource. They are therefore not further discussed here. File Identifier (unique identifier for this metadata file): Some participants used this attribute in the same way as the URL attribute in other schemas, while quite a few did not use this attribute or filled it with a question mark, suggesting that there was some confusion how to use it. Reference Date (date for the cited resource): Participants used this date in different ways.
Some recorded the date when the metadata was recorded, others may have used it as the publication date. Geographic location (geographic area of the dataset): Similar to the Coverage attribute in Dublin Core, participants used this attribute to specify a spatial coverage (e. g. , 'Australia') and in some cases did not assign a value because it was irrelevant (e. g. , for technical educational material on mobile data collection, where a specific area is not relevant). Character Set (full name of the character coding standard used for the metadata set): No participant used this attribute. Topic Category (main theme(s) of the dataset): Some participants used this attribute in the same way as the Subject attribute in other schemas, while quite a few did not use this attribute, suggesting that there was some confusion about how to use it.
Quite a number of attributes from ISO 19115 turned out not to be useful for describing educational resources. These attributes are useful for geographic data, but probably too detailed to describe educational resources. Very few participants used these attributes, such as Spatial Resolution (factor which provides a general understanding of the density of spatial data in the dataset), Spatial Representation Type (method used to spatially represent geographic information), Reference System (description of the spatial and temporal reference systems used in the dataset), and Lineage (information about the events or source data used in constructing the data specified by the scope or lack of knowledge about lineage).
The values also have to be applicable globally. Our choice of attributes and lists of values were guided by these observations. Including a Digital Object Identifier (DOIs) as metadata attribute in the prototype catalogue can assist with making educational resources more discoverable through both general purpose and library search engines. However, our results show that a DOI is seldomly assigned to educational resources. Even though there are commonalities between metadata schemas for educational resources and geospatial resources, the results show that educational resources cannot be described in the same way as geospatial data and services. Metadata about geospatial data requires very specific elements, for example the spatial resolution or lineage, which are essential for data but not relevant for an educational resource (unless it is a dataset).
Also, many catalogues and portals for geospatial data already exist, and the aim with our scientific initiative is not to replace those catalogues but to link or integrate them. For example, one could include in the catalogue a single educational resource with metadata about a geoportal for geospatial datasets. Such an entry in the catalogue could help instructors to find real world datasets for use in their teaching material. We also asked ourselves whether a catalogue with a search and filter interface is really needed. Katumba and Coetzee (2017)  showed that geospatial catalogue items published as HTML pages marked up with Schema. org and Dublin Core improved the visibility and facilitated the discovery of geospatial resources on the Web. Most people use search engines such as Google and Bing when they look for something on the Web.
If there is more relevant information about a webpage, it is easier for search engines to understand what the page is about, and the page can be ranked more appropriately in search results (UK Geospatial Commission, 2020). In other words, our prototype catalogue could be used to add, moderate and maintain metadata about geospatial educational resources, which could then be made available for harvesting by other catalogues. The catalogue information could also be made available in a format that web search engines can index. Both of these approaches would enhance discoverability of geospatial educational resources. The concern with search engines is that with the vast volumes of information on the Web, it is a challenge to identify educational resources of good quality. Google's solution to the quality challenge for datasets returned in search engine results is Google Dataset Search (https://datasetsearch.
research. google. com/). Datasets (e. g. , a CSV file, images, data in proprietary format or even training parameters for machine learning) are indexed in Google Dataset Search if a metadata file (i. e. , JSON-LD, RDFa or microdata) to describe the dataset is available on the Web. There are strict quality guidelines to be adhered to, otherwise the dataset may be marked as spam. A similar approach for educational resources would also solve the quality challenge. A catalogue that is moderated by a community of educators (e. g. , members of the GeoForAll or the ISPRS Commission on Education) can overcome the quality challenge.
(nature or genre of the resource): Possible values for the 'Type' attribute in Dublin Core are Collection, Dataset, Event, Image, Interactive Resource, Moving Image, Physical Object, Service, Software, Sound Still Image, Text. Since participants were presented with a free format field, they used this attribute to describe the kind of resource, e. g. , 'tutorial', 'lesson plan' or 'assignment'. Material Type (Activity/Lab, Assessment, Case Study, Dataset, Diagram/Illustration, Full Course, Game, Homework / Assignment, Interactive, Lecture, Lecture Notes, Lesson, Lesson Plan, Module, Primary Source, Reading, Simulation, Student Guide, Syllabus, Teaching/Learning Strategy, Textbook, Unit of Study. All participants used this attribute. While the Dublin Core metadata attribute is free text, in the OER Commons a list of possible values specific to educational material is provided.