Interface Complex

All Superinterfaces:
BioPAXElement, Cloneable, Controller, Entity, Level3Element, Named, Observable, PhysicalEntity, Serializable, XReferrable
All Known Implementing Classes:
ComplexImpl

public interface Complex extends PhysicalEntity
Definition: A physical entity whose structure is comprised of other physical entities bound to each other non-covalently, at least one of which is a macromolecule (e.g. protein, DNA, or RNA). Complexes must be stable enough to function as a biological unit; in general, the temporary association of an enzyme with its substrate(s) should not be considered or represented as a complex. A complex is the physical product of an interaction (complexAssembly) and is not itself considered an interaction. Comment: In general, complexes should not be defined recursively so that smaller complexes exist within larger complexes, i.e. a complex should not be a COMPONENT of another complex (see comments on the COMPONENT property). The boundaries on the size of complexes described by this class are not defined here, although elements of the cell as large and dynamic as, e.g., a mitochondrion would typically not be described using this class (later versions of this ontology may include a cellularComponent class to represent these). The strength of binding and the topology of the components cannot be described currently, but may be included in future versions of the ontology, depending on community need. Examples: Ribosome, RNA polymerase II. Other examples of this class include complexes of multiple protein monomers and complexes of proteins and small molecules.
  • Method Details

    • getComponent

      Set<PhysicalEntity> getComponent()
      Defines the PhysicalEntity subunits of this complex. This property should not contain other complexes, i.e. it should always be a flat representation of the complex. For example, if two protein complexes join to form a single larger complex via a complex assembly interaction, the component of the new complex should be the individual proteins of the smaller complexes, not the two smaller complexes themselves. Exceptions are black-box complexes (i.e. complexes in which the component property is empty), which may be used as component of other complexes because their constituent parts are unknown / unspecified. The reason for keeping complexes flat is to signify that there is no information stored in the way complexes are nested, such as assembly order. Otherwise, the complex assembly order may be implicitly encoded and interpreted by some users, while others created hierarchical complexes randomly, which could lead to data loss. Additionally, the physicalEntityParticipants used in the component property are in the context of the complex, thus should not be reused between complexes. For instance, a protein may participate in two different complexes, but have different conformation in each.
      Returns:
      components of this complex
    • addComponent

      void addComponent(PhysicalEntity component)
      Defines the PhysicalEntity subunits of this complex. This property should not contain other complexes, i.e. it should always be a flat representation of the complex. For example, if two protein complexes join to form a single larger complex via a complex assembly interaction, the component of the new complex should be the individual proteins of the smaller complexes, not the two smaller complexes themselves. Exceptions are black-box complexes (i.e. complexes in which the component property is empty), which may be used as component of other complexes because their constituent parts are unknown / unspecified. The reason for keeping complexes flat is to signify that there is no information stored in the way complexes are nested, such as assembly order. Otherwise, the complex assembly order may be implicitly encoded and interpreted by some users, while others created hierarchical complexes randomly, which could lead to data loss. Additionally, the physicalEntityParticipants used in the component property are in the context of the complex, thus should not be reused between complexes. For instance, a protein may participate in two different complexes, but have different conformation in each.
      Parameters:
      component - to be added as a new member
    • removeComponent

      void removeComponent(PhysicalEntity component)
      Defines the PhysicalEntity subunits of this complex. This property should not contain other complexes, i.e. it should always be a flat representation of the complex. For example, if two protein complexes join to form a single larger complex via a complex assembly interaction, the component of the new complex should be the individual proteins of the smaller complexes, not the two smaller complexes themselves. Exceptions are black-box complexes (i.e. complexes in which the component property is empty), which may be used as component of other complexes because their constituent parts are unknown / unspecified. The reason for keeping complexes flat is to signify that there is no information stored in the way complexes are nested, such as assembly order. Otherwise, the complex assembly order may be implicitly encoded and interpreted by some users, while others created hierarchical complexes randomly, which could lead to data loss. Additionally, the physicalEntityParticipants used in the component property are in the context of the complex, thus should not be reused between complexes. For instance, a protein may participate in two different complexes, but have different conformation in each.
      Parameters:
      component - to be removed from members.
    • getComponentStoichiometry

      Set<Stoichiometry> getComponentStoichiometry()
      The stoichiometry of components in a complex.
      Returns:
      the stoichiometry of components in a complex.
    • addComponentStoichiometry

      void addComponentStoichiometry(Stoichiometry stoichiometry)
      The stoichiometry of components in a complex.
      Parameters:
      stoichiometry - add a stoichiometry for the member.
    • removeComponentStoichiometry

      void removeComponentStoichiometry(Stoichiometry stoichiometry)
      The stoichiometry of components in a complex.
      Parameters:
      stoichiometry - remove a stoichiometry for the member.
    • getSimpleMembers

      Set<SimplePhysicalEntity> getSimpleMembers()
      Gets the member physical entities which are not complex. When the complex is nested, members of inner complexes are added to the returned set recursively.
      Returns:
      non-complex member physical entities
    • getMemberReferences

      Set<EntityReference> getMemberReferences()
      Gets the EntityReferences of the member simple physical entities. When the complex is nested, contents of the member complexes are retrieved recursively.
      Returns:
      non-complex members' entity references