Hi Jonathan,

again a comment regarding file conversion (same data file, examples/biochemical_models/data.xlsx); now it concerns json and yaml export via

obj-tables convert schema.csv data.xlsx data.json obj-tables convert schema.csv data.xlsx data.yml

From the original tables, I had expected a data structure such as

[ [model_1], [compound1, compound2, compound3, ..] [reaction1, reaction2] ]

where the entries point to each other via their ids: e.g., reaction1 would have an attribute "Model", with value "e_coli", which matches the id of model1.

Now I saw that the the attributes (by which objects point to other objects) do not contain ids (or "variable names"), but the objects themselves. Specifically, the data structure starts with compound1, which contains (as an attribute) a data structure describing model1, which in turn contains all compounds and reactions (which then, again, contain "simple" instances of the model). In the end, there are all other compounds (with no model or reaction information at all.

I imagine that this data structure does the job for exporting / importing the python data objects, but it is difficult to make sense of. Can you have a look at this again and see if my solution (described above) would also work for you? (that is, representing a table by a list of relatively "flat" objects, whose attributes can be strings or lists, but not objects themselves, and which instead point to other objects via ids?)

Thank you!

All the best, Wolf

Stored Models, such as spreadsheets and delimited files on disk, can become incompatible with updates to model definitions in obj_model. Create a utility that migrates stored models to be compatible with a modified model. E.g., Django has a migration utility, which was originally called fabric.

Hi Jonathan,

the example file examples/biochemical_models/data.xlsx contains three data tables, but when I convert it to csv or tsv, e.g. using

obj-tables convert schema.csv data.xlsx data.csv

the output file contains only a singel table (Reaction), which is the last table in the original xlsx file. I think by default, all three tables should be exported as one multi-table csv / tsv file. Ideally, the tables should appear in the same order as in the original file, but that's only for convenience - if it's difficult to implement this, the order may also change.

Thank you!

Best, Wolf

When trying to validate that two obj_tables.obj_math.NumpyArrayAttribute are of same shape, I got the error that they do not have an attribute shape. What am I doing wrong.

Class methods

• cls.get_related_attributes() - returns names of all RelatedAttributes of the class
• cls.get_scalar_attributes() - returns all LiteralAttributes of the class
• cls.get_attributes() - returns names of all Attributes
• cls.get_related_name(attribute) - for a given RelatedAttribute of this class, get the related name

Instance methods

• self.get_empty_scalar_attributes() - returns LiteralAttributes that are set to None
• self.get_nonempty_scalar_attributes() - opposite of above
• self.get_empty_related_attributes() - returns RelatedAttributes that are set to None or []
• self.get_nonempty_related_attributes() - opposite of above

Hi Jonathan,

I just tried to put comment lines (with the usual %/ .. /% syntax) into a schema file, in order to visually structure the file. Apparently, comments in schema files are not supported so far. Would it be possible / desirable to allow such comment lines (which the parser could simply ignore), just for convenience?

(This is low priority)

Thank you!

Best, Wolf

Hi Jonathan

In def set_value(self, obj, new_value), at ../obj_model/obj_model/core.py:3884: ValueError an example error looks like: ValueError: Attribute '<wc_lang.core.RateLaw object at 0x7fbb31678a58>' of '<wc_lang.core.RateLawEquation object at 0x7fbb31678b00>' must be None

I think it would be better if the first value was the string value of the attribute and the 2nd was something like the classname, id and name of the Model. Thanks

Currently, overriding attributes managed by the ManyToX relationship manager gives for example the following error: ValueError: Attribute "obj_tables.core" of class "Evidence" inherited from "object" must be a subclass of StringAttribute because the attribute is already defined in the superclass.

Hi Jonathan,

on the documentation page, in "Tabular format for datasets" I find

"schema: Use this key to annotate the name of the schema of the table. If this key is set, ObjTables will check that its value matches the name of the schema used to interpret the table."

It's not clear to me how the name of the schema is defined in the schema file itself. Is there a metadata item "name='..'"? Could you maybe clarify this in the documentation?

Thank you!

Best, Wolf

Hi Jonathan,

I noticed that, when importing a multi-table tsv ObjTables file, the tables become reordered alphabetically. Can this be changed, to keep the original order? (I understand that alphabetical order is a good solution if the tables come from multiple tsv files).

Thank you!

Best, Wolf

Hi Jonathan,

I'm trying out the obj-tables command line tool, command

obj-tables init-schema schema.csv schema.py

and get the error message

Traceback (most recent call last): File "/usr/local/bin/obj-tables", line 10, in sys.exit(main()) File "/usr/local/lib/python3.6/dist-packages/obj_tables/main.py", line 270, in main app.run() File "/usr/local/lib/python3.6/dist-packages/cement/core/foundation.py", line 916, in run return_val = self.controller._dispatch() File "/usr/local/lib/python3.6/dist-packages/cement/ext/ext_argparse.py", line 808, in _dispatch return func() File "/usr/local/lib/python3.6/dist-packages/obj_tables/main.py", line 125, in _default utils.init_schema(args.in_file, out_filename=args.out_file) File "/usr/local/lib/python3.6/dist-packages/obj_tables/utils.py", line 445, in init_schema wb = wc_utils.workbook.io.read(filename) File "/usr/local/lib/python3.6/dist-packages/wc_utils/workbook/io.py", line 889, in read reader = reader_cls(path) File "/usr/local/lib/python3.6/dist-packages/wc_utils/workbook/io.py", line 705, in init path)) ValueError: path 'schema.csv' must have one glob pattern '*' in its base name

Can you make sense of it?

Thank you!

All the best, Wolf

Support linear expressions not written in canonical polynomial form, such as x * 2. Expand on the work in LinearParsedExpressionValidator which uses Python's ast to parse and analyze expressions.

Because obj tables Model instances are indexed by unique keys, unexpected behavior can arise from aliased references. E.g., suppose that a person using wc_lang creates two reactions Models that use the same flux_bounds (another Model) in a whole-cell model model. Let the reaction ids be 'ex_m1' & 'ex_m2'. Then these expressions refer to the two reactions

model.reactions.get_one(id='ex_m1')
model.reactions.get_one(id='ex_m2')

And these expressions refer to the FluxBounds Model that they share.

model.reactions.get_one(id='ex_m1').flux_bounds
model.reactions.get_one(id='ex_m2').flux_bounds

Thus, any changes to one flux_bounds entity will change the other. These two references to one FluxBounds Model are called 'aliases' in Computer Science, which has studied aliasing deeply, especially in computer language and compiler theory (google scholar "mark wegman aliasing").

Aliasing is likely to cause problems for obj model users that don't expect aliasing, i.e., that don't realize that multiple references point to the instance. E.g., model.reactions.get_one(id='ex_m1').flux_bounds.min *= 10 would also change the value of model.reactions.get_one(id='ex_m2').flux_bounds.min which might not be expected.

The only possible technical change obj tables could make to address this would be to avoid reusing objects just on the basis of data values in unique keys. However, that would likely have other consequence.

Other than that, there's nothing technical obj tables can do to address this. Warnings aren't appropriate, and would almost certainly be ignored; and errors aren't appropriate. So the best thing to do is alert users to this issue in the obj tables documentation.

Hi Jonathan,

I'm sorry for bringing this up again, it's about the "uncontrolled" columns (those that do not start with a "!").

If I remember correctly, the parser does not ignore them, but reads them and attaches their content to the data objects as "comments" or extra information. For my own intended usage of ObjTables (for the results of Enzyme Cost Minimisation) it would be important that this information can also be exported again, such that after a round of import and export, the "uncontrolled" columns would still exist. I think this is not the case right now.

Could you implement this?

Thank you!!

Best, Wolf

Hi Jonathan,

we talked about this already, but I'd like to bring this up again.

Since SBtab does not support grouped tables, it will not be able to import ObjTables files that use this feature. Therefore, it would be great if there was an option in ObjTables that allows for import and export of data files in an alternative form. Instead of

 | !GROUP |       |

!A | !X | !Y |!B

this form could read, for example,

!A | !::GROUP::X | !::GROUP::Y | !B

It's not urgent, but it would be good to know whether you would be willing to implement this in principle.

Thank you!

Best, Wolf

Hi Jonathan,

In the list of datatypes on the website, it could be helpful to give an example string for each datatype (or at least those where strings are not lengthy). In most cases the sytax is obvious, but with Boolean values, lists, or dates, for example, the syntax may be less clear. If this makes the website to crowded (which I think it may do), maybe there could be an extra dataset file that contains one item for each datatype, just for the sake of an example?

Best, Wolf