dataesr/scientific-paragraphs-categorization huggingface dataset:
KE-chain guides engineers through the various steps of the Systems Engineering development process through a dedicated and user-friendly GUI. KE-chain serves as broker for the other OCE technologies and data, thereby hiding as much implementation detail as possible from the engineers so that they can focus on their engineering activities. A schematic overview of KE-chain as front end for the OCE is depicted in Fig. 3. KE-chain gives access to different data standards for the modeling information across the development process (such as SysML, CPACS, CMDOWS), manages expert knowledge and tools such as ADORE, MDAx, KADMOS, and supports the collaborative application of the MBSE methodology with the aim to perform MDAO. These tools are either embedded directly in the KE-chain front end or interact with the KE-chain data model through the Python library Pykechain  [28].
OCE tools are integrated as engineering services which can be executed directly on the KE-chain server using Docker containers hosting dedicated Python computational environments. The collaborative definition and modelling of systems, stakeholders, needs, scenarios, and requirements is supported by the GUI of KE-chain. Different people having different roles in the development process (e. g. customers, requirement engineers) can collaboratively author and inspect the data regarding the first two steps of the AGILE 4. 0 Systems Engineering process depicted in Fig. 1  using KE-chain. In addition, model validation scripts are integrated in the KE-chain back end in order to automatically identify possible errors, missing details and inconsistencies in the information produced by different members of the team.
The intermediate part of the AGILE 4. 0 Systems Engineering Product Development process focuses on the generation of multiple alternatives for system architectures that fulfil all the needs demanded by the stakeholders. System architectures are created by multiple people through the modelling of an architecture design space based on the ADSG. The GUI for editing the ADSG is implemented in a tool called ADORE  [29]. Its graphical user interface is implemented using web technologies to ensure that the back end (the Python code implementing the ADSG) and the front end (the browser-based interactive GUI code for manipulating the ADSG) do not have to reside on the same server. This enables the use of the tool and method without any need for local installation. Beyond mere user convenience, this also serves to protect IP rights and enables accelerated release cycles.
C. Tool Integration in Cross-Organization Collaborative Workflows The AGILE 4. 0 OCE provides and integrates several technologies that support the execution of cross-organization collaborative MDAO workflows generated as described in sections IV-A and IV-B, considerably easing the practical collaboration challenges identified in section III-C. To support connecting the variety of domain-specific tools at data level, the AGILE 4. 0 OCE utilizes a common format for data compatibility among engineering tools, the Common Parametric Aircraft Configuration Schema (CPACS)  [33]. CPACS is an open-source, XML-based common language for the exchange of product data. It allows storage of parametric definitions of aircraft geometries, as well as analysis results of the individual design disciplines, in a hierarchical structure that facilitates the consistent exchange of product data at multiple levels of fidelity.
As an example, ONERA's surrogate modelling competences relies on the SMT Toolbox  [36]  and are made accessible "as a service" to SMR through WhatsOpt  [37] , a web application supporting MDAO collaborative activities. In order to achieve this new capability, SMR has been extended to facilitate the registration of WhatsOpt surrogate models so they can be executed directly via the SMR user interface as well as indirectly from within RCE workflows utilizing SMR model. The registration of the WhatsOpt surrogate model at SMR is possible from WhatsOpt, making a surrogate model created using WhatsOpt to be available via the SMR as well. The metadata of the surrogate model is provided using a JavaScript Object Notation (JSON) format file including the inputs and outputs information as well as the associated WhatsOpt identifier.
Four AGILE 4. 0 partners are collaborating in this AC, as shown in Fig. 9. Each partner provides different analysis tools necessary to enable the specified trade-off. GKN Fokker provides two analysis tools: the Multidisciplinary Modeler (MDM)  [39]  and the Cost Analysis Tool for Manufacturing of Aircraft Components (CATMAC)  [40]. MDM is a Knowledge Based Engineering (KBE) tool that generates the geometric model of the flap. The MDM has a module called CAD2FEM that generates the FEM model of the flap. CATMAC calculates the manufacturing and assembly costs of the flap. TU Delft provides two analysis tools: Proteus  [41] , which uses the FEM model from the MDM to size the composite skin of the flap, and the Landing Performance Tool, which calculates the landing distance of the aircraft. NLR provides the AMLoad  [42]  tool, which calculates the loads on the flap for different load cases.
To keep the execution time under one hour, it was decided to replace the ASTRID and tailplane sizing and maximum lift estimation tools with surrogate models. For the latter, an approach similar to the one applied to wing mass estimation was applied. For the ASTRID tool, however, IP rights constraints were applicable, and therefore it was not possible to create a surrogate model locally. Instead, the SMR service is used to call a surrogate model residing at the partner's computer. Both the family-level and the aircraft-level workflows are modelled using MDAx and implemented in RCE. The RCE workflows are created directly from MDAx export, but require some modifications before they are actually executable: Disciplines had to be replaced either with the appropriate script(s) and tool(s) or by a Brics call; scripts were added to convert between family-level and aircraft-level CPACS files; and converger, output writer, and Brics settings were iteratively checked and corrected.
Once the DOE or optimization algorithm starts to generate design vectors to be analyzed, ADORE takes care of converting the design vectors to a physical architecture model that can be evaluated. As architectures are evaluated using the MDAO workflow in RCE, a bridge needs to be established. This is done using MultiLinQ which maps an architecture to a CPACS file and back, using rules defined using its GUI. Communication between MultiLinQ and the workflow in RCE is established using Brics: A Brics Python adapter sends the file to the workflow and waits for it to send back a response. Fig. 15  shows this in a sequence diagram. Experience gained from the AC7 workflow shows that Brics works well within the context of IP-rights constraints, and in general for remote or cross-environment (Python to RCE) data communication.
For this reason, several tool-specific trees were created with their own respective identifiers for filtering, something that is not (yet) supported by the CPACS standard. On the family-level, MDAx is well-suited to create RCE workflows that implement such filtering. However, to achieve that, several custom scripts were needed to automatically modify tool I/O definitions for the three aircraft. Adding such modelling features to the MDAx GUI would be a valuable addition. Using ADORE together with MultiLinQ to drive the optimization loop works very well, especially when applying newly developed optimization algorithms implemented in Python. Using MultiLinQ to define the logic for mapping a physical architecture to a CPACS file, however, takes quite a lot of debugging and it remains to be seen whether that approach is flexible enough to cover all application cases.
High-fidelity results can be obtained in drastically reduced computation time thanks to the integration of surrogate models provided via the SMR in the design workflow. Tradeoff analyses to evaluate the best retrofit solution according to stakeholders' needs are hereby proven and within reach. The Family Concept Design application case introduces several challenges to the collaborative environment. For example, Brics technology is successfully applied in the setup and application of a large and complex collaborative workflow, using custom scripts rather than the ready-to-use RCE Brics Plug-ins. Several disciplines are integrated in the workflow using surrogate models to reduce the optimization workflow runtime. This application case also demonstrates successful application of several collaborative systems engineering tools, such as MDAx for workflow modelling, ADORE for manipulating ADSGs, and MultiLinQ for linking architecture models created using ADORE to MDAO workflows.
Introduction Accuracy of feature annotation and metabolite identification in biological samples is a key element in metabolomics research. However, the annotation process is often hampered by the lack of spectral reference data in experimental conditions, as well as logistical difficulties in the spectral data management and exchange of annotations between laboratories. Objectives To design an open-source infrastructure allowing hosting both nuclear magnetic resonance (NMR) and mass spectra (MS), with an ergonomic Web interface and Web services to support metabolite annotation and laboratory data management. Methods We developed the PeakForest infrastructure, an open-source Java tool with automatic programming interfaces that can be deployed locally to organize spectral data for metabolome annotation in laboratories.
Standardized operating procedures and formats were included to ensure data quality and interoperability, in line with international recommendations and FAIR principles. Results PeakForest is able to capture and store experimental spectral MS and NMR metadata as well as collect and display signal annotations. This modular system provides a structured database with inbuilt tools to curate information, browse and reuse spectral information in data treatment. PeakForest offers data formalization and centralization at the laboratory level, facilitating shared spectral data across laboratories and integration into public databases. Conclusion PeakForest is a comprehensive resource which addresses a technical bottleneck, namely large-scale spectral data annotation and metabolite identification for metabolomics laboratories with multiple instruments.
Introduction Over the last 20 years, untargeted metabolomics has developed into a powerful phenotyping tool to better understand biological systems and identify associated biomarkers. This approach, based on multiple analytical platforms, generates massive and complex data that need appropriate analyses to extract biologically-meaningful information  (Alonso et al. , 2015). In particular, downstream analysis of metabolomics data requires annotation and identification of features in metabolic profiles. In order to move towards standardized identification methods, the metabolomics community has proposed a definition of metabolite identification accuracy ranges from unknown compounds to confidently-identified compounds  (Sumner et al. , 2007). This classification undergoes regular amendments, led by the Metabolomics Society and international consortia  (Creek et al.
, 2014; Malinowska & Viant, 2019) , in order to reduce ambiguities, better account for chemical structures and improve metabolite annotation confidence. However, metabolite annotation remains a major bottleneck in untargeted mass spectrometry (MS) and nuclear magnetic resonance (NMR) metabolomics  (Dona et al. , 2016; Nash & Dunn, 2019) , and the development of workflows and dedicated tools is critical for accurate metabolite identification  (Misra, 2021). In high-resolution MS or NMR datasets, the first annotation step generally consists of matching experimental accurate masses or chemical shifts with those contained in public and commercial databases. Vendors and associated companies offer a large number of solutions to mine MS or NMR spectral libraries directly from their own instruments (e.
g. NIST™) and proprietary databases such as Che-nomx™. However, these solutions can lack interoperability with academic bioinformatic tools and often require specific acquisition conditions that oblige operators to adopt operating procedures that differ from experimental conditions. Public libraries have the advantage of hosting large-scale data from different organisms and technical instruments, and include a multiplicity of cross-references concerning biological or chemical information  (Vinaixa et al. , 2016). Valuable metabolomics resources in the field include MS libraries such as Wishart laboratory databases  (Wishart et al. , 2018) , the Global Natural Product Social Molecular Networking (GNPS,  Wang et al. , 2016) , LIPID MAPS  (Fahy et al. , 2009) , MassBank  (Horai et al. , 2010) , Metlin  (Guijas et al.
, 2018) , MoNA or mzCloud™. The NMR community shares resources with MS, such as the human metabolome database  (Wishart et al. , 2009) , and NMRspecific banks such as the BioMagResBank  (Ulrich et al. , 2007) , the Birmingham Metabolite Library  (Ludwig et al. , 2012) , and more generalist banks including NMRShiftDB  (Kuhn & Schlörer, 2015)  for organic compounds. This relative abundancy of resources represents a large data heterogeneity, from "in silico" spectra derived from modeling and/ or references to highly-curated spectra obtained from pure compounds, and remains far from containing experimental data of all known metabolites  (Vinaixa et al. , 2016). As with commercial resources, the exchange and interoperability of annotations from one laboratory to another can be difficult due to different formatting requirements.
Moreover, existing databases are not always easy to increment with new compounds or spectra from external users due to logistical constraints or lack of recommendations  (Johnson & Lange, 2015; Spicer et al. , 2017). Database interoperability simplifies the mining of multiple databases, promotes efficient use of metabolomics data and is at the heart of FAIR guidelines ("Findable, Accessible, Interoperable, Reusable"). At the metadata level, common vocabulary and consensual description levels in data collecting steps are required  (Alseekh et al. , 2021). At the computing level, common formats and application programming interfaces (API) are needed to enable data exchange between databases and connect databases to data treatment tools  (Anwar et al. , 2021; Merlet et al. , 2016). Recent calls in the metabolomics community emphasize the need to develop adapted informatics infrastructures for laboratories based on FAIR principles in order to improve the exchange and interoperability of annotations from one laboratory to another and the sharing (and inclusion) of local spectral libraries with reference databases  (Haug et al.
Materials and methods PeakForest is a modular framework including a database, a graphical user interface and a Web API. It is designed to ensure interoperability, easy deployment and code sustainability. Particular care has been taken to ensure resource security and intellectual property (data author, licensing, bibliographic references). PeakForest manages metabolomic data during the metabolite identification process, from the acquisition of chemical standard spectra, the annotation of spectra in biological matrices via external peak matching tools, to the spectra linkage with external resources for biological interpretation or publication (PeakForest has been specifically designed to be easily interfaced with external tools). Users can import compounds and spectral data manually extracted from raw data, curate information and exploit this knowledge via data export or PeakForest Web services connected tools (Fig.
PeakForest framework technical specifications PeakForest is a Java Web application (version 8) and has been designed as an API's toolbox (Online Resource 1). The architecture leverages a complete data model, integrating entities as chemical compounds and spectra. PeakForest proposes representational state transfer (REST) protocol-based Web services allowing programmatic data access to external resources and tools. Based on the OpenApi (v3. 0) standard, any developer can generate a PeakForest Web services client in common programming languages (Python, R…). Centralizing the REST specifications in a unique OpenAPI compliant file allows consistent documentation, up-to-date code and exchanges between servers and clients. All PeakForest components use the same Java APIs. The Web application and the REST documentation are hosted on a Tomcat server (version 7) allowing the application to be run using a basic Java virtual machine (version 8).
Source and code project PeakForest is a free and open-source project under the CECILL-2. 1 6 license, published on GitHub. 7 Issues and incidents can be reported on this PeakForest official public Fig. 1  PeakForest database inputs and outputs 3 https:// peakf orest. org/ local_ insta ll. 4 https:// peakf orest. org/ howto. 5 https:// hub. docker. com/u/ metab ohub. 6 https:// cecill. info/ licen ces/ Licen ce_ CeCILL_ V2. 1-en. html. 7 https:// github. com/ peakf orest. repository. The PeakForest database model and project code have been deposited on APP, 8 a European organization for the protection of authors and publishers of digital creations (ID:  IDDN. FR. 001. 180009. 000. S. C. 2021. 000. 31230).
Compounds data and metadata inputs Adapted for compounds already present in public databases, the import module allows the addition of individual chemical compounds, attributes a specific internal identifier, and creates the associated compound card from an InChIKey or a common name (Fig. 2 ). An "addition assistant" checks if the compound is already present in the database, and proposes compound candidates based on the Fiehn 'Chemical Translation Service'  (Wohlgemuth et al. , 2010)  and the PubChem PUG-REST service  (Kim et al. , 2018)  where necessary to complete the missing lnChIKey data. Using the same Web services, this module fills missing information such as synonyms, structural representation of compounds and provides external cross-references where available. The module computes accurate mass, formulae and SMILES (simplified molecular-input line-entry system) as well as running molecule structure image depiction with OpenBabel.
A "cross-reference identifiers" section includes four selected external chemical compounds bank references, with ChEBI  (Hastings et al. , 2016) , PubChem  (Kim et al. , 2021) , KEGG  (Kanehisa et al. , 2016) , and HMDB  (Wishart et al. , 2018 ) and a modular system to add any Web hyperlinks from specific biological knowledge banks or metabolic networks databases. The compound card also gives direct access to the full list of spectral cards available on the database instance, grouped by analytical techniques.
Spectral data and metadata inputs The spectral module allows the addition of new spectra to the local PeakForest database. PeakForest supports a large range of spectral types, in line with common metabolomics analytical technologies: NMR-1D ( 1 H, 13 C), NMR-2D (JRES, COSY, TOCSY, NOESY, HSQC, HMBC), LC-MS(/ MS n ), FIA-MS(/MS n ) and GC-MS. During the spectral import process, all spectra are associated with a chemical compound, and qualified as either a chemical standard, part of a chemical standard-mix, present in a reference biological matrix (e. g. NIST plasma) or in a biological (or environmental) matrix. Spectral data models have been designed based on expert advice using standardized metadata describing NMR and MS acquisition methods. Heterogeneity of analytical instruments is considered, and unique descriptors 10 are proposed to enable metadata sharing within the metabolomics community.
PeakForest uses IUPAC nomenclature and MassBank consortium proposal 11 for mass spectrometry  (Murray et al. , 2013)  and suggests the use of standardized and chemically-consistent ion annotation procedure following the recommendations of  Damont et al. , 2019  for user-defined peak attributions  (Damont et al. , 2019). The database structure also supports information on sample preparation and species origins. An interactive and adaptive Web form is provided for spectrum addition, with four major steps for a LC-MS spectral import example: spectrum type, sample type, liquid chromatography condition and MS analyser information. An excel-like file template can also be generated with prefilled and predefined data and metadata based on user analytical methods (example templates in Online Resources 3-6).
Standardized operating procedures to ensure data quality Different standard operating procedures (SOPs) provide comprehensive information about the data that can be stored in PeakForest, allowing users to achieve high-quality data levels in local PeakForest databases. All SOPs and publication references are publicly and freely-available on the PeakForest Web portal peakforest. org. To illustrate Web interfaces and MetaboHUB SOPs application, a PeakForest demonstrator is available at https:// demo. peakf orest. org. This instance contains a dataset of 96 chemical compounds selected for their biological interest and their relativelyeasy identification in biological matrices or biofluids. The demonstrator also contains a spectra collection acquired on different analytical platforms for a range of analytical conditions by the MetaboHUB consortium, including flow injection analysis (FIA), reversed-phase (C18) chromatography and hydrophilic interaction chromatography (HILIC) coupled to an Exactive or an Orbitrap Fusion (Thermo Fisher Scientific) or an Impact HDII Quadrupole-Time Of Flight (QToF) (Bruker, Daltonics) mass spectrometer; gas chromatography coupled to Accurate Mass QToF 7200 mass spectrometer (Agilent Technologies, Inc); Avance III NMR spectrometers (Bruker, Biospin) with different environments (magnetic field from 500 to 800 MHz for proton frequency and probes at room temperature to cryoprobes).
In silico data checking and automatic/manual curation The PeakForest data model specifies mandatory data and metadata to be included during import phases, with inbuilt routines to limit or identify mistakes and data inconsistency. For example, PeakForest manages chemical compound unicity, based on the InChI/InChIKey set. If a user imports information about a compound already present in the database, new common names are added to existing ones as synonyms but properties such as the accurate mass are not recomputed. If different external identifiers (e. g. ChEBI ID) are provided, the system does not update them but creates a "curation message" associated with the compound. This curation message text will indicate the nature of the conflict and "curator" users will be able to manually update the entry if a correction is required.
Exporting data from PeakForest Since sharing and opening data are as important as building and organizing individual laboratory data and metadata, PeakForest proposes two ways to export local collections into current metabolomics standards. This functionality guarantees the interoperability of PeakForest data collections with common bioinformatics tools, as well as the export into international metabolomics databases (MassBank, MONA, HMDB, GNPS, …) and repositories (MetaboLights, Metabolomics Workbench, …). All compounds and their properties can be exported as a "comma separated value" formatted file, and individual. compound cards can also be exported manually as a SDF  (Dalby et al. , 1992)  formatted file. Spectra are exportable in the MassBank text format and/ or specific open formats adapted to different measurement techniques (e.