|
From: Lucian S. <luc...@gm...> - 2020-04-02 21:17:57
|
Thank you both so much! I've addressed the points I could in the text; the final version is now at http://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/distrib/sbml-level-3-distrib-package-proposal.pdf?format=raw To reply to your specific points: On Wed, Apr 1, 2020 at 5:02 PM Rahuman Sheriff <sh...@eb...> wrote: > * One of the authors of the specification is affiliated to a private > company. Should there be a conflict of interest statement ? You remember > the MSB discussion. I don’t know if it applies for the format specification > too ? > I don't think we need to worry for specs themselves, but I'll check on the JIB submission, where there might be. (Although 'Eight Pillars Ltd' is Stuart's name for himself as an independent consultant.) > * I share the same opinion as Bertt, it would have been better to keep the > "external definitions” which cannot be simulated, encoded as annotations. > Hopefully you can consider this for the future release, so that all > annotations can be handled by combine-annot tools. > This is an idea I hadn't considered before--I'll bring it up with the list! > * With increasing single-cell omics research / data, it might become > useful to draw a value from a probability distribution of expression of a > protein across single cell population for modelling. I hope you will > consider to include sampling from probability density function for the next > release. > Do you mean an experimentally-defined probability density function? That does indeed sound useful. I could imagine coordinating with the Arrays package to make this happen: you define an array with the nth percentile for each index, then pick an index at random using a uniform. I don't know if that'll be the best moving forward, but finding something definitely seems worth it. > * The definitionURL (e.g. http://www.sbml.org/sbml/symbols/distrib/normal) > are resolved to an empty page with just value. I suppose this is the common > practise. Would have been nice if cross-linked to the right ontology term. > This is a good point--I'll work with Mike in the upcoming weeks to get pages up at those sites (like we already have for the other core csymbols). (Since sbml.org itself is undergoing a site redesign, this may have to wait until after that happens, but it's on the list.) > * In the section 3.9, the extended SBase class, it would be useful to show > an example the usage of distrib along with the qual Package. > Putting in a qual example is a good idea: I've added one to the 'Interactions with other packages' section (the new 4.4 bit). > * Are the http://dist.org/something used as place holders or are there > plans to create them ? > There were no plans to create them; they were supposed to be obviously-nonfunctional URLs. I've adjusted the text slightly in those sections to make this clearer. > * This is not an issue at all; the entire document is in US english, > except few words (e.g. acknowledgement ) which are in British english. > Good catch! I've fixed this one, and am happy to fix others. This is probably a function of Stuart starting the document and me finishing it ;-) Also, from Brett: - Non-resolving URL's for annotation, while technically correct, in the age of identifiers.org these are not exactly helpful I agree--I'll contact the probonto people and see if they can update their system so that this works. - The Uncertainty or uncertParameter description should clearly state that it is purely an annotation and can not affect the model's numerical results (as discussed earlier in this thread) and can be ignored for simulation purposes. Another option would be to treat the whole DistribBase as any other annotation. I've added the following paragraph to the 'Uncertainty' class definition: ------- [...Each \Uncertainty child must be a unique set of statistical measures.] These statistical measures do not numerically affect simulation of the model. They are, in essence, a controlled annotation format specifically designed for this sort of information. Tools may use this information as they wish, just as they can with other annotation information. ----- Again, sorry for the slow response. > Oh my goodness; you've been much quicker than I feel I would have been able to be, under the circumstances. Huge thanks again to both you and Brett. -Lucian |