Background and Purpose

In the course of studying protease amplification systems, we faced several problems. One of them is the search for parameters for protease kinetics modeling. (See "Amplification" in Modeling for more information on amplification systems) The results of the modeling indicated that the system could be improved by changing parameters related to the protease. For example, if a smaller $K_{m}$ results in a desired output, changing the protease/substrate pair to one with a smaller Km can improve the system. On the other hand, finding proteases with specific parameters is not easy in practice. MEROPS and UniProt are known as protease and protein databases, but kinetic parameters such as $k_{cat}$ and $K_{m}$ are not systematically registered. Furthermore, our amplification system necessitates the use of proteases not naturally found in mammalian cells to prevent interactions with existing metabolic pathways. This complicates the quest for these proteases. In other words, there is a gap between identifying protease-related parameters that need to be modified in a theoretical setting and their actual implementation in the system. Therefore, we have created a database called Proteameter, primarily focused on protease kinetic parameters, through a literature review. Our aim is to bridge the gap between the results obtained from modeling and their practical implementation in the field. Proteameter can be made available on the web, serving as a platform where numerous users can share and exchange parameter information. Not only proteases, but dry labs will always require extensive literature research for modeling. This software will no doubt help iGEM teams looking to use proteases in the future to more quickly examine their systems. In addition, this software was actually utilized in Modeling. See for more information in Modeling Page.

Requirement

The primary objective of this software is to specify a range of kinetic parameters for a protease and display protease/substrate pairs meeting the defined criteria. There are two parameters to consider when analyzing the reaction rate of a protease: $k_{cat}$ and $K_m$. (Explanation of $k_{cat}$ and $K_{m}$) In order to use the modeling results, we came up with a UI that allows the two parameters to be specified independently, as shown below. The range of the two parameters can be specified by moving the boundary of the two-dimensional region as shown below.

When registering parameters, a 'Condition' was designed as a single unit (Entity) containing the protease, substrate, and the parameters determined by the protease as its elements. The Condition also includes other reaction conditions and references for the parameters. Since there can be multiple Conditions associated with one protease or one article, and this relationship is considered essential for understanding the connections between Conditions, Protease and Article were also treated as Entities, creating a ‘1:N relationship’ with Condition. The final Entity Relationship diagram is presented below. This relationship enables users to: Access all conditions related to a specific protease View all conditions published in a particular paper.

Implementation and Features - User's Perspective

The final software source code is available at https://gitlab.igem.org/2023/software-tools/utokyo . See the Gitlab repository for instructions on how to run the software and deploy it to a server. Applications that register multiple types of Entities with various parameters tend to have complex input procedures. Therefore, in the development of the software, special attention was given to prevent users from becoming confused about data entry procedures or having to discard their input and start over. Typical examples are shown below.

Implementation and Features - Developer's Perspective

Integration with other software

Proteameter has information on parameters related to proteases, but other parameters such as sequence and 3D structure are essential when actually building a system using proteases. MEROPS and UniProt are databases that collect protease data. Therefore, we have registered links to these existing databases in the Protease record of Proteameter. This allows users who have found a suitable protease using Proteameter to access other database software containing information such as sequence and 3D structure for consideration of implementation in their applications. In addition, as seen in the Implementation and Features - Developer Perspectives section, Proteameter is now available as a Web API for public access to Proteameter data. This allows other software to access Proteameter data and use it in their own applications. For example, a software that uses proteases as a part of its system can use the Proteameter API to automatically search for proteases that meet the desired parameters and use them in the system. This will allow users to more easily find proteases that meet their needs and reduce the time required to build their systems.

Conclusion and Future Prospects

Proteameter was developed and created as per requirements with the purpose of streamlining the actual implementation considerations when it is valid to adjust protease parameters based on modeling results. Proteameter was also actually used in Modeling (see Modeling page). The current Proteameter has only minimal functionality implemented. For example, proteases and conditions can be registered, but cannot be referenced or deleted. In addition, although Proteameter data registration is currently completely anonymous, it is expected that login and other measures to protect data from malicious editing will be necessary for publicly available operations. Also, measures must be taken to prevent performance degradation as registration data grows further. Currently, all conditions that match the constraints are retrieved for a query, but it is desirable to use pagenationg to prevent too much data from being displayed at one time. In addition, careful investigation is needed to ensure that the current implementation is not causing the N+1 probrem that can occur in a relational database.