dataesr/scientific-paragraphs-categorization huggingface dataset:
To verify this for the 2PP model, a sample of 10,000 doublets (k, k s /k) was generated with the Latin Hypercube Sampling, and the NIPCE metamodel applied to the sample. The PDFs of the 120 and 10,000 NIPCE predictions are shown together in Figure  9 , where the bars' heights are scaled by the total number of predictions for each case (i. e. , 120 and 10,000, respectively). Using all 190 (HAX model) or 120 (2PP model) data sets allows for the computing of the NIPCE-predicted PDF of the outputs of interest. The NIPCE allows for an increase in sample size, but the PDF is similar to the PDF predicted, with a sample size of 190 or 120. To verify this for the 2PP model, a sample of 10,000 doublets (k, ks/k) was generated with the Latin Hypercube Sampling, and the NIPCE metamodel applied to the sample.
For the 2PP model, the roughness height k is the most sensitive parameter, responsible for about 90% of the changes in ice thickness and extension. To improve the rough turbulence models, it seems necessary to reinforce the experimental databases by precisely measuring the heat transfer variations induced by typical ice roughness. The present work shows that the precise knowledge of the heat transfers associated to a specific roughness pattern is key to ensuring reliable numerical icing predictions. Future investigations will be conducted to apply the same methodology to an airfoil. Canada. CFD computations were made on the Cedar supercomputer from Simon Fraser University, managed by Calcul Québec and Compute Canada.
In  [13]  the authors show the interest in using a model-driven approach for robotic application in the context of ROS, allowing component reusability and composability and giving the opportunity to generate ROS code from models. It follows the AutomationML standard  [7]. Such benefits are also possible with HyperFlex  [3, 9]  a model-driven engineering environment, whose approach and toolchain enable the explicit representation of robot system architectures. It aims at supporting the development of software product lines for autonomous robots based on robotic component frameworks, such as ROS and Orocos. The modeling of robot system architectures is done at design time with HyperFlex. The ReApp (Reusable Robot Applications for Flexible Robot Plants Based on Industrial ROS) project  [27]  does model-based design of robot applications too.
The architecture is explicitly modeled, and it is possible to switch from one target platform to another easily. The same benefits are claimed by ROS Model  [12, 11] , a DSL allowing to design robot applications. Its main platform target is ROS, but it allows the possibility to switch target later. One interesting feature is to be able to do some limited validation at design-time, by checking the interconnection between the components (ROS nodes). It is also possible to do reverse engineering, generating a ROS model that can be used in their framework from ROS source code. This reverse engineering is made with the help of the static analyzer of ROS software: High Assurance ROS (HAROS)  [23]. It can perform static analysis of C++ source code and build visual representation of the components of a ROS system.
Robot Operating System (ROS) ROS is a popular, widely used open source framework for developing robot software systems. It aims to reduce the difficulties of the development process with a set of libraries and tools. It has been initiated in 2006 and was an attempt to avoid the situation in which robotics was stuck reinventing the wheel. ROS provides a common interface to any robot, allowing programs to be reused more easily and it also offers a common interface for real robot and simulated robot, allowing to develop in simulation. The fundamental concepts of the ROS implementation are nodes, messages, topics and services. • Nodes are software modules, typically POSIX processes, sending and receiving messages. A node is a part of a much larger system, and nodes communicate with each other through messages.
General Purpose Modeling Language Approach The Object Management Group (OMG) promotes, among other technologies, the Unified Modeling Language (UML), as a generalpurpose modeling language. UML is a graphical language for visualizing, defining and building software-intensive system artifacts. UML provides a standard way to express a system's blueprints, which include both conceptual items like business processes and system operations and concrete items like programming language instructions, database schemas, and reusable software components  [20]. Tool IBM Rational Rhapsody 2  is an UML industrial tool integrating validation capabilities. It supports UML, SysML, UAF and AUTOSAR, and has great possibilities for the modelisation of the behavior with the possibility to do simulation of the model with symbolic execution.
UML Profiles Approach A UML profile  [24]  provides a generic extension mechanism for customizing UML models for particular domains and platforms. UML profiles are defined using stereotypes, tag definitions and constraints, applied to specific model elements, like Classes, Attributes or Operations. Stereotypes are used to customise the standard UML to the needs of specific application domains without altering the standard metamodel and while allowing some compatibility with generic UML tools. For the purpose of our study, we focus on a tool that offers a very good coverage of profile-based extensions: Papyrus  [8]. Tool Papyrus  [8]  is an open source modeling environment based on Eclipse, supporting UML, SysML and DSL. From a UML profile, it is possible to create a model with model execution and code generation enabled.
Domain-Specific Languages (DSL) Approach DSLs are a key part of MDE that offer the possibility to address specific application domains using constructs specific to these domains. DSLs aim at being accessible to field engineers that have little or no knowledge of computer science and they make this possible by offering a high level of abstraction. Tool Sirius 3  is an open-source software project of the Eclipse Foundation. It allows to create a DSL with a high level of customization, for example, models can be represented as diagrams, tables, matrices, trees, etc. It does not have validation capabilities or code generation, but those can be added using additional plugins, such as Acceleo or Xtext.
All of these objects are created in a package in the class diagram representing the ROS application. Figure  2  shows the class diagram of the ROS teleoperated robot Use Case we defined. In the component diagram we connect the nodes with ROS topics and services through their ports to define the structure of the application. Moreover, we exploit the advanced IBM Rational Rhapsody support for behaviour modeling of each node through statecharts, that include the manipulation of signals. We have modeled the three use cases using Rhapsody. Based on these modelings we evaluated the metrics identified in the previous section and this will be exploited in the comparison presented in the Section 8.
In addition, we defined the graphical representation of statemachine diagram associated to each node to determine its behaviour. This simple state-machine diagram allows the user to define states and transitions and to associate events, guards and actions to transitions as well as actions to states. The state-machine is event-based, so the transitions will be triggered by topic or service messages (this is comparable to the signal reception in the UML state machines). From the models, we can then generate the complete code of the ROS packages using the Eclipse plugin Xtext. We defined rules in the Xtend language that will be used during the transformation. The models are parsed and depending on the rules, they are transform into text, generating the C++ or Python code. The next paragraph presents the implementation of the use cases.
Comparison Technique Various approaches can be used to model ROS applications and several tool candidates are available. In order to choose between the various alternatives, as objectively as possible, we identified three promising yet conceptually different alternatives: (i) using UML language to model ROS applicationshere we use IBM Rational Rhapsody tool, (ii) using a UML profile to extend the UML standard with the few concepts needed to better capture ROS applications primitives -for this purpose we use the Papyrus tool, and (iii) creating a custom graphical DSL targeting ROS applications -Sirius offers an effective help in this direction. As mentioned in Section 3, other approaches for applying MDE to ROS applications exist in the literature and these approaches took one or the other of these directions, however, none presented an objective analysis of the reasons why.
This makes the model less complete since it forces the user to add by hand each attributes for each project and can lead to missing attributes for the complete code generation. Table  2  follows the scientific goal 2 (SG2): The tool should allow to use verification methods on the models. In terms of behaviour modeling (M1), the three approaches allow one to do it. Using UML profiles in Papyrus or native UML in IBM Rational Rhapsody, behavior can be specified using the state machines already defined in the standard UML, and the graphical DSL can do it by creating its own state machine. The state machine we created with the DSL is simple, but allows one to design a behaviour of node composed of composite states with history state, states, and transitions with fields such as on entry, do, on exit or guard to write code behaviour.
Using DSL, the component diagram can be customised to be close to the ROS graph (such as the one illustrated in Figure  1 ), making it more understandable for the field engineer. On the opposite, UML approaches require the field engineers to have previous knowledge on UML. Moreover, the need to use interfaces and signals/events in the UML approaches is also a disadvantage compared to DSL, since in ROS only a message type is needed to interface into a topic. Table  5  presents qualitative information for the three approaches. The three tools used to model the approaches are available on Linux and Microsoft Windows, however, IBM Rational Rhapsody (used for the native UML approach) is the only one not available on Mac OS (GM1). Papyrus and Sirius (used for the profile and DSL approaches) are both Open Source (GM2), while IBM Rational Rhapsody is Closed Source with paid licence.
The three approaches allow one to generate code (GM3). For the profile approach, Papyrus can natively generate Java and C++ code, and for the native UML approach, IBM Rational Rhapsody can generate C and C++ code. Code generation is also possible using DSL. Although Sirius does not natively allow this functionality, it can be easily done by integrating plugins compatible with the tool (for instance, Acceleo or Xtext), which allows to generate source text or models from domain-specific models. Thus, the advantage of using DSL is that one is not constrained in the choice of target language and can add all the needed details for the desired target language in the generation. The preparation of the code generator requires again bigger efforts compared to the other two approaches, but it leads to more freedom in the code generation.
Moreover, with the help offered by modern MDE environments such as Sirius, the ROS DSL specification can be used for generating ROS code and for performing early model validation, which as far as our ROS modeling is concerned, was an important criterion for comparison. The results also highly depend on the modeling tools used to create the models. In this study we used Papyrus, IBM Rational Rhapsody and Sirius, due to their modeling capabilities and vast usage. Other tools may lead to other results. The comparison we provide in this study is generic and could benefit other domains aiming to use modeling in the early steps on the development of applications. However it is not definitive. The outcomes of our comparison are highly dependent on the criteria we set. ROS systems could be modeled with any modelling approach, but the use of a DSL seems to be more appropriate in our settings (and in settings with similar priorities as ours) since DSLs offer more flexibility.
Recent advances in sequencing technologies and high-throughput phenotyping have revolutionized the analysis in the field of the plant sciences. However, there is an urgent need to effectively integrate and assimilate complementary information to understand the biological system in its entirety. We have developed AgroLD, a knowledge graph that exploits Semantic Web technologies to integrate information on plant species and in this way facilitate the formulation and validation of new scientific hypotheses. AgroLD contains around 900M triples created by annotating and integrating more than 100 datasets coming from 15 data sources. Our objective is to offer a domain specific knowledge platform to answer complex biological and plant sciences questions related to the implication of genes in, for instance, plant disease resistance or adaptative responses to climate change.
The question is, therefore, how to structure and manage the complexity of biological data in order to extract knowledge that can be used to identify the molecular mechanisms controlling the expression of plant phenotypes. Our hypothesis is that weaving these data and disparate information into a knowledge graph (KG) would enable the formulation and validation of research hypotheses that would link genotype to phenotype, hence unlocking the potential of the currently available decentralized scientific data. We have developed AgroLD (for Agronomy Linked Data)  [4] ,  4  a FAIR knowledge graph powered by Semantic Web technologies as a structure to integrate data, to enable knowledge sharing and to allow information retrieval at scale. It is designed to integrate available information on various plant model species in the agronomic domain such as rice, arabidopsis and wheat, to name a few.
The online documentation  5  shows the complete list of species with the total number of related protein entities. Among the contributions of the project is the development of the AgroLD schema, which combines newly created concepts/properties with concepts/properties imported from various ontologies from the biology field. Because life sciences and bioinformatics produce a large plethora of specific data formats, specific open source tools for data conversion to the Resource Description Framework (RDF) following the AgroLD schema have been developed and discusses in this paper. These different steps have led to the construction of several graphs on plant molecular interactions, which have been interlinked to form the AgroLD KG. We present these tools, together with a data fusion approach that allows for the construction of the pivotal AgroLD graph.
OntoForce 7  developed a new tool named DISQOVER for data discovery in life sciences. However, to the best of our knowledge, there was no equivalent in the plant sciences field before the AgroLD platform  [4]  was launched in 2015. In a related topic, KNETMINER  [38]  is a graph database for plant molecular network that has been developed with Neo4J and provides also a subset of its datasets through a SPARQL endpoint. Both KNETMINER and AgroLD have the same purpose and target the same scientific community. However, KNETMINER offers limited access to its features in its free version, while AgroLD has the advantage of being open and FAIR. 3 The AgroLD Knowledge Graph.
Overview AgroLD is built in phases spanning vast aspects of plant molecular interactions. The current phase (second phase) covers information on genes, proteins, predictions of homologous genes, metabolic pathways, plant phenotype and genetic studies. At this stage, we have integrated data from several resources such as Ensembl plants  [5] , UniProtKB  [6] , Gene Ontology Annotation  [7]. The choice of these sources has been guided by the biological community, as they are widely used and have a strong impact on the user's confidence. We have also integrated resources developed by the local SouthGreen platform  [8]  such as Trop-GeneDB  [9] , a tropical plant genetics database, OryGenesDB  [10] , a rice genomics database, GreenPhylDB  [11] , a comparative genomics database for tropical plants, OryzaTagLine  [12] , a rice phenotype database and SniPlay  [23] , a rice genomic variation database.
These resources bring together experimental data produced by researcher groups in Montpellier and the South of France. The online documentation provides an overview of the integrated data sources  8. The conceptual framework of AgroLD is based on well-established ontologies in the plant field such as Gene Ontology  [14] ,  Plant Ontology [15]  or Plant Trait Ontology  [16]. Furthermore, we developed a dedicated schema 9  that creates links between the imported ontologies and introduces new classes and properties. The online documentation  10  shows the complete list of the used ontologies. The majority of these ontologies are hosted by the OBO Foundry project  [17]. In the following, we describe the components of the knowledge graph and the process of its construction.
Statistics As of today, AgroLD contains more than 900 Millions triples resulting of the integration of roughly 100 datasets gathered in 33 named graphs. Table  1  gives a summary of all number of features. Table  3  gives an overview of available resources and tools. All datasets are available in Zenodo under the Creative Commons Attribution 4. 0 International license (CC-BY 4. 0). Each resource can contain several datasets, for instances, one dataset per species or per data type. Combining all ontologies and datasets imported, AgroLD graph gather 383 classes and 793 properties. Among the pipelines developed to lift up the datasets, we focused also on connecting our datasets with others. The property rdfs:seeAlso reach the total number of almost 80 millions of outbound links making the AgroLD graph correctly linked with other datasets in the LOD.
Besides, we paid attention to increasing the number of semantic annotations with imported ontologies, which increased the number of links between datasets making the overall graph denser. We created more than 14 million semantic links linking entities to ontological classes. Finally, our data linking strategy (see next section) allowed us to create around 160,000 owl:sameAs links between entities. exist within the Semantic Web community, including Datalift  [21] , Tarql  [22] , RML. io  [23] , none of them were adapted to take into account the complexity of data formats in the biological domain (e. g. VCF format  [18] ) or even the complexity of the information they could contain. A simple example illustrates this complexity through the GFF (Generic Feature Format)  [19] , which represents genomic data in a TSV type format (file with tabs as separators).
Challenges in Creating the AgroLD Graph The process of creating a knowledge graph is complex and challenging. In this section, we will present some of the challenges we had to address and in particular those related to managing the heterogeneity of the datasets and their sizes, aligning the entities and assessing the data quality. Concerning data heterogeneity, the main problem was the variety of the data formats which we solved by having RDF as unified format. We proposed several pipelines that were able to handle this variety and manage the size of the datasets. Indeed, as discussed in Section 3. 3, in the majority of cases, we preferred developing our own solutions instead of using generic tools to manage better the complexity or the size of the datasets. Another problem was the heterogeneity of the genomic coordinates (i.
e. different naming of the chromosome identifier, missing information, etc. ). We solved it by choosing a unique representation and transforming all coordinates in URIs patterns following the FALDO ontology representation  [34]. Concerning the entity linking problem (i. e. same entities having different names or identifiers), we managed to only partially solve this problem, by using pattern matching in URIs, or database cross-links to identify mappings between entities. Indeed, in the case where entities have a different namespace URI (e. g. namespace1:identifier1 and namespace2:identifier1), we search patterns matching in the URIs and create a new URI doing the mapping between them. In the case when entities have different URIs with no matching patterns but having synonym properties (i. e.
Data Access and Applications The AgroLD KG is available for access via a SPARQL enpoint 20. However, although the SPARQL language is efficient to build queries, regarding access to 20 http://agrold. southgreen. fr/sparql RDF data, it remains difficult to handle for our main users, which are mainly biologists with little or no background in formal query languages. Therefore, we propose a web application implementing various elements of a semantic search systems, such as pattern-based querying, graphical visualization, information retrieval tools. Hence, the AgroLD platform provides three entry points, as described in  [4] : -Quick Search is a faceted search plugin made available by Virtuoso that allows users to search by keywords and browse AgroLD content by navigating through links. Fig. 2A  shows the result of a keyword search.
The main area on the top left corresponds to the query area. Thanks to the YASQE tool, proposing several code editing functions, the code syntax is highlighted and checked for errors. Furthermore, users can load their own queries stored in a file in order to run batch queries and save their results in various file formats. It is also possible to build up queries by using query patterns. In this case, the users can select one of the dozen query patterns shown on the right. The query appears in the left-hand area within the query text box. Users can read the code of the query and see differently colored pieces of code according to the type of variable, string fields and SPARQL syntax. Hence, users can directly modify the code. There is also a text box above the query box that allows users to modify the value of the string parameter and by clicking on the apply button, it modifies the string value of the query.
Use-case Scenarios A better understanding of genotype-phenotype relationships requires the integration of biological information of various kinds. However, this information is often dispersed in several databases on the Internet each with different data models, scales or distinct means of access. For biologists, it is difficult to search relevant information in these databases as the mass of information can be incomplete and hard to manage. These problems are particularly relevant in the context of genetic association analyses or GWAS (Genome Wide Association Studies), which allow to associate large regions of the genome (locus) with a phenotypic trait (trait). GWAS loci often include several hundred genes that need to be analysed in order to identify only a fraction of the genes associated with the trait under study.
Next, the authors identified 20 candidate genes distributed along chromosome 4. By building a second query Q2, which retrieve the genes available for chromosome 4 and using a filter on "panicle", we obtained 15 genes results. Finally, the authors narrowed down the genomic region of chromosome 4 between 30 Megabases and 32 Megabases. They identified five candidates genes namely OsKS3, OsKS1, OsKS2, OsMADS31 and NAL1. On our side, querying the same genomic region with similar filters (Q3), we obtained only one gene: NAL1. However, using a less restrictive query (Q4), we obtained 81 genes results including the five candidates identified by the authors. By comparing our results to the ones in the paper, we can first argue that the authors have a larger GWAS/QTL datasets than AgroLD currently has integrated.