dataesr/scientific-paragraphs-categorization huggingface dataset:
If the failure already exists, the user follows the instructions to repair the machine. Otherwise, the failure will be documented by Alice or by machine domain experts as shown in Figure  5. Sometimes, the impacts of a failure may differ from one machine to another. So, existing repair procedures might be adapted or new procedures might be created to repair the machine. This process ends, in the edge level, by sharing the collected data with the SemKoRe Server in the cloud. When the SemKoRe Server receives failure data from a SemKoRe Agent instance, the data must be validated by a machine domain expert before it is integrated into the SemKoRe Knowledge Graph. After the validation process, data are anonymized to protect the data and customer privacy and business sensitive information of the customers (see Section 6.
3). The anonymized data are then aggregated (see Section 6. 4) in order to get insights about the occurrence frequency of failures, their impacts and the most adapted/used repairing procedures. The aggregated data are then shared with the SemKoRe Agents instances connected to the same machine type. On the other side, each SemKoRe Agent instance integrates the data it receives from the cloud into the local triplestores (Graph databases).
• The machine failure T-Box, containing the concepts defined in the failure ontology; and, • A-Box data, containing the instances of the T-Box concepts. Knowing that the SemKoRe Server manages data relative to several types of machines, the A-Box retrieved by a gateway contains only the information relative to the machines connected to it. The startup commissioning service sends a request to the SemKoRe Server with the identity and the type of the connected machines. The SemKoRe Server runs then a Construct SPARQL query to create a sub-graph containing all the data (T-Box and the A-Box) related to the provided machine type. The resulting sub-graph is sent back to the gateway.
Anonymization Service Privacy protection is a very important concern for our customers. They do not want to share any machine and process-related data in a way that could potentially expose sensitive business information. To address this concern, we implemented a simple service (described below), in the SemKoRe Server in the cloud, to anonymize the collected data before sharing it with other sites or locations. When a failure occurs, the gateway creates an instance of "Failure Occurrence Class", containing information about the failure, e. g. , symptoms, impact, root causes if known, and the failure context, which includes the machine ID, its location, timestamp when failure occurred, and a snapshot of the current parameters. The whole process consists of three steps: 1. The SemKoRe Server removes the machine ID, location, and owner-related information and does not share this information.
Failure Data Aggregation Hosted in SemKoRe Server, this service and aggregates failure data collected from different gateways in order to produce deep insights on the machine failures and their characteristics including symptoms, impacts, and root causes. Once the aggregation is done, the data are shared by the SemKoRe Server with the connected gateways that need it. We have defined a list of simple aggregations that are applied to the failure data: 1. For each machine type, get the list of all failures and their frequency; 2. For each failure, compute the list of all possible symptoms with the frequency of each symptom; 3. For each failure, compute the list of all possible impacts with the frequency of each impact; 4. For each failure, compute the list of all possible root causes with the frequency of each root cause; and 5.
Failure Data Sharing The failure data sharing is done through the SemKoRe Server's message broker. Each gateway subscribes to the topic ". /failure_updates/{machine_type}", where {machine_type} is the type of machine to which the gateway is connected. When failure data are sent to the SemKoRe server (through the REST interface), it is validated, anonymized, aggregated and then published on the message topic corresponding to the right machine type. The gateways receiving these data will simply update the locally stored graph data.
• Microsoft Azure: The SemKoRe Server services are hosted on Microsoft Azure, which provides high-performance cloud services. The server uses Azure IoT Hub  [31]  to connect the IoT devices to the cloud using several communication protocols, including the MQTT (Message Queuing Telemetry Transport) messaging protocol  [32] , which we used to simplify the data flow transmission between our SemKoRe agent and server services. For the edge, the Azure IoT Edge service was used to easily connect the edge gateways to the cloud via Azure IoT Hub as shown in Figure  7. • Docker: This is a popular container-based virtualization  [33]  tool. Docker supports many operating systems and hardware architectures, and allows self contained applications to be packaged and executed with a high level of portability and reproducible results  [34].
We used Docker to package all of the services of SemKoRe Server and SemKoRe Agent. In reality SemaKoRe agent will reside with many other components. Docker allows us to have the flexibility of deploying different components easily and manage/extend them without impacting others. As we are still in early stage, we were not able to implement the SemKoRe in real conditions with SemKoRe Agent running on Industrial Gateways connected to real machines. The main obstacle was that the current hardware available for this work had ARM architecture and so it would require a significant effort to port the triplestore and other software components. That effort was beyond the scope of our work. However, after the successful PoC, the business team decided to use an industrial PC as a gateway with enough RAM (8GB), processing (Intel Atom) and storage (64GB) capability.
The next iteration of this work will use this industrial PC when it is ready for commercialization. In the meantime, we evaluated our implementation by simulating many virtual SemKoRe Agent instances on a PC equipped with an Intel(R) Core(TM) i7-7820HQ processor, and 16Gb of RAM. We used a single GraphDB server to manage separate triplestores for all the SemKoRe Agent instances. We randomly defined a set of three machine types {Packaging Machine, Palletizing Machine, Pasteurization Machine} that we associated to the active SemKoRe Agents. Each machine type was associated with at least two SemKoRe Agent instances which were then connected to the cloud SemKoRe Server. Our current implementation choices will facilitate an easy transition to industrial PCs in future. We generated random machine failure data by defining a set of potential failures for each machine type.
Each failure was then associated to a set of potential characteristics: symptoms, impacts, root causes and solving procedures. For each machine failure occurrence, we randomly picked one of the potential failures of the machine, and then picked a random number of the failure characteristics from the predefined sets. We were able to demonstrate that the failure data were collected by each SemKoRe Agent and successfully shared with the SemKoRe Server. The data were aggregated and shared back with the SemKoRe Agent instances connected to the same machine type.
Learned Lessons Conducting this study helped us to learn several lessons. The first lesson is that the use of semantic web technologies to solve complex industrial problems is still a largely unexplored area. Even today most of the solutions on the market focus on the enterprise and IT side than on the operational side of large industries. This means that there are mature solutions that use semantic web technologies to bridge siloed enterprise data in RDBMS (Relational Database Management System) and unstructured data like documents but there is no mature solution that can do the same for data described in operation technology protocols, e. g. , OPC-UA (Open Platform Communications-Unified Architecture)  [35]. The second lesson is that technologies such as triplestore are not easily adoptable to typical industrial use cases.
Motivation: CellDesigner is a well-established biological map editor used in many large-scale scientific efforts. However, the interoperability between the Systems Biology Graphical Notation (SBGN) Markup Language (SBGN-ML) and the CellDesigner's proprietary Systems Biology Markup Language (SBML) extension formats remains a challenge due to the proprietary extensions used in CellDesigner files. Results: We introduce a library named cd2sbgnml and an associated web service for bidirectional conversion between CellDesigner's proprietary SBML extension and SBGN-ML formats. We discuss the functionality of the cd2sbgnml converter, which was successfully used for the translation of comprehensive large-scale diagrams such as the RECON Human Metabolic network and the complete Atlas of Cancer Signalling Network, from the CellDesigner file format into SBGN-ML.
CellDesigner is a well-established Systems Biology Workbench that facilitates biological network management including diagram editing and mathematical exploration of biochemical interactions  (Funahashi et al. , 2007). Maps developed using CellDesigner are included in large-scale scientific efforts such as the PANTHER Pathway  (Mi and Thomas, 2009), the BioModels (Le Novere et al. , 2006) , the Atlas of Cancer Signaling Network (ACSN)  (Kuperstein et al. , 2015)  and the Virtual Metabolic Human  (Noronha et al. , 2019)  databases and within the Disease Maps Project  (Mazein et al. , 2018). While there are several solutions managing separately SBGNspecific format (e. g. Gonc¸alves et al. , 2013; van Iersel et al. , 2012 )  V C The Author(s) 2020. Published by Oxford University Press. All rights reserved.
Methods The cd2sbgnml converter is a standalone Java-based software developed for translation between the CellDesigner (version 4. 4) file format, which is an extension of SBML with layout information, and the PD and AF languages of the SBGN standard format. The cd2sbgnml tool uses (i) the libSBGN library  (van Iersel et al. , 2012)  dedicated to management (reading, writing) of the SBGN files and (ii) the JAXB library and a manually-curated XSD file (created specifically for CellDesigner 4. 4) for handling CellDesigner files. The cd2sbgnml dual converter offers both a command line utility (scripts) and a graphical user interface to facilitate access to its functionality. A log file is also created to accommodate eventual messages of exceptions and warnings generated during the translation process.
Direct links to other links: In CellDesigner, arcs can point to other arcs. However, this representation is valid in SBGN ER only, which is not currently supported by the cd2sbgnml converter. Thus, such links are discarded by the translator. Representation of CellDesigner 'mixed' diagrams: While the reduced notation of CellDesigner is similar to the AF SBGN language, CellDesigner allows development of 'mixed' diagrams, where the main notation and reduced notation are combined. However, given that the SBGN standard has separate means to represent PD and AF projections, losing reactions of this or that type is unavoidable when converting such mixed diagrams.
Funding This work was supported by the  European Union   Horizon 2020 research and innovation programme PRECISE  [ 668858  to L. R. and E. B. ], iPC [826121 to A. Z. and E. B. ]; and the  Scientific and Technological Research Council of Turkey  [ 111E036  to U. D. ]. This work was also supported by the  Innovative Medicines Initiative Joint Undertaking  under grant agreement no. IMI 115446  (eTRIKS) to  Charles Auffray  and  Rudi Balling , resources of which are composed of financial contributions from the  European Union 's  Seventh Framework Programme  ( 2007-2013 ) and EFPIA companies.
In order to bridge the communication between both disciplines, it is important for data scientists to also have knowledge on how to design effective visual representations of the solution. If it is not the case, then it would be necessary to include information visualization experts to contribute in this domain. Finally, there are the providers of the nontraditional data to be used for building the solution who might not necessarily belong to any of the involved disciplines but are equally relevant as stakeholders, as defined by the data collaboratives framework  [9]. The methodology is summarized in Figure  1  and consists of the following steps: 1. Algorithm Design: to process both domain requirements and nontraditional datasets to reach a first version of the solution.
Algorithm Design We worked with anonymized mobile phone data of type "Extended Detail Records" (XDR), consisting of billing records of data usage by smartphones. Each record contains the following metadata: device identifier (anonymous), tower identifier, and timestamp. The device identifiers are coherent in the dataset, which means that a spatio-temporal trajectory of users can be constructed from XDR. However, its usage in transportation analysis is not straightforward. For instance, towers have a connection coverage of around 1 kilometer on average. They are not distributed uniformly in the city, making the spatial granularity dense but not uniform. The temporal granularity is not uniform either, with varying frequencies during the day  [43]. A trajectory can be constructed for each device, enabling the identification of trips  [37] , but care must be taken since this trajectory does not necessarily resemble a traditional route in the city (see Figure  2 ).
From a modeling perspective, we noted that single trajectories were not enough to reliably identify its mode(s) of transportation, which implied that we needed to aggregate user trajectories. Then, we identified that the situation could be described as a soft clustering problem, where each cluster is labeled with a mode of transportation. This rationale was based on how public transport users follow specific routes and how people tend to repeat their trajectories in commuting trips, which allowed us to aggregate them in terms of recurrent trips. After testing the accuracy of several clustering methods, we found that a model known as Topic-Supervised Non-Negative Matrix Factorization (TS-NMF)  [44]  was commonly assessed as an interpretable model due to is simple mathematical definition. Being a semisupervised model, it enables the integration of external knowledge in parts of the dataset.
The room was arranged as a round table in which all participants could see each other and interact in a comfortable way. Participants were able to connect their mobile devices to the screen and use an interactive pointer within the system, as a way to enable single and collaboratively built queries and questions. After the session, participants filled out a questionnaire regarding their experience. However, the most fruitful information was extracted from the conversation between experts during the session. From their perspective, this kind of model could be valuable; however, they questioned how the model outcomes could be integrated in their own pipeline of tools, both in terms of operational and methodological aspects. On the one hand, they needed more estimations of the data and model bias and errors, which were still not provided by the visualization nor the model.
After following the methodology, the end-result was a solution for a transportation problem based on data science. The methodology and its execution were designed having adoption of the solution as one key objective. We can comment that, indeed, the solution was adopted-it is being used at the time of writing this paper to infer the OD matrix and its corresponding modal partition in the conurbation of Rancagua-Machalí, in the south of Santiago. This conurbation is much smaller than Santiago, with around 300K inhabitants, and is being surveyed with a travel survey at the same time, which will allow the generation of an effective ground truth dataset to evaluate the system and serve as a pilot for the entire collaborative effort between these three institutions.
Acknowledgments: We wish to thank the  Atelier Team at Inria Chile  (http://inria. cl/) for help in organizing and holding the interactive session, particularly to  Celeste Bertin  for her technical support. We thank  Sebastián Aedo  and  Víctor Navarro  for their help implementing software. We also thank  Francisca Arévalo  for help in organizing and designing the pilot workshops and  Karina Flores  for interviewing experts in the last stages of the research. Finally, we thank  Viviana Muñoz  from the  Secretary of Transportation  for helping us to build bridges between disciplines.
Phylogeography and demography of the H. melpomene clade We obtained approximately 5. 2 Mb of sequence distributed across 8 chromosomes from 473 individuals and 39 populations representing 10 species from the H. melpomene clade (S1 and S2 Tables). Phylogenetic reconstructions confirmed that H. cydno populations, with the sole exception of H. c. cordula found east of the Andes and in the Magdalena Valley, and H. timareta populations from east of the Andes cluster as separate lineages from the H. melpomene clade (Fig 1B  and 1D ). Phylogenetic inferences including all sequenced regions agreed with previous multilocus phylogenies, in which H. cydno and H. timareta form a sister clade to H. melpomene (Figs 1D and S1)  [44, 50]. The tree built using only neutral background data (i. e. , regions a priori not suspected to be under mimicry selection, see Materials and methods) largely clustered populations according to geography, i.
Parallel selective sweep signatures between mimetic species There has been considerable interest in whether the H. erato and H. melpomene co-mimics have co-diverged and simultaneously converged onto the same colour pattern  [88] [89] [90] [91]  or whether one species evolved towards diverse phenotypes of the other, i. e. , advergence  [67, [92] [93] [94]. Homologous genes control corresponding phenotypes  [30, 35, 95, 96] , but there is no allele sharing between the melpomene and erato clade  [67, 68]. We used published genomic data for H. erato (Van Belleghem and colleagues, 2017; S10 Table) to obtain 8. 9 Mb of sequence homologous to the regions studied in the H. melpomene clade for 103 individuals from 13 populations and 3 species in the H. erato radiation and scanned for selective sweeps.
Many studies have used naive genome scans to identify selection in natural populations, but such an approach can lead to false positives  [101]. More integrative approaches, which   [39]. Full, grey lines connect colour pattern elements with annotated CREs. Note that the genetics of the yellow forewing band differs between H. erato¸in which it involves the WntA and optix locus, and H. melpomene, in which the band is controlled by the cortex and its shape by the WntA region. Data are available from https://github. com/markusmoest/SelectionHeliconius. git. CLR, composite likelihood ratio; CRE, cis-regulatory element. https://doi. org/10. 1371/journal. pbio. 3000597. g005 combine selection scans with information on phenotypic selection in the wild and genetic trait mapping, can give a more complete picture of how selection shapes specific loci and phenotypes  [10, 12, 14, 16, 102].
SLiM simulations Simulations were conducted to compare the genomic signatures of classical selective sweeps and sweeps that occur via adaptive introgression using SLiM (version 2) forward-in-time population simulation software  [123, 124]. Because SLiM tracks mutations and individuals through time, we were able to track individual beneficial alleles going to fixation and post sweep; however, it is computationally intractable to simulate very large populations with SLiM, and so we instead simulated smaller populations and rescaled population genetic parameters, N and μ, such that our results are applicable to Heliconius (as is commonly done  [124, 125] ). Two populations of N = 1,000 were simulated with a neutral mutation rate μ of 6×10 -7 such that the expected level of neutral diversity in the population was 0.
Inference of selection and summary statistics in sliding windows Summary statistics informative on diversity and selection patterns were calculated. From the unphased data, nucleotide diversity, Kelly's Z nS , Tajima's D, and number of sites genotyped for each population were calculated in 1 kb nonoverlapping sliding windows with at least 100 sites genotyped for at least 75% of all individuals within that population using custom python scripts and the EggLib library version 3  [129]. Scans for selection using signals of extended haploptype homozygosity and calculation of the pooled integrated haplotype homozygosity score (iHH12)  [11, 130]  were performed using the program selscan1. 2 [131]  and our phased data set.
VolcanoFinder We also tested the new software VolcanoFinder on our data, described in a recent preprint, which is specifically designed to detect introgression sweeps but can also detect classic sweeps  [27]. As for the SF2 runs, we used data sets with outgroup minimum 1 (-OM1) and background SFS calculated from background regions to generate the allele frequency files and the required unnormalized site frequency spectrum. We then ran VolcanoFinder with the following specifications: Model 1 and P = 0. melpomene clade populations for each of the 4 colour pattern regions. Superimposed, semitransparent SweepFinder2 peaks are depicted in grey. Colour pattern genes (yellow), known CREs (red), and additional genes with evidence for a putative role in colour patterning (blue and green for genes discussed in the main text) are highlighted and assigned a number in the top row.
Also shown are neutral background values, BG, calculated over neutral simulations, either without migration (left hand panels, for classic sweeps) or with migration at M = 0. 2 (right hand panels, for introgressed sweeps). Time is given in units of scaled generations. Data are available from https://github. com/markusmoest/SelectionHeliconius. git. BG, background; CLR, composite likelihood ratio. https://doi. org/10. 1371/journal. pbio. 3000597. g002.
Note that the yellow hindwing bar controlled by the cortex region can be expressed on the dorsal and ventral side (yellow/yellow square symbol) or on the ventral side only (black/yellow square symbol) [39]. Moreover, the actual shape of the forewing band can depend on the allelic state of WntA. Full, grey lines connect colour pattern elements with annotated CREs. Phenotypes are depicted on the right. Data are available from https://github. com/markusmoest/SelectionHeliconius. git. CLR, composite likelihood ratio; CRE, cis-regulatory element. https://doi. org/10. 1371/journal. pbio. 3000597. g003.
Grey shadings indicate annotated CREs, and red and grey arrows depict associations with the respective colour pattern elements in the H. melpomene clade. Data are available from https://github. com/markusmoest/SelectionHeliconius. git. CLR, composite likelihood ratio; CRE, cis-regulatory element. https://doi. org/10. 1371/journal. pbio. 3000597. g004.
Top and bottom panel show colour pattern phenotypes, and symbols indicate distinct colour pattern elements and their presence in each population panel. Note that the yellow hindwing bar controlled by the cortex region can be expressed on the dorsal and ventral side (yellow/yellow square symbol) or on the ventral side only (black/yellow square symbol) [39]. Full, grey lines connect colour pattern elements with annotated CREs. Note that the genetics of the yellow forewing band differs between H. erato¸in which it involves the WntA and optix locus, and H. melpomene, in which the band is controlled by the cortex and its shape by the WntA region. Data are available from https://github. com/markusmoest/SelectionHeliconius. git. CLR, composite likelihood ratio; CRE, cis-regulatory element.