SBML-JSON Converter: GSoC 2020

 Greetings, Almost towards the end, we didn't have anything new to discuss in the last meeting, except the identifier (id) of COBRA model components. The 'id' of an SBML component is an important attribute and should not be manipulated. COBRApy, however, allows the user to pass a replacement function to manipulate the component ids. It also asks the user to pass a reverse replacement function to modify the ids while writing the model back. We discussed this thing and both of the mentors were having an opinion that ids should not be manipulated at all, it can create problems. Currently, the COBRApy writes the same manipulated ids in the JSON format, and if we apply the defined id pattern properties of SBML to these manipulated ids, these ids may get failed. So at the time of reading/writing the model from JSON, I have used the default replacement functions to fix the ids. Another thing which we discussed was the things which COBRApy communities have listed to port the code f

Greetings, The last meeting was not too long, it ended in approximately 35 minutes. The mentors first went through the JSON schema-V2 to see the definitions of features added to JSON like group, user defined constraint, annotation etc. They suggested a few modifications like adding pattern properties for datetime and Id. The schema was otherwise all fine. After this, we started discussing the helper function for adding user defined constraints. I had implemented this method by parsing string by my own and extracting information out of it, which lead to various restrictions on defining the constraint. But Matthias suggested that the best way to handle expression inside a string is by using the Abstract Syntax Tree (AST). By using the tree, we can define our constraint expression more freely, with just a few restrictions. So I shall add this support using AST. The other important thing that we discussed was the JSON validation function. Currently, I was using the inbuilt JSON validation

Greetings, This week, Phase II has ended, and we have covered almost all the major tasks of our project, except for one i.e modifying the JSON schema according to the newly implemented formats like metadata, FBC-v3, and unsupported packages inside JSON like Groups. So this week, I am required to work on the JSON schema, along with a few modifications in the "UserDefinedConstraint" class. One thing that mentors noted in the Contraint class was that the "id" attribute of constraint objects is not a required one, according to the doc. It is optional for users to set the id for constraint objects. However, since COBRApy uses a self-made data structure i.e DictList, to store "listof..." type components of SBML, which uses the id attribute of the object to map the actual COBRA object, id's were a must for COBRA objects if we want to store them inside a DictList. So to make sure that each COBRA constraint object has an id, we are generating one internally if

Greetings, It had been quite long since the start of the coding period and we have covered almost all major functionalities. Last week, we implemented the "UserDefinedConstraint" class introduced in FBC-v3. This class is used to define additional user constraints using reaction fluxes or non-constant parameters. Up until now, most of my work was revolving around modifying the data structures of various components, so I never went to understand the SBML components and the relationship between them. However, the "UserDefinedConstraint" class was not having any support in COBRApy till now and we were required to build it from scratch. And it required the understanding of reaction fluxes, objective function, flux bounds, exchange reactions, boundary species, etc. But thanks to my mentors again, they helped me to understand them all by answering my doubts and providing appropriate resources. The "UserDefinedConstraint" class along with the "UserDefinedC

Greetings, Last week I modified the 'history' class as suggested by the mentors and added a COBRApy's own Datetime class. This class is going to store date and time in the format '%Y-%m-%dT%H:%M:%S%z', as stored inside in the SBML document for storing created and modified dates. Last week, I also started with the implemention of the 'Group' package inside JSON and other formats. The current COBRApy implementation has a separate Group class (extending the Object class) for storing group data, and members inside this group (referencing other model components) are simply stored in a 'Dictlist'. The document for Group package says that the members of 'Group' should inherit from the basic SBase class (or COBRApy's Object class), so I thought that we would need a separate class for storing 'members' inside the Group. I made a 'GroupMember' class and inherited it from COBRApy's Object class. By inheriting from Object cla

Greetings, Glad to tell you that we have completely covered all the metadata classes including the "notes" feature, which by now was having only minimal support in COBRApy. I have already discussed the annotations classes in the previous blogs, so let me now give you a summary of the "notes" feature. "Notes" in SBML are a place to store any type of information that is intended to be seen by humans only. We should not have any machine parseable information in it. However, a few years back, when SBML did not have support for adding some of the properties/information anywhere in the document, they were put into the "notes" field in the form of key-value pairs, and later extracted from the "notes" string when required. When support for these features was added in the SBML, encoding of any data inside the "notes" field was restricted again. But this led to the presence of some models out there in the world, which has that inform