dataesr/scientific-paragraphs-categorization huggingface dataset:
However, if a package defines an SIdRef that may refer to any SBase, it is legal for those references to point to SBML Level 3 Version 2 SIds. In particular: • An SIdRef defined in a SBML Level 3 Version 1 package may be used to reference an element from Level 3 Version 2 Core that has an SId, but did not have one in Version 1. • An SIdRef defined in a SBML Level 3 Version 1 package may be used to reference an element from an SBML Level 3 Version 2 package. • Any Math object defined in a SBML Level 3 Version 1 package may reference any SBML Level 3 Version 2 package SId defined as having mathematical meaning. To take some examples: the reference attribute of a SBML Level 3 Version 1 Layout GeneralGlyph is of type SIdRef, and was designed to be able to point to arbitrary SBML Level 3 Version 1 core and package elements.
If used in a Level 3 Version 2 Core document, it could now point to an AssignmentRule, which it would not have been able to do in a SBML Level 3 Version 1 document. Alternatively, it could point to an SBML Level 3 Version 2 package element that inherited an SId from SBase. Similarly, any Math element in an SBML Level 3 Version 1 package must be designed to be able to contain SIdRefs to SBML Level 3 Version 1 Core elements with mathematical meaning, but whose meaning might have been changed by a SBML Level 3 Version 1 package. These formulas may now skip the middle man and refer directly to SBML Level 3 Version 2 package SIds that have their own mathematical meaning.
Subset of MathML used in SBML Level 3 Core The subset of MathML elements used in SBML Level 3 Version 2 Core is listed below. An SBML Level 3 package may extend this subset (and if so, must define required="true" on the SBML container Section 4. 1). • token: cn, ci, csymbol, sep • general : apply, piecewise, piece, otherwise, lambda (however, as discussed elsewhere, lambda is restricted to use in FunctionDefinition) • relational operators: eq, neq, gt, lt, geq, leq • arithmetic operators: plus, minus, times, divide, power, root, abs, exp, ln, log, floor, ceiling, factorial, quotient, max, min, rem • logical operators: and, or, xor, not, implies • qualifiers: degree, bvar, logbase • trigonometric operators: sin, cos, tan,  sec, csc, cot, sinh, cosh, tanh, sech, csch, coth, arcsin, arccos, arctan, arcsec, arccsc, arccot, arcsinh, arccosh, arctanh, arcsech, arccsch, arccoth  • constants: true, false, notanumber, pi, infinity, exponentiale • MathML annotations: semantics, annotation, annotation-xml The inclusion of logical operators, relational operators, piecewise, piece, and otherwise elements facilitates the encoding of discontinuous expressions.
(Being "dimensionless" is not the same as having undeclared units!) If SBML defined numbers as being by default dimensionless, it would result in many models being technically incorrect without the modeler being aware of it unless their software tools performed dimensional analysis. Many software tools do not perform unit analysis, and so potential errors due to inconsistent units in a model would not be detected until other researchers and database curators attempted to use the model in software packages that did check units. We believe the negative impact on interoperability would be too high. SBML borrows an idea from CellML  (Hedley et al. , 2001) , another model definition language with goals similar to SBML's, and allows an additional attribute to appear on MathML cn elements; the value of this attribute can be used to indicate the unit of measurement to be associated with the number in the content of the cn element.
Treatment of unspecified units If an expression contains literal numbers and/or SBML components without declared units, the consistency or inconsistency of units may be impossible to determine. In the absence of a verifiable inconsistency, an expression in SBML is accepted as-is; the writer of the model is assumed to have written what they intended. However, this is not equivalent to assuming the expression does have consistent units. The lack of declared units on quantities in an SBML model does not render the model invalid insofar as the SBML specification is concerned, but it reduces the types of consistency checks and useful operations (such as conversions and translations) that software systems can perform. In some cases, it may be possible to determine that expressions containing unspecified units are inconsistent regardless of what units would be attributed to the unspecified quantities.
The Graphical Layout ("layout") package, by contrast, cannot ever change the mathematical interpretation of any model; thus, its required attribute must be set to "false". If a package is declared optional (i. e. , its required flag is set to "false"), it means the time-course dynamics of the model can be correctly inferred even if the elements and attributes added by that particular SBML package are ignored. "Ignoring" a package can be accomplished in multiple ways: a reader could either skip those elements or attributes altogether during parsing, or read them but not interpret them, or do something similar. The following are some ways in which packages with required="true" may change the time-course dynamics of a model: • An element with a (potential) mathematical meaning may be left undefined in the core specification of SBML Level 3, but may have a value defined by a package.
Use of units in a model As already mentioned, unit declarations are optional in SBML. This design decision was a consensus choice among SBML developers and users, driven by the exigencies of non-commercial software development and the realities of models found in existence. It has an important and possibly counterintuitive implication that must be kept in mind when writing and interpreting SBML models: units associated with quantities do not alter the numerical interpretation of those quantities. An example may help make this more clear. We know that one metre equals 1000 millimetres: 1 m = 1000 mm However, the equality above relies on interpreting the units on both sides, and taking the "1" and "1000" to be dimensionless. If readers ignored unit labels altogether or were unable to process them, they would see 1 = 1000 which is obviously incorrect.
An initial assignment cannot be made to reaction identifiers; that is, the symbol attribute value of an InitialAssignment cannot be an identifier that is the id attribute value of a Reaction object in the model. This is identical to a restriction placed on rules (see Section 4. 9. 5 on p. 64). It may also not reference the id of a FunctionDefinition. If the symbol attribute of an InitialAssignment object references an object in an SBML namespace that is not recognized by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the assignment must be ignored-the symbol must not be assigned by the construct if the interpreter cannot understand the package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not recognized by the interpreter, it may produce a warning to the user.
The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute), or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units). If the variable attribute of an AssignmentRule object references an object in an SBML namespace not recognized by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the assignment rule must be ignored-the object's value must not be assigned by the rule if the interpreter cannot understand the package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not recognized by the interpreter, it may produce a warning to the user.
The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute) divided by the model-wide unit of time, or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units) divided by the model-wide unit of time. If the variable attribute of a RateRule object references an object in an SBML namespace that is not recognized by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the rate rule must be ignored-the object's value must not be assigned by the rule if the interpreter cannot understand the package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not recognized by the interpreter, it may produce a warning to the user.
(The latter situation can only arise if an SBML package is present in the SBML document with a package:required attribute of "true". ) In the context of a simulation, rate rules are in effect for simulation time t > 0. Other types of rules and initial assignments are in effect at different times; Section 3. 4. 8 on p. 28 describes these conditions. As mentioned in Section 4. 9. 3 for AssignmentRule, a model must not contain more than one RateRule or AssignmentRule object having the same value of variable; in other words, in the set of all assignment rules and rate rules in an SBML model, each variable appearing in the left-hand sides can only appear once. This simply follows from the fact that an indeterminate system would result if a model contained more than one assignment rule for the same variable or both an assignment rule and a rate rule for the same variable.
The units of measurement associated with the identifier are described in Section 4. 11. 6. A LocalParameter must not have the same id value as a Species referenced by any of the parent Reaction's SpeciesReference objects. (If this were permitted, the local scoping would mean that the SpeciesReference would refer to a LocalParameter, which is not a Species-which would create an inconsistency. ) The effective scope of where a LocalParameter id can be used in SBML Level 3 Core is restricted to the math of the KineticLaw, since no other construct within a Reaction can reference an SId. However, SBML Level 3 packages may introduce new ways of referencing SId values within a Reaction that could also refer to LocalParameter objects. Packages could therefore introduce cases where a KineticLaw can exist without a math element but with a new package construct that (for example) uses a ListOfLocalParameters to provide the package construct with locally-scoped parameters to reference.
• A variable cannot be assigned a value in an EventAssignment object instance and also be assigned a value by an AssignmentRule, i. e. , the value of the variable attribute in an EventAssignment instance cannot be the same as the value of a variable attribute in an AssignmentRule instance. (Assignment rules hold at all times, therefore it would be inconsistent to also define an event that reassigns the value of the same variable. ) If the variable attribute of an EventAssignment object references an object in an SBML namespace that is not recognized by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the event assignment must be ignored-the object's value must not be assigned if the interpreter cannot understand the package.
If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not recognized by the interpreter, it may produce a warning to the user. (The latter situation can only arise if an SBML package is present in the SBML document with a package:required attribute of "true". ) Note that the time of assignment of the object identified by the value of variable is always the time at which the Event is executed, not when it is triggered. The timing is controlled by the optional Delay. The time of assignment is not affected by the Event attribute useValuesFromTriggerTime-that attribute affects the time at which the EventAssignment's math expression is evaluated. In other words, SBML allows decoupling the time at which the variable is assigned from the time at which its value expression is calculated.
Although the use of SBO can be beneficial, it is critical to keep in mind that the presence of an sboTerm value on an object must not change the fundamental mathematical meaning of the model. An SBML model must be defined such that it stands on its own and does not depend on additional information added by SBO terms for a correct mathematical interpretation. SBO term definitions will not imply any alternative mathematical semantics for any SBML object labeled with that term. Two important reasons motivate this principle. First, it would be too limiting to require all software tools to be able to understand the SBO vocabularies in addition to understanding SBML. Supporting SBO is not only additional work for the software developer; for some kinds of applications, it may not make sense. If SBO terms on a model are optional, it follows that the SBML model must remain unambiguous and fully interpretable without them, because an application reading the model may ignore the terms.
Relationships to the SBML annotation element Another way to provide this information would be to place SBO terms inside the SBase annotation element (Section 3. 2 on p. 14 and Section 6 on p. 100). However, in the interest of making the use of SBO in SBML as interoperable as possible between software tools, the best-practice recommendation is to place SBO references in the sboTerm attribute rather than inside the annotation element of an object. If instead the approach of using annotation is taken, the qualifiers (Section 6. 5 on p. 103) linking the SBML element and SBO term should be chosen extremely carefully, since it will no longer be possible to assume an "instance to class" relationship. Although sboTerm is just another kind of optional annotation in SBML, SBO references are separated into their own attribute on SBML components, both to simplify their use for software tools and because doing so asserts a stronger and more focused connection in a more regimented fashion.
A standard format for the annotation element This section describes the recommended non-proprietary format for the content of Annotation objects in SBML when (a) referring to controlled vocabulary terms and database identifiers that define and describe biological and biochemical entities, and (b) describing the creator of a model and its modification history. Such a structured format should facilitate the generation of models compliant with the MIRIAM guidelines for model curation  (Le Novère et al. , 2005). The format described in this section is intended to be the form of one of the top-level elements that could reside in an Annotation object attached to an SBML object derived from SBase. The element is named rdf:RDF. The format described here is compliant with the constraints placed on the form of annotation elements described in Section 3.
Use of URIs The SBML MIRIAM annotation format allows the expression of relationships between SBML elements on the one hand, and resources referred to by values of rdf:resource attributes on the other. The BioModels. net relation elements (see Section 6. 5 on the following page) simply define the nature of the relationship. The value of a rdf:resource attribute is a URI that uniquely identifies both the resource and the data within the resource. Since a URI is not a URL, it does not have to map to a physical Web object; it simply needs to identify, uniquely, a controlled vocabulary term or database object. It is essentially just a label. For instance, an actual URL for an Internet resource might be https://www. uniprot. org/uniprot/P12999, and this might correspond to the URI https://identifiers.
org/uniprot/P12999  (Juty et al. , 2012). It is important that the portion of a rdf:resource value that identifies a data entry is always a perennial identifier. For example, a Species object representing a protein could be annotated with a reference to the database UniProt by the resource identifier https://identifiers. org/uniprot/P12999, thereby identifying exactly the intended protein. This identifier maps to a unique entry in UniProt which is never deleted from the database. In the case of UniProt, this is known as the "accession" portion of the entry. When the entry is merged with another one, both "accession" entries are conserved. A UniProt entry also possesses an "entry name" (the Swiss-Prot "identifier"), a "protein name", "synonyms", and other parts, but only the "accession" is perennial, and that is what should be used.
These URIs are not part of the SBML standard per se, and will grow independently from specific SBML levels and versions. As the set changes, existing URIs will not be modified, although the physical resources associated with each one may change (for example, to use updated URLs). The form of the URIs will always have the form resource:identifier. An up-to-date list and explanations of the URIs are available online at the address https://www. ebi. ac. uk/miriam/main/collections. Each entry lists the database in question, the URI to be used to reference that database, and example URIs for referencing particular entries in those databases. The URI rule list will evolve with the evolution of databases and resources. Note this means that all rdf:resource must be MIRIAM URIs and thus cannot refer to, for example, other elements in the model.
bqbiol:is The biological entity represented by the SBML component is the subject of the referenced resource. This could serve to link a reaction to its counterpart in (e. g. ) the ChEBI or Reactome databases. bqbiol:isDescribedBy The biological entity represented by the SBML component is described by the referenced resource. This relation could be used, for example, to link a species or a parameter to a publication describing the quantity of the species or the value of the parameter.
Recalling the values of the parameters k on , k off , and k cat , k on = 1 000 000 litre mole -1 second -1 k off = 0. 2 second -1 k cat = 0. 1 second -1 it becomes clear that, with the values of E, S and ES all in millimoles, Equations 5 and 6 no longer lead to units of mole/second for the reaction rates. To compensate, we change the values of the constants k on , k off , and k cat using the following simple transformations: k * on = k on • 1 mole 1000 millimoles 2 = 1 litre mole millimole -2 second -1 k * off = k off • 1 mole 1000 millimoles = 0. 0002 mole millimole -1 second -1 k * cat = k cat • 1 mole 1000 millimoles = 0. 0001 mole millimole -1 second -1 The "mole/millimole" portion of the units are admittedly unconventional for mass-action kinetic rate constants. They are unlikely to correspond to values found in textbooks or databases.
An additional point is worth noting in passing. Although the value attributes of various SBML components are of type double (e. g. , Parameter's attribute value), this does not mean that component values are limited only to decimal numbers. As noted above, other constructs such as InitialAssignment can be used to set the value of an object, and since those constructs offer the power of MathML, the results may be rational numbers such as fractions. Software developers should be aware of this possibility when planning the type of storage variables used to hold SBML objects' values.
Appropriate uses of annotations In the description of the Annotation object available on every component derived from SBase (Section 3. 2. 6 on p. 16), we already made the point that it is critical not to put data essential to understanding a model into annotations. This raises a question: what kind of data may be appropriately put into annotations? Here are some examples: • Identification information for cross-referencing components in a model with items in a data resource such as a database. This is the purpose of the annotation scheme described in Section 6 on p. 100. • Application-specific processing instructions that do not change the essential meaning of a model, but help a particular application with tasks such as managing the model, maintaining state data across editing sessions, etc.
Syntax of annotations The annotation scheme described in Section 6 on p. 100 is useful for many, but not all, situations. It is tempting to develop new annotation syntaxes for situations that fall outside the scope of the SBML MIRIAM annotation scheme. However, a proliferation of proprietary annotation schemes will hinder software interoperability in the long run. <listOfUnitDefinitions> <unitDefinition id="degree_Fahrenheit"> <notes><p xmlns="http://www. w3. org/1999/xhtml"> This captures the notion that the size of a degree in Fahrenheit is 5/9 the size of a degree on the kelvin scale. </notes> <listOfUnits> <unit kind="kelvin" multiplier="5" scale="0" exponent="1"/> <unit kind="dimensionless" multiplier="9" scale="0" exponent="-1"/> </.
General rules concerning basic XML requirements 10101. An SBML XML file must use UTF-8 as the character encoding. More precisely, the encoding attribute of the XML declaration at the beginning of the XML data stream cannot have a value other than "UTF-8". An example valid declaration is <?xml version="1. 0" encoding="UTF-8"?>. (References: SBML L3V1 Section 4. 1; SBML L3V2 Section 4. 1. ) 10102. An SBML XML document must not contain undefined elements or attributes in the SBML Level 3 Core namespace or in a SBML Level 3 package namespace. Documents containing unknown elements or attributes placed in an SBML namespace do not conform to the SBML specification. 4. 7. 3, 4. 2. 4, and 4. 9. 4; SBML L3V2 Section 4. 7. 3, Section 4. 2. 3, and Section 4. 9. 4. )  10534. L When the value of the attribute variable in a RateRule object refers to a SpeciesReference object, the unit of measurement associated with the RateRule's math expression should be consistent with {unit derived from dimensionless}/{unit of time}.
Acknowledgments The development of SBML was originally funded by the  Japan Science and Technology Agency (JST)  under the  ERATO Kitano Symbiotic Systems  Project during the years  2000-2003. From 2003  to the present, funding for development of SBML and associated software such as libSBML and the  SBML Test Suite  has been provided chiefly by the  National Institute of General Medical Sciences (USA)  via grant numbers  GM070923  and  GM077671. Additional grant funding has in the past been provided by  National Human Genome Research Institute (USA) ; the  International Joint Research Program of NEDO (Japan) ; the  JST ERATO-SORST Program (Japan) ; the  Japanese Ministry of Agriculture ; the  Japanese Ministry of Education, Culture, Sports, Science and Technology ; the  BBSRC e-Science Initiative (UK) ; the  DARPA IPTO Bio-Computation Program (USA) ; the  Army Research Office's Institute for Collaborative Biotechnologies (USA) ; and the  Air Force Office of Scientific Research (USA).