PhysicalProcess

class pyomexmeta.PhysicalProcess(physical_process_ptr: ctypes.c_longlong)

Interface for creating PhysicalProcess type composite annotations

From section 2.3.7.2 of the OmexMeta specification:

The example annotation above is for a physical property of a physical entity. However, models also include variables for the rates of physical processes, such as chemical reactions, transport of solutes, flow of fluids in vessels, etc., For these entities, we recommend the use of a composite annotation, where a custom physical process is instantiated and linked to its participants: the energetic sources and sinks as well as mediators whose amounts modulate the magnitude of the physical process property.

Sources, sinks and mediators are the physical entities that participate in the process: source amounts are consumed by the process, sink amounts are produced, and mediator amounts remain unchanged. In the biochemical domain, sources and sinks correspond to ”reactants” and ”products”, but the former terms are much broader. Below, we provide an example of a composite annotation for the rate of a chemical reaction with one source, one sink, and one mediator.

First, we assert statements indicating that the model includes a variable that represents a physical property of a process that is a chemical flow rate (opb:OPB 00592).

myOMEX:MyModel.xml#property_metaid_0

bqbiol:isPropertyOf local:process_0 ; bqbiol:isVersionOf opb:OPB_00592 .

The above annotation would be appropriate for a CellML model, where property metaid 0 points to the CellML variable representing the chemical flow rate. However, in SBML models, processes are indicated by reactions, and there is no separate entity of variable for the flow rate. Therefore, an annotation about chemical flow rate for an SBML model would have to be defined within the RDF file, using the local: namespace. That annotation would make reference to the process, which would have a corresponding entity (the reaction) in the SBML file.

We next assert statements that indicate the physical entity participants in the process: the energetic sources, sinks, and mediators. In this case, there is one source, one sink, and one mediator. Optionally, the sources and sinks can include stoichiometry statements (using the semsim:hasMultiplier quali- fier) to indicate the production/consumption ratios for the process participants (mediator participation statements cannot include stoichiometries).

Optionally, we can also name or describe the process itself. Often, there is no knowledge resource for naming processes, but within the realm of biochemical reactions, many are named by resources such as the Gene Ontology (process branch) and RHEA (for metabolic reactions).

local:process_0

semsim:hasSourceParticipant local:source_0 ; semsim:hasSinkParticipant local:sink_0 ; semsim:hasMediatorParticipant local:mediator_0 ; bqbiol:isVersionOf <https://identifiers.org/GO:0004022> .

local:source_0

semsim:hasMultiplier 1.0 ; semsim:hasPhysicalEntityReference myOMEX:MyModel.xml#species_metaid_0 .

local:sink_0

semsim:hasMultiplier 2.0 ; semsim:hasPhysicalEntityReference myOMEX:MyModel.xml#species_metaid_1 .

local:mediator_0

semsim:hasPhysicalEntityReference myOMEX:MyModel.xml#species_metaid_2 .

RDF statements indicating the biological identity of the chemical species that participate in the process (the resources with the species metaid * URI fragments in this example) would be included elsewhere in the RDF. For SBML models where these chemical species are explicitly represented using <species> elements, the metadata IDs should point to those elements in the SBML code. For other formats, such as CellML, that do not support such elements, the metadata IDs should point to physical entities instantiated elsewhere in the RDF, using the local: namespace.

We recognize that creating composite annotations for biological processes in this manner can duplicate information that is present in an SBML model’s reaction network structure. However, because annota- tions are stored in a separate location from the source code, these composite annotations are necessary, so that all biological features represented in a model are exposed in the RDF metadata. This way, the community can more easily apply RDF-processing tools to analyze, query, and reason over semantic metadata in COMBINE archives, in a manner that is independent of the source code used by the model.

__init__(physical_process_ptr: ctypes.c_longlong)

Constructor for PhysicalProcess.

This constructor is not designed to be used directly by users. Instead users should create a PhysicalProcess directly from the an instance of Editor.

Parameters

physical_process_ptr – A ctypes int64 integer representing the memory address (pointer) of this PhysicalProcess.

__weakref__

list of weak references to the object (if defined)

about(about: str, uri_type: pyomexmeta.pyomexmeta_api.eUriType) → pyomexmeta.pyomexmeta.PhysicalProcess

Sets the about (subject) portion of the PhysicalProcess.

This can be either:

  • a uri of a metaid that exists in the model xml, such as the case with sbml

  • could need creating in this local namespace (i.e. internal to the RDF graph), such as the case with CellML

Users need to know which use case they need for their annotation language.

Parameters

  • about – The string to use as the metaid. When type is eUriType.MODEL_URI then this string must be an existing metaid in the xml. When type is eUriType.LOCAL_URI, this name can be arbitrary, as long as its unique within the RDF graph.

  • type – either eUriType.MODEL_URI or eUriType.LOCAL_URI

Returns

PhysicalProcess. Reference to self

add_mediator(physical_entity_reference: str, uri_type: pyomexmeta.pyomexmeta_api.eUriType) → pyomexmeta.pyomexmeta.PhysicalProcess

Adds an energetic mediator to this PhysicalProcess, such as a enzyme or other catalyst in a reaction

Parameters

  • physical_entity_reference – The string of the metaid for the energetic mediator. If uri_type is eUriType.MODEL_URI (for instance when annotating sbml), this string needs to exist as a metaid on an element of xml. If uri_type is eUriType.LOCAL_URI (i.e. CellML) then this identifier can be string that is unique in the rdf document

  • uri_type – One of eUriType.LOCAL_URI or eUriType.MODEL_URI

  • multiplier – int representing the stoichiometry of the mediator

Returns

PhysicalProcess. Reference to self.

add_sink(physical_entity_reference: str, uri_type: pyomexmeta.pyomexmeta_api.eUriType, multiplier: float = 1.0) → pyomexmeta.pyomexmeta.PhysicalProcess

Adds an energetic sink to this PhysicalProcess, such as a product in a reaction

Parameters

  • physical_entity_reference – The string of the metaid for the energetic sink. If uri_type is eUriType.MODEL_URI (for instance when annotating sbml), this string needs to exist as a metaid on an element of xml. If uri_type is eUriType.LOCAL_URI (i.e. CellML) then this identifier can be string that is unique in the rdf document

  • uri_type – One of eUriType.LOCAL_URI or eUriType.MODEL_URI

  • multiplier – int representing the stoichiometry of the sink

Returns

PhysicalProcess. Reference to self.

add_source(physical_entity_reference: str, uri_type: pyomexmeta.pyomexmeta_api.eUriType, multiplier: float = 1.0) → pyomexmeta.pyomexmeta.PhysicalProcess

Adds an energetic source to this PhysicalProcess, such as a reactant in a reaction

Parameters

  • physical_entity_reference – The string of the metaid for the energetic source. If uri_type is eUriType.MODEL_URI (for instance when annotating sbml), this string needs to exist as a metaid on an element of xml. If uri_type is eUriType.LOCAL_URI (i.e. CellML) then this identifier can be string that is unique in the rdf document

  • uri_type – One of eUriType.LOCAL_URI or eUriType.MODEL_URI

  • multiplier – int representing the stoichiometry of the source

Returns

PhysicalProcess. Reference to self.

delete() → None

Clear up resources used by this PhysicalProcess

get_ptr() → ctypes.c_longlong

Returns the memory address that points to this PhysicalProcess

has_property(property_about: Optional[str] = None, about_uri_type: Optional[pyomexmeta.pyomexmeta_api.eUriType] = None, is_version_of: Optional[str] = None, property: Optional[pyomexmeta.pyomexmeta.PhysicalProperty] = None) → pyomexmeta.pyomexmeta._PropertyBearer

Create a PhysicalProperty associated with a PhysicalEntity, EnergyDiff or PhysicalProcess.

This method has 3 signatures in the underlying C++ library. This method unpacks the user supplied arguments and passes them to the correct signature, depending on what is supplied.

The first signature is used with sbml models and requires only the is_version_of arument. This is commonly used for annotating sbml models and therefore, when only one string argument is passed to has_property() the argument is used for the is_version_of argument (see example below).

Parameters

is_version_of – (str) represents an OPB term from the Ontology of Physical Biology.

In the above case, the necessary local identifiers are created automatically and are guarenteed to be unique throughout your RDF graph. In some circumstances, you might want to have control over the metaids used for local uri’s. The above would create a PhysicalProperty with the subject or “about” portion equal to local:EntityProperty0000. We can set this ourselves using the second overload, which requires three arguments:

Parameters

  • property_about – The subject or “about” portion of the PhysicalProperty triples.

  • eUriType.LOCAL_URI if the uri for property_about should be local to the (about_uri_type) – annotation (rdf) graph or eUriType.MODEL_URI if it instead points to a element of the model (which is common in CellML).

  • The OPB term to use for the "isVersionOf" predicate (is_version_of) –

Finally, you can create the Property yourself and pass that to has_property() instead. This is often more useful in CellML models.

is_version_of(version: str, uri_type: pyomexmeta.pyomexmeta_api.eUriType = 3) → pyomexmeta.pyomexmeta.PhysicalProcess

Deprecated. Use hasProperty intead