Forums

Hi Sarah,


Sarah Keating wrote:
> Dear libSBML-users
>
> Once again we are asking your opinions on how we (libSBML) tackle an
> issue :-)
>
> SBML L2V2 introduced the restriction that within an annotation element
> there cannot be more than one top-level element using the same
> namespace. Prior to L2V2 it was valid and thus there are L2V1 models
> that do this.
>
> LibSBML-3 allows conversion of these models to later levels/versions and
> merely reproduces the annotation. Thus creating invalid models.
> LibSBML-4 introduces the "strict" conversion flag that allows a user to
> specify that conversion should not take place if either the source or
> the target model is invalid. A number have people have raised the issue
> that they would like to have even more control over conversion involving
> annotations with multiple top level elements in the same namespace;
> since the "mathematical" model can easily be converted and it is only
> the presence of the annotations that invalidates the SBML. So it would
> seem we need an additional flag that allows the user to indicate that
> conversion should happen and that something should be done to stop the
> resulting annotations being invalid.
>
> There are a number of options for what libSBML could do with the
> annotations :
>
> 1) strip the offending annotations - so the first use of a namespace
> remains but subsequent elements are deleted
>
>
I think this is very arbitrary and will probably lead to useless,
annotations that will probably mean trouble for applications that read
this particular annotation.

> 2) strip all annotations regardless
>
>
Do you mean "strip all annotations from that namespace"? If so, I think
that is the best solution.


> 3) try and adjust the annotations so that elements from multiple
> namespaces get bundled into a single element within that namespace
> for example create a XXX:root namespace and put all the XXX
> annotations into this element.
>
Again, I think this is not a good idea since root is probably not a
valid element in that namespace and this will probably cause trouble for
applications that try to validate elements from that namespace.
Maybe it would be possible to create a new element in the sbml namespace
lets call it "badAnnotations" and put all those annotations in there.

> This is our dilemma. One of the "prime directives" of libSBML has always
> been - We will round trip your annotations without interference. Since
> all of the alternatives involve violating this we would like your
> opinions on the options. We particularly want opinions from people who
> use annotations to store their own information.
>
>
I think this specific problem does not touch the layout or the render
annotation since they only have one top level element per namespace and
per annotation.

Cheers

Ralph


> Thank you for your time !
>
> Sarah, Akiya & Mike
> ____________________________________________________________
> To manage your libsbml-development list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>
> For a web interface to the libsbml-development mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the libsbml-development list,
> contact sbml-team@caltech.edu
>
>
>

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu