SBML Level 3: an extensible format for the exchange and reuse of biological models

1Systems modeling and numerical simulations in biology can be traced to the mid‐20th century. Though general theorizing about systems began earlier, the application of systems analysis to biology gained attention in the 1950s thanks to the work of biologists such as von Bertalanffy and Kacser (Von Bertalanffy,; Kacser, ). The era of numerical simulation in biology truly began with the landmark works of Chance on enzyme kinetics (Chance et al, ), Hodgkin and Huxley on the molecular basis of neuronal transmission (Hodgkin & Huxley, ), and Turing on the chemical basis of morphogenesis (Turing, ). Since then, the number and variety of models have grown in all of the life sciences. As precise descriptions of phenomena that can be simulated, analyzed, and compared with experimental data, models provide unique insights that can confirm or refute hypotheses, suggest new experiments, and identify refinements to the models.

2The availability of more data, more powerful modeling methods, and dramatically increased computing power led to the rise of systems biology as a compelling research theme around the turn of the millennium (Kitano,; Ideker et al, ). Though computational models were at first published as printed equations in journal articles, the desire to reuse an ever‐increasing number of models called for digital formats that were interoperable between software systems and could be easily exchanged between scientists (topics of interest as early as the 1960s; c.f. Garfinkel, ). This drove efforts to create tool‐independent ways of representing models that could avoid the potential for human translation errors, be stored in databases, and provide a common starting point for simulations and analyses regardless of the software used (Goddard et al,; Hucka et al,; Lloyd et al, ). One such effort was SBML, the Systems Biology Markup Language. Its initial design was motivated by discussions to create a “metabolic model file format” following a 1999 workshop (recounted by Kell & Mendes, ). A distributed community thereafter discussed ideas that informed work at Caltech in late 1999/early 2000 and led (after a series of public drafts) to the specification of the official version of SBML Level 1 version 1 being released in March 2001 (Hucka et al, ).

3While SBML was initially developed to exchange compartmental models of biochemical reaction networks primarily formulated in terms of chemical kinetics (Hucka et al, ), it was always understood that there existed more types of models than the initial version of SBML could represent explicitly. However, seeking community consensus on a limited set of simpler features, which could be readily implemented in software at the time, was deemed a more pragmatic strategy. A deliberate decision was taken to delay the addition of more advanced capabilities to a later time. As a result, SBML has evolved in stages in a community‐driven fashion that has benefited from the efforts of many researchers worldwide over two decades. As time passed, the need to support a broader range of model types, modeling frameworks, and research areas became apparent. SBML's success in serving as an interchange format for basic types of models led communities of modelers to ask whether it could be adapted or expanded to support more types. In addition to reaction‐diffusion models, alternative modeling frameworks have risen in popularity in the past decade (Machado et al, ), and researchers have faced interoperability problems between software tools developed for their use. These needs drove a profound change in SBML's structure: A facility to permit layering the core of SBML with new features suited to more types of models, together with a way for individual models to identify which sets of extensions they need for proper interpretation. The release of SBML Level 3 (Hucka et al, ) has provided a new foundation to enable the exchange of a greater variety of models in various domains of biology (Fig 1).

4In the rest of this article, we begin by summarizing SBML's general structure and then describe the modularity introduced in Level 3 and the wide range of modeling formalisms supported by Level 3 packages. We follow that by describing the community aspects of SBML development. We continue with a discussion of SBML's impact on both computational modeling and the modeling community, and finally, we close with a discussion of forthcoming challenges.

5The core of SBML is focused on encoding models in which entities are located in containers and are acted upon by processes that modify, create, or destroy entities. The containers do not need to correspond to physical structures; they can be conceptual or abstract. Additional constructs allow parameters, initial conditions, other variables, and other mathematical relationships to be defined (Fig 2A). In the most common type of model, the “entities” are biochemical substances, the “containers” are well‐mixed and spatially homogeneous, and the “processes” are biochemical reactions happening within or between the containers. This originally led to the SBML constructs being named species, compartments, and reactions, respectively (Fig 2B), but these names are historical artifacts and belie the generality of the underlying scheme. Software applications can map the names to other concepts to better suit their purposes. For instance, “species” could be mapped to populations of molecules, cells, or even organisms.

6Modelers and software developers are encouraged to use SBML's reaction construct to define a model's behavior in preference to formulating the model explicitly as a system of equations. This gives users freedom to convert the model into the final format they prefer—a simpler operation than (for example) inferring a reaction network from a system of differential equations. More importantly, the approach also naturally handles models where reaction kinetics are unknown or unneeded, such as interaction maps, and supports the elaboration of the reaction construct using SBML packages (discussed below). That said, the use of reactions is optional, and SBML provides features sufficient for encoding a large diversity of purely mathematical models, too. Whether using reactions or not, values of model variables and their changes over time may be fixed or determined by mathematical expressions, either before or during simulation, continuously or in response to discrete events, with or without time delays. Units of measurement can be specified for all entities and values; in addition to adding a layer of essential physical knowledge (after all, how else could one interpret whether a time course is in milliseconds or years?), information about units can be used to verify the relationships expressed in a model. Units also facilitate reuse of models and components, interconnection of models, conversion of models between different frameworks, and integration of data with models.

7SBML does not dictate which framework must be used to analyze or simulate a model; in fact, it purposefully lacks any explicit way to specify what is done with a model—whether to run simulations or other types of analyses, how to run them, or how to present the results—because externalizing this information enhances model reusability and permits independent innovation in separate but complementary formats. Two of the most popular methods for time‐course simulation are commonly used: one is numerical integration of differential equations created from the reactions and other relationships affecting model variables, and the other is simulating the time evolution of the model as a stochastic system via algorithms such as the one developed by Gillespie. Alternative approaches are also in use, particularly when a model is enhanced with SBML packages.

8Any element of an SBML model can be elaborated using machine‐readable metadata as well as human‐readable notes. For metadata, two schemes are supported. The first is direct labeling of SBML elements with terms from the Systems Biology Ontology (SBO; Courtot et al, ), which allows the mathematical semantics of every element of a model to be precisely specified. The second scheme uses semantic web technologies and provides greater flexibility to capture additional metadata. For instance, a molecular species in a model can be linked to a UniProt entry (The UniProt Consortium, ) if it represents a protein, or to ChEBI entry (Hastings et al, ) if it represents a simple chemical. Gene Ontology terms (GO; Ashburner et al, ) can be attached to species, compartments, and mathematical elements representing biological processes and functions. Simple provenance data such as identities of creators can be added to facilitate attribution and versioning. To help standardize how annotations are stored, SBML encourages the use of guidelines and resources established for this purpose (Le Novère et al, ). Finally, software tools can also use annotations to encode tool‐specific data in their own formats, thus providing a way to capture data that might otherwise be lost. Annotations thereby help enrich the meaning of model components, facilitate the understanding and reuse of models, and help software work with SBML more flexibly (Neal et al, ).

9The core features described above have been a backbone of SBML ever since Level 2, even as SBML continued to evolve. The development of the modular Level 3, discussed in the next section, provided an opportunity to rethink and redesign a few other rarely used features. For example, the species charge attribute, designed to represent molecular charge, was removed in Level 3 in favor of letting an SBML package introduce more complete support for the relevant concepts.

10Constant evolution in scientific methods presents challenges for the creation of software tools and standards. One challenge arises because the creation of new standards requires labor, testing, and time. This often causes standardization efforts to lag behind the latest technical developments in a constantly moving field. A second challenge is that users want support for new methods and standards in software tools, which pressures developers to implement support quickly. Combined with the first challenge, it means that sometimes problems with a standard's definition are not discovered until more developers attempt to use it in different situations, which in turn often means that revisions to a standard are needed after it is published. Finally, another challenge is that software development often takes place under resource constraints (funding and time), limiting the scope of work that software developers can undertake—including, sometimes, limiting how many features of a standard they can support in their software.

11The SBML community sought to address these challenges by putting in place certain structural features in SBML's development process. The first is the notion of Levels. A Level in SBML is an attempt to provide a given set of features for describing models, with higher Levels providing more powerful features. For example, the ability to express discrete events was added to SBML Level 2 but does not exist in Level 1. SBML Levels are mostly upwardly compatible, in the sense that the vast majority of models encoded in Level n can be translated to Level n + 1. Versions are used to introduce refinements to a given Level to account for realizations that come from real‐life use of SBML. Finally, SBML Level 3 introduced an extensible modular architecture consisting of a central set of fixed features (named SBML Level 3 Core), and a scheme for adding packages that can augment the Core by extending existing elements, adding new elements, and adjusting the meaning or scope of elements. A model declares which packages it uses in order to guide its interpretation by software applications. If a software tool detects the presence of packages that it does not support, it may inform users if it cannot work with the model. Together, these three features (Levels, Versions, packages) help address the challenges discussed above: they ease coping with evolution in methods by collecting significant changes into discrete stages (SBML Levels), they help deal with the inevitable need for revisions (Versions within Levels), and they allow developers to limit the feature set they implement (SBML Levels on the one hand, and SBML Level 3 packages on the other).

12Packages allow SBML Level 3 (Hucka et al, ) to represent many model types and characteristics in a more natural way than if they had to be shoehorned into SBML Core constructs exclusively. Twelve packages have been proposed to date (Table 1); eight have been fully developed into consensus specifications and are each used by at least two software implementations (Box 1), and another two have draft specifications in use by software tools. New packages can be developed independently, within dedicated communities, at a pace that suits them. This was the case for logical modeling with the CoLoMoTo community (Naldi et al, ), constraint‐based modeling within the COBRA community (Heirendt et al, ), and rule‐based modeling with a community of like‐minded software creators (Faeder et al,; Zhang et al,; Palmisano et al,; Boutillier et al, ).

13The “distrib” package (Smith et al, ) provides the means to encode information about the distribution and uncertainty of numerical values assigned to a model element. Biological models often contain elements that have inexact numerical values, since they are based on values that are stochastic in nature or data that contains uncertainty; however, core SBML has no direct support for encoding values sampled from distributions. The recently‐finalized “distrib” package adds constructs for sampling of random values from probability distributions and describing uncertainty statistics about element values.

14The “comp” package (Smith et al, ) allows users to build models from other complete models or from model fragments, as a way to manage complexity and construct composite models. “Submodels” can be described within the same SBML file or linked from external files. A submodel can act as a template, and the same definition can be reused multiple times in other models to avoid duplication and enable reuse of parts. The “comp” package also enables submodels to have explicit interfaces (known as ports) for optional black‐box encapsulation. Finally, “comp” was designed so that a hierarchical model can be converted into a single SBML model that does not use any “comp” features, making it readable by software that does not directly support the package. The library libSBML (Bornstein et al, ) provides a facility to do this.

15The “fbc” package (Olivier & Bergmann, ) provides a means of encoding constraint‐based models and optimizations, such as is done in Flux Balance Analysis (Bordbar et al, ). Constructs in the “fbc” package allow for the definition of a list of objectives for minimization or maximization, as well as flux bounds on reactions and gene‐reaction mappings. Additional information such as chemical formula and charge enable further model analyses, including calculation of reaction mass balances, electron leaks, or implausible sources of matter.

16The “groups” package (Hucka & Smith, ) provides constructs to describe conceptual relationships between model elements. Groupings can indicate classification, partonomy, or merely a collection of things; a group's meaning can be specified using semantic annotations. Groups have no semantic meaning and cannot influence the mathematical interpretation of an SBML model.

17The “multi” package (Zhang and Meier‐Schellersheim, ) manages the combinatorics produced by entities either composed of multiple components, such as molecular complexes, or that can exist in multiple states, such as proteins with post‐translational modifications. With the “multi” package, rules can be defined for how reactions depend on the states of the entities and their locations. The package adds syntactic constructs for molecular species types, compartment types, features, binding sites, and bonds. Entire families of molecular complexes sharing certain properties can be defined using patterns created using these constructs.

18The “qual” package (Chaouiya et al, ) provides constructs to encode models whose dynamics can be represented by discrete, reachable states connected by state transitions denoting qualitative updates of model elements. Examples include logical regulatory networks (Boolean or multivalued) and Petri nets. The “qual” package introduces SBML elements to allow the definition of qualitative species, which are used to associate discrete levels of activities with entity pools, as well as transitions, which define the possible changes between states in the transition graph.

19The “layout” (Gauges et al, ) and “render” (Bergmann et al, ) packages extend SBML to allow graphical representations of networks or pathways to be stored within SBML files. The “layout” package enables the encoding of positions and sizes of graphical elements such as nodes and lines, while the information about colors, fonts, etc., is defined by the “render” package. This separation presents several advantages. For example, applications can offer multiple styles for visualizing the same layout of a network map. Most of the essential aspects of a network diagram can be expressed using just the “layout” package, and thus tools do not necessarily have to implement a full graphics environment if they do not need to support customizing a diagram's look‐and‐feel.

20Several benefits accrue from leveraging SBML as a starting point rather than creating a new, independent format. One is it makes clear where common features overlap. Most computational modeling frameworks in the domain of biology share some common concepts—variables that represent characteristics of different kinds of entities and processes that represent interactions between entities, containers/locations, etc.—and reusing SBML Level 3 Core constructs makes the conceptual similarities explicit. This in turn makes interpretation of models easier (no need to learn new terminology) and reuse simpler (no need to translate between independent formats). Another benefit is that the creators of the format can leverage existing features developed for SBML, such as mechanisms for annotations, rather than spend time developing new approaches to achieving the same goals in a new format. This in turn leads to another benefit: the ability to reuse at least some parts of existing software libraries developed for SBML. It also means that a software application may be able to interpret at least some fundamental aspects of a model even if the application is not designed to work with a particular SBML Level 3 package, by virtue of understanding SBML Core (and perhaps other packages used by the model). This improves the potential for model reuse, and benefits model creators and software developers alike. Finally, a common foundation simplifies the creation of multiframework models in which some parts of the model use one formalism and other parts use others [e.g., coupling kinetic models with flux balance analysis; Watanabe et al, ).

21Though this modular approach has benefits, it is not without potential pitfalls. The main risks are fragmentation of the community, and incompatibility of packages due to complex feature dependencies. The SBML community has addressed the former by maintaining communications between package developers; the community processes have such interactions built in. As for the latter, API libraries (see Box 2) can handle some combinations of packages and hide some of the complexity. Still, there remain some combinations of packages that are not fully understood, and it remains for future work to define how (if ever) they can be combined for use in a single model.

22A catalog (http://sbml.org/SBML_Software_Guide) of software applications, libraries, and online services known to support SBML—over 290 entries to date A tabular interface highlights supported SBML features of each software system.A list interface displays human‐readable summaries of software systems.Software can be added to the list upon request.

23A tabular interface highlights supported SBML features of each software system.

24A list interface displays human‐readable summaries of software systems.

25Software can be added to the list upon request.

26SBML's success can be attributed largely to its community‐based development and its consensus‐oriented approach. SBML has always been developed through engagement with its user community to achieve goals expressed by that same community. To resolve occasionally conflicting technical demands, a guiding principle has been to seek consensus between different viewpoints and the needs of different groups, to find a middle ground that would be—while perhaps not a perfect solution—an acceptable and usable solution. This attracted the researchers and software developers who constitute SBML's foremost stakeholders. By using SBML in everything from software to textbooks, they helped drive further development to face the real needs expressed by the people who have those needs. This engagement allowed faster feedback from users to developers and has helped produce a rich toolkit of software and other resources that facilitate SBML's incorporation into software (Box 2).

27Over the years, the community has designed rules to organize its governance, develop and maintain the specifications, and facilitate collaboration among users. The development of SBML and its Level 3 packages is shepherded by the SBML Editors, a group of community‐elected volunteers serving terms of 3 years who follow a written and public process detailed on the web portal SBML.org.1 SBML Editors write or review SBML specification documents, organize discussions and vote on specific technical issues, and enact the decisions of the community. Major proposed changes to the specifications and packages are discussed by the community via the SBML mailing lists2 as well as during annual face‐to‐face meetings.

28The community currently comes together twice a year within the context of meetings organized by COMBINE the Computational Modeling in Biology Network; Hucka et al, ). HARMONY (the Hackathon on Resources for Modeling in Biology) is a codefest that focuses on the development of software, in particular via the development of libraries, tools, and specifications; by contrast, the COMBINE Forum meetings focus on the presentation of novel tools and the discussion of proposed features. In addition to these general meetings, special SBML working groups are organized as needed to drive SBML package development. COMBINE's central activity is coordinating and harmonizing standardization in computational biology, and SBML is one of its core standards. FAIRsharing, a broader community network that covers life sciences more comprehensively (Sansone et al, ), maintains interconnected and organized collections of resources in many areas, including curated links between SBML and many associated funders, databases, and standards.3

29As contributors to developments in methods, software, and standards over the past two decades (Hucka et al, ), we can attest to SBML's profound impact on the field, both from our own first‐hand experiences and from surveys (Klipp et al, ) that indicate SBML has become a de facto standard. The impact is a result of SBML's community‐oriented development approach and its design.

30The SBML development process has helped shape the field partly by directly involving software developers and modelers. Frequent workshops have provided essential feedback for developers to help them better serve modelers’ needs (e.g., Waltemath et al, ). Workshops as well as resources such as the SBML Software Guide (see Box 2) helped raise awareness of existing tools, which in turn increased their use and the use of SBML. This helped create a culture of sharing models and building on existing work in systems biology (Stanford et al, ). It also led to new activities centered on the models themselves, including automatic model generation, analysis of model structures, model retrieval, and integration of models with experimental data (Dräger & Palsson, ). SBML's successful approach to community organization has led other standardization efforts (BioPAX, NeuroML, SBGN, SED‐ML) to adopt some of the same approaches; SBML was also a founding member of COMBINE (Hucka et al, ), discussed above. Some of the primary standardization efforts in COMBINE, such as BioPAX (Demir et al, ) and NeuroML (Gleeson et al, ), are more domain‐specific than SBML; others, such as CellML (Lloyd et al, ), overlap SBML's primary domains but offer alternative abstractions; and finally, still others, such as SBGN (van Iersel et al, ), SBOL (Roehner et al, ), and SED‐ML (Waltemath et al, ), are complementary formats.

31Before the advent of SBML, it was challenging to exchange models because software tools used incompatible definition schemes. As models increased in size and complexity, manually rewriting them became more difficult, error‐prone, and eventually untenable. The development of SBML has enabled the use of a single model description throughout a project's life cycle even when projects involve heterogeneous software tools (Box 3). SBML‐compatible software tools today allow researchers to use SBML in all aspects of a modeling project, including creation (manual or automated), annotation, comparison, merging, parametrization, simulation/analysis, results comparison, network motif discovery, system identification, omics data integration, visualization, and more. Such use of a standardized format, along with standard annotation schemes (Neal et al, ) and training in reproducible methods, improves research workflows and is generally recognized as promoting research reproducibility (Waltemath & Wolkenhauer, ).

32SBML's impact on computational systems biology includes its facilitation of collaborative work. In multiple instances, it has precipitated entirely new projects, as illustrated by the examples below.

33Encoding a model in a standard format such as SBML makes it easier to use different software tools for different purposes without format conversion, and thus makes it easier to leverage the most suitable tools at different points in a workflow. The following is an example. A signaling pathway can be designed graphically using CellDesigner (Funahashi et al, ). The resulting model can then be semi‐automatically annotated using the online tool semanticSBML (Krause et al, ). Experimental kinetic information can be retrieved in SBML format from the SABIO‐Reaction Kinetics database (Wittig et al,). Tools such as COPASI (Hoops et al, ) and PyBioNetFit (Mitra et al, ) provide facilities to estimate parameters and to simulate the model with various algorithms. Other SBML‐enabled tools such as Tellurium (Medley et al, ) and PySCeS (Olivier et al, ) provide capabilities such as identifiability and bifurcation analysis. Each step of the process applied to a model from creation to publication of results—modeling, simulation, and analysis—can be documented using notes attached to every model element. The model can even be turned into a publishable document using SBML2LaTeX (Dräger et al, ). Finally, the model can be exported from selected modeling tools, together with data and other information all bundled together in COMBINE Archive format (Bergmann et al, ) and published in model repositories such as BioModels Database (Malik‐Sheriff et al, ).

34Being able to describe model elements precisely using semantic annotations facilitates the creation of automated pipelines (Dräger et al, ). Such pipelines can combine existing models with databases of molecular phenotypes or reaction kinetics (Li et al, ). They can also generate models de novo from data resources, as has been demonstrated by the Path2Models project (Büchel et al, ). Path2Models has produced 143,000 SBML models—all fully annotated—for over 2,600 organisms, by using pathway data. Metabolic pathways were encoded in SBML Level 3 Core while signaling pathways were encoded with the SBML “qual” package (Chaouiya et al, ). Moreover, constraint‐based models of genome‐scale reconstruction were provided for each organism. Other pipelines have now been built, including ones that can systematically generate alternative models for different tissue types (Wang et al, ) and patient data (Uhlen et al, ), an important step toward personalized medicine.

35Constraint‐based modeling approaches such as Flux Balance Analysis and its variants permit the use of whole‐genome reconstructions together with experimental molecular phenotypes, in order to predict how mutations or different environments affect metabolism as well as predict drug targets and biomarkers (O'Brien et al, ). With the availability of genome‐scale metabolic reconstructions, the use of metabolic flux models at the same scale has been increasing (Bordbar et al, ). A recent development in the field has been the curation of consensus metabolic models, in particular for human metabolism (Brunk et al, ). Those community efforts rely on SBML for encoding and sharing the models, including annotations, which are crucial to being able to reuse the reconstructions later, and also for visual representation using the Layout (Gauges et al, ) and Rendering (Bergmann et al, ) packages. The Flux Balance Constraint package (Olivier & Bergmann, ) enables encoding of the information required for model optimization and flux calculation. Unambiguous encoding in SBML has been shown to be crucial for interpreting models and precisely computing fluxes (Ebrahim et al,; Ravikrishnan & Raman, ), and new validation tools for genome‐scale metabolic models have been made available by the larger community (e.g., MEMOTE; Lieven et al, ).

36The availability of a well‐defined format has also facilitated the comparison of software tools to each other. Using SBML‐encoded models has become the norm to assess the accuracy of modeling software: initially it is done manually using models from BioModels Database (Bergmann & Sauro, ), and now, it is more commonly done using the SBML Test Suite (Box 2). SBML's semantics are defined precisely enough that many simulation systems can produce equivalent results for over 1200 test cases, lending confidence that SBML‐based simulations can be reproducible in different software environments.

37While chemical kinetics models have been a staple of systems biology, other modeling frameworks exist. These have benefited from efforts to extend Level 3 to better suit their specific characteristics. Even when models could in principle be encoded using core SBML constructs, the use of features explicitly adapted to the needs of a domain can make model interpretation less error‐prone and more natural. The former issue was demonstrated vividly when ad hoc methods of encoding genome‐scale models led to incorrect interpretations, and a subsequent proposal to use SBML Level 3 “fbc” addressed representational inconsistencies that had hindered reproducibility (Ebrahim et al, ). The use of more domain‐specific forms of encoding has been preferred by several communities, such as the qualitative and rule‐based modeling communities. For example, the quickly adopted package SBML Level 3 “qual” (Chaouiya et al, ) supports software interoperability for qualitative modeling, illustrated by the use of CellNOpt (Terfve et al, ), which provides a set of optimal Boolean models that best explains the causal relationships between elements of a signal transduction network and associated data, and the subsequent use of GINsim (Chaouiya et al, ) or Cell Collective (Helikar et al, ) to assess the dynamical properties of these models. Rule‐based modeling can represent models that are impossible to express as reaction networks, such as polymerization (Faeder et al, ), or simply impractical to represent due to the combinatorial number of reactions implied by the rules (Hlavacek et al, ). Storing rule definitions in SBML is now feasible with the “multi” package, allowing rule‐based modeling tools such as Simmune (Zhang et al, ) and BioNetGen (Faeder et al, ) to read and write the same model definitions.

38SBML has also eased the automated processing of models to the point where they have become just another type of data in the life sciences. SBML is used today as an import/export format by many databases of mathematical models (Misirli et al,; Norsigian et al,; Malik‐Sheriff et al, ), as well as by pathway databases (Caspi et al,; Mi et al,; Fabregat et al, ) and reaction databases (Ganter et al,; Wittig et al, ). SBML is the preferred format for model curation in BioModels Database (Malik‐Sheriff et al, ), not only because of its popularity but also because of its provisions to precisely encode and annotate models to support reproducible modeling. SBML is also used to share models by more generic data management platforms such as SEEK (Wolstencroft et al, ) and comprehensive online simulation environments (e.g., Moraru et al,; Weidemann et al,; Lee et al,; Peters et al, ). Moreover, having an agreed‐upon format has facilitated the introduction of better model management strategies. This includes support for tasks such as model storage and retrieval (Henkel et al, ), version control (Scharm et al, ), and checking quality and validity (Liebermeister,; Lieven et al, ). The proliferation of derived models has led to the development of methods to compare model structure and semantic annotations (Lambusch et al, ), culminating in the development of several methods to quantify model similarities (Henkel et al, ), that can then be used to improve the relevance of model searches. Once model elements can be compared, one can align, combine, and merge different models (Krause et al, ).

39A broader impact of SBML as a de facto standard has been the support of publishers and funding agencies. Many journals, aware of the challenges surrounding the reproducibility of scientific results, encourage authors not only to describe their models but also to make their models available in electronic form. Molecular Systems Biology was the first supporter of submissions in SBML format (beginning in 20054, 5). Today, most journals still avoid requiring a specific format, though some such as the BMC6 and FEBS7 journals do explicitly encourage authors to submit SBML files as supporting material for research where it is relevant. Others, such as Biophysical Journal (Nickerson & Hunter, ), recommend authors deposit models in repositories such as BioModels Database, which encourages the use of common standard formats such as SBML. Many funding agencies also now have policies related to data sharing, and some program announcements suggested the use of SBML where appropriate.8

40Finally, the continued development of SBML has stimulated collaborative work and the creation of consortia. This has led to better awareness and communication within groups interested in specific modeling frameworks. A good example is the CoLoMoTo effort mentioned above; it was launched by researchers who needed a format to exchange qualitative models between their software tools and developed the Qualitative Modeling package for SBML (Naldi et al, ) as the solution. Nevertheless, challenges remain, as discussed in the next section. These will need to be confronted to ensure the longevity of SBML as well as continued developments.

41For nearly two decades, SBML has supported mathematical modeling in systems biology by helping to focus the efforts of the community and foster a culture of openness and sharing. The field is evolving rapidly, which presents challenges that the community and SBML must face.

42The first challenge is to remain usable in the face of relentless growth in model sizes. One of the drivers of larger size is the rising popularity of genome‐scale metabolic models (Bordbar et al, ), which can be produced semi‐automatically (Henry et al, ). Modeling approaches have also been developed to combine the use of several such models (e.g., Bordbar et al, ). It is reasonable to expect models of ecosystems to be produced soon (microbiomes and their host). Model sizes will also increase as more models of tissues and organs are exchanged and reused, encouraged by the use of software packages that facilitate this approach, such as the open‐source tools CHASTE (Mirams et al, ) and CompuCell3D (Swat et al, ). The challenge this presents is how to define, organize, and manage large models. Meeting the challenge will require a combination of novel approaches to model storage (e.g., Henkel et al, ) and comparison (e.g., Scharm et al,,), as well as more effective use of SBML Level 3 features. For example, the SBML Hierarchical Model Composition (“comp”) package (Smith et al, ) provides a way to encode models in SBML out of separate building blocks or from preexisting models; this can make larger models easier to structure and maintain, and it is a natural way to construct multiscale models. Similarly, the Arrays package may help to define and structure larger models by allowing models to be defined in a more compact form.

43A related challenge concerns human usability of SBML and similar XML‐based formats. Though SBML is intended for software, not humans, to use directly, desire for a text‐based or spreadsheet‐based equivalent is often voiced (e.g., Kirouac et al, ). Various answers have been developed in the form of text‐based notations (e.g., Gillespie et al,; Smith et al, ) and spreadsheet conventions (e.g., Lubitz et al, ), with bidirectional translators for SBML. These formats have undeniable appeal for many users and use cases, despite that they do not capture the entirety of SBML (often having limited or missing facilities to express units, annotations, or SBML packages). Their chief drawback is that they become error‐prone to use as model size increases. Graphical user interfaces (GUIs; e.g., Funahashi et al,; Hoops et al,; Moraru et al, ) can overcome this; software with GUIs can help with the cognitive burden of tracking large numbers of model elements. On the other hand, GUIs can be tedious to use when entering large models, performance of some software does not scale well with increasing model sizes, and some cannot be controlled programmatically for automation purposes. A middle ground may be domain‐specific modeling languages layered on top of programming languages such as Python (e.g., Lopez et al,; Olivier et al,. However, these tend to appeal only to users who are comfortable with (or willing to take time to learn) the programming language used as a substrate. Overall, further innovation in this area would be welcome, both to help support SBML Level 3 packages and to help users cope with ever‐increasing model sizes.

44Because of the diversity of biological phenomena amenable to mathematical modeling, as well as their scales and properties, it is likely that a broad variety of modeling approaches will be added to every researcher's essential toolbox (Cvijovic et al, ). Methods such as multiagent and lattice approaches are coming into wider use to represent evolving cell populations, cell migration, and deformation. Some researchers are experimenting with solutions using existing SBML packages (Watanabe & Myers,; Varela et al, ). Modeling the development of tissues and organ function may also require combining these approaches with reaction‐diffusion models, or multiphysics approaches (Nickerson et al, ). Population modeling will need to complement traditional instance‐based systems if we want to take into account patient variability or information coming from single‐cell measurements (Levin et al, ). The coupling of different approaches within the same simulation experiment is also becoming more frequent. Biomolecular reactions modeled using ODEs, Poisson processes, and Flux Balance Analyses have been coupled in the first whole‐cell model (Karr et al, ). At the organ level, liver lobules have been modeled using a combination of metabolism and multiagent models (Schliess et al, ). Several approaches mixing modeling of cell mechanical properties and gene regulatory networks or signaling networks have been used to study morphogenesis (e.g., Tanaka et al, ). The coupling of different approaches can be done within a single hybrid model, or each model can be simulated using different software and with dynamic synchronization at run time (Mattioni & Le Novère, ). Once again, the SBML “comp” package can play a role in supporting these approaches, but other methods and software will be needed in the future, as well as better support for coupling models at run time using, for example, SED‐ML (Waltemath et al, ).

45These developments are arising in a landscape where structural models are sometimes not the central object of study, and instead function as collection of integrated information. An example of this is RECON3D, a comprehensive human metabolic network with metabolite and protein structure information (Brunk et al, ). SBML will continue to have a pivotal role here too. When SBML was introduced, the state of modeling workflows and software tools was more primitive and it was natural that a model was self‐contained. SBML‐encoded models often had predefined parameter values (as initial values for state variables or parameters for mathematical expressions), but today, modelers increasingly want to use the same model with different parameterizations, sometimes with parameter values expressed as distributions, lists, or ranges rather than unique values. A project may also use an ensemble of related models that differ in parameters or in turning some model elements on or off (Kuepfer et al, ). The semantic annotation of SBML elements also has become increasingly important, forming a bedrock for many of the analyses using SBML‐encoded models. The growth in size and scope of annotations has recently led the modeling community to propose a standard way of storing annotations in separate linked files (Neal et al, ), relying on the COMBINE Archive format (Bergmann et al, ) to bundle everything together. Other formats that can complement SBML have been developed, and further coordination and evolution will undoubtedly happen in the future. As mentioned above, SED‐ML is a format that provides a way to encode what to do with a model, which complements SBML and compensates for its lack of features to define procedures. Finally, experimentation in integrating SBML more directly with other formats and data also continues. For instance, preliminary work has shown that SBML can be enriched with SBOL (Voigt et al, ) to provide models of DNA components’ behavior (Roehner & Myers, ), and conversely, ongoing work in supporting genome‐scale models of metabolism and gene expression (known as ME‐models, Thiele et al, ) augments SBML with SBOL to more fully capture models for use with ME‐modeling software. Future developments in modeling paradigms may require similar flexibility in how models are represented: some may be best served by implementing new SBML packages, others by extending existing packages, still others by combining SBML with other formats.

46Besides the technical challenges, social and cultural challenges also exist for formats such as SBML. One is to continue raising awareness among researchers, software developers, and funders of the existence of SBML and related COMBINE standards. Some may not yet be using SBML simply because they are not aware of it, or its recent addition of support for many modeling formalisms (Fig 1). Raising awareness will require continual education and outreach, especially to students and early‐career scientists. Awareness would be aided by greater promotion on the part of journals and reviewers of the use of SBML and related formats in paper submission guidelines. Despite some progress in this area (discussed in the previous section), the lack of stronger demands by journals and reviewers is surely one reason authors are either not aware or not motivated to publish their models in software‐independent formats.

47In addition, usability of standard formats depends crucially on their implementation in software tools, and motivating this work is another challenge for SBML. A pivotal factor for the success of SBML has been the extensive software ecosystem, which provides relatively easy import and export of SBML from popular software systems. However, implementing full SBML compatibility in software is not a simple matter, and problems with compatibility in the software ecosystem can be a significant source of frustration. Improving the software requires continuous investment in tool development.

48That, in turn, is related to a final challenge: obtaining and maintaining funding. By virtue of not being a native format of any particular software tool, a format such as SBML may require extra work to define by consensus, and then again for developers to implement in software—and still, it will lag behind the leading edge of research because exchange formats only become important after more than one software system has something to exchange. Funders may wonder whether the resources, time and effort spent on standards development would not be better applied to other goals. However, these costs must be weighed against the costs to a whole research field of not having standards—and there are many such costs. To take one example, models in nonstandard formats are more difficult to review, verify, and reuse. Journal reviewers may not have access to the necessary software, or the software may not be well tested, all of which increase the chances that the published model contains errors. Researchers can spend substantial time attempting to reproduce the results, only to fail. Worse, this is a repeating cost: failures to reproduce models are rarely published or publicized, which means an untold number of researchers may spend time (and research funding) on a futile effort. Funders recognize that too many research results are irreproducible, and have urged community action (e.g., Collins & Tabak, ). The continued development of exchange formats, such as SBML, is a crucial and cost‐effective means to enable reproducible research.

49SBML and associated software libraries and tools have been instrumental in the growth of systems biology. As modeling and simulation grew in popularity, SBML allowed researchers to exchange and (re)use new models in an open, well‐supported, interoperable format. SBML has made possible much of the research pursued by the authors of this article and also helped us to structure our thoughts about our models and the biology they represent. Today, scientists can build, manipulate, annotate, store, reuse, publish, and connect models to each other and to basic data sources. In effect, SBML has turned models into a kind of data and transformed modeling in biology from an art to an exercise in engineering.

50As the field of systems biology continues to grow and address emerging challenges, SBML will grow along with it. This evolution will (as it always has) depend on close cooperation between biologists and software developers. We hope that SBML will continue to be a source of inspiration for many researchers, especially those new to the field. In return, may they help develop the next generation of SBML to support more comprehensive, richer, and more diverse models, and expand the reach of systems modeling toward entire cells, organs, and organisms.

51SMK, DW, MK, FZ, AD, CC, and MH wrote the bulk of the manuscript. Together with FTB, AF, CSG, TH, SH, RM‐S, SLM, IIM, CJM, AN, BGO, SS, JCS, LPS, MJS, DT, LW, and DJW, they also wrote and/or edited specifications for SBML Level 3 Core and the Level 3 packages. MLB, KB, JRF, HFG, TMH, YI, WL, ALL, DL, EM, CJP, KR, NR, CAS, BES, JS, JCS, NS, NT, and JW contributed proposals for SBML Level 3 and/or are past or current members of the SBML Team. MM‐S, HMS, BP, HB, HK, AF, HH, JCD, and MH were principal investigators (or the equivalent, depending on the institution) for grants supporting SBML development.

52The SBML community members listed in the Appendix supported the development of SBML Level 3 through participation in discussions, commentary on specification documents, and/or implementation of SBML‐using software.

53TH has served as a shareholder and/or has consulted for Discovery Collective, Inc.