draeger-lab / ModelPolisher

ModelPolisher accesses the BiGG Models knowledgebase to annotate SBML models.
MIT License
23 stars 7 forks source link

Conflict with SBML validation #100

Closed Biomathsys closed 2 years ago

Biomathsys commented 4 years ago

Hi,

I am using ModelPolisher via Docker. I see the following warnings: May 26, 2020 1:27:41 PM de.zbit.util.prefs.SBPreferences analyzeCmdArgs --- WARNING: Option SBML_VALIDATION conflicts with the value COMPRESSION_TYPE of option NONE.

May 26, 2020 1:27:41 PM de.zbit.util.prefs.SBPreferences analyzeCmdArgs --- WARNING: Rejecting option SBML_VALIDATION=false.

In addition, one folder has been created with the name of output but it is empty.

I was wondering if this warnings are coming for not validation of Model or not? While My model is valid and was checked with SBMLvalidator.

Thanks in advance. Best,

mephenor commented 4 years ago

This is an issue with the library used for parsing command-line options, with sets validation to false, if the output file is not zipped, as the online service was used for validation and this probably should save bandwidth. I since enabled offline validation, but haven't yet fixed this issue.

I need to check the empty folder issue. Could you please provide your input parameters and maybe the input file?

mephenor commented 4 years ago

After checking the file, this seems to an issue with namespace prefixes, as the model for which this happens has html: and sbml: prefixes for each corresponding element.

The SysBio dependency used to validate the file type lets ModelPolisher skip the input file, as <sbml:sbml does not conform to the regex used for validation, which only expects sbml followed by a whitespace. Removing the namespace and adjusting the sbml namespace declaration remedies this problem for now, however this likely needs to be considered/changed in SysBio.

Additionally a NullPointerException is triggered when appending notes, as html:html tags are present, where they should be html:body. While there is code in ModelPolisher that deals with this problem, it does currently not expect a prefix. This behavior thus needs to be changed.

For now sed -i.bak 's/sbml://g' <model>.xml && sed -i 's/xmlns:sbml/xmlns/g' <model>.xml && sed -i 's/html:html/html:body/g' <model>.xml should make such a model work with ModelPolisher.

mephenor commented 4 years ago

SBMLReader seems to have issues when I disable the filetype check and feed the model as is:

16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - Cannot find a parser for the  namespace
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - Cannot find a parser for the  namespace
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - Cannot find a parser for the  namespace
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - !!! event.isEndElement: there is a problem in your SBML file !!!!
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - This should never happen, there is probably a problem with the parsers used.
 Try to check if one needed parser is missing or if you are using a parser in development.
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - Cannot find a parser for the  namespace
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - !!! event.isEndElement: there is a problem in your SBML file !!!!
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - This should never happen, there is probably a problem with the parsers used.
 Try to check if one needed parser is missing or if you are using a parser in development.
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - Cannot find a parser for the  namespace
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - !!! event.isEndElement: there is a problem in your SBML file !!!!
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - This should never happen, there is probably a problem with the parsers used.
 Try to check if one needed parser is missing or if you are using a parser in development.
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - !!! event.isEndElement: there is a problem in your SBML file !!!!
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - This should never happen, there is probably a problem with the parsers used.
 Try to check if one needed parser is missing or if you are using a parser in development.
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - !!! event.isEndElement: there is a problem in your SBML file !!!!
16:51:50 [main] WARN  org.sbml.jsbml.xml.stax.SBMLReader - This should never happen, there is probably a problem with the parsers used.

@draeger Does SBML/JSBML support declaration of each namespace at the top level like <sbml:sbml xmlns:fbc="http://www.sbml.org/sbml/level3/version1/fbc/version2" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core" sboTerm="SBO:0000624" level="3" version="1" fbc:required="false"> ? I commonly just see the declaration of the sbml namespace there, in the form of xmlns="http://www.sbml.org/sbml/level3/version1/core"

draeger commented 4 years ago

Yes, the prefix sbml: for the elements already at the top-level element is (to my knowledge) legal if there is a namespace declaration in the same element that defines the name space. Apparently, that's the case here: xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core" sboTerm="SBO:0000624" which clearly defines the prefix sbml.

Where and why is that useful? It is needed if a model contains numbers with units in a mathematical expression. Unfortunately, MathML does not define a way to attach units to numbers, but SBML does. However, a unit attribute must be added to the numbers in the form sbml:unit. To this end, the prefix sbml needs to be declared. And once it is declared, it can (but doesn't have to) be used as a prefix for any SBML element or attribute.

It seems to me that not much attention was spent on this. Could you please transfer the problem to JSBML? It is possible that the parsers for SBML don't consider the case properly.

mephenor commented 4 years ago

@draeger I'll open an issue with JSBML for that, as I already wanted to adress the issue with malformed XML in the notes (i.e. html tag instead of body) throwing a NullPointerException instead of somehow handling it in a graceful way. I could, however, implement functionality corresponding to the sed commands above on our side to deal with the issue for now.

This might be a general issue with CarveMe models, as the respective model had <html:p>Description: This model was built with CarveMe version 1.2.2</html:p> in its model notes, though I'd need to check out CarveMe to be sure.

@Biomathsys might have more information regarding the model. Would it be okay to provide the input model to the JSBML team should they need to check it to resolve the issue on their side?

draeger commented 4 years ago

@Biomathsys can also provide the model to the JSBML team directly, it doesn't have to be publicly uploaded.

Schmoho commented 2 years ago

Added this to the Release 2.1 project, as the commit 1dcb3db that is supposed to solve this is in the 2.1 branch.

Schmoho commented 2 years ago

Unfortunately. without the model data available I am not really able to reproduce this right now.

It seems to me however that the approach taken in the above mentioned commit is not really solid.

If the sbml prefix is necessary to support units, wiping it seems to be a rather bad idea to me. As far as I understood the above discussion, this is mostly an upstream issue with JSBML - if that is the case, I would actually propose not to handle these issues at all in our code.

@draeger Any input?

Schmoho commented 2 years ago

This was already reverted via 9dfd32e as it introduced a bug. As this issue does not appear to be somehow actionable, I am closing it.