proper complex-child relation in sbml

created from discussion with Robert Phair

@Robert Phair
You identified one of the problems that I had with multi package. In theory there is possibility to define complex formation in multi but I just could not figure out how to do it properly. I would happily add it but I need to know how. Are you or your developers familiar with the package and could help here? I just need a proof of concept and I will implement it by myself.
The only thing that could do to discover the complex formation is to check the coordinates in layout extension. But I know it's far from perfect (for instance nested complexes are a bit tricky to handle)

Robert Phair  2 months ago
@piotr I had a conversation with Fengkai Zhang on the sbml-discuss Google group. He is one of the principal developers of multi, and is the developer of SIMMUNE, a tool for modeling and simulation of the immune system. He's in Ron Germain's group at the US NIH. He was eager to help. I asked him how he would code the SMAD1/5/8 complex in SBML multi. and this was his response: "Hi Robert,
Thank you for working to support the multi package! Thank you for the question. I include this reply to the multi list. I think we could also continue to discuss here as multi is part of sbml.
Specific to your question, you could first define mult:speciesTypes in the following way:
<multi:listOfSpeciesTypes>
   <multi:speciesType multi:id="st_SMAD1" multi:name=" SMAD1" …/>
   <multi:speciesType multi:id="st_SMAD5" multi:name=" SMAD5" …/>
   <multi:speciesType multi:id="st_SMAD8" multi:name=" SMAD8" …/>
	<multi:speciesType multi:id="st_SMAD1_5_8" multi:name=" SMAD1_5_8" …>
	   <multi:listOfSpecieTypeInstances>
	       <multi:speciesTypeInstance multi:id="sti_SMAD1" multi:speciesType="st_SMAD1" … />
	       <multi:speciesTypeInstance multi:id="sti_SMAD5" multi:speciesType="st_SMAD5" … />
	       <multi:speciesTypeInstance multi:id="sti_SMAD8" multi:speciesType="st_SMAD8" … />
	   </ multi:listOfSpecieTypeInstances >
	</multi:speciesType >
	…
</multi:listOfSpeciesTypes > 
And in speces to reference the speciesTypes, you may have:
<listOfSpeces>
   <species id="species_SMAD1_5_8" multi:speciesType="st_SMAD1_5_8"… /> 
    <species id="species_SMAD1" multi:speciesType="st_SMAD1"… /> 
    <species id="species_SMAD5" multi:speciesType="st_SMAD5"… /> 
	<species id="species_SMAD8" multi:speciesType="st_SMAD8"… /> 
	…
</listOfSpeces>
 
Depending the purpose, annotation can be added to species, speciesType, and/or speciesTypeInstance. I consider species should be a good place to be annotated with a uniprot id."
I, too, have problems with the multi-spec, largely because it does not explicitly define how to handle any particular biological scenario. In other words, I think the spec is more like a framework. The trouble with a framework is that different developers can handle the same task in different ways. To me, this is antithetical to to the SBML goal of interoperability - model exchange among software tools. This was probably caused by the SBML competing priority to satisfy multiple development groups. I was not there. I am not an expert. So I have no grounds for complaint. But I think Fengkai is more than willing to help. (edited) 

Robert Phair  2 months ago
@piotr I think your method for encoding complexes is logical, but maybe Fengkai's method has something to teach us. Our lead developer, @Jason Zwolak, has a long history working with SBML, but he has not worked with multi. He has, however, read the multi spec, and might want to join in this conversation because we want to be able to import MINERVA models into ProcessDB.

piotr  2 months ago
@Robert Phair In theory it should be doable, the only issue that I can see (that might become a problem) is that we have to create separate multi type for every single species on the map. We also need to somehow identify the BioEntity type of the multi type at the same level (if it's a small moleculer/protein/phenotype/etc). In theory the distinction should be doable using SBO term, but I remember there was an issue with that don't remember what it was though.
Another issue is that we would need to duplicate definitions of modification residue types and structural type information in every multi type defined. And this might result in a very messy SBML.
Nevertheless I can give it a try when I find some time.