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

[Frank B. <fbergman@u.washington.edu>]

Hello All, 

> >
> > Well, what for example about the <curve> element which might have an
> > annotation "The following curve shows the osciallation of bla bla
> bla",
> > but does not have an id!?
> 
>   Do you mean that a curve should have an ID or shouldn't? If an id is
> going to be problematic to fit into an inheritsnce hierarcy, then
> probably it should juet be included where needed, but if there is an
> argument for all elements having an ID then it would make sense to
> have id in a common base class, like in sbml.
> 
>   One solution would be to add another base class with an 'id'
> attribute which extends SedBase ,so you have
> 
>                           SedBase
>                         /         \
>        IdentifiableSedBase         \
>           /             \            \
>        Simulation,   Output           Curve
> 
> 

IMHO: I'd have id in the base class. There might be lots of reasons why one
would like to uniquely identify *all* elements in the description. We don't
have to have it mandatory but we should not altogether prohibit it. What
about in half a year we  see the need to access curve elements, to change
one of the attributes. 


>   I'll try and expland. I was thinking of a case of a non-curated
> model. For a ccurated model it is in a sense fixed, can be referred
> to, changes can be relative to it because it, or at least that version
> of the model is immutable. MAybe I don't understand the model creation
> process very well, but if you have different sedml files with embedded
> sbml files, each referring to a  different version of a particular
> model, then it is confusing to the user to have lots of slightly
> different model files in their system. But maybe htis isn't actually a
> problem, as it is up to a tool developer to provide support to the
> user, and I suppose from a library developlment point of view, so long
> as the combined sedml/sbml file is internally consistent, then that's
> the important thing.
> 

I still think, in order to keep the miase documents consistent, we should
not depend on users to manually sync models and description. That should be
a tool issue. However, I'm a bit worried by what you mean with 'immutable'.
Right now there is nothing that says that a model has to be immutable. A
model comes from a 'source' attribute, and after that a set of changes is
applied to it. For the software it should not be relevant where the model is
coming from. The only difference of having a remote file reference is
greater latency times, and possibly timeouts while accessing the file, other
than that it will and SHOULD behave exactly as if it came from a local
directory. 


> 
> 
> Just one more issue, how big do you think these files are likely to
> get, realistically, over the next few years? I'm thinking that as most
> models are relatively small then the sed-ml files will be easily held
> in memory for the forseeable future?
> 

Again, I'm against embedding the model (and later measurement data) directly
into the description file. Which then of course limits the file size
drastically. But even model + description data should fit into memory
easily. I'm not so sure if it comes to measurement data, but of course that
has not been decided upon. 

> Cheers
> 
> Richard
> 
> 
> 
> --
> Dr Richard Adams
> Senior Software Developer,
> Computational Systems Biology Group,
> University of Edinburgh
> Tel: 0131 650 8281/8285
> email : ric...@ed...
> 
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> 
> -----------------------------------------------------------------------
> -------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Miase-discuss mailing list
> Mia...@li...
> https://lists.sourceforge.net/lists/listinfo/miase-discuss