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

[Dagmar K. <da...@eb...>]

Richard Adams wrote:
>>>       2. Most if not all top-level elements have an 'id' attribute,
>>> would it make sense to put the 'id' field in SEDBase?
>>>
>>>       
>> 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? 

In my opinion it should not and so far it does not have one ... But 
people might have a different opinion? Does anyone see a need to have an 
id for the curves?

> 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
>
>
>   Or, if a complex inheritance hierarchy is preferred to be avoided,  
> then an 'Annotation' class  could be defined which is composed into  
> the top level elements, and a base class just has an ID.
>   

Hmm, I would keep the ids where they are as there are (up to now) quite 
a few elements without id... unless another identifiableSedBase class 
would make life far easier for you!?

>>>          3) Could a model file be optionally  embedded in a sedml file?
>>>
>>>       
>> For the moment, no. And  I would really like to avoid that. But if
>> people want to do that they could wrap some additional XML element
>> around a model and a sed-ml file... :-)
>>
>>     
>>>    This gets round the need to keep sedml independent of sbml, also a
>>> single file gets round the file coordination issue,  but it raises new
>>> problems of keeping in synch possibly multiple copies of a model. But
>>> for non-curated models that must be an issue anyway?
>>>
>>>       
>   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. 

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 ;-)

(Of course, users can always use their personal/internal model base, but 
for those who use official ones, it should be guaranteed that 
everybody's really talking about the same model.)

> Re Frank's comments about a C/C++ library and ported versions being  
> the ideal, I can't disagree with that based on the success of libsbml,  
> but  I do think there is room for a native Java implementation as well  
> -   the Java bioinformatics community is quite large and just looking  
> at the sbml interopperability forum there are a lot of questions about  
> linking in the Java bindings. Just being able to drop a jar into your  
> classpath would be quite handy for a lot of Java apps especially as  
> often incorporating libsbml causes portability problems for what were  
> previously  completley Xplatform apps.
>   

Agree.

> 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?
>   

Can't imagine size will be a problem... but there are other things 
around today that have not been foreseen a couple of years ago ;-)

Cheers,
Dagmar