dataesr/scientific-paragraphs-categorization huggingface dataset:
Our model is developed through a community effort and has evolved steadily since its origin in the BioMedBridges project (concluding in 2015)  [2] , and more recently during its development for ELIXIR  [3] , resulting in the latest stable version 3. 3. 0. In the Comparison to Related Efforts section we introduce and compare biotoolsSchema to various relevant software metadata initiatives, in the context of providing stable solutions to maintain FAIR principles (Findable, Accessible, Interoperable, Reusable)  [4]  between software providers and consumers. biotoolsSchema is broadly applicable but optimized to describe bioinformatics tools-application software with welldefined data-processing functions (inputs, outputs, and operations). This includes simple tools with 1 or a few closely related functions, and complex, multimodal tools with many functions, available for immediate use as online services, or in a form that users can download, install, configure, and run themselves.
biotoolsSchema defines 50 scientific, technical, and administrative attributes. It concentrates on salient common features, necessary and sufficient for the systematic cataloguing and use of tool information in a variety of contexts. Internally, the EDAM ontology  [5]  enables rigorous and consistent description of tool functionalities (see "Model of tool function"), such that tools can be readily found, comprehended, and compared by typical software end-users. biotoolsSchema is available as XML Schema (XSD) and JSON Schema variants and can be used to validate corresponding tool descriptions in XML, JSON, and YAML formats. We summarize the design, methods, and implementation of biotoolsSchema, comparing it to complementary approaches. We also summarize its applications, including the description of a dataset of >17,000 tools registered in the bio.
Scope biotoolsSchema is applicable to a nearly complete range of application software, including command-line tools, scripts, libraries, workflows, web applications, database portals, web APIs, web services, SPARQL end points, desktop applications, plug-ins, workbenches, and suites. These tool types and their definitions were settled following an analysis of bio. tools and are included as a controlled vocabulary within biotoolsSchema (see section Controlled vocabularies). They are intended to provide a practical and intuitive designation. In principle, when describing a tool, 1 or more tool types may be assigned, reflecting the different facets of the software being described. biotoolsSchema includes general attributes such as tool description, publication, and license. Execution-layer information, e.
Software attributes biotoolsSchema covers a total of 50 scientific, technical, or administrative software attributes, organized for convenience into 9 logical groupings (Fig. 1 , Table  1 ). To support the broadest range of applications, only bare-bones metadata (name, short description, and home page) are mandated, the rest of the attributes (Table  2 ) being conditionally required or optional. The small mandatory core of elements was also a practical necessity for the curation of bio. tools at a very large scale, to facilitate the registration of new entries that can be subsequently improved by the author or the broader community. Element cardinality constraints (1 only, 1 to many, 0 or 1, 0 to many) were chosen to provide flexibility, where applicable. To enable concise information, standard identifiers are used where possible, e.
Scientific concepts The EDAM ontology  [5]  provides the core vocabulary for the scientific description of tools including types of data and data identifiers, data formats, operations, and topics. EDAM organizes these concepts into the EDAM Topic, Operation, Data, and Format subontologies. Concepts may be specified by 1 or both of an EDAM concept URI (e. g. ,  [12] ) and/or a term (e. g. , "Proteomics")a preferred label or synonym of a concept from the appropriate EDAM subontology. It is strongly recommended to specify at least the URI because these persistently identify a concept (labels and synonyms can change).
Credits and contact information Credits and contacts for a tool are handled by a consolidated mechanism. Creditable or contactable entities of various types (e. g. , "Person," "Institute") and roles (e. g. , "Developer," "Support") must have ≥1 of a name, e-mail, and URL. ORCIDs provide a persistent reference to information on an individual person. Global Research Identifier Database Identifiers (GRID IDs) and Research Organization Registry Identifiers (ROR IDs) are used for organizations, and Crossref Funder Registry Identifiers (FundRef/Funder IDs) for funding organizations. Specification of these IDs, where available, is strongly recommended because these enable sustainable maintenance and reuse of relevant metadata.
biotoolsSchema supports other types of identifier, and software version information may be attached to the entire tool description, or to a specific identifier, download, or publication, and specified in a flexible way allowing, e. g. , a single version label or a list or range of labels to be annotated. In case a single label  annotation reflects a rigorous assignment of software version made by the tool developer, this can be used in conjunction with the bio. tools tool ID to uniquely identify a particular software artefact. As of September 2020, bio. tools includes 17,370 entries and a total of 301,956 individual annotations, including 101,517 references to concepts from the EDAM ontology, as per attributes de-fined within biotoolsSchema. Individual tool descriptions vary in richness and are being progressively improved, through an initiative that engages the community with the curation process  [16, 17] , e.
g. , producing a high-quality tool description corpus for proteomics data analysis  [18]. The bio. tools content, user interfaces, and API will be described in more detail in a future publication. The type of tool identifier, e. g. , "doi" Tool type  (15)  The type of application software, e. g. , "Command-line tool" Operating system (3) The operating system supported by a downloadable software package, e. g. , "Linux" Programming language  (57)  Name of programming language the software source code was written in, e. g. , "C" License (326) Software or data usage license, e. g. , "GPL-3. 0" Maturity  (3)  How mature the software product is, e. g. , "Mature" Cost  (3)  Monetary cost of acquiring the software, e. g. , "Free of charge" Accessibility  (3)  Whether there are non-monetary restrictions on accessing an online service, e.
Serialization formats and transformations bio. tools supports upload and download of biotoolsSchemaformatted data in a choice of serialization formats (XML, JSON, or YAML). XML support in bio. tools was developed using XSLT transformations to support 2-way, lossless interconversions between biotoolsSchema-formatted XML files and the JSON, YAML, and generic XML formats that are natively supported by the Django web framework used by bio. tools. This offers maximum flexibility to providers and consumers of biotoolsSchemaformatted data, allowing for rigorous validation (against the XSD) irrespective of favoured format. The transforms are freely available  [19]. For illustration purposes, a sample JSON file for the SignalP command-line tool (biotools:signalp) (Fig. 4 ) is shown. We also recently created conversion code to support the lightweight JSON-LD format of the Bioschemas  [20]  Tool profile, which is now available through the bio.
Comparison to Related Efforts Various research infrastructure or community-led initiatives (Table  4 ) have defined, or are in the process of defining, sets of information fields to describe bioinformatics software application metadata. The Health Care and Life Sciences (HCLS) Community Profile  [21]  was an early effort of the Semantic Web Health Care and Life Sciences Interest Group  [22]. It specifies dataset descriptions using the Resource Description Framework (RDF), using 24 core metadata elements, and recommends reuse of various well-established, general-purpose RDF controlled vocabularies including Dublin Core  [23] , Friend-of-a-Friend  [24] , and PROV  suited for general-purpose, lightweight markup of web pages for discovery purposes. This is in contrast to biotoolSchema, which is tailored specifically to detailed descriptions of applica-tion software especially, and mandates stricter syntax and semantics.
A Tool Profile  [27]  currently under development for the Bioschemas project  [20]  will provide guidelines on the consis- Basic metadata requirements for software citation  [34]  Various initiatives for software metadata of relevance to biotoolsSchema are described. tent adoption of Schema. org markup for the description of software tools in life sciences, including, e. g. , recommending the use of EDAM ontology for scientific aspects. The emerging Tool Profile is fully compatible with biotoolsSchema, and we have implemented it in bio. tools, which now serves via the API a Bioschemas serialization of the bio. tools content. Parallel to initiatives depending upon Semantic Web technologies are efforts reflecting existing practice or the requirements of various research infrastructures. CFF  [1]  is a YAML format for general-purpose software annotations.
Its focus is to support all citation-specific use cases for the citation of software and thus promote attribution and credit of research software. It provides more detail in this area than biotoolsSchema but lacks attributes, e. g. , around tool functionality, which are a focus of biotoolsSchema. The DataCite Metadata Schema from DataCite  [35] -a non-profit organization that provides persistent identifiers (DOIs) for research data-includes core metadata properties primarily for resource identification, citation, and retrieval, encapsulated in an XML schema with usage guidelines. The Application Profile included in the Guidelines for Software Repository Managers from OpenAIRE [36]-a European project supporting Open Science-is based on DataCite and covers 23 software attributes, primarily to make software products citable.
Similarly, the Software Citation Principles produced by FORCE11 community initiative  [37]  define 11 basic metadata requirements for software citation. The SciCrunch registry  [38]  shares a similar purpose to bio. tools but uses an RDF-based data model. Their scope is similar, but biotoolsSchema enables, through its use of EDAM, the end-user to drill down to fine-grained aspects of tool functionality such as specific inputs, outputs, and operations. SciCrunch uses persistent Research Resource Identifiers (RRIDs)  [39] , which in case of computational tools are equivalent to bio. tools tool IDs. The eInfraCentral Service Description Template produced by the European E-Infrastructure Services Gateway, eInfraCentral  [40] , is (as a work in progress) defining the information requirement for a common E-Infrastructures service catalogue, which will describe and offer services to endusers in a harmonized way, through the European Open Science Cloud (EOSC) portal  [41].
The crosswalk (a work in progress) yields an exhaustive set of 65 software metadata concepts (mostly mapped to Schema. org concepts) and can inform efforts to produce a minimal concept vocabulary for software reflecting a consensus in the mappings. biotoolsSchema has been submitted as a CodeMeta crosswalk (see below) and covers many of the common concepts, despite these not always being explicitly mapped owing to technical limitations of how the crosswalk is currently represented. This summary of initiatives is not exhaustive. Others include the DOE CODE initiative  [45]  for code archiving by the U. S. Department of Energy (DOE), guidelines  [46]  for rich search results for software from Google, and specialized ontologies for software including SWO  [47]  and OntoSoft  [48] , each serving a different use case.
We have thus a plethora of different recommendations and ways to annotate and share software metadata. The diversity reflects a wide range of perspectives, use cases, and contexts but brings the challenge of curating software metadata and sharing it between systems whilst avoiding inconsistencies and duplication of efforts. We ameliorate this interoperability issue, at least so far as sharing and reusing bio. tools metadata, through an exhaustive crosswalk (Table  5 ) between biotoolsSchema elements and key software metadata initiatives including CodeMeta, Schema. org, OpenAire, DataCite, HCLS, eInfra-Central, FORCE11, and miscellaneous RDF vocabularies. Each element in biotoolsSchema was mapped, where possible, to the corresponding field used by these initiatives, and the mappings aggregated, discussed, and reviewed, resulting in a consolidated crosswalk (Table  5 ) for biotoolsSchema, which has been submitted to the CodeMeta.
Here, biotoolsSchema, through its use of the EDAM ontology, enabled the precise annotation of tool inputs, outputs, and operations that was critical for workflow synthesis. biotoolsSchema thus encompasses diverse use cases, from provenance through to query and discovery, and can help to standardize the curation and exchange of metadata across software projects, repositories, initiatives, and organizations. In biotoolsSchema, a great complexity of informationincluding tool functionalities, fields of use, interfaces, deployments, distributions, documentation, and so on-is reduced to a manageable and practical level. The model is applicable to nearly all technical types of tool, and supports the uniform description of key scientific, technical, and administrative attributes. Specifically, in line with tasks T1 and T3 addressing tool surveys and community-oriented registries, it allows for a presentation and comparison of tool information, which often cannot conveniently be obtained from a Google search or cursory inspection of a provider's website.
biotoolsSchema will thus provide a means to relate a large set of tools such as in bio. tools to a broader and flourishing ecosystem of workflows, databases, and ontologies. Future changes will be pragmatic, driven by community use cases, and in light of practical experience of what data are useful and readily available. No single model, registry, or initiative can hope to cover all bases. biotoolsSchema can be augmented by (and will not duplicate) the functionalities of re-lated well-maintained models provided by more specialized initiatives, e. g. , execution-layer information about command-line tools provided by CWL, or information about service end points supported by OpenAPI  [58]. More specifically, we plan to build upon previous work  [59] [60] [61] [62]  to improve the cross-linking and cross-enrichment of execution-oriented tool descriptions with biotoolsSchema data.
Volatile attributes, or attributes that must be frequently recalculated, such as metrics of usage, technical performance data, links to similar tools, software dependencies, hardware requirements, and so on, will remain out of scope. Different software metadata use cases have different information requirements. biotoolsSchema supports very minimal or much more comprehensive information specifications, according to needs, without imposing a high curation burden and thus a barrier to adoption. It provides the basis for, but cannot in itself specify, a flexible information requirement suited to diverse purposes and contexts, e. g. , curation of registries such as bio. tools, required information for service delivery plans, publication of software articles, or metrics for software metadata or project quality.
For such purposes, a framework  [63]  for tool information requirements is under development ("Tool Information Profiles"), which is based on biotoolsSchema but goes beyond the syntactic/semantic constraints that can conveniently be defined in XML schema. Human-readable guidelines for curation of software metadata are also being developed as part of an emerging Curators Guide  [64]. biotoolsSchema, with progressive development and adoption, can benefit the whole bioinformatics community. It can help to support best practices promoted by various research infrastructures that emphasize the value of bioinformatics software registries for findability  [65, 66] , and bridge the gap between technology-oriented developers and service-oriented research infrastructures and organizations. The field of software metadata management is socially and technically very complex and includes many more stakeholders and perspectives than are summarized here, with multiple projects serving different but overlapping needs, use cases, and contexts.
Design considerations Requirements were established during a series of communityled workshops resulting in 10 founding principles and design considerations, now implemented as characteristics of biotoolsSchema: r Practical-focus on salient attributes of practical value in ev- eryday use, especially to support the discovery, use, and practical interoperability of software; superfluous details are excluded. r General-generally applicable, i. e. , to all manner of bioinfor- matics resources (see Scope). r Consistent-use ontologies and standardized enumerations of terms (see Controlled Vocabularies) where possible, to support precise searches over biotoolsSchema-formatted data and return of consistent and therefore comparable information. r Concise-mandate URLs or standard identifiers where possible, helping to ensure the sustainable upkeep of biotoolsSchema-formatted data and support future integrations, applications, and cross-linking with other resources.
I4S Software dependencies are documented and mechanisms to access them exist. biotoolsSchema provides a controlled vocabulary of documentation types (e. g. , Installation instructions), which should describe software dependencies in detail. It also provides a controlled vocabulary for describing dependencies between software resources as relationships between tools (using, e. g. , "uses" and "usedBy" of "relation" attribute biotoolsSchema attribute "documentation" supports links to various documentation resources, and specification of documentation type (e. g. , "Citation instructions"). For each FAIRness criterion for software (in column 1) as proposed in  [51] , the role of bio. tools (column 2) and biotoolsSchema (column 3) are summarized. Some of these criteria, such as the assignment of an identifier, are satisfied by a bio.
The events allowed us to combine contributions such as the addition of content by domain experts with the collection of feedback and requirements on EDAM, biotoolsSchema, and bio. tools. Whenever possible, we also included downstream activities, including request management using agile techniques such as priority poker, and development and debugging activities. In parallel, development was informed by growth in bio. tools: major content providers and other end-users have helped to validate the model, with the registry itself providing a valuable dataset for this purpose. Thus, we consider the stable version (3. 3. 0) to satisfy major community requirements and provide a solid foundation upon which the content, functions, integration, and applications of portals such as bio. tools can be built.
The model must be subject to future improvements, and the schema is extensible; both the number and type of attributes can evolve, according to end-user requirements. To provide stability for developers and software dependencies, major changes are restricted to approximately yearly cycles in released stable versions. Future versions will not depart fundamentally from the attributes or structure described in this article. From version 3. 0. 0, version numbers follow the SemVer 2. 0. 0 scheme  [68]. All developments are tracked at GitHub [69]; feedback, contributions, and collaboration are welcome. biotoolsSchema is a community-driven project governed under the leadership of the French ELIXIR Node (Jacques van Helden, Joint Head of Node) in collaboration with partners within and beyond ELIXIR, ensuring its sustainability.
Downloaded from https://academic. oup. com/gigascience/article/10/1/giaa157/6121637 by guest on 23 February 2021 Downloaded from https://academic. oup. com/gigascience/article/10/1/giaa157/6121637 by guest on 23 February 2021 [25]re4: Sample JSON file for signalp tool. [25]. We will describe in a future publication biotoolsRDF[26], an application ontology that defines the OWL2 Web Ontology Language encoding of biotoolsSchema. Like the HCLS Community Profile, it reuses other well-established vocabularies wherever possible, but provides a richer set of attributes and is specifically geared towards application software metadata rather than Figure 4: -continued datasets in general. Tangential to these is the Schema. org vocabulary, founded by the major web search engine providers. It is an exhaustive controlled vocabulary used to annotate con-tents of web pages and is organized into a hierarchy of a broad range of conceptual classes.
Non-linear arithmetic expressions over sole discrete variables are allowed too. Automata Synchronization. IPTAs can be synchronized together on shared actions, or by reading shared variables. All variables (clocks, parameters, discrete) are potentially global in IMITATOR. This allows users to define models component by component. Arbitrary Flows. Since version 3. 0, IMITATOR supports arbitrary (constant) flows for clocks; this way, clocks do not necessarily evolve at the same time, and can encode different concepts from only time: temperature, amount of completion, continuous cost. Their value can increase or decrease at any predefined rate in each location, and can become negative. In that sense, IMITATOR's clocks are closer to continuous variables (as in hybrid automata) rather than TAs' clocks; nevertheless, we keep the name clock for sake of backward-compatibility.
Distribution IMITATOR is distributed under the terms of the GNU General Public License. Its source code is therefore publicly available, and benefited from several contributors' additions. IMITATOR is available online 2  , together with its documentation, and a benchmarks library  [26]. IMITATOR depends on several libraries. Notably, the core engine relies on the Parma Polyhedra Library (PPL)  [32]  for the computation of symbolic states. As a consequence, IMITATOR can be cumbersome to compile. For this reason, standalone binaries are available for all Linux-like systems. A Docker version 3  (made by Jaime Arias) and a prototype Web service 4  are available too. An extensive user manual, explaining all algorithms and providing users with a full description of the input syntax for models and properties, is available  [10].
A Selection of Applications IMITATOR was applied to a variety of both academic and industrial case studies over the last few years. These applications range within several domains, including real-time systems, testing and monitoring, cybersecurity, or hardware verification. One can cite: -the parametric verification of an asynchronous memory circuit by ST-Microelectronics (from a model described in  [37] ), -verification of parametric scheduling problems by Astrium Space Transportation  [40]  and ArianeGroup SAS  [13] , -analysis of music scores  [38] , -verifying the multi-processor image processing system of an unmanned aerial aircraft with uncertain periods, as a benchmark made public by Thales  [46] , -parametric pattern matching and monitoring of logs from the automative industry  [20] , -synthesis of timing/cost parameters in attack-fault trees  [23, 31] , -testing product lines using parametric constraints  [44] , -verification of an industrial asynchronous leader election algorithm by Thales using IMITATOR combined with abstractions  [18] , -performing parametric opacity analyses for timed automata  [30] , and -synthesis of parameter valuations guaranteeing liveness properties for the Bounded Retransmission Protocol  [11].