SBML-JSON Converter: GSoC 2020

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