dataesr/scientific-paragraphs-categorization huggingface dataset:
78 km on each side of the current (recorded) position of the plane as it maintained course on the track line. Marks indicating a distance of 2. 78 km from the plane at the target survey altitude (305 m) were placed on the plane struts to aid in estimating this distance. Vessels beyond 2. 78 km were not recorded, and it is assumed that all recreational vessels within 2. 78 km were detected. One limitation of the data set is that there is no information identifying individual vessels, and therefore, it is not possible to determine if a vessel was observed multiple times. For the purpose of this study, recreational vessels comprise open fishing (center-console) boats, runabouts (speed boats, Cigarette, Scarab, etc. ), offshore sport fishing boats, sailboats, charter and head boats, and yachts.
Data analysis We used estimates of relative North Atlantic right whale occurrence from  Gowan and Ortega-Ortiz (2014). They found that the probability of observing a North Atlantic right whale could be modeled using sea surface temperature (SST), water depth, survey year, distance to shore, distance to the 22°C SST isotherm, and an interaction between time of year (i. e. , semimonthly period) and northing (see Gowan and Ortega-Ortiz 2014 for details). Estimates of relative North Atlantic right whale occurrence probability were produced for semimonthly (approximately 2-week) periods. However, we averaged these semimonthly estimates within each month to fit the monthly temporal resolution of the current study. Monthly estimates of recreational vessel abundance were obtained using generalized additive models (GAMs) applied to vessel sightings and explanatory variables that were selected based on previous studies.
To assess for collinearity among explanatory variables, Pearson's correlation estimates were produced in R software using the PerformanceAnalytics package  (Peterson et al. 2018) , and correlated variables (r > 0. 7) were not included in the same models  (Dormann et al. 2013). Model selection was determined by Akaike information criterion corrected for small sample size (AICc). The MuMIn package  (Barton and Barton 2015)  was used to obtain AICc values and AICc weights. Relationships between recreational vessel sightings and environmental covariates were modeled with GAMs using a negative binomial distribution and logit link in R software using the mgcv package  (Wood 2001). Poisson, hurdle, and zero-inflated models were also tested, but we found them less appropriate based on the overdispersion of residuals.
For the GAMs, a penalty term was added to the regression to control for the smoothness of the fitted curve and avoid overfitting  (Wood 2006 ). The smoothness selection was fit using spline-based penalized likelihood estimation with the restricted maximum likelihood (REML) method  (Wood 2006 ), and forward model selection was carried out using the double penalty approach to smooth and remove irrelevant covariates from the model  (Marra and Wood 2011). Overdispersion of the residuals for each competing model was assessed using the overdispersion function in mgcv  (Zuur 2012 ). Autocorrelation of residuals was estimated using the gstat package (Pebesma 2004). Once we had selected the best-fit GAM, we used it to predict the abundance of recreational vessels across the gridded study area. We modified the approach used by  Vanderlaan et al.
(2009)  to obtain monthly estimates of the relative probability (P rel ) that a whale (Eq. 1) and a recreational vessel (Eq. 2) occupied a specific grid cell i: Maps displaying the monthly index of relative encounter risk were generated using ArcGIS Pro. Direct observations of North Atlantic right whale/vessel interactions (cooccurrence) were recorded by the EWS during surveys. These interaction reports are considered conservative estimates, as they consist of presenceonly data and are limited to times and areas with survey effort, but their locations were overlaid on maps of model-predicted relative encounter risk for qualitative comparison. P.
Acknowledgments: This work was supported by the Southeast Regional Office NOAA Fisheries Services pursuant to National Oceanic and Atmospheric Administration Award number NAI00R4170079, by the University of Florida, and by the Florida Sea Grant College Program. We would like to thank Barb Zoodsma and all those involved in the Early Warning System for the job that they do and for sharing the data they record on the spatial distribution of right whales and recreational vessels. This project would not be possible without their efforts and support.
This article falls within the related areas of climate services and geographic information. We present the architecture and features of the Data and Knowledge Platform (DKP), innovative geographic software that was designed as support for climate-service elaboration in the context of change on given geographic areas. It is intended for a community of stakeholders who need visual and geographic tools to design services improving the resilience of society regarding specific local issues. The platform provides different functions for seeking all available geographic information. Anticipating large volumes of data that are to be stored, we opted for a NoSQL database rather than a textual repository. In this paper, we present the different features of the platform and its ability to support visual climate service co-design, and we illustrate our statement with an example.
At the first stage of the development and all along its life cycle, available related structured and unstructured data are potentially useful to extract information related to its geography. For its part, the geographic-information-retrieval (GIR) domain combines both objectives of Information retrieval (IR) and geographic-information systems (GIS), and deals with the challenges of extracting geographic information from unstructured-data volumes, generally on the web. CS and GIR domains share this intrinsic geographic nature. Among multiple challenges posed in the relatively new field of GIR is the development of user interfaces that facilitate the search for information  [3, 4]. The platform presented in this paper is part of this theme. We present the architecture and features of the Data and Knowledge Platform (DKP) geographic software that was conceived as support for climate-service elaboration in the context of the global change impact on given geographic locations.
• providing support to CS providers in the search for geographic information; • storing voluminous and geographically labelled data of various types thanks to a very flexible NoSQL data structure; and • defining a user interface mainly on the basis of geographic views extracted from its data. The platform was built within the framework of European project INNOVA (European Research Area for Climate Services, ERA4CS). The INNOVA project (https://www. innovaclimate. org/) considers climate-service innovations for transformational adaptation in addition to incremental adaptation. The project is organized around four local case studies called hubs, connected across the project. Each hub focuses on a specific geographic area in Europe, including overseas, on which climate-change impact is particularly awkward.
While the current version of the DKP is only dedicated to the four INNOVA hubs, it is easily extended to any new similar case of CS design for which this task may be facilitated by the visualization of climate impact and correlated geographic information to address local climate-related risk issues. The DKP design is generally intended to support CS suppliers in their task by allowing to: (a) gather georeferenced information on a given local climate-change case study for further design of solutions towards mitigation, (b) explore climate data and other categories of digital data into a geographic framework, and (c) act out climate-change scenarios related to a given activity. However, in this first version, it particularly fits the case of the French West Indies (Guadeloupe and Martinique islands) INNOVA hub in which the development of services is studied to assess the risk of the impact of climate change on island agriculture.
In this paper, we discuss the use of the platform, and demonstrate its interest on this local case study. The discovered knowledge using the platform is of three kinds, depending on the platform tool: • a data-search module that allows users to search and filter the database via a search engine in order to identify any DKP resource matching a user query; • a knowledge-extraction module that only focuses on climate data and is able to answer questions on the evolution of specific climatic conditions; and • a text-mining module that allows users to conduct deep analysis of DKP textual resources associated either to a given hub or resulting from a more complicated query. The contribution of the work presented in this paper resides in the originality and novelty of the platform for the climate-service domain, i.
e. , not only its geographic support for the co-design of climate services, but also the contribution it makes to urgent local needs in the region, for example, for local and regional authorities and other regional decision makers. It falls within the domain of data and knowledge platforms that are designed for a given type of application or a dedicated user community. The rest of this paper is structured in six sections. Section 2 details (a) the area of climate services, design issues, and challenges; and (b) the objectives and geographic nature of the DKP. Section 3 presents the data-storage management of the platform with data schema and techniques that were implemented. Section 4 focuses on the visual and geographic staging of resources on the platform. Section 5 shows how data may be analyzed and evaluated to extract useful knowledge for the design of a service.
Usability and usefulness are important criteria. In the multiplicity of views on the concept of climate service, here we recall the strongest features: (A) A climate service processes climate information obtained by analyzing (with scientific knowledge) massive datasets collected on weather (air pressure, temperature, humidity, and wind speed and direction), and climate datasets (precipitation and temperature); (B) since climate data like climate projections are not directly usable by final users, and user needs are not obvious to identify, climate services fill the gap between climate data and the practical needs of end users; (C) the design of a climate service requires numerous and time-consuming exchanges between suppliers and final users; (D) climate services are used in the context of climate adaptation and they are inseparable from sustainable-development solutions; and (E) climate services are primarily used to support decision making on local issues.
Data Management: Spatiotemporal and Geographic Context One of the most important points of the DKP, with the aim of developing services, is its ability to store heterogeneous data for linking climate data, some of which can be georeferenced, to observations on other domains such as agriculture, health, biodiversity, or economy. For this purpose, the DKP adopts a simple but scalable data structure for storing heterogeneous data that may come from various domains and/or sources. This functionality is crucial in the development of a climate service, since it implements climate-service characteristics (A) and (B) defined in the Section 1, namely, (A) the ability to gather climate data and (B) the gap reduction between climate data and the needs of end users. It therefore meets Objective G1 of climate-service design (as defined in the Section 1) of facilitating local understanding of the climate through data exploration.
More precisely, the DKP exploits a NoSQL database known to be efficient for storing and managing massive data that structures data with JavaScript object notation (JSON) format  [9]. Two kinds of data are stored in the DKP: (i) Spatiotemporal data that relate exclusively to dated numerical values that can be linked to a geographic area (e. g. , average temperature on a region, corn production on a country, and number of tourists in a city). Spatiotemporal data can be linked to the whole territory, a region, or a specific GPS point on the map. (ii) Related resources that relate to all other resources associated to the study (images, videos, documents, etc. ). Figure  3  describes the adopted structure for storing (a) spatiotemporal and (b) related resource data. Three families of NoSQL databases can be distinguished by those based on key values, on columns, and on documents.
For the DKP, we chose to use ElasticSearch that implements a document-based approach. The approach based on documents is the most powerful for data containing information with a complex structure (types, lists, nesting). In addition, ElasticSearch has the particularity of efficiently indexing textual data, thus simplifying the text-mining methods detailed below. (i) Spatiotemporal data allow to store numerical values attached to a geographic area. (see Figure  3a ). Each spatiotemporal datum added to the DKP has to define: the date (in year-month-day format, e. g. , 1960-01-01), the related country (e. g. , Guadeloupe), the data domain and subdomain (e. g. , domain = Climate and subdomain = Temperature), the source where the data comes from (e. g. , French weather institute), the identifiers of the layer and the associated geographic area to make the link with the area in the geographic information system (GIS), and the stored values (e.
g. , min = 24 and max = 32). Obviously, on the same date, we may have data on several countries, domains, subdomains, sources, or geographic areas. For instance, data can be provided by several sources; we may store temperature values coming from the public French Weather Institute and by independent surveys. More generally, the JSON format used by the NoSQL database of the DKP allows the structure to grow easily by adding new branches to the underlying structure. Finally, geographic areas are stored into GeoJSON files  [10]  that contain all unit areas in which data can be associated. Obviously, several GeoJSON files can be uploaded to associate data with different geographic divisions. (ii) Related-resource data cover all related resources that have to be stored. This may be pictures, videos, documents, or external links.
As for spatiotemporal data, the data structure adopted here can easily evolve, and allows to store data coming from different countries, types, or sources. Thus, the DKP includes two modules that facilitate data visualization and management. 1. A data-exploration module that facilitates data visualization. For instance, Figure  4  shows how spatiotemporal data and resources are displayed in the DKP exploration module. The left panel of the application allows to choose one of the spatiotemporal data added to the application. Once spatiotemporal data are selected, they can be visualized on the center panel on a map through the GIS. On the example of Figure  4 , rainfall data collected on the whole Martinique island on a given date are displayed in the center. Finally, the right panel of the application is devoted to the visualization of related resources.
This interface also allows to delete or update existing resources. 2. A data-upload module that facilitates imports into the NoSQL database of the DKP. Indeed, the backend part of the DKP implements several forms to simplify imports of spatiotemporal data and resources. For instance, Figure  5  shows the form that allows users to add new resources into the DKP. Once the form is completed, the building process of the underlying JSON document and the insertion into the correct branch of the NoSQL database is automatically performed by the DKP. In addition, during the import process of spatiotemporal data, the user may import data time series by providing a CSV file containing dates. When data are uploaded, the user may choose to link data to the whole territory, a given region, or a specific GPS point.
Geographic Staging of DKP Resources Another important feature of the DKP is the ability to dynamically visualize on a map previously stored and organized spatiotemporal data in order to meet Objective G2, i. e. , support users in managing climate-related risks. For this purpose, a geographic information system (GIS)  [12]  was integrated to manage cartographic data. GIS are particularly well-suited for manipulating georeferenced data as they facilitate their treatment by offering multiple tools to store, analyze, and display them. A user who has uploaded spatiotemporal agricultural data about sugarcane plantations in a given geographic region can use the graphical interface of the DKP in order to see their spatial distribution on a map and their evolution over time thanks to a slide allowing to navigate past, present, and future values.
Related-resource data can also be represented as points on a region map. These resources are linked to keywords so they can be queried using geographic-information-retrieval tools. For instance, pictures or texts associated to a location may be accessible on the map while using the DKP for visual analysis. This additional information may be particularly useful for the user as they try to better understand the context. The DKP offers multiple tools allowing the user to perform data staging in order have a more accurate view of the stored data. In Figure  4 , we can see the DKP interface allowing to dynamically visualize spatiotemporal data over the selected time periods. The type of displayed spatiotemporal data can be chosen on the left panel. Data are organized into main categories such as agriculture or meteorology.
The central panel shows the map of the concerned region. By default, an entire selected region is displayed, here being the island of Martinique, but the user can zoom in or out by using dedicated buttons on the top left of the map or by scrolling up or down when the cursor is positioned on the map. A color scale shown on the upper-right part of the map is used to graphically represent the data values. The user can choose to consider the whole region as a single part, or to see multiple subregions (towns, localities, etc. ). By moving the slide under the map from left to right, the user can see the evolution of the selected dataset over the time. It is possible to change the considered timescale (minutes, months, years) with a menu on the right of the slide as shown in Figure  6. The dates corresponding to the beginning of the available time period, current position of the slide, and end of the period can be seen in the left, center, and right boxes above the slide, respectively.
At the bottom of the center part, a media-player-type interface is available in order to play, stop, rewind, and accelerate the visualization according to the selected timescale. This is a very useful feature as it allows the user to create, view, and compare different scenarios about the evolution of spatiotemporal data such as crop quantities. Specifically, meteorological-projection data that are estimates of future climate characteristics, such as temperature or precipitations, based on more or less optimistic representative-concentration-pathway (RCP) scenarios, can be integrated in the DKP as spatiotemporal data in order to assess the sustainability of a crop in the future. Figure  7  shows an example of the use of DKP data on given crop data on the island of Guadeloupe at different times.
The slider was moved from one picture to another, and the represented value on the map (surface area of the crop) evolves over time. Figure  8  shows an example of resource data associated to a point on a map through its latitude and longitude co-ordinates. Here, it is a picture of a sugarcane field is linked to its actual georeferenced position. After clicking on the point of interest, a menu allows to select all related data on the resource menu on the right. All unrelated resources to the point disappear so that the user can focus on the desired data. From a technical point of view, when the user creates a geographic point, its co-ordinates are stored into the NoSQL database of the architecture. When resources are added to the DKP, their co-ordinates are also stored in a dedicated table.
Knowledge Discovery and Geographic Resources In the previous sections, we showed how the DKP is used to store heterogeneous data and stage them through a GIS. The last important feature of the DKP is its ability to explore and analyze all data uploaded through two analytic approaches that work on data: (i) a data-search module that allows users to search and filter data in DKP via a search engine, (ii) a knowledge-extraction module that only focuses on climate data and searches for the evolution of specific climatic conditions given by a domain expert, and (iii) a text-mining module that allows users to analyze all documents either associated to a hub or resulting from a search. As described in climate-service characteristics D and E (Section 1), this functionality is important for the development of climate services since it highlights useful knowledge for climate adaptation.
Such knowledge can then be used to support decision making. These modules thus aim to fully respond to two of the main objectives of climate-service design described in the Section 1: (2) support users in managing climate-related risks and (3) support the co-design of a climate service. (i) The DKP search engine allows to search for data according to various filters given by the user, such as hubs, kinds of resources, categories, or various keywords. The search engine also allows to search for resources around a GPS point. On the example of Figure  9a , resources are searched within a radius of 20 km around the GPS point provided by the user. Indeed, if the DKP can store a large amount of heterogeneous data, it is important to be able to navigate these data and select the relevant resources for the purpose of developing climate services.
Thus, the DKP exploits all metadata associated to uploaded data and, in particular, Dublin core metadata, to filter data that are proposed to the user during the search process. This module works as follows. 1. The user starts describing his search with a set of terms or keywords (eg. "sugar" and "cane"). 2. The DKP analyzes all types of data, including spatiotemporal data and resources, and only selects those whose metadata match with the user request. 3. Results are displayed as tabs by classifying them according to their type (pictures, videos, documents, or links), as shown on Figure  9. If documents are found, they are analyzed to extract a word cloud that summarizes the most frequent words found in all documents resulting from the request. The associated word cloud is displayed in a new tab.
In the same way, if spatiotemporal data are found, the DKP offers the possibility to download them into a CSV file. In such a file, the first column corresponds to the dates for which data are found, and the other columns correspond to values for each date. These data are available from the CSV Data tab. For instance, with the terms "sugar" and "cane", we can download data on the production of sugarcane each year on the island of Guadeloupe. (ii) The search for the evolution of specific climate conditions is mainly dedicated to domain experts who want to analyze the evolution of specific climate conditions. Indeed, this module that only works on DKP climate data allows users to define climate conditions on one or more attributes. The platform then analyzes and aggregates data to highlight how the occurrence of the given conditions evolved over time.