Re: [Miase-discuss] sed-ml library?

[Nicolas Le n. <le...@eb...>]

Frank Bergmann wrote:

>> The fact that we are not allowing SBML models to be embedded in the
>> SED-ML files does not change a thing. The actual problem with referring
>> to external sources which might address different versions of (even
>> curated) models remains. Imho we cannot get around having either a
>> "version" attribute in the <model> element or making sure the model
>> resources we allow for reference have unambigious URIs for each version
>> of the models ;-)
> 
> I honestly think this is making live much more difficult. If I read a
> description file which tells me the models is at: 
> 
> http://modelrepository.net/interestingModel.xml
> 
> I know exactly what to do and how to get it. Even if your give me a
> biomodels urn. That is all well. Now if you start and say, "oh but take
> version X" ... then I cannot automatically resolve it anymore. I don't know
> how to go to the source repository and request a different version. And I
> don't see how you can unambiguously describe how models and versions are to
> be kept on all repositories. But again, this is a non-issue. At the time of
> writing, the software tool knows exactly which model was run, so the tool
> can make sure the description is correct. 

That would be solved if a unique identifier scheme was adopted. In 2006, I 
succeeded to have almost everyone around a table to talk about model 
repository interoperability. And the first thing we agreed upon was to 
develop a single identifier scheme and set-up a resolver. It did not happen 
because I so hopelessly disorganised. But everyone agree in principle.

Now, MIRIAM imposes that a model's annotation carry "The time and date of 
creation, and the date and time of last modification" (rule 4, box 4 of the 
paper). In SBML we have elements to encode that. One possibility would be 
to implement tests in SED-ML. The model processing could only be performed 
if the source model passed the tests. Those tests could be anything. But 
the timestamps could be subjected to one. "if date is less than X, then 
proceed, otherwise stop and send a message".

Which brings me to another point: Should-we need a message throwing system, 
or is-it a tool problem?

-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468, Skype:n.lenovere, AIM:nlenovere, MSN:nle...@ho...
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/