public class GeneProduct extends SBase
Association of a gene product with a Reaction
In the SBML Level 3 Flux Balance Constraints (“fbc”) package
representation format, a GeneProduct object represents a single gene or
implied gene product. The gene or gene product is identified using the
required attribute 'label', which is a text string. (This attribute is
separate from the usual SBML 'id' attribute, which is used to
cross-reference entities within an SBML model.) A GeneProduct object can
also possess an optional 'associatedSpecies' attribute; if this a
attribute is defined, it should have a value of type SIdRef
and be the identifier of a Species object defined in the enclosing Model.
An 'associatedSpecies', if it exists, is interpreted to be a species
associated with the gene or gene product that is represented by the
GeneProduct object.
Association and
GeneAssociation annotation classes. Please see the Version 1 and
Version 2 “fbc” specifications for more details.| Constructor and Description |
|---|
GeneProduct()
Creates a new
GeneProduct with the given SBML Level, Version, and
“fbc”package version. |
GeneProduct(FbcPkgNamespaces fbcns)
Creates a new
GeneProduct with the given FbcPkgNamespaces object. |
GeneProduct(GeneProduct orig)
Copy constructor for
GeneProduct. |
GeneProduct(long level)
Creates a new
GeneProduct with the given SBML Level, Version, and
“fbc”package version. |
GeneProduct(long level,
long version)
Creates a new
GeneProduct with the given SBML Level, Version, and
“fbc”package version. |
GeneProduct(long level,
long version,
long pkgVersion)
Creates a new
GeneProduct with the given SBML Level, Version, and
“fbc”package version. |
| Modifier and Type | Method and Description |
|---|---|
GeneProduct |
cloneObject()
Creates and returns a deep copy of this
GeneProduct object. |
void |
delete()
Explicitly deletes the underlying native object.
|
java.lang.String |
getAssociatedSpecies()
Returns the value of the 'associatedSpecies' attribute of this
GeneProduct. |
java.lang.String |
getElementName()
Returns the XML element name of this object.
|
java.lang.String |
getId()
Returns the value of the 'id' attribute of this
GeneProduct. |
java.lang.String |
getLabel()
Returns the value of the 'label' attribute of this
GeneProduct. |
java.lang.String |
getName()
Returns the value of the 'name' attribute of this
GeneProduct object. |
int |
getTypeCode()
Returns the libSBML type code for this SBML object.
|
boolean |
hasRequiredAttributes()
Predicate returning
true if all the required attributes
for this GeneProduct object have been set. |
boolean |
isSetAssociatedSpecies()
Predicate returning
true if this GeneProduct's 'associatedSpecies'
attribute is set. |
boolean |
isSetId()
Predicate returning
true if this GeneProduct's 'id' attribute is set. |
boolean |
isSetLabel()
Predicate returning
true if this GeneProduct's 'label' attribute is
set. |
boolean |
isSetName()
Predicate returning
true if this GeneProduct's 'name' attribute is
set. |
void |
renameSIdRefs(java.lang.String oldid,
java.lang.String newid)
Replaces all uses of a given
SIdRef type attribute value with another
value. |
int |
setAssociatedSpecies(java.lang.String associatedSpecies)
Sets the value of the 'associatedSpecies' attribute of this
GeneProduct. |
int |
setId(java.lang.String sid)
Sets the value of the 'id' attribute of this
GeneProduct. |
int |
setLabel(java.lang.String label)
Sets the value of the 'label' attribute of this
GeneProduct. |
int |
setName(java.lang.String name)
Sets the value of the 'name' attribute of this
GeneProduct. |
int |
unsetAssociatedSpecies()
Unsets the value of the 'associatedSpecies' attribute of this
GeneProduct. |
int |
unsetId()
Unsets the value of the 'id' attribute of this
GeneProduct. |
int |
unsetLabel()
Unsets the value of the 'label' attribute of this
GeneProduct. |
int |
unsetName()
Unsets the value of the 'name' attribute of this
GeneProduct. |
addCVTerm, addCVTerm, appendAnnotation, appendAnnotation, appendNotes, appendNotes, connectToChild, deleteDisabledPlugins, deleteDisabledPlugins, disablePackage, enablePackage, equals, getAncestorOfType, getAncestorOfType, getAnnotation, getAnnotationString, getColumn, getCVTerm, getCVTerms, getDisabledPlugin, getElementByMetaId, getElementBySId, getIdAttribute, getLevel, getLine, getListOfAllElements, getListOfAllElements, getListOfAllElementsFromPlugins, getListOfAllElementsFromPlugins, getMetaId, getModel, getModelHistory, getNamespaces, getNotes, getNotesString, getNumCVTerms, getNumDisabledPlugins, getNumPlugins, getPackageCoreVersion, getPackageName, getPackageVersion, getParentSBMLObject, getPlugin, getPlugin, getPrefix, getResourceBiologicalQualifier, getResourceModelQualifier, getSBMLDocument, getSBOTerm, getSBOTermAsURL, getSBOTermID, getURI, getVersion, hashCode, hasValidLevelVersionNamespaceCombination, isPackageEnabled, isPackageURIEnabled, isPkgEnabled, isPkgURIEnabled, isSetAnnotation, isSetIdAttribute, isSetMetaId, isSetModelHistory, isSetNotes, isSetSBOTerm, isSetUserData, matchesRequiredSBMLNamespacesForAddition, matchesSBMLNamespaces, removeFromParentAndDelete, removeTopLevelAnnotationElement, removeTopLevelAnnotationElement, removeTopLevelAnnotationElement, renameMetaIdRefs, renameUnitSIdRefs, replaceTopLevelAnnotationElement, replaceTopLevelAnnotationElement, setAnnotation, setAnnotation, setIdAttribute, setMetaId, setModelHistory, setNamespaces, setNotes, setNotes, setNotes, setSBOTerm, setSBOTerm, toSBML, toXMLNode, unsetAnnotation, unsetCVTerms, unsetIdAttribute, unsetMetaId, unsetModelHistory, unsetNotes, unsetSBOTerm, unsetUserDatapublic GeneProduct(long level, long version, long pkgVersion) throws SBMLConstructorException
GeneProduct with the given SBML Level, Version, and
“fbc”package version.
level - a long integer, the SBML Level to assign to this GeneProduct.
version - a long integer, the SBML Version to assign to this GeneProduct.
pkgVersion - a long integer, the SBML Fbc Version to assign to this GeneProduct.
SBMLConstructorExceptionSBMLDocument having a different
combination of SBML Level, Version and XML namespaces than the object
itself will result in an error at the time a caller attempts to make the
addition. A parent object must have compatible Level, Version and XML
namespaces. (Strictly speaking, a parent may also have more XML
namespaces than a child, but the reverse is not permitted.) The
restriction is necessary to ensure that an SBML model has a consistent
overall structure. This requires callers to manage their objects
carefully, but the benefit is increased flexibility in how models can be
created by permitting callers to create objects bottom-up if desired. In
situations where objects are not yet attached to parents (e.g.,
SBMLDocument), knowledge of the intented SBML Level and Version help
libSBML determine such things as whether it is valid to assign a
particular value to an attribute. For packages, this means that the
parent object to which this package element is being added must have
been created with the package namespace, or that the package namespace
was added to it, even if that parent is not a package object itself.public GeneProduct(long level, long version) throws SBMLConstructorException
GeneProduct with the given SBML Level, Version, and
“fbc”package version.
level - a long integer, the SBML Level to assign to this GeneProduct.
version - a long integer, the SBML Version to assign to this GeneProduct.
pkgVersion - a long integer, the SBML Fbc Version to assign to this GeneProduct.
SBMLConstructorExceptionSBMLDocument having a different
combination of SBML Level, Version and XML namespaces than the object
itself will result in an error at the time a caller attempts to make the
addition. A parent object must have compatible Level, Version and XML
namespaces. (Strictly speaking, a parent may also have more XML
namespaces than a child, but the reverse is not permitted.) The
restriction is necessary to ensure that an SBML model has a consistent
overall structure. This requires callers to manage their objects
carefully, but the benefit is increased flexibility in how models can be
created by permitting callers to create objects bottom-up if desired. In
situations where objects are not yet attached to parents (e.g.,
SBMLDocument), knowledge of the intented SBML Level and Version help
libSBML determine such things as whether it is valid to assign a
particular value to an attribute. For packages, this means that the
parent object to which this package element is being added must have
been created with the package namespace, or that the package namespace
was added to it, even if that parent is not a package object itself.public GeneProduct(long level) throws SBMLConstructorException
GeneProduct with the given SBML Level, Version, and
“fbc”package version.
level - a long integer, the SBML Level to assign to this GeneProduct.
version - a long integer, the SBML Version to assign to this GeneProduct.
pkgVersion - a long integer, the SBML Fbc Version to assign to this GeneProduct.
SBMLConstructorExceptionSBMLDocument having a different
combination of SBML Level, Version and XML namespaces than the object
itself will result in an error at the time a caller attempts to make the
addition. A parent object must have compatible Level, Version and XML
namespaces. (Strictly speaking, a parent may also have more XML
namespaces than a child, but the reverse is not permitted.) The
restriction is necessary to ensure that an SBML model has a consistent
overall structure. This requires callers to manage their objects
carefully, but the benefit is increased flexibility in how models can be
created by permitting callers to create objects bottom-up if desired. In
situations where objects are not yet attached to parents (e.g.,
SBMLDocument), knowledge of the intented SBML Level and Version help
libSBML determine such things as whether it is valid to assign a
particular value to an attribute. For packages, this means that the
parent object to which this package element is being added must have
been created with the package namespace, or that the package namespace
was added to it, even if that parent is not a package object itself.public GeneProduct() throws SBMLConstructorException
GeneProduct with the given SBML Level, Version, and
“fbc”package version.
level - a long integer, the SBML Level to assign to this GeneProduct.
version - a long integer, the SBML Version to assign to this GeneProduct.
pkgVersion - a long integer, the SBML Fbc Version to assign to this GeneProduct.
SBMLConstructorExceptionSBMLDocument having a different
combination of SBML Level, Version and XML namespaces than the object
itself will result in an error at the time a caller attempts to make the
addition. A parent object must have compatible Level, Version and XML
namespaces. (Strictly speaking, a parent may also have more XML
namespaces than a child, but the reverse is not permitted.) The
restriction is necessary to ensure that an SBML model has a consistent
overall structure. This requires callers to manage their objects
carefully, but the benefit is increased flexibility in how models can be
created by permitting callers to create objects bottom-up if desired. In
situations where objects are not yet attached to parents (e.g.,
SBMLDocument), knowledge of the intented SBML Level and Version help
libSBML determine such things as whether it is valid to assign a
particular value to an attribute. For packages, this means that the
parent object to which this package element is being added must have
been created with the package namespace, or that the package namespace
was added to it, even if that parent is not a package object itself.public GeneProduct(FbcPkgNamespaces fbcns) throws SBMLConstructorException
GeneProduct with the given FbcPkgNamespaces object.
The package namespaces object used in this constructor is derived from a
SBMLNamespaces object, which encapsulates SBML Level/Version/namespaces
information. It is used to communicate the SBML Level, Version, and
package version and name information used in addition to SBML Level 3 Core. A
common approach to using libSBML's SBMLNamespaces facilities is to create an
package namespace object somewhere in a program once, then hand that object
as needed to object constructors of that package that accept it as and
argument, such as this one.
fbcns - the FbcPkgNamespaces object.
SBMLConstructorExceptionSBMLDocument having a different
combination of SBML Level, Version and XML namespaces than the object
itself will result in an error at the time a caller attempts to make the
addition. A parent object must have compatible Level, Version and XML
namespaces. (Strictly speaking, a parent may also have more XML
namespaces than a child, but the reverse is not permitted.) The
restriction is necessary to ensure that an SBML model has a consistent
overall structure. This requires callers to manage their objects
carefully, but the benefit is increased flexibility in how models can be
created by permitting callers to create objects bottom-up if desired. In
situations where objects are not yet attached to parents (e.g.,
SBMLDocument), knowledge of the intented SBML Level and Version help
libSBML determine such things as whether it is valid to assign a
particular value to an attribute. For packages, this means that the
parent object to which this package element is being added must have
been created with the package namespace, or that the package namespace
was added to it, even if that parent is not a package object itself.public GeneProduct(GeneProduct orig) throws SBMLConstructorException
GeneProduct.
orig - the GeneProduct instance to copy.SBMLConstructorExceptionpublic void delete()
In general, application software will not need to call this method directly. The Java language binding for libSBML is implemented as a language wrapper that provides a Java interface to libSBML's underlying C++/C code. Some of the Java methods return objects that are linked to objects created not by Java code, but by C++ code. The Java objects wrapped around them will be deleted when the garbage collector invokes the corresponding C++ finalize() methods for the objects. The finalize() methods in turn call the GeneProduct.delete() method on the libSBML object.
This method is exposed in case calling programs want to ensure that the underlying object is freed immediately, and not at some arbitrary time determined by the Java garbage collector. In normal usage, callers do not need to invoke GeneProduct.delete() themselves.
public GeneProduct cloneObject()
GeneProduct object.
cloneObject in class SBaseGeneProduct object.public java.lang.String getId()
GeneProduct.
getId in class SBaseGeneProduct.
SBase.getIdAttribute(),
SBase.setIdAttribute(String sid),
SBase.isSetIdAttribute(),
SBase.unsetIdAttribute()
The identifier given by an object's 'id' attribute value
is used to identify the object within the SBML model definition.
Other objects can refer to the component using this identifier. The
data type of 'id' is always SId or a type derived
from that, such as UnitSId, depending on the object in
question. All data types are defined as follows:
letter .= 'a'..'z','A'..'Z' digit .= '0'..'9' idChar .= letter | digit | '_' SId .= ( letter | '_' ) idChar*The characters
( and ) are used for grouping,
the character * 'zero or more times', and the character
| indicates logical 'or'. The equality of SBML identifiers
is determined by an exact character sequence match; i.e., comparisons must
be performed in a case-sensitive manner. This applies to all uses of
SId, SIdRef, and derived types.
Users need to be aware of some important API issues that are the result of
the history of SBML and libSBML. Prior to SBML Level 3
Version 2, SBML defined 'id' and 'name' attributes on only a subset
of SBML objects. To simplify the work of programmers, libSBML's API
provided get, set, check, and unset on the SBase object class itself
instead of on individual subobject classes. This made the
get/set/etc. methods uniformly available on all objects in the libSBML
API. LibSBML simply returned empty strings or otherwise did not act when
the methods were applied to SBML objects that were not defined by the SBML
specification to have 'id' or 'name' attributes. Additional complications
arose with the rule and assignment objects: InitialAssignment,
EventAssignment, AssignmentRule, and RateRule. In early versions of SBML,
the rule object hierarchy was different, and in addition, then as now,
they possess different attributes: 'variable' (for the rules and event
assignments), 'symbol' (for initial assignments), or neither (for
algebraic rules). Prior to SBML Level 3 Version 2, getId()
would always return an empty string, and isSetId() would always return
false for objects of these classes.
With the addition of 'id' and 'name' attributes on SBase in Level 3
Version 2, it became necessary to introduce a new way to interact
with the attributes more consistently in libSBML to avoid breaking
backward compatibility in the behavior of the original 'id' methods. For
this reason, libSBML provides four functions (getIdAttribute(),
setIdAttribute(String), isSetIdAttribute(), and
unsetIdAttribute()) that always act on the actual 'id' attribute inherited
from SBase, regardless of the object's type. These new methods
should be used instead of the older getId()/setId()/etc. methods
unless the old behavior is somehow necessary. Regardless of the Level and
Version of the SBML, these functions allow client applications to use more
generalized code in some situations (for instance, when manipulating
objects that are all known to have identifiers). If the object in
question does not posess an 'id' attribute according to the SBML
specification for the Level and Version in use, libSBML will not allow the
identifier to be set, nor will it read or write 'id' attributes for those
objects.
public java.lang.String getName()
GeneProduct object.
In SBML Level 3 Version 2, the 'id' and 'name' attributes were
moved to SBase directly, instead of being defined individually for many
(but not all) objects. LibSBML has for a long time provided functions
defined on SBase itself to get, set, and unset those attributes, which
would fail or otherwise return empty strings if executed on any object
for which those attributes were not defined. Now that all SBase objects
define those attributes, those functions now succeed for any object with
the appropriate level and version.
The 'name' attribute is
optional and is not intended to be used for cross-referencing purposes
within a model. Its purpose instead is to provide a human-readable
label for the component. The data type of 'name' is the type
string defined in XML Schema. SBML imposes no
restrictions as to the content of 'name' attributes beyond those
restrictions defined by the string type in XML Schema.
The recommended practice for handling 'name' is as follows. If a software tool has the capability for displaying the content of 'name' attributes, it should display this content to the user as a component's label instead of the component's 'id'. If the user interface does not have this capability (e.g., because it cannot display or use special characters in symbol names), or if the 'name' attribute is missing on a given component, then the user interface should display the value of the 'id' attribute instead. (Script language interpreters are especially likely to display 'id' instead of 'name'.)
As a consequence of the above, authors of systems that automatically generate the values of 'id' attributes should be aware some systems may display the 'id''s to the user. Authors therefore may wish to take some care to have their software create 'id' values that are: (a) reasonably easy for humans to type and read; and (b) likely to be meaningful, for example by making the 'id' attribute be an abbreviated form of the name attribute value.
An additional point worth mentioning is although there are restrictions on the uniqueness of 'id' values, there are no restrictions on the uniqueness of 'name' values in a model. This allows software applications leeway in assigning component identifiers.
Regardless of the level and version of the SBML, these functions allow client applications to use more generalized code in some situations (for instance, when manipulating objects that are all known to have names). If the object in question does not posess a 'name' attribute according to the SBML specification for the Level and Version in use, libSBML will not allow the name to be set, nor will it read or write 'name' attributes for those objects.
getName in class SBaseSBase.getIdAttribute(),
GeneProduct.isSetName(),
GeneProduct.setName(String sid),
GeneProduct.unsetName()public java.lang.String getLabel()
GeneProduct.
GeneProduct as a
string.public java.lang.String getAssociatedSpecies()
GeneProduct.
GeneProduct as a string.public boolean isSetId()
true if this GeneProduct's 'id' attribute is set.
The identifier given by an object's 'id' attribute value
is used to identify the object within the SBML model definition.
Other objects can refer to the component using this identifier. The
data type of 'id' is always SId or a type derived
from that, such as UnitSId, depending on the object in
question. All data types are defined as follows:
letter .= 'a'..'z','A'..'Z' digit .= '0'..'9' idChar .= letter | digit | '_' SId .= ( letter | '_' ) idChar*The characters
( and ) are used for grouping,
the character * 'zero or more times', and the character
| indicates logical 'or'. The equality of SBML identifiers
is determined by an exact character sequence match; i.e., comparisons must
be performed in a case-sensitive manner. This applies to all uses of
SId, SIdRef, and derived types.
Users need to be aware of some important API issues that are the result of
the history of SBML and libSBML. Prior to SBML Level 3
Version 2, SBML defined 'id' and 'name' attributes on only a subset
of SBML objects. To simplify the work of programmers, libSBML's API
provided get, set, check, and unset on the SBase object class itself
instead of on individual subobject classes. This made the
get/set/etc. methods uniformly available on all objects in the libSBML
API. LibSBML simply returned empty strings or otherwise did not act when
the methods were applied to SBML objects that were not defined by the SBML
specification to have 'id' or 'name' attributes. Additional complications
arose with the rule and assignment objects: InitialAssignment,
EventAssignment, AssignmentRule, and RateRule. In early versions of SBML,
the rule object hierarchy was different, and in addition, then as now,
they possess different attributes: 'variable' (for the rules and event
assignments), 'symbol' (for initial assignments), or neither (for
algebraic rules). Prior to SBML Level 3 Version 2, getId()
would always return an empty string, and isSetId() would always return
false for objects of these classes.
With the addition of 'id' and 'name' attributes on SBase in Level 3
Version 2, it became necessary to introduce a new way to interact
with the attributes more consistently in libSBML to avoid breaking
backward compatibility in the behavior of the original 'id' methods. For
this reason, libSBML provides four functions (getIdAttribute(),
setIdAttribute(String), isSetIdAttribute(), and
unsetIdAttribute()) that always act on the actual 'id' attribute inherited
from SBase, regardless of the object's type. These new methods
should be used instead of the older getId()/setId()/etc. methods
unless the old behavior is somehow necessary. Regardless of the Level and
Version of the SBML, these functions allow client applications to use more
generalized code in some situations (for instance, when manipulating
objects that are all known to have identifiers). If the object in
question does not posess an 'id' attribute according to the SBML
specification for the Level and Version in use, libSBML will not allow the
identifier to be set, nor will it read or write 'id' attributes for those
objects.
isSetId in class SBasetrue if the 'id' attribute of this SBML object is
set, false otherwise.
SBase.getIdAttribute(),
SBase.setIdAttribute(String sid),
SBase.unsetIdAttribute(),
SBase.isSetIdAttribute()public boolean isSetName()
true if this GeneProduct's 'name' attribute is
set.
In SBML Level 3 Version 2, the 'id' and 'name' attributes were
moved to SBase directly, instead of being defined individually for many
(but not all) objects. LibSBML has for a long time provided functions
defined on SBase itself to get, set, and unset those attributes, which
would fail or otherwise return empty strings if executed on any object
for which those attributes were not defined. Now that all SBase objects
define those attributes, those functions now succeed for any object with
the appropriate level and version.
The 'name' attribute is
optional and is not intended to be used for cross-referencing purposes
within a model. Its purpose instead is to provide a human-readable
label for the component. The data type of 'name' is the type
string defined in XML Schema. SBML imposes no
restrictions as to the content of 'name' attributes beyond those
restrictions defined by the string type in XML Schema.
The recommended practice for handling 'name' is as follows. If a software tool has the capability for displaying the content of 'name' attributes, it should display this content to the user as a component's label instead of the component's 'id'. If the user interface does not have this capability (e.g., because it cannot display or use special characters in symbol names), or if the 'name' attribute is missing on a given component, then the user interface should display the value of the 'id' attribute instead. (Script language interpreters are especially likely to display 'id' instead of 'name'.)
As a consequence of the above, authors of systems that automatically generate the values of 'id' attributes should be aware some systems may display the 'id''s to the user. Authors therefore may wish to take some care to have their software create 'id' values that are: (a) reasonably easy for humans to type and read; and (b) likely to be meaningful, for example by making the 'id' attribute be an abbreviated form of the name attribute value.
An additional point worth mentioning is although there are restrictions on the uniqueness of 'id' values, there are no restrictions on the uniqueness of 'name' values in a model. This allows software applications leeway in assigning component identifiers.
Regardless of the level and version of the SBML, these functions allow client applications to use more generalized code in some situations (for instance, when manipulating objects that are all known to have names). If the object in question does not posess a 'name' attribute according to the SBML specification for the Level and Version in use, libSBML will not allow the name to be set, nor will it read or write 'name' attributes for those objects.
isSetName in class SBasetrue if the 'name' attribute of this SBML object is
set, false otherwise.
GeneProduct.getName(),
GeneProduct.setName(String sid),
GeneProduct.unsetName()public boolean isSetLabel()
true if this GeneProduct's 'label' attribute is
set.
true if this GeneProduct's 'label' attribute has been set,
otherwise false is returned.public boolean isSetAssociatedSpecies()
true if this GeneProduct's 'associatedSpecies'
attribute is set.
true if this GeneProduct's 'associatedSpecies' attribute has
been set, otherwise false is returned.public int setId(java.lang.String sid)
GeneProduct.
The string sid is copied.
The identifier given by an object's 'id' attribute value
is used to identify the object within the SBML model definition.
Other objects can refer to the component using this identifier. The
data type of 'id' is always SId or a type derived
from that, such as UnitSId, depending on the object in
question. All data types are defined as follows:
letter .= 'a'..'z','A'..'Z' digit .= '0'..'9' idChar .= letter | digit | '_' SId .= ( letter | '_' ) idChar*The characters
( and ) are used for grouping,
the character * 'zero or more times', and the character
| indicates logical 'or'. The equality of SBML identifiers
is determined by an exact character sequence match; i.e., comparisons must
be performed in a case-sensitive manner. This applies to all uses of
SId, SIdRef, and derived types.
Users need to be aware of some important API issues that are the result of
the history of SBML and libSBML. Prior to SBML Level 3
Version 2, SBML defined 'id' and 'name' attributes on only a subset
of SBML objects. To simplify the work of programmers, libSBML's API
provided get, set, check, and unset on the SBase object class itself
instead of on individual subobject classes. This made the
get/set/etc. methods uniformly available on all objects in the libSBML
API. LibSBML simply returned empty strings or otherwise did not act when
the methods were applied to SBML objects that were not defined by the SBML
specification to have 'id' or 'name' attributes. Additional complications
arose with the rule and assignment objects: InitialAssignment,
EventAssignment, AssignmentRule, and RateRule. In early versions of SBML,
the rule object hierarchy was different, and in addition, then as now,
they possess different attributes: 'variable' (for the rules and event
assignments), 'symbol' (for initial assignments), or neither (for
algebraic rules). Prior to SBML Level 3 Version 2, getId()
would always return an empty string, and isSetId() would always return
false for objects of these classes.
With the addition of 'id' and 'name' attributes on SBase in Level 3
Version 2, it became necessary to introduce a new way to interact
with the attributes more consistently in libSBML to avoid breaking
backward compatibility in the behavior of the original 'id' methods. For
this reason, libSBML provides four functions (getIdAttribute(),
setIdAttribute(String), isSetIdAttribute(), and
unsetIdAttribute()) that always act on the actual 'id' attribute inherited
from SBase, regardless of the object's type. These new methods
should be used instead of the older getId()/setId()/etc. methods
unless the old behavior is somehow necessary. Regardless of the Level and
Version of the SBML, these functions allow client applications to use more
generalized code in some situations (for instance, when manipulating
objects that are all known to have identifiers). If the object in
question does not posess an 'id' attribute according to the SBML
specification for the Level and Version in use, libSBML will not allow the
identifier to be set, nor will it read or write 'id' attributes for those
objects.
setId in class SBasesid - the string to use as the identifier of this object.
SBase.getIdAttribute(),
SBase.setIdAttribute(String sid),
SBase.isSetIdAttribute(),
SBase.unsetIdAttribute()public int setName(java.lang.String name)
public int setLabel(java.lang.String label)
GeneProduct.
label - the value of the 'label' attribute to be
set.
public int setAssociatedSpecies(java.lang.String associatedSpecies)
GeneProduct.
associatedSpecies - the value of the
'associatedSpecies' attribute to be set.
public int unsetId()
GeneProduct.
The identifier given by an object's 'id' attribute value
is used to identify the object within the SBML model definition.
Other objects can refer to the component using this identifier. The
data type of 'id' is always SId or a type derived
from that, such as UnitSId, depending on the object in
question. All data types are defined as follows:
letter .= 'a'..'z','A'..'Z' digit .= '0'..'9' idChar .= letter | digit | '_' SId .= ( letter | '_' ) idChar*The characters
( and ) are used for grouping,
the character * 'zero or more times', and the character
| indicates logical 'or'. The equality of SBML identifiers
is determined by an exact character sequence match; i.e., comparisons must
be performed in a case-sensitive manner. This applies to all uses of
SId, SIdRef, and derived types.
Users need to be aware of some important API issues that are the result of
the history of SBML and libSBML. Prior to SBML Level 3
Version 2, SBML defined 'id' and 'name' attributes on only a subset
of SBML objects. To simplify the work of programmers, libSBML's API
provided get, set, check, and unset on the SBase object class itself
instead of on individual subobject classes. This made the
get/set/etc. methods uniformly available on all objects in the libSBML
API. LibSBML simply returned empty strings or otherwise did not act when
the methods were applied to SBML objects that were not defined by the SBML
specification to have 'id' or 'name' attributes. Additional complications
arose with the rule and assignment objects: InitialAssignment,
EventAssignment, AssignmentRule, and RateRule. In early versions of SBML,
the rule object hierarchy was different, and in addition, then as now,
they possess different attributes: 'variable' (for the rules and event
assignments), 'symbol' (for initial assignments), or neither (for
algebraic rules). Prior to SBML Level 3 Version 2, getId()
would always return an empty string, and isSetId() would always return
false for objects of these classes.
With the addition of 'id' and 'name' attributes on SBase in Level 3
Version 2, it became necessary to introduce a new way to interact
with the attributes more consistently in libSBML to avoid breaking
backward compatibility in the behavior of the original 'id' methods. For
this reason, libSBML provides four functions (getIdAttribute(),
setIdAttribute(String), isSetIdAttribute(), and
unsetIdAttribute()) that always act on the actual 'id' attribute inherited
from SBase, regardless of the object's type. These new methods
should be used instead of the older getId()/setId()/etc. methods
unless the old behavior is somehow necessary. Regardless of the Level and
Version of the SBML, these functions allow client applications to use more
generalized code in some situations (for instance, when manipulating
objects that are all known to have identifiers). If the object in
question does not posess an 'id' attribute according to the SBML
specification for the Level and Version in use, libSBML will not allow the
identifier to be set, nor will it read or write 'id' attributes for those
objects.
unsetId in class SBaseSBase.getIdAttribute(),
SBase.setIdAttribute(String sid),
SBase.isSetIdAttribute(),
SBase.unsetIdAttribute()public int unsetName()
GeneProduct.
In SBML Level 3 Version 2, the 'id' and 'name' attributes were
moved to SBase directly, instead of being defined individually for many
(but not all) objects. LibSBML has for a long time provided functions
defined on SBase itself to get, set, and unset those attributes, which
would fail or otherwise return empty strings if executed on any object
for which those attributes were not defined. Now that all SBase objects
define those attributes, those functions now succeed for any object with
the appropriate level and version.
The 'name' attribute is
optional and is not intended to be used for cross-referencing purposes
within a model. Its purpose instead is to provide a human-readable
label for the component. The data type of 'name' is the type
string defined in XML Schema. SBML imposes no
restrictions as to the content of 'name' attributes beyond those
restrictions defined by the string type in XML Schema.
The recommended practice for handling 'name' is as follows. If a software tool has the capability for displaying the content of 'name' attributes, it should display this content to the user as a component's label instead of the component's 'id'. If the user interface does not have this capability (e.g., because it cannot display or use special characters in symbol names), or if the 'name' attribute is missing on a given component, then the user interface should display the value of the 'id' attribute instead. (Script language interpreters are especially likely to display 'id' instead of 'name'.)
As a consequence of the above, authors of systems that automatically generate the values of 'id' attributes should be aware some systems may display the 'id''s to the user. Authors therefore may wish to take some care to have their software create 'id' values that are: (a) reasonably easy for humans to type and read; and (b) likely to be meaningful, for example by making the 'id' attribute be an abbreviated form of the name attribute value.
An additional point worth mentioning is although there are restrictions on the uniqueness of 'id' values, there are no restrictions on the uniqueness of 'name' values in a model. This allows software applications leeway in assigning component identifiers.
Regardless of the level and version of the SBML, these functions allow client applications to use more generalized code in some situations (for instance, when manipulating objects that are all known to have names). If the object in question does not posess a 'name' attribute according to the SBML specification for the Level and Version in use, libSBML will not allow the name to be set, nor will it read or write 'name' attributes for those objects.
unsetName in class SBaseGeneProduct.getName(),
GeneProduct.setName(String sid),
GeneProduct.isSetName()public int unsetLabel()
GeneProduct.
public int unsetAssociatedSpecies()
GeneProduct.
public void renameSIdRefs(java.lang.String oldid, java.lang.String newid)
Replaces all uses of a given SIdRef type attribute value with another
value.
In SBML, object identifiers are of a data type called SId.
In SBML Level 3, an explicit data type called SIdRef was
introduced for attribute values that refer to SId values; in
previous Levels of SBML, this data type did not exist and attributes were
simply described to as 'referring to an identifier', but the effective
data type was the same as SIdRef in Level 3. These and
other methods of libSBML refer to the type SIdRef for all
Levels of SBML, even if the corresponding SBML specification did not
explicitly name the data type.
This method works by looking at all attributes and (if appropriate)
mathematical formulas in MathML content, comparing the referenced
identifiers to the value of oldid. If any matches are found, the
matching values are replaced with newid. The method does not
descend into child elements.
renameSIdRefs in class SBaseoldid - the old identifier.newid - the new identifier.public java.lang.String getElementName()
For GeneProduct, the XML element name is always 'geneProduct'.
getElementName in class SBase'geneProduct'.public int getTypeCode()
LibSBML attaches an identifying code to every kind of SBML object. These
are integer constants known as SBML type codes. The names of all
the codes begin with the characters SBML_.
In the Java language interface for libSBML, the
type codes are defined as static integer constants in the interface class
libsbmlConstants. Note that different Level 3
package plug-ins may use overlapping type codes; to identify the package
to which a given object belongs, call the
method on the object.
SBase.getPackageName()
The exception to this is lists: all SBML-style list elements have the type
SBML_LIST_OF, regardless of what package they
are from.
getTypeCode in class SBaseSBML_FBC_GENEPRODUCT (default).
GeneProduct.getElementName(),
SBase.getPackageName()ListOf.getItemTypeCode()).
public boolean hasRequiredAttributes()
true if all the required attributes
for this GeneProduct object have been set.
hasRequiredAttributes in class SBaseGeneProduct object are: