The Week 8
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 information present inside the notes field, and that information is required to be parsed out from "notes" string if someone uses any such model.
COBRApy by now was only extracting any information present inside notes field which is of the form "<p> key: value </p>", and dropping all the other "notes" data. So this was one of the sources of information loss. JSON and other formats did not even have any support for storing the "notes" data. We discussed this issue with the COBRApy community on their issue list, and they suggested not to have any separate parser for storing notes data, and storing simple "notes" string will do the work. We, therefore, approached this issue like we approached the annotation, i.e having backward compatibility of using the "notes" dictionary along with storing the notes string also in the same class. We made a separate class for notes, which would behave like a dictionary i.e it can be iterated or indexed, but this class will also store the direct "notes" string inside it and calling an object of this "notes" class will return the corresponding "notes" string. Both the notes string and dictionary will be synchronized with each other, and adding any new key-value which is not present inside the notes string will be allowed. Inside JSON and other formats too, the complete notes string will be put as it is.
I added the support for "notes" data inside COBRApy and made the tests for it last week. In the last meeting, mentors were going through the metadata classes and suggested some modifications. I must agree that I am learning a lot about better coding styles, how to write more efficient codes, which is easily readable, compact, and complete, all thanks to my mentors for their guidance. Last week, we also had the first-phase evaluation, and we successfully passed it. We might meet again during the week, and go through the code to make small modifications and finalize them.
Thanks for reading. See you next week.
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 information present inside the notes field, and that information is required to be parsed out from "notes" string if someone uses any such model.
COBRApy by now was only extracting any information present inside notes field which is of the form "<p> key: value </p>", and dropping all the other "notes" data. So this was one of the sources of information loss. JSON and other formats did not even have any support for storing the "notes" data. We discussed this issue with the COBRApy community on their issue list, and they suggested not to have any separate parser for storing notes data, and storing simple "notes" string will do the work. We, therefore, approached this issue like we approached the annotation, i.e having backward compatibility of using the "notes" dictionary along with storing the notes string also in the same class. We made a separate class for notes, which would behave like a dictionary i.e it can be iterated or indexed, but this class will also store the direct "notes" string inside it and calling an object of this "notes" class will return the corresponding "notes" string. Both the notes string and dictionary will be synchronized with each other, and adding any new key-value which is not present inside the notes string will be allowed. Inside JSON and other formats too, the complete notes string will be put as it is.
I added the support for "notes" data inside COBRApy and made the tests for it last week. In the last meeting, mentors were going through the metadata classes and suggested some modifications. I must agree that I am learning a lot about better coding styles, how to write more efficient codes, which is easily readable, compact, and complete, all thanks to my mentors for their guidance. Last week, we also had the first-phase evaluation, and we successfully passed it. We might meet again during the week, and go through the code to make small modifications and finalize them.
Thanks for reading. See you next week.
Comments
Post a Comment