dataesr/scientific-paragraphs-categorization huggingface dataset:
Genetic menu is present only if genetic expression data are provided, either by connecting MorphoNet to an external genetic database, or by uploading it through the specific genetic information format, or by a combination of the two. The menu shows the full provided list of genes, with the gene name, the total number of objects expressing the specific gene and the possibility to color-label these objects. In addition to single gene expressions, users can also visualize using a color-code the overlap and the union of expression patterns of two or more genes. If quantitative expression levels are provided, users can also visualize them as heat maps. Users can in addition obtain the list of genes expressed by any picked object, or search specific genes by name. Genetic expression patterns can also be manually curated directly from the Genetic menu.
Screenshots of visualized dataset, as well as movies of spatial and temporal dynamics, can be produced in the Movie menu. When creating a movie (Scenario), users can create keyframes of specific views of the data (both in space and in time) and can tune the frame-rate between two subsequent keyframes. In addition, they can choose whether to interpolate dataset movements between two subsequent selected views. Once a movie has been edited, users can visualize it and download it as an. mp4 file. Movies can also be uploaded to the cloud and shared with other users. For both screenshots and movies, all user interactions with objects (e. g. , color selections) are taken into account. Finally, depending on the user account level and on the user rights on each specific dataset, user account options may allow users to modify and erase dataset information, share the whole dataset and, eventually, its information with other specific users, change the default point of view or erase the whole dataset.
MorphoNet implementation. MorphoNet is a web-based application composed of a front-end application on the client (internet browser) and a back-end support on the server which communicate through classical http requests. The structure of MorphoNet integrates a database for uploading and sharing, which is hosted on the back-end, and a 3D interactive interface for visualization and other advanced dataset interaction, which is hosted on the front-end. The front-end application of MorphoNet is accessible through the url http:// www. morphonet. org on any Internet browser, but we strongly recommend to use Firefox, which is free and accessible on any operating system. We also extensively tested MorphoNet on two versions of Chrome (72. 0. 3626. 121 and 73. 0. 3683. 75) on Windows 7, 8, 10, on MacOS Sierra 10.
13, Mojave 10. 14 and on Ubuntu 14, 16, 18. MorphoNet is fully compatible with the tested Chrome browser versions. MorphoNet uses the browser internal library WebGL 2. 0 to display complex morphological data, and thus needs a recent computer with enough memory and CPU power to support this library. The main technical limitation of MorphoNet, imposed by the very structure of WebGL, is the 2 GB limit of memory use, as is the case for many online mesh visualization platforms. However, for a better interactivity with the dataset during more advanced user interactions (information upload, computations, lineage tree exploration), we suggest to limit the total size of a dataset mesh to 500 MB. This can be achieved by decimating the dataset mesh, i. e. , decreasing the number of polygons composing the mesh, for instance through MeshLab (http://www.
meshlab. net). In the same spirit, in order to optimize the interaction with the dataset, we recommend to limit the total number of elementary objects in each dataset to half a million. Also, for optimal loading, the dataset should not contain more than 1 thousand. obj files (each. obj file can contain more than one elementary object, see "Format specification" section). The front-end application is developed in Unity 3D v2017 Personal Edition using C# language. During the building of the application, Unity converts all code to JavaScript, which makes it readable by any browser. We provide, by application/request, the possibility to add new data on our own server. A database implemented in MySQL stores all necessary information of MorphoNet (datasets, users, quantitative data, curations, etc.
). The server uses classical apache and PHP libraries to communicate with the browser. Any researcher/laboratory can also install MorphoNet on their own server to create their own private morpho-browser. Researchers with little computer science knowledge can create a new dataset and upload their meshes directly through the web interface (as. obj files, see "Format specification" section). For a more controlled upload, however, we recommend to employ the MorphoNet API written in Python, which is provided at the url http://www. morphonet. org/HELP/HelpAPI. php. The API allows uploading meshes distributed in multiples files, their associated information, and permits to perform common user functions (e. g. , create, share or delete datasets). Once data are uploaded to the server, users can directly visualize and interact with them on MorphoNet.
For a smoother usage, a daemon, running on the server, converts the. obj format of each new mesh in AssetBundle, which is the optimized Unity format. User rights: creation of users and groups. Any registered user on MorphoNet has the right to create new users. Once created, a user can be erased only by him/ herself or by MorphoNet administrators. Any registered user on MorphoNet has the right to create a user group. Groups are used to easily share datasets/information with all group members. These groups can be either private or public: in private groups, only group managers can add new members, while any users can freely decide to join a public group. The group creator is automatically a manager. Other group members can be either managers or simple members. Both managers and members have access to group datasets and information, while only managers can add/remove users (for private groups), manage the group structure and allow manager rights to other members.
Once created, groups can be completely erased from the database of MorphoNet by MorphoNet administrators only. Group managers can, however, decide at any time to make the group inactive by archiving it. The group then becomes hidden and its rights to dataset access are suspended. Managers can reactivate archived groups at any time. User rights: dataset and information access and sharing. Once a dataset is created by uploading surface meshes to the MorphoNet database, it will stay private until the creator of the dataset decides to give access to other selected users (or user groups). As such, each dataset has a community of allowed users who can, with different access rights, read and/or upload information to it. Allowed users for each dataset in MorphoNet can be granted three access-rights levels: Creator, i.
e. , the user who uploaded the meshes to the cloud; there is one Creator only per dataset; Owner, i. e. , users having full-right access to meshes and information; each dataset can have several Owners; Reader, i. e. , users having read-only access to meshes and information; each dataset can have several Readers. Users who have not been given access to a specific dataset will neither be able to see it nor to access it. Both Creator and Owners can upload new information to the dataset. All uploaded information can either be kept private, or shared will all users with read access (Creator, Owners, and Readers). Creator and Owners can also download both meshes and all information they have access to. Private information can only be seen by the specific Owner who uploaded it and by the Creator of the dataset, who has full access to everything associated with his/ her dataset.
Both the Creator and Owners can grant access rights to other users or user groups. Readers have no upload/download/share right and can only visualize meshes and shared information. A dataset can also be made public, in which case all registered users on MorphoNet automatically acquire Reader rights. In addition, public datasets can be accessed by users from anywhere in the world without the need for a MorphoNet account: public access will be granted to unregistered users, with visualization rights only. Format specification. In order to fully exploit the interdisciplinary networking structure of the idea behind morphological browsers we have hereby introduced, we created a generic format for morphological information specification. To this end, we take advantage of the object-based structure of morphological datasets by introducing morphodynamic information categories which can be projected on elementary blocks.
Each of these objects can be uniquely identified by an object tuple (OTP) given by its context. For example, when both temporal information and several visualization channels are present in a dataset, at any given time point and for any given visualization channel, one is left with a collection of objects. Therefore, OTPs in such datasets correspond to three integer numbers separated by commas: t, id, ch, specifying the time point (t), the visualization channel (ch) and the ID of the specific object given in the obj file (id). On the other hand, if only one time point and one channel is provided in the dataset, OTPs can be simplified to just the simple id specified in. obj files. Morphological datasets. Morphological datasets must be uploaded to MorphoNet in the form of surface meshes. More specifically, we employ one of the most used format to represent meshes, i.
e. , the OBJ format. Each. obj file contains a list of elementary objects present at a given time point, of its vertices and of its faces. Each elementary object is identified by the time index at which it exists and its specific id at each given time, followed by the list of coordinates of its vertices and the list of faces composed of three vertices (each vertex being numbered starting from 1, with a global numbering running over all vertices of all objects at any given time point). This leaves dataset owners the freedom to choose the level of detail of their morphological unit, which will then be interpreted by MorphoNet as the elementary object with which users can interact. Each elementary brick should be referenced in the. obj file by the letter g (standard in the obj format) followed by its OTP.
For an optimal experience when interacting with the dataset, the total number of objects should not be higher than half a million. This is due to the intrinsic limits to the WebGL memory as of today. Morphological information. Thanks to flexible OTPs, users can upload information to be visualized in the dataset. The general structure of information is a property associated with a specific object. The unique MorphoNet information format consists of a list of entries of the form OTP: property. Properties can, in turn, represent several different kinds of morphological information, each identified by a specific information type. The type of information must be mentioned at the beginning of the list as type: information type. Each property must be given a name in order to uniquely identify it in the database.
Genetic Information provides gene expression information associated with object OTP. The number characterizes the expression level (either given as boolean 0/1 or as more precise quantitative expression level). The gene name whose expression is given in the information must be specified as the name of the information file uploaded to the database. Dictionary Information links object OTP1 to object OTP2 with a quantitative information on this link. Such a quantitative information is represented as heat map on the dataset. For instance, object OTP1 is associated with its direct physical neighbors, with additional quantitative information on their contact areas. Sphere Information visualizes a sphere on the dataset, having the same color selection as object OTP, centered at coordinates x,y,z and with radius r.
Acknowledgements We thank  M. Brozovic  for helping with the MorphoNet-ANISEED connection. We thank  J. Dardaillon  for her precious help in the MorphoNet-ANISEED connection and in the NCBI taxonomy API. We thank  F. Boudon  for generously providing the dataset of simulated Mango tree. We thank  J. Traas  for kindly providing the dataset of Arabidopsis meristem and gene expression patterns, and for discussions and feedbacks. We thank  A. Perna  for providing the dataset of Cubitermes nest structure. We thank  G. Cerutti  for his help with the creation of surface meshes on volume segmentation datasets. We thank  H. Oliveri  for providing the dataset of simulated meristem. We thank  C. Dantec  and the  CRBM  for helping with and hosting the MorphoNet website. B. L. , J. L. , C. G. , and P. L.
acknowledge financial support from the  Agence Nationale de la Recherche  ( Dig-Em  contract,  ANR-14-CE11-0013 ;  Equipex Morphoscope2 ,  ANR-11-EQPX-0029 ;  Institut de Biologie Computationnelle, IBC ,  ANR 11-BINF-0002 ) and from the  Inria Project Lab Morphogenetics.
). For this purpose, elected officials use software such as Microsoft Excel or QlikView  [10, 30]  in a fixed environment. Although their job requires ubiquitous data analysis, several elected officials reported the lack of suitable and easy to use tools to perform this task on mobile devices: "We use a pre-made dashboard in council meetings. If the pre-made charts are not sufficient, the meeting is adjourned so we can make new ones on a [desktop] computer". As this requirement was the most frequent outcome of the interviews, we developed with the participants a usage scenario in which elected officials need to perform data analysis on a mobile device.
Usage Scenario Before a council meeting, Jessica, an elected official, performs a data analysis on the current year's city budget, sorted by districts (Fig. 1 ). Equipped with her professional tablet only, the presentation of her analysis during the council meeting raises questions from other officials concerning the increase of costs for this year. To answer these questions, she needs to perform a new analysis by separating the types of costs for each district, for instance the employees' salary, the outsourcing cost and the materials cost. She uses a pivot table  [10]  to quickly produce a cross-analysis summary, from which a graphical representation is rapidly generated. To this end, she performs a two-step process: 1) select the spreadsheet dataset corresponding to the city budget; 2) create the pivot table by affecting the "district" variable to the table rows, the "types of costs" variable to the table columns, and defining the summary function (e.
Intersection is based on two simple gestures that do not require a precise pointing on a single cell, which is usually small. Stack-and-Drag is similar to a mouse-based selection on desktop spreadsheets but avoids the need to accurately select the tiny anchor on the corner of a selected cell. Finger Stack offers the advantage of a direct selection (a simple touch and stack) without any smartphone translation. We decided to confront these advantages in a controlled study and to compare them with touch interaction. We found no mobile spreadsheet app providing the required API and software tools to integrate custom interaction techniques and stacking gestures recognition. Therefore, we developed a new spreadsheet app that conforms exactly to the Google Spreadsheet app  [12]  in terms of interface layout, touch interaction, and cell size (284x53px).
Results We chose to rely on estimation techniques with 95% confidence intervals and ratio analysis as recommended by the APA  [38]. Ratio is an intra-subject measurement that expresses the effect size (pair-wise comparison) and is computed between each of the geometric means. All CIs are 95% BCa bootstrap confidence interval. For the reader more used to interpret the p-values, a parallel might be drawn with results obtained through the estimation technique and CIs reports (see Fig. 3  in  [22] ). Scripts used to compute the geometric mean and CIs were used in  [40]  and are available online  [14]. This result holds when considering the different cells range categories individually. When analyzing the impact of the Scroll factor (cells range categories involving N=9 and/or M=33), results show that when scrolling is required, trials take on average 64% CI [58.
Study 2: pivot table creation After validating the initial and necessary step of selecting a cell range, we focus on the remaining actions needed to create and manipulate a pivot table to support ubiquitous data analysis. In Excel on a Microsoft Surface tablet, after selecting the desired data (step 1) and pressing on the right menu/sub-menu to insert the pivot table, the app activates a wizard. The wizard is displayed on the right side of the screen, on a secondary tab or on the tab containing the data. The wizard presents the headers of the selected rows and four shelves, representing the four components of a pivot table (Row, Column, Value and Filter  [25]  -see Fig. 8-C ). Each column header can then be dragged and dropped (step 2) on one of the four wizard's shelves. A touch on the elements in the Value shelf allows changing the summary function using a pop-up window.
Each trial consisted in filling one (Value), two (Value and Row), three (Value, Row and Column) or four (Value, Row, Column and Filter) shelves of the wizard with one element. In some trials participants also had to modify the summary function (Sum, Number, Mean). Participants were asked to complete the task as fast and accurately as possible. The task instructions were displayed on the tablet screen before each trial and on a secondary computer screen during the trial. The instructions consisted of a pivot table wizard already filled with the required elements and configured with a specific summary function. A touch button allowed the user to start the trial. Once the wizard was correctly filled, an automatic validation was triggered after 500ms. We used the same dataset as in  [21] , consisting in movie attributes (e.
g. genre, MPAA rating), budget, total gross and review ratings. We trimmed the dataset to 200 rows and 12 columns as in  [21]. Design. Our study followed a 4*4*2 within-subjects design with Interaction technique (Tactile, Dual-Screen Touch, Stack-and-Touch, Stack-and-Translate), Number of wizard's Shelves to modify (one, two, three or four) and Summary Function (yes or no) as factors. The study was divided into 4 blocks, each block corresponding to one technique. The order of blocks was counterbalanced across participants by means of a 4x4 Latin square. For each block, participants could perform training trials until they felt ready. Then they performed 24 pivot table creations (8 conditions performed 3 times). The order of trials was randomized. Participants could take a break between each trial and each block.
In total, we collected 4 ITs x 8 configurations x 3 repetitions x 12 participants = 1152 trials. Apparatus, participants and collected data. We used the same tablet and smartphone than in the previous study. We upgraded both devices to Android 7. 1 to run our pivot table code (which required Java 8). We also used a computer screen (16", 1366x768 pixels) to permanently display the instructions during a trial. We recruited 12 participants (7 females), aged 31. 7 years on average (SD = 6. 8). Participants were all students of the local university's computer science department. Two of them took part in study 1, limited to the selection phase (step 1). They were all right-handed and familiar with mobile devices (7. 8 on a 0-9 scale), desktop spreadsheets (6. 5) and pivot tables  (6. 3). The experiment lasted 78 minutes on average.
We determined the number of search pages we would have to review to capture 80% of the total relevant papers and used that as our common search limit across all ecosystem service categories. This process led us reviewing the top vices and recorded the direction of change (negative or positive impact). From each reviewed paper, we recorded the mechanism of impact, the direction of climate effects on the ecosystem service (either positive or negative) relative to current conditions, the spatial scope of the effect, the kind of study and the marine ecosystem type where the impact was recorded. We structured our data collection with a pathways of effects model, according to the following structure: General Climate Change Stressor → Impact Mechanism → Ecosystem Service Category A pathways of effects model includes general climate stressors leading to impact mechanisms that link the general stressors with the ecosystem services (sensu  Singh et al.
g. , Perfloc  [8]  or the IEEE CTW 2019 Positioning Algorithm Competition  [9] ), since it enables all teams to work with the same data and technologies for fair benchmarking. Contrary to on-site competitions, where the teams have to survey the area in their own way for calibration purposes, off-site competition organizers provide all the required data to calibrate and evaluate the indoor positioning systems. Thus, since IPIN 2015, the indoor competition includes an off-site track. At first, it was based on a Wi-Fi fingerprinting database collected at three different buildings in a university campus  [10]. Since 2016, the Smartphone-based off-site track provides all data that can be captured in real-time with a smartphone  [11] -  [13]. Using data sets for the competition has enabled the inclusion of new buildings, which in turn added diversity to the evaluation areas.
II. PREPARATION OF IPIN 2018 COMPETITION TRACKS AND DATASETS This section describes the preparation of the IPIN 2018 competition tracks, which has been carried in partnership with the French High School of Surveyors and Topographers (ESGT), under the supervision of the GEOLOC laboratory of the French Institute of Science and Technology for Transport, Development and Networks (IFSTTAR). The competition was also prepared in collaboration with the Institute of New Imaging Technologies (INIT) from Universitat Jaume I and other institutions. The IPIN competition basically consists of two main parts: an on-site and off-site competition, although every part can have one or more tracks in the competition: • The on-site challenges occur at the competition location, i. e. the conference venue or, as in this case, a shopping mall.
The teams deploy their own Indoor Positioning System (IPS), respecting and obeying the restrictions set by organizers, and estimate in real-time the coordinates of the target points as they are reached by the person carrying the location system and following a track previously arranged by the organizers. Competitors are allowed to access the venue the day before the competition for calibration and site survey. • The off-site challenges allow competitors to calculate traces from data provided to them before the competition. Data are of various nature: Wi-Fi, magnetic field, inertial signals, Bluetooth Low Energy (BLE), etc. They comprise two parts provided to competitors: The first part of the dataset is recorded on a geolocated path (or paths) where the geographical coordinates of the reference points and the corresponding data are provided; this path is used for calibration; the second part of the dataset are raw data from the same location where previous data were taken, and their coordinates must be estimated by the competitors.