dataesr/scientific-paragraphs-categorization huggingface dataset:
Distance Measures Depending on the dataset at hand, we consider dierent distance measures. In the case of Twitter and Flickr, we compute the great circle distance between two GPS coordinates  [15]. For the trajectories we use the symmetric Hausdor distance  [16] , which is dened as follows. Let P and Q be two sets of points in the Euclidean space. H (P, Q) := max p 2P min q 2Q d(p, q) where d is the Euclidean distance. The symmetric Hausdor distance between two trajectories P and Q is dened as b H (P, Q) = max(H (P, Q), H (Q, P)). All the distance measures considered in our experiments are metrics.
Dynamic Model of Computation In the case of Twitter and Filckr, we evaluated the algorithms under the sliding window model  [6, 7]. In this case, if a point is inserted at time t, it will be removed at time t +W , where W is the duration of the sliding window. As a result, at each point in time t, new points might be added to the current dataset in which case any point with timestamp t + W will be removed (if any). We then focus on the task of maintaining a clustering of all trajectories available up to any given point. At any point in time, either a new point is added to one of the available trajectories at that time or a new trajectory is created. Since trajectories might be updated in any arbitrary order, the sliding window model turns out to be over-simplistic in this setting. Therefore the approach in  [6]  cannot be used.
We observe that in practice it is important to have small maximum radius, in that, this might lead to more "meaningful" clusters. Figure  1  (left) measures the approximation ratio as a function of k, while Figure  1  (right) measures the approximation ratio as a function of in Twitter. For any given value of k and we report the median, the rst and third quartiles, as well as maximum and minimum approximation ratio obtained by the algorithm when executed on the whole dataset. The two algorithms have been tested for the same value of k and , however, some additional space between the corresponding values in the plot has been introduced to improve the presentation. We can observe that our algorithm (FD) consistently delivers better approximation ratio then the algorithm presented in  [6]  (SW).
Trajectory Data and Multicore Implementation In this section, we consider the task of clustering trajectory data. We consider the scenario where at each point in time, either a new point is added to one of the existing trajectories or a new trajectory consisting of one single point is created. Each update can therefore be seen as either an insertion of a new trajectory or a deletion of an existing trajectory followed by an insertion of the updated trajectory. Since trajectories can be modied in any arbitrary order, the sliding window model appears to be simplistic in this setting. Therefore, the algorithm in  [6]  cannot be used. The Computing the distance between two trajectories requires (r ) operations, where r is the maximum number of points in the two trajectories. In our dataset, most trajectory contain up to 500 points with the largest one containing nearly 4000 points.
Concentration around the Expectation Our last experiment aims to study the concentration around the expected running time (i. e. Theorem 5. 8) from an experimental point of view. We consider 100 runs of our algorithm on the Twitter dataset using the default values and we show the histogram of the average running time in Figure  7. We can see that almost all runs require 5. 8 ⇤ 10 4 seconds on average, while in very few cases the average running time is more than 12 ⇤ 10 4 seconds, which is consistent with Theorem 5. 8.
* This research was partially supported by a grant from the  PROCORE   France-Hong Kong Joint Research Scheme  sponsored by the  Research Grants Council of Hong Kong  and the  Consulate General of France in Hong Kong  under the project  F-HKU702/16. † This research was partially supported by the  Hong Kong RGC  under the grants  17217716. ‡ This research was partially supported by  French National Agency (ANR)  under project  FIELDS  ( ANR-15-CE23-0006 ).
Dispersion of Cell Size Distribution The coefficient of variation C V describes the dispersion of cell size distribution with C V = σ d c /d c , where σ d c represents the standard deviation of the cell diameters, and d c is the average cell diameter (equivalent sphere)  [21, 25]. The volume of each cell can be measured directly by the software iMorph (Aix-Marseille Université, Marseille, France)  [37]. Considering the cells equivalent to the spheres, the distribution of the normalized cell diameters (by the average diameter) exhibits a Gaussian unimodal shape (shown in Section 2. 3). By analysing σ d c and d c , the coefficient of variation C V can be estimated to be 0. 136. It should be noted that the analysis of the dispersion of cell size distribution was performed on fully contained cells.
Generation of Numerical Models The recent Voronoi-based approach  [25, 35] , which has been used for open-cell structures before, was extended to numerically generate periodic irregular closed-cell structures. The general generation process can be found in the above papers. Various software, i. e. , VORO++, Surface Evolver  [42]  and Matlab  [43] , can be used to support the generation and treatment of periodic structures  [21]. Surface Evolver helps to generate an energetically stable structure rather than just a random one, which makes the resulting structure more realistic. Moreover, the cell size distribution can be directly specified and finely controlled in Surface Evolver. For closed-cell structures, the cells obtained by Surface Evolver will be "separated", i. e. , every face is duplicated and each of the two copies is grouped with other connected faces, with each group constituting the boundaries of one of the original cells.
Finite Element Implementation The generated structures were meshed with linear tetrahedron solid elements by the commercial package ICEM CFD 16. 2 (ANSYS, Inc. , Canonsburg, PA, USA)  [48]  and solved by the Hill's lemma based periodic computational homogenization approach  [21, 25]. Hill's lemma approach was recently implemented on open-cell models and has been verified as an efficient and accurate computational homogenization approach. It permits the full effective elastic stiffness matrix [C hom ] to be obtained with only one finite element computation and without imposing boundary macro-loadings  [25] , in contrast to the usual FEM homogenization approaches. According to  [25] , the homogenized elastic behavior {σ} = [C hom ]{ } can be written with the modified Voigt notation (any symmetric second order tensor a is represented by the vector {a} = T {a 11 , a 22 , a 33 , √ 2a 23 , √ 2a 13 , √ 2a 12 } where a ij are its components in the basis (e 1 , e 2 , e 3 )) as: {σ} = [C] + T [F][K] -1 [F] { }.
II. RELATED WORKS Many studies have been done to improve interoperability between health sensors  [11] -  [15] ,  [17]. Hofer et al. [11]  proposed an interoperable health system for monitoring obstructive pulmonary diseases named COMPASS. These authors developed a server-client RESTful architecture with a publish/subscribe mechanism running on Android devices with the aim of increasing the quality of care by collecting and analyzing sensors data in a long-term monitoring context. Collected data were sent to a remote server for storage and later processing. The authors used a prototype multi-sensor medical device from Biovotion, measuring several vital signs such as blood oxygenation, heart rate, skin temperature and steps count. Data were retrieved from the sensor using ISO/IEEE 11073 protocol and sent remotely using HL7 standard protocol  [18].
2) OPERATING MODE In this section, we detail the operating mechanism of the middleware as displayed in the flowchart of Fig. 1. When a measure is requested, the middleware starts by determining the list of sensors able to perform this measure (Fig. 1 -1  ). This list is retrieved from the middleware database. Then, users can ask the middleware to apply two filters on the sensors list. The first one deals with users' privacy, and removes from the list any sensor that sends its data to the manufacturer. Therefore, only sensors allowing direct communication are used. The second filter limits measures to  either medical devices or wellness devices. Of course, if users want to use any type of sensors, this filter should not be applied. If the middleware is used for a medical development goal, it can measure data with medical devices only.
When users request a continuous measure, the middleware retrieves only sensors able to perform such measure, then sorting sensors with regard to their accuracy is applied as mentioned above. For example, a heart rate can be measured continuously with a pulse oximeter but not with a blood pressure monitor. Thereafter, a discovery service is launched to retrieve data from the established sensors list. The service iterates this list until data is measured from one of the sensors (Fig. 1 2 ). The most accurate sensor is used first. It starts by determining the appropriate SDK or API to use. Based on the communication technology used by sensors, we distinguish three processes: • If the sensor communicates via Wi-Fi (Fig. 1 2 3 ), a web request is performed to retrieve data. This request is intended either to the sensor or to its manufacturer's cloud.
It starts by applying the filters described above, sorting sensors based on their reliability then launching the discovery service in order to determine which sensor the final user handles. It also identifies which communication protocol the sensor implements to decide which SDK or API to enable. Since some sensors require an identified user, the device manager communicates with a credentials manager to get the login ID that should be used. The credentials manager stores credentials provided by the application developer. The communication between the device manager component and sensors is done through the hardware layer of the operating system running the middleware. The middleware has also an update manager component in charge of updating sensors firmware. Regarding updating the middleware, to add new sensors for instance, developers should upgrade it in their development project, as they would update any software library used as a dependency.
IV. RESULTS We developed this middleware for the Android platform. It supports OS versions starting API 19 (KitKat 4. 4), since older versions are no longer supported  [11] ,  [23]. The middleware is programmed using Java language, and is interoperable with the six sensors described in Table  2. With these sensors, healthcare application can retrieve up to 24 data, described in Table  3. To test our middleware, we implemented an Android application integrating this middleware to retrieve health measures, as would other developers do for their developments. This application stores measured data in a local database and then displays them on a chart. In a recent work  [9] , we used iHealth API to retrieve data. Since then, iHealth has published an SDK enabling direct communication with its sensors.
Therefore, an Internet connection is required. Unlike A&D, both iHealth and Netatmo sensors require developer credentials to communicate their data. Netatmo requires in addition the credentials of the final user who should provide them through the developer's application. Developers can communicate these data to the middleware credentials manager that uses SharedPreferences. It is a keyvalue interface for storing data in a given context. Since the context used by the middleware is supplied by the developers' application, both sides can access the same data. The middleware cache is also based on the SharedPreferences interface. The database used by the middleware is SQLite, which is also supported natively by Android. Asynchronous communications are done using IntentServices. These components are designed to perform long operation in a worker thread.
They have the benefit of stopping themselves once the requested task is done allowing optimizing the use of the platform resources. The communication between different components of the middleware is done using the ResultReceiver interface. Since API 23 (Android Marshmallow 6. 0), users grant permissions to an application at runtime rather than at installation time. In order to respect users' privacy, the middleware only requests necessary permissions for the required SDK instead of requesting all permissions at once. Table  4  details the number of lines of code a developer needs to write when using our middleware to implement a specific protocol compared to a self implementation of the protocol. The middleware has an average cyclomatic complexity of 1. 92 and a total cyclomatic complexity of 435.
Regarding the Samsung device, since it does not have an Internet connection, it could not retrieve data from the Netatmo weather station which is a cloud-based sensor (cf. data are available about the saved measures such as their category (medical or wellness), the sensor used to perform the measure, its accuracy, etc. The developed application based on the middleware allows the user to retrieve his health data and to store them locally maintaining privacy. It offers an alternative solution to commercial applications. Regarding the implementation effort, the middleware spares developers from implementing by themselves each protocol. The benefit increases with the rising of the number of implemented protocols as detailed in Table  4. As a matter of fact, when using the middleware, only 2. 74% of the code amount is needed compared to the non-use of the middleware.
Even if this is implementation-specific, it gives an order of magnitude of the implementation effort. Listing 1 shows the necessary code to request a specific type of data whereas Listing 2 shows how data are read. This benefit is even more significant as smartphone applications size keeps increasing. We analyzed 250 applications obtained from Google Play through a search with the keyword ''health monitoring''. Eighteen applications were excluded because they were outside the scope (servers and battery monitoring). Among the rest of the applications, we considered only those having more than 10 000 downloads resulting in 115 applications among 232. Forty-five percent of these applications communicate with at least one health sensor (weight scale, blood pressure monitor, etc. ). The average size of these applications is 33.
As a matter of fact, sensors n • 1 (A&D weight scale), n • 2 (A&D blood pressure monitor) and n • 4 (iHealth oximeter) need to be activated manually by the user in order to retrieve the measures. For sensor n • 3 (iHealth blood pressure monitor), the middleware needs around 37 seconds to perform the measure. This delay is normal and required for the device cuff to inflate and deflate in order to determine the user's blood pressure. For sensor n • 5 (iHealth actimeter), it needs 5. 6 seconds to establish a connection and to retrieve current data, and 0. 412 second to retrieve measures from sensor n • 6 (Netatmo weather station). We also used several software analysis tools to ensure a high quality code of the middleware. This enabled us to maintain it and upgrade it easily in the future. First, we used the Checkstyle tool.
This ensures for developers willing to use it that the middleware code respects coding standards and conventions and, therefore, is easily understandable. PMD software was also used to provide a clean and readable code. The Android Studio default tool, Lint, was also used to look for optimizations and identify potential errors. In this work, we developed a middleware, as a software library, that improves interoperability with health sensors implementing both standard and proprietary protocols. It allows developers to communicate with a greater diversity of sensors and to manipulate data without worrying about which communication protocol to use in order to achieve a better health monitoring. It is also able to take account of the used material characteristics, legal requirements and users' privacy.
From a simulation perspective, using a modular approach may be less advantageous depending on the implementation since event routing is a potential source of overhead  [23] , although several techniques  [16, 24]  allow managing this issue. In contrast, multiPDEVS has no communication overhead between components influencing each other since it avoids traditional event routing. We realized an implementation of multiPDEVS using Quartz (code available at https://github. com/rumenzu/ quartz. ), a Crystal port of DEVS-Ruby  [25] , which is a simulation tool that allows specification of PDEVS models. It provides several extensions such as Cell-DEVS  [4]  or DSDE  [26] , and we extended it to integrate multiPDEVS and its simulator. To define new multiPDEVS models, Quartz provides a class MultiComponent::Model which can be modularly coupled to other models and to which may be added component models.
This simple model allows us to test our implementation using highly interacting low computational components that remain active during the whole simulation. In order to verify our intuition that we may obtain best execution times using multiPDEVS due to the absence of event routing, we implemented the same model using the Cell-DEVS extension of Quartz in order to compare both results. For this performance analysis, we ran ten simulations for each approach (multiPDEVS and Cell-DEVS) using the same model, the same initial conditions, and the same environment (Quartz) and measured the elapsed real time. The test environment is based on an Intel(R) Core(TM) i5-3210 M CPU @ 2. 50 GHz (3 MB L2 cache), 8 GB (2x DDR3L-1600 Mhz) of RAM, and an Apple SSD SM128E hard drive, running on OSX 10. 11. 4. Software used is Quartz.
The future of agricultural research depends on data. The sheer volume of agricultural biological data being produced today makes excellent data management essential. Governmental agencies, publishers and science funders require data management plans for publicly funded research. Furthermore, the value of data increases exponentially when they are properly stored, described, integrated and shared, so that they can be easily utilized in future analyses. AgBioData (https://www. agbiodata. org) is a consortium of people working at agricultural biological databases, data archives and knowledgbases who strive to identify common issues in database development, curation and management, with the goal of creating database products that are more Findable, Accessible, Interoperable and Reusable. We strive to promote authentic, detailed, accurate and explicit communication between all parties involved in scientific data.
For example, traits, images, seed/sample sources, sequencing data and high-throughput phenotyping results become much more informative when integrated with germplasm accessions and pedigree data. Access to low-cost, high-throughput sequencing, large-scale phenotyping and advanced computational algorithms, combined with significant funding by the National Science Foundation (NSF), the US Department of Agriculture (USDA) and the US Department of Energy (DOE) for cyberinfrastructure and agricultural-related research have fueled the growth of databases to manage, store, integrate, analyse and serve these data and tools to scientists and other stakeholders. To describe agricultural-related databases, we use the term 'GGB (genomic, genetic and breeding) database'. GGB databases include any online resource that holds genomic, genetic, phenotypic and/or breeding-related information and that is organized via a database schema, and contained within a database management system (or DBMS, which is a computer application that manages and provides access to one or more types of database systems, including relational, Resource Description Framework (RDF), or nonrelational (noSQL) storage systems).
GGB databases play a central role in the communities they serve by curating and distributing published data, by facilitating collaborations between scientists and by promoting awareness of what research is being done and by whom in the community. GGB databases prevent duplicated research efforts and foster communication and collaboration between laboratories  (2, 3). As more and more organisms are sequenced, cross-species investigations become increasingly informative, requiring researchers to use multiple GGB databases and requiring that GGB databases share data and use compatible software tools. Use of common data standards, vocabularies, ontologies and tools will make curation more effective, promote data sharing and facilitate comparative studies  (2). The AgBioData consortium (https://www.
agbiodata. org) was formed in 2015 in response to the need for GGB personnel to work together to come up with better, more efficient database solutions. The mission of the consortium, comprised of members responsible for over 25 GGB databases and allied resources, is to work together to identify ways to consolidate and standardize common GGB database operations to create database products with more interoperability. Member databases and resources are listed at https://www. agbiodata. org/databases and https:// fairsharing. org/collection/AgBioData. The AgBioData consortium joins the larger scientific community in embracing the Findable, Accessible Interoperable, and Reusable (FAIR) data principles, established by stakeholders from the scientific, publishing and library communities  (4). FAIR principles have rapidly become standard guidelines for proper data management, as they outline a roadmap to maximize data reuse across repositories.
However, more specific guidelines on how to implement FAIR principles for agricultural GGB data are needed to assist and streamline implementation across GGB databases. Members of the AgBioData consortium convened in Salt Lake City, UT on 18 & 19 April 2017 to describe challenges and recommendations for seven topics relevant to GGB databases-Biocuration, Ontologies, Metadata and persistence, GGB database platforms, Programmatic (Machine) access to data, Communication and Sustainability. Preceding this workshop, a survey was sent out to all AgBioData members regarding the seven topics, in order to identify concerns and challenges of AgBioData members. The results were used to focus and foster the workshop discussions. Here we present the current challenges facing GGBs in each of these seven areas and recommendations for best practices, incorporating discussions from the Salt Lake City meeting and results of the survey.
The purpose of this paper is 3-fold: first, to document the current challenges and opportunities of GGB databases and online resources regarding the collection, integration and provision of data in a standardized way; second, to outline a set of standards and best practices for GGB databases and their curators; and third, to inform policy and decision makers in the federal government, funding agencies, scientific publishers and academic institutions about the growing importance of scientific data curation and management to the research community. The paper is organized by the seven topics discussed at the Salt Lake City workshop. For each topic, we provide an overview, challenges and opportunities and recommendations. The acronym 'API' (Application Programming Interface) appears frequently in this paper, referring to the means by which software components communicate with each other: i.