sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss

[SED-ML-discuss] global id attributes

[Richard A. <ric...@ed...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[SED-ML-discuss] Announcing libKiSAO

[Anna Z. <zhu...@eb...>]

Dear KiSAO/SED-ML users,

We would like to announce libKiSAO -- a new Java library for querying 
Kinetic Simulation Algorithm Ontology (KiSAO 
http://www.biomodels.net/kisao) from within your Java programs. It 
supports new, recently redesigned, OWL version of KiSA Ontology 
(http://www.biomodels.net/kisao/#kisao2.0) and provides easy methods for 
retrieving information about simulation algorithms, their 
characteristics, parameters and interrelationships, stored in KiSAO.

With libKiSAO you can:

    * Get a collection of simulation algorithms stored in KiSAO.          

      |            Collection<IRI> algorithms = kisaoQuery.getAllAlgorithms();|

    * Get descendants and ancestors of a given simulation algorithm.

      |            boolean directOnly = true;
                  Collection<IRI> descendants = kisaoQuery.getDescendants(algorithmIRI, directOnly);|

    * Find a simulation algorithm by its name, synonym, MIRIAM urn or id.

      |            IRI iriByName = kisaoQuery.getIRIByName("tau-leaping method");
                  IRI iriByMiriamUrn = kisaoQuery.getIRIbyURN("urn:miriam:biomodels.kisao:KISAO_0000039");|

    * Get information about a simulation algorithm.         

      |            String name = kisaoQuery.getName(algorithmIRI);
                  Collection<String> synonyms = kisaoQuery.getAllSynonyms(algorithmIRI);
                  String definition = kisaoQuery.getDefinition(algorithmIRI);
      |

    * Get characteristics and parameters, used by a given simulation
      algorithm.          

      |            boolean hasCharacteristic = true;
                  Collection<String> algorithmCharacteristics = kisaoQuery.getCharacteristics(algorithmIRI, hasCharacteristic);
                  Collection<String> algorithmParameters = kisaoQuery.getParameters(algorithmIRI);|

    * Get algorithms with the specified characteristics (e.g. discrete
      stochastic).          

      |            boolean hasCharacteristic = true;
                  Collection<IRI> discreteStochasticAlgorithms = kisaoQuery.getAlgorithmsByCharacteristic(hasCharacteristic,
                  	KiSAOIRI.DISCRETE_VARIABLE_CHARACTERISTIC_IRI, KiSAOIRI.STOCHASTIC_SYSTEM_BEHAVIOUR_CHARACTERISTIC_IRI);|

    * And much more...

libKiSAO 1.0.1 release candidate version can be *downloaded* from 
SourceForge 
(https://sourceforge.net/projects/kisao/files/libKiSAO-1.0.1-rc1.zip/download).

More information and examples are available on the libKiSAO web page 
(http://www.biomodels.net/kisao/libkisao.html).

Any feedback, use cases, feature requests, questions, bugs or 
suggestions are very welcome.

Thank you for your attention and co-operation,

Sincerely,

Anna Zhukova

BioModels.net Team

Re: [SED-ML-discuss] KiSAO: algorithm parameter survey

[Anna Z. <zhu...@eb...>]

Dear KiSAO/SED-ML users,

This is a reminder, that the KiSAO parameter survey closes next Tuesday, 
31st May.

https://www.surveymonkey.com/s/kisao_parameters 
<https://www.surveymonkey.com/s/kisao_parameters>

Thank you for your continued co-operation and support,

Sincerely,

BioModels.net Team

Anna Zhukova wrote:
> Dear KiSAO/SED-ML users,
>
> As many of you are aware, the current implementation of the Kinetic 
> Simulation Algorithm Ontology (KiSAO http://www.biomodels.net/kisao) 
> in OBO format is rather restrictive. For example, the multiple 
> inheritance  means that many algorithms occupy more than one position 
> in the ontology, and often appear at different levels in the various 
> component branches. An example of this would be the 
> 'Bortz-Kalos-Liebowitz method', which possesses the characteristics 
> 'discrete variables', 'progression with adaptive time steps', 
> 'non-spatial description' and 'stochastic system behaviour', and hence 
> appears in all four branches. This is in fact true of virtually all 
> the methods in the ontology.
>
> In our efforts to improve both the hierarchical arrangements of KiSAO 
> terms, as well as make it more useful to the community from a 
> reasoning standpoint, we are currently in the process of 
> re-implementing KiSAO in OWL. This much richer language allows us to 
> create a separate branch of algorithm characteristics ('progression 
> with adaptive time steps', etc.), and subsequently link the algorithms 
> to the characteristics using the 'hasProperty' relationship. This work 
> is well under way.
>
> In addition, we plan to incorporate, for each KiSAO method, 
> information regarding the parameters that can be used in the 
> simulation experiment settings. We would like to engage the community 
> at this stage, and have created a survey to address the subject. It 
> should take very little time to complete, as is it mostly composed of 
> check boxes. It addresses the main points below:
>
> * For the list of parameters we plan to include, are there any that 
> you would like to suggest?
> * Of the list of parameters on the survey page, do you think they are 
> appropriately named, or are there more suitable names you have in mind?
> * Do you know of any algorithms that you would like to see 
> incorporated (associated references appreciated)?
>
> The survey can be found here:
>
> https://www.surveymonkey.com/s/kisao_parameters
>
> The deadline for submitting responses to this survey is 31st May, 
> 2011, after which we will notify you of the results.
>
> Thank you for your continued co-operation and support,
>
> Sincerely,
>
> BioModels.net Team
>

Re: [SED-ML-discuss] A SED-ML visualizer/editor tool

[Robert P. <rp...@in...>]

Richard,

Did a Windows install and tried to load a file from the examples folder. Got
this exception:

java.lang.ClassCastException: org.eclipse.ui.ide.FileStoreEditorInput cannot
be cast to org.eclipse.ui.IFileEditorInput

Probably I just did something wrong during install, but I would like to look
at your tool. Any ideas?

Thanks.

Robert

On Tue, May 24, 2011 at 11:41 AM, Richard Adams <ric...@ed...>wrote:

> Dear SED-MLers,
>   I'd like to bring to your attention a new tool for editing, viewing and
> running SED-ML files - the SED-ED editor.   The main aims of the app are to
>   make it easier to view and understand the contents of SED-ML documents,
> to provide a UI for validation support, to help  with the generation of
>  XPath expressions accurately, and to provide tooling to support the
> proposed Sedx archive format.
>
>   Features include:
>
>    -  Create   new SED-ML files  from scratch.
>    -  Edit existing SED-ML files  using a graphical/form based editor.
>    -  Auto-generation of XPath expressions to identify selected elements
> and attributes in your model.
>    -  Previews of model changes.
>    -  Model agnostic, at least for editing (simulating  is SBML only ).
>    -  Create, edit, view and expand sedx archive files.
>    -  Graphical layout of SED-ML components (  including autolayout, align,
> zoom).
>    -  SED-ML validation and display of errors/warnings.
>
> Example SED-ML files and sedx archives  are included in the download to
> help you get started.
>
>
> This is an early, alpha release of the editor, which we've tested and
> believe to work on at least the example models, but we'd really appreciate
> any feedback on missing features / bugs to make the application more robust
> at an early stage.
>
> The download instructions and a screenshot are below, for those interested.
>
>  Thanks for your attention,
>
>  Best wishes
>
>      Richard
>
> Availability:
>
> The SED-ED editor is available in three forms:
> 1) As a standalone application for Windows/Mac/Linux, accessible from
> https://sourceforge.net/projects/jlibsedml/files/
>      To get started:
> 1.  Download, unzip, double-click the launch icon in the unzipped folder
> 2. When the application starts, click Window->Help to open the Help pages
> which tell you  how  to use the application and work with the included
> examples.
>
> 2) As a plugin for the SBSIVisual workbench. This has the same editing
> functionality as the standalone app but also enables simulation of  least
> ODE based SBML models, defined in SEDML. To get started:
> 1. Download and extract SBSIVisual from
> http://sourceforge.net/projects/sbsi/
> 2. Follow the instructions in the README file to launch the app for your
> platform.
> 3.  To install the SED-ED plugin,  go to Help->Install New Software, and in
> the ensuing dialog choose the 'Public SBSI' from the 'Work with'  drop down
> list.
> 4. In the list of plugins, select  the 'SEDML tools' and follow the prompts
> to install the plugin.
> 5. Once the plugin is installed you can create a new Project (
> File->New->SBSI system) and drag the examples folder into the new project.
> 6. The SED-ED help pages can be accessed from Window->Help. The example
> files will be put in your application folder.
>
> 3) As an Eclipse plugin. This is essentially the same installation as  2),
> step 3 onwards,  except you'll need to manually add the update site URL
> http://www.sbsi.ed.ac.uk/update in step 3. The example files will be put
> into the top-level folder of your Eclipse install.
>
>
>
>
>
>
>
>
>
>
> Dr Richard Adams
> Software Development Team Leader,
> Centre For Systems Biology Edinburgh
> University of Edinburgh
> Tel: 0131 651 9019
> email : ric...@ed...
> Web: http://csbe.bio.ed.ac.uk/adams.php
>
>
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>


-- 
Robert D Phair PhD  |  Chief Scientific Officer  |  Integrative
Bioinformatics Inc
Los Altos, CA
www.integrativebioinformatics.com

ProcessDB: Modeling for Biological Discovery

[SED-ML-discuss] A SED-ML visualizer/editor tool

[Richard A. <ric...@ed...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [SED-ML-discuss] [sed-ml-editors] New editors

[Mike H. <mh...@ca...>]

On Mon, 23 May 2011 15:09:19 +0200, Dagmar Waltemath wrote:
>>> 
>>> We should probably create a page on sed-ml.org, similar to:
>>> http://sbml.org/SBML.org:About
>>> http://www.sbgn.org/About
>>> to present the editors and their mission.
>> 
>> That sounds like an excellent idea
> 
> I'll contact Mike and ask whether we can re-use his page layout.

Sure, that's fine, if the SBGN leaders do not mind that the look and feel ends up being copied by another effort. 

It will take a little bit of customization for someone to set up for a new effort, for example to change the header graphics, but it shouldn't be too difficult or time consuming.  More difficult, however, will be to get a new site running with the same system.  Nicolas Rodriguez has experience copying and reinstalling the sbgn site -- it's not trivial, so I recommend trying to get him to do it.  Thanks to his experience with it, he will be able to do it 10x faster than someone else trying to work through it from scratch.

MH

[SED-ML-discuss] election of SED-ML editors

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

Dear Colleagues,

The vote for the election of SED-ML editors is now closed. 17 people 
expressed their opinion. You can see the results on the attached chart.

We had five candidates, and five positions. Therefore this vote determines 
the length of the initial term, allowing a gradual replacement in the 
future. Because of the timing of elections, and the need for stability in 
the initial period of SED-ML implementation, the year 2011 is not counted 
in the count-down. All the editors will officially start on June 1st, but 
the first "year" will last 19 months, until December 2012.

Andrew Miller will step-down on 31st December 2012
Richard Adams will step-down on 31st December 2013
David Nickerson will step-down on 31st December 2013
Frank Bergmann will step-down on 31st December 2014
Dagmar Waltemath will step-down on 31st December 2014

Thank-you all for your participation.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] [sbml-discuss] encoding a maximum function for t<=t0

[Frank T. B. <fbe...@ca...>]

> 
> But, why do-we contruct our own aggregated symbols. Could-we used the
> MathML recommended method:
> http://www.w3.org/TR/MathML3/chapter4.html#contm.nary.unary
> 

SedML 1.1 uses MathML 2.0 so this url would change slightly to: 

http://www.w3.org/TR/MathML2/chapter4.html#contm.maxmin

The main reason for not allowing that syntax is because we don't have a set
description in SED-ML. While we could easily accommodate the form: 

<apply>
  <max/>
  <ci> a </ci>
  <ci> b </ci>
</apply>

We would have no way of allowing this one: 

<apply>
  <max/>
  <bvar><ci>x</ci></bvar>
  <condition>
    <apply><and/>
      <apply><in/><ci>x</ci><ci type="set">B</ci></apply>
      <apply><notin/><ci>x</ci><ci type="set">C</ci></apply>
    </apply>
  </condition>
  <ci>x</ci>
</apply>

So while we would 'claim' that we were using the MathML max symbol, we would
actually only implement a tiny subset of its scope. Rather than doing that
we decided to use our own csymbol, this will make it easier for people to
adopt and we will see it in software sooner. 

Cheers
Frank

Re: [SED-ML-discuss] [sbml-discuss] encoding a maximum function for t<=t0

[Richard A. <ric...@ed...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [SED-ML-discuss] [sbml-discuss] encoding a maximum function for t<=t0

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

On 18/05/11 16:08, Richard Adams wrote:
> Nicolas,
>
> Are the max / min functions in section 2.2.1.3 of the SED-ML spec not what
> you mean?
> All the examples in the MIASE paper can be encoded in SED-ML

Arrgh. I'm an idiot. I did not see them in the list so I jumped to the 
wrong conclusion. From one of the authors of the spec, this is pretty sad 
... Sorry all.

But, why do-we contruct our own aggregated symbols. Could-we used the 
MathML recommended method:
http://www.w3.org/TR/MathML3/chapter4.html#contm.nary.unary

?

> On 18 May 2011, at 15:39, Nicolas Le Novère wrote:
>
>> Hello all,
>>
>> Just to mention that we need the min/max functions in SED-ML as well. I
>> thought it was there but it is not. And as a result SED-ML cannot encode
>> one of the examples present in the MIASE paper ...
>>
>> So I would vote to include min and max to the next version of the core (or
>> in the extended math package, if this is still planned)
>>
>> Cheers
>>
>> On 18/05/11 09:51, sch...@eb... <mailto:sch...@eb...> wrote:
>>> Dear all,
>>>
>>> A model I'm trying to encode is using the function
>>> max*(x,t0) = max(x,t<=t0)
>>> where x is a variable, t the time and t0 the current time.
>>>
>>> Is there a way to encode this in SBML? The most natural way to do it would
>>> be a
>>> xmax = piecewise(x,gt(x,xmax),xmax)
>>> but that is rejected as circular assignment (also when xmax has an initial
>>> value, i.e. the expression itself would be mathematically valid).
>>>
>>> Alternatively, is there a reason this is prohibited entirely instead of
>>> checking whether xmax has an initial value?
>>>
>>> Regards,
>>> Michael
>>>
>>> ____________________________________________________________
>>> To manage your sbml-discuss list subscription, visit
>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>
>>> For a web interface to the sbml-discuss mailing list, visit
>>> http://sbml.org/Forums/
>>>
>>> For questions or feedback about the sbml-discuss list,
>>> contact sbm...@ca... <mailto:sbm...@ca...>
>>
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> developers boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>
> Dr Richard Adams
> Software Development Team Leader,
> Centre For Systems Biology Edinburgh
> University of Edinburgh
> Tel: 0131 651 9019
> email : ric...@ed... <mailto:ric...@ed...>
> Web: http://csbe.bio.ed.ac.uk/adams.php
>
>
>
>
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] [sbml-discuss] encoding a maximum function for t<=t0

[Richard A. <ric...@ed...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [SED-ML-discuss] [sbml-discuss] encoding a maximum function for t<=t0

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

Hello all,

Just to mention that we need the min/max functions in SED-ML as well. I 
thought it was there but it is not. And as a result SED-ML cannot encode 
one of the examples present in the MIASE paper ...

So I would vote to include min and max to the next version of the core (or 
in the extended math package, if this is still planned)

Cheers

On 18/05/11 09:51, sch...@eb... wrote:
> Dear all,
>
> A model I'm trying to encode is using the function
> max*(x,t0) = max(x,t<=t0)
> where x is a variable, t the time and t0 the current time.
>
> Is there a way to encode this in SBML? The most natural way to do it would
> be a
> xmax = piecewise(x,gt(x,xmax),xmax)
> but that is rejected as circular assignment (also when xmax has an initial
> value, i.e. the expression itself would be mathematically valid).
>
> Alternatively, is there a reason this is prohibited entirely instead of
> checking whether xmax has an initial value?
>
> Regards,
> Michael
>
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbm...@ca...


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[SED-ML-discuss] jlibsedml bugfix release

[Richard A. <ric...@ed...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [SED-ML-discuss] KiSAO: removing deprecated classes

[Frank T. B. <fbe...@ca...>]

Hello Anna, 

 

I really approve of the restructuring of KISAO. Since you are asking whether
any of the obsolete classes are currently used, yes they are. In my
implementation libSedML (http://libsedml.sf.net), and applications dependent
on it, a snapshot is included that allows to determine whether a discrete
stochastic trace or a continuous simulation is requested in the
UniformTimeCourseSimulation. 

 

>From the Obo file it was very easy to determine whether any given algorithm
is a child of "algorithm using stochastic rules". In the proposed version of
KISAO it is now necessary to determine that the given algorithm has "'has
property' some 'stochastic system behavior'. This slightly increases the
amount of work to be done. Now tools have to *know* the terms in the
ontology. Before it was sufficient to *know* the parent terms. 

 

Cheers

Frank

 

 

From: Anna Zhukova [mailto:zhu...@eb...] 
Sent: Wednesday, May 11, 2011 8:25 AM
To: sed...@li...
Subject: [SED-ML-discuss] KiSAO: removing deprecated classes

 

Dear KiSAO users, 

As many of you are aware, we are working on re-implementing KiSAO (Kinetic
Simulation Algorithm Ontology http://www.biomodels.net/kisao
<http://www.biomodels.net/kisao> ) in OWL and improving the hierarchical
arrangements of KiSAO terms. For instance, we've created a new branch,
describing algorithm characteristics (such as 'continuous variables',
'spatial description', 'explicit method type', etc.) and replaced the
subsumption-based inheritance in the 'kinetic simulation algorithm' branch
with a 'has property' relationships between algorithms and their
characteristics. For example, 

'Bortz-Kalos-Liebowitz method' 'subClassOf' 'algorithm using adaptive
timesteps'

 axiom was replaced with 



'Bortz-Kalos-Liebowitz method' 'has property' 'progression with adaptive
timesteps'. 

Due to this improvement 'simulation algorithm' branch subclassing is now
based only on types of algorithms and their derivation (where one algorithm
is derived from another pre-existing one) and we got rid of multiple
inheritance. 

The classes, describing algorithm subsumptions in the old KiSAO, thereby
became useless: 

*	'algorithm using adaptive timesteps' (KISAO_0000041),  
*	'algorithm using fixed timesteps' (KISAO_0000037), 

*	'algorithm using continuous variables' (KISAO_0000018), 
*	'algorithm using discrete variables' (KISAO_0000016), 

*	'algorithm using non-spatial description' (KISAO_0000026),  
*	'algorithm using spatial description' (KISAO_0000023), 

*	'algorithm using stochastic rules' (KISAO_0000036),  
*	'algorithm using deterministic rules' (KISAO_0000035), 

*	'explicit tau-leaping method' (KISAO_0000039), 
*	'implicit tau-leaping method' (KISAO_0000083), 
*	'non-spatial tau-leaping method' (KISAO_0000002), 

*	'Non-spatial Gillespie-like method' (KISAO_0000042), 
*	'Gillespie-like approximate stochastic simulation method'
(KISAO_0000001), 
*	'Gillespie-like exact stochastic simulation method' (KISAO_0000096).

We've deprecated them, but they are still visible in Protege and similar
tools. To make the ontology structure even more clear we would like to
completely remove these obsolete classes, if no one has references to them
so far.

So, please, if you are using/ referring to one of these obsolete classes,
let us know till Wednesday, 18 May 2011, otherwise we'll remove them from
the new version of KiSAO.

Thank you for your co-operation and support, 

Sincerely, 

BioModels.net Team 

Re: [SED-ML-discuss] Proposal by Frank on nested simulations

[Frank T. B. <fbe...@ca...>]

> I have a few comments on the proposal; some of them also apply to other
parts
> of the current version of SED-ML; however, I think that this is an
opportunity to
> resolve some of the more general issues, so I am reiterating them as they
> come up in the proposal.
> 

Hello Andrew, first of all thank you very much for the feedback on the
proposal. Let me reply in turn:

>    1) As I have previously noted for SED-ML 'Change' features, I don't
think the
> choice of XPath as a way of describing variables is a good one, simply
because
> it only works for languages where it is possible to reference every
variable with
> XPath (this doesn't work for CellML 1.1 with imports, and it certainly
won't
> work for any non-XML based languages; suggesting that representation
> languages change to accommodate SED-ML doesn't seem like a good approach
> either). If SED-ML is truly going to be model representation language
neutral, I
> would suggest that the exact mechanism for referencing variables be model
> representation language specific, and that this functionality be
referenced
> everywhere that a variable needs to be targeted.

SED-ML L1V1 currently targets languages that can be expressed in XML. And
for all those languages the change features do work. I'm fairly certain any
CellML model using imports can also be expressed as a model that does not
use imports. So I don't think the nested proposal introduced any new
artifact. 

The advantage to the pre-processing instructions for SED-ML we currently
have, is that they can be applied without explicit knowledge of that
language. For example the libSedML (http://libsedml.sf.net) library can
apply pre-processing to CellML models without having to have knowledge about
it. 

>    2) The concept of 'steady state' without any parameters does not seem
> realistic for solvers that do purely numerical processing of the model;
finding a
> definitive steady state requires analytic treatment of the model; at the
very
> least, there needs to be some kind of description of the algorithm for
> determining when an acceptable approximation of steady state has been
> reached, along with the parameters of that algorithm.

The steadyState task as described in the experiment and implemented in
libSedML can be easily used for numerical processing, with libraries such as
KinSolve or NLEQ. I agree that there should be more description about the
method, and that is food for KISAO. Any parameter for that solver should not
differ from parameters needed to satisfy integrators or stochastic solvers. 

>    3) "then the models time parameter is changed". In some representation
> languages (CellML included) variables like time can be defined to
anything; I
> suggest at least writing:
>    "then the model's time^1 parameter is changed.
>    Footnote 1: In this document, time refers to the bound variable over
which
> numerical integration can be performed".
>   However, I don't fully understand what it means to change a bound
variable
> outside of the numerical integration over which it is bound. Do you mean
the
> bottom of the range over which integration occurs ("starting time")?

Please remember that this proposal was made before the SED-ML L1V1 spec was
finalized. Now that we have a way to reference even implicit variables such
as SBML's time symbol by using a URN this is no longer an issue. SetValue
can be applied to that time symbol just as well as any explicit variable in
CellML. 

>    4) I think the name and semantics of OneStep are potentially confusing,
> because there are two possible interpretations: 'one step' of a parameter
scan,
> and 'one step' of the underlying solver algorithm. The specification says
"one
> integration step of the integrator", but that is not what is most useful
here.
> Numerical integrator algorithms that are useful for stiff problems have
> dynamic step sizes, but performing a step with a dynamic step size is
practically
> useless for a parameter scan.

Certainly, I would be happy to rephrase it as 'a simulation until the next
output step'. I'm perfectly fine with solvers using an adaptive step size
internally. All that was meant was that after calling: 

oneStep(currentTime, 0.05)

the model is at the state currentTime + 0.05, and the datagenerators are
able to collect variables for that state. 


>    5) The two 'integration task primitives' need a set of parameters that
depend
> on the KiSAO algorithm selected; I think a mechanism for algorithm
specific
> parameters dependent on the KiSAO ID is required.
> 

That is why I made the primitives inherit from the Simulation class. Here
they can get all the benefits from additional parameterization via KISAO or
tool specific annotations. 

> Additionally, filter primitives could be available:
>    a) All points are added to the vector of outputs.
>    b) Points are added to the vector, with a minimum spacing between
points.
>    c) Only the final point is added to the vector of outputs.
> 

I agree, I hope this is something we can cover in the next version (or level
if that is what the community decides) of SED-ML. It would be sufficient to
be able to reference results from previous simulation tasks along with
external data. I wanted the proposal to be as simple as possible, so that it
can extend SED-ML to a larger variety of simulation experiments. 

> I think that the specification should explicitly say that multiple
primitives are
> allowed in the 'task slot', and that they should be performed
sequentially.
> 

I would be fine with that extension. Though we might have to allow for an
additional order attribute, as many people do not want the order imposed by
the XML file. 

> For ranges, I'd suggest the ability to define a bound variable and use
that as a
> parameter to algorithms or some other parameter.
> 

That is one possibility ... consistent with the current SED-ML version would
also be a specific URN that refers to a nested tasks range value. 

Again thank you for the feedback ... I'll be sure to update the proposal
soon and post some examples. 

Best
Frank

[SED-ML-discuss] KiSAO: removing deprecated classes

[Anna Z. <zhu...@eb...>]

Dear KiSAO users,

As many of you are aware, we are working on re-implementing KiSAO 
(Kinetic Simulation Algorithm Ontologyhttp://www.biomodels.net/kisao) in 
OWL and improving the hierarchical arrangements of KiSAO terms. For 
instance, we've created a new branch, describing algorithm 
characteristics (such as 'continuous variables', 'spatial description', 
'explicit method type', etc.) and replaced the subsumption-based 
inheritance in the 'kinetic simulation algorithm' branch with a 'has 
property' relationships between algorithms and their characteristics. 
For example,

'Bortz-Kalos-Liebowitz method' 'subClassOf' 'algorithm using adaptive timesteps'

  axiom was replaced with

'Bortz-Kalos-Liebowitz method' 'has property' 'progression with adaptive timesteps'.

Due to this improvement 'simulation algorithm' branch subclassing is now 
based only on types of algorithms and their derivation (where one 
algorithm is derived from another pre-existing one) and we got rid of 
multiple inheritance.

The classes, describing algorithm subsumptions in the old KiSAO, thereby 
became useless:

    * 'algorithm using adaptive timesteps' (KISAO_0000041),
    * 'algorithm using fixed timesteps' (KISAO_0000037),

    * 'algorithm using continuous variables' (KISAO_0000018),
    * 'algorithm using discrete variables' (KISAO_0000016),

    * 'algorithm using non-spatial description' (KISAO_0000026),
    * 'algorithm using spatial description' (KISAO_0000023),

    * 'algorithm using stochastic rules' (KISAO_0000036),
    * 'algorithm using deterministic rules' (KISAO_0000035),

    * 'explicit tau-leaping method' (KISAO_0000039),
    * 'implicit tau-leaping method' (KISAO_0000083),
    * 'non-spatial tau-leaping method' (KISAO_0000002),

    * 'Non-spatial Gillespie-like method' (KISAO_0000042),
    * 'Gillespie-like approximate stochastic simulation method'
      (KISAO_0000001),
    * 'Gillespie-like exact stochastic simulation method' (KISAO_0000096).

We've deprecated them, but they are still visible in Protege and similar 
tools. To make the ontology structure even more clear we would like to 
completely remove these obsolete classes, if no one has references to 
them so far.

So, please, if you are using/ referring to one of these obsolete 
classes, let us know till Wednesday, 18 May 2011, otherwise we'll remove 
them from the new version of KiSAO.

Thank you for your co-operation and support,

Sincerely,

BioModels.net Team

Re: [SED-ML-discuss] KiSAO: algorithm parameter survey

[Anna Z. <zhu...@eb...>]

Dear KiSAO/SED-ML users,

We would like to remind you that the KiSAO (Kinetic Simulation Algorithm 
Ontology) survey is still open:

https://www.surveymonkey.com/s/kisao_parameters 
<https://www.surveymonkey.com/s/kisao_parameters>

We would welcome your invaluable contributions in shaping its further 
development.
Thank you for your continued co-operation and support,

Sincerely,

BioModels.net Team

On 08/04/11 13:44, Anna Zhukova wrote:
> Dear KiSAO/SED-ML users,
>
> As many of you are aware, the current implementation of the Kinetic 
> Simulation Algorithm Ontology (KiSAO http://www.biomodels.net/kisao) 
> in OBO format is rather restrictive. For example, the multiple 
> inheritance  means that many algorithms occupy more than one position 
> in the ontology, and often appear at different levels in the various 
> component branches. An example of this would be the 
> 'Bortz-Kalos-Liebowitz method', which possesses the characteristics 
> 'discrete variables', 'progression with adaptive time steps', 
> 'non-spatial description' and 'stochastic system behaviour', and hence 
> appears in all four branches. This is in fact true of virtually all 
> the methods in the ontology.
>
> In our efforts to improve both the hierarchical arrangements of KiSAO 
> terms, as well as make it more useful to the community from a 
> reasoning standpoint, we are currently in the process of 
> re-implementing KiSAO in OWL. This much richer language allows us to 
> create a separate branch of algorithm characteristics ('progression 
> with adaptive time steps', etc.), and subsequently link the algorithms 
> to the characteristics using the 'hasProperty' relationship. This work 
> is well under way.
>
> In addition, we plan to incorporate, for each KiSAO method, 
> information regarding the parameters that can be used in the 
> simulation experiment settings. We would like to engage the community 
> at this stage, and have created a survey to address the subject. It 
> should take very little time to complete, as is it mostly composed of 
> check boxes. It addresses the main points below:
>
> * For the list of parameters we plan to include, are there any that 
> you would like to suggest?
> * Of the list of parameters on the survey page, do you think they are 
> appropriately named, or are there more suitable names you have in mind?
> * Do you know of any algorithms that you would like to see 
> incorporated (associated references appreciated)?
>
> The survey can be found here:
>
> https://www.surveymonkey.com/s/kisao_parameters
>
> The deadline for submitting responses to this survey is 31st May, 
> 2011, after which we will notify you of the results.
>
> Thank you for your continued co-operation and support,
>
> Sincerely,
>
> BioModels.net Team
>

[SED-ML-discuss] Election of SED-ML editors

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

Dear Colleagues

The community has recently been asked who could be potential SED-ML 
editors. Five people have been nominated, which have all accepted. Since we 
are electing five editors, the purpose of this consultation is not to 
decide who will be editors. However, the votes will be used to establish 
the order in which the editors will step down.

You can now vote for your favorite candidates. You can vote for up to three 
candidates. Voting for yourself, if you are one of the nominees, is 
perfectly fine. The vote will be closed on Friday 20th May at 17:00 UTC.

In order to avoid multiple votes, the vote is authenticated and you have to 
provide your name and e-mail address. However, this information will not be 
made public, and will not be available to the current editors, except 
Nicolas Le Novere, who is not candidate.

Please vote at:
https://www.surveymonkey.com/s/CB7W5HY

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] KISAO

[Anna Z. <zhu...@eb...>]

>>         1. classes
>>         a. move deprecated classes into another 'development' ontology document so
>>         they don't show up in the release version
>         These (now deprecated) classes were used in the 1.0 version of
>         KiSAO, so in KiSAO 2.0 we marked them deprecated (instead of
>         removing) in case someone already had references to them. I'd
>         say it's more a problem of an appropriate ontology browser. In
>         OBO-Edit these deprecated (obsolete for OBO) classes are not
>         shown in the main hierarchy tree, but in a special 'Obsolete'
>         branch, which can be folded up. If there is an option to hide
>         deprecated classes in Protege (I've sent them such a feature
>         request
>         <https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3160&start=0>),
>         then the problem will be solved, won't it?
>
>
>     hmm - i haven't checked, but do the classes appear in the
>     bioportal version too?
>

No, obsolete classes do not appear in the Bioportal.

>>         b. 'isHybridOf' - more generally - 'is variant of'
>         Can you please explain what 'is variant of' will mean?
>         Now I don't see the difference between 'is variant of' and
>         inheritance:  LSODAR and LSODES are variants of Livermore Solver.
>
>
>
>     in strict inheritance, it is the case that the child inherits all
>     attributes of the parent.
>
>     'is variant of' indicates that there is a similarity and
>     difference among the entities that is rooted in one or more
>     attributes.
>
>         The idea of 'isHybridOf' relation was to show that some
>         algorithm is a combination of several other ones: "the whole
>         system is subdivided into appropriate parts and different
>         simulation methods operate on these parts at the same time."
>         Example of hybrid algorithm is Pahle's method (used in
>         COPASI). It combines the stochastic Gibson-Bruck's next
>         reaction method with different algorithms for the numerical
>         integration of ODEs. "The biochemical network is dynamically
>         partitioned into a deterministic and a stochastic subnet
>         depending on the current particle numbers in the system. The
>         stochastic subnet contains reactions involving low numbered
>         species as substrate or product. All the other reactions form
>         the deterministic subnet. The two subnets are then simulated
>         in parallel using the stochastic and deterministic solver,
>         respectively."
>
>
>     right, so 'is hybrid of' considers two things : i) variation in
>     that there is similarity and differences from another entity and
>     ii) causality - that portions of that entity have led to this one.
>     in SIO, this would be a subproperty of 'is variant of' and 'is
>     causally related from'
>

Thanks, I get it.

>>         a. given that you're starting to develop a hierarchy of datatypes, you
>>         should**strongly**  consider converting all of your datatypes into classes
>>         with restrictions on the kind of value that hold e.g. 'relative tolerance'
>>         (using manchester owl syntax)
>>
>>         'relative tolerance'
>>           subClassOf
>>           'quantity'
>>           and 'has value' some decimal
>>           and 'has value' only decimal
>>
>>         If there are other aspects that differentiate a 'relative tolerance' from
>>         'tolerance', then now you can formalize it with other axioms.
>         Just to be sure we talk about the same things: you call them
>         datatypes, but they are not datatypes, but datatype properties
>         (linking individuals to data values).
>
>     yes
>
>         I agree the way of representing parameters which you propose
>         is more flexible if we decide to add axioms describing aspects
>         other than domain (simulation algorithms that uses the
>         parameter)  and range. But it will entail the problem with the
>         OBO version of KiSAO. Now we convert the OWL datatype
>         properties to OBO relations (and keep information about
>         domains and ranges), for example:
>
>         [Typedef]
>         id: KISAO:0000228
>         name: tau-leaping epsilon
>         domain: KISAO:0000039 ! tau-leaping method
>         range: xsd:decimal
>
>         But if we do as you propose: replace datatype properties with
>         owl classes, their domains with axioms containing object
>         property 'is used in', such as:
>
>         'tau-leaping epsilon'
>         subClassOf
>         ('is used in' some 'tau-leaping method')
>
>         and replace ranges with axioms containing datatype property
>         'has value':
>
>         'tau-leaping epsilon'
>           subClassOf
>         ('has value' some xsd:decimal
>           and 'has value' only xsd:decimal)
>
>         then axioms containing 'is used in' object property can be
>         easily converted to OBO:
>
>         relationship: 'is used in' 'tau-leaping method'
>
>         but it's not possible (is it?) to convert axioms containing
>         _datatype_ property 'has value', because there's no OBO term
>         for 'xsd:decimal':
>
>         relationship: KISAO:0000259 xsd:decimal   ! --<-- this is not possible as xsd:decimal is not a term
>
>         while for the range tag not only terms, but also XML-Schema
>         primitives can be used in OBO:
>
>         range: xsd:decimal
>
>         Do you, probably, see a better solution for OBO?
>
>
>     OBO is looking more and more like OWL, but without all the
>     necessary semantics nor analysis required to support the
>     constructs in the language (consider that OBO 1.4 allows one to
>     place restrictions on transitive properties - good luck with this
>     in practice).
>
>      My advice is to go with a language for formal knowledge
>     representation that was designed as such from the beginning, and
>     is an essential part of the Semantic Web effort.
>
>
> I discussed the issue with Chris Mungall - we both wonder why you need 
> compatibility with OBO at this point?

The idea was to try to have the both versions of ontology, containing 
all the information, if it is possible. But you are right, it's becoming 
unjustified. Thanks for pointing it out.  We'll convert the algorithm 
parameters to owl classes.

-- 
Anna Zhukova
Intern, Computational Systems Neurobiology Group,
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton, Cambridge
CB10 1SD, United Kingdom

Re: [SED-ML-discuss] KISAO

[Michel D. <mic...@gm...>]

On Tue, Apr 26, 2011 at 1:50 PM, Michel Dumontier <
mic...@gm...> wrote:

>
>
> On Tue, Apr 26, 2011 at 9:12 AM, Anna Zhukova <zhu...@eb...> wrote:
>
>>  Dear Michel,
>>
>> Thanks for your suggestion for KiSAO.
>> I'd like to discuss some of them.
>>
>>  1. classes
>> a. move deprecated classes into another 'development' ontology document so
>> they don't show up in the release version
>>
>>  These (now deprecated) classes were used in the 1.0 version of KiSAO, so
>> in KiSAO 2.0 we marked them deprecated (instead of removing) in case someone
>> already had references to them. I'd say it's more a problem of an
>> appropriate ontology browser. In OBO-Edit these deprecated (obsolete for
>> OBO) classes are not shown in the main hierarchy tree, but in a special
>> 'Obsolete' branch, which can be folded up. If there is an option to hide
>> deprecated classes in Protege (I've sent them such a feature request<https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3160&start=0>),
>> then the problem will be solved, won't it?
>>
>>
> hmm - i haven't checked, but do the classes appear in the bioportal version
> too?
>
>  b. added disjointness among classes (this helps support reasoning on negated
>> existential axioms)
>> c. LSODA variants not axiomatically differentiated
>>
>>  Thanks, we'll do it.
>>
>>  2. object properties
>> a. deprecate 'lacksProperty', as you can create negated existential axioms
>>
>>  The 'lacksProperty' was added for OWL to OBO conversion: it is not
>> possible to represent negation in OBO, so we use ('lacksProperty'  ?X)
>> instead of (not 'hasProperty' ?X) in OBO version of KiSAO. So
>> 'lacksProperty' is necessary for an OBO version of KiSAO. But you are right,
>> we should deprecate it in the OWL version. Thanks.
>>
>>  b. 'isHybridOf' - more generally - 'is variant of'
>>
>>  Can you please explain what 'is variant of' will mean?
>> Now I don't see the difference between 'is variant of' and inheritance:
>> LSODAR and LSODES are variants of Livermore Solver.
>>
>
> in strict inheritance, it is the case that the child inherits all
> attributes of the parent.
>
> 'is variant of' indicates that there is a similarity and difference among
> the entities that is rooted in one or more attributes.
>
>
>>  The idea of 'isHybridOf' relation was to show that some algorithm is a
>> combination of several other ones: "the whole system is subdivided into
>> appropriate parts and different simulation methods operate on these parts at
>> the same time." Example of hybrid algorithm is Pahle's method (used in
>> COPASI). It combines the stochastic Gibson-Bruck's next reaction method with
>> different algorithms for the numerical integration of ODEs. "The biochemical
>> network is dynamically partitioned into a deterministic and a stochastic
>> subnet depending on the current particle numbers in the system. The
>> stochastic subnet contains reactions involving low numbered species as
>> substrate or product. All the other reactions form the deterministic subnet.
>> The two subnets are then simulated in parallel using the stochastic and
>> deterministic solver, respectively."
>>
>>
> right, so 'is hybrid of' considers two things : i) variation in that there
> is similarity and differences from another entity and ii) causality - that
> portions of that entity have led to this one. in SIO, this would be a
> subproperty of 'is variant of' and 'is causally related from'
>
> a. given that you're starting to develop a hierarchy of datatypes, you
>> should **strongly** consider converting all of your datatypes into classes
>> with restrictions on the kind of value that hold e.g. 'relative tolerance'
>> (using manchester owl syntax)
>>
>> 'relative tolerance'
>>  subClassOf
>>  'quantity'
>>  and 'has value' some decimal
>>  and 'has value' only decimal
>>
>> If there are other aspects that differentiate a 'relative tolerance' from
>> 'tolerance', then now you can formalize it with other axioms.
>>
>>  Just to be sure we talk about the same things: you call them datatypes,
>> but they are not datatypes, but datatype properties (linking individuals
>> to data values).
>>
> yes
>
>> I agree the way of representing parameters which you propose is more
>> flexible if we decide to add axioms describing aspects other than domain
>> (simulation algorithms that uses the parameter)  and range. But it will
>> entail the problem with the OBO version of KiSAO. Now we convert the OWL
>> datatype properties to OBO relations (and keep information about domains and
>> ranges), for example:
>>
>> [Typedef]
>> id: KISAO:0000228
>> name: tau-leaping epsilon
>> domain: KISAO:0000039 ! tau-leaping method
>> range: xsd:decimal
>>
>>
>> But if we do as you propose: replace datatype properties with owl classes,
>> their domains with axioms containing object property 'is used in', such as:
>>
>> 'tau-leaping epsilon'
>> subClassOf
>> ('is used in' some 'tau-leaping method')
>>
>>
>> and replace ranges with axioms containing datatype property 'has value':
>>
>> 'tau-leaping epsilon'
>>  subClassOf
>> ('has value' some xsd:decimal
>>  and 'has value' only xsd:decimal)
>>
>>
>> then axioms containing 'is used in' object property can be easily
>> converted to OBO:
>>
>> relationship: 'is used in' 'tau-leaping method'
>>
>>
>> but it's not possible (is it?) to convert axioms containing *datatype*property 'has value', because there's no OBO term for 'xsd:decimal':
>>
>> relationship: KISAO:0000259 xsd:decimal   ! -- <-- this is not possible as xsd:decimal is not a term
>>
>> while for the range tag not only terms, but also XML-Schema primitives
>> can be used in OBO:
>>
>> range: xsd:decimal
>>
>> Do you, probably, see a better solution for OBO?
>>
>>
> OBO is looking more and more like OWL, but without all the necessary
> semantics nor analysis required to support the constructs in the language
> (consider that OBO 1.4 allows one to place restrictions on transitive
> properties - good luck with this in practice).
>
>  My advice is to go with a language for formal knowledge representation
> that was designed as such from the beginning, and is an essential part of
> the Semantic Web effort.
>

I discussed the issue with Chris Mungall - we both wonder why you need
compatibility with OBO at this point?

m.


>
> m.
>
>
>> Thanks,
>>
>> Anna Zhukova
>>
>> Intern, Computational Systems Neurobiology Group,
>> European Bioinformatics Institute,
>> Wellcome Trust Genome Campus,
>> Hinxton, Cambridge
>> CB10 1SD, United Kingdom
>>
>>
>
>
> --
> Michel Dumontier
> Associate Professor of Bioinformatics
> Carleton University
> http://dumontierlab.com
>



-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com

Re: [SED-ML-discuss] KISAO

[Michel D. <mic...@gm...>]

On Tue, Apr 26, 2011 at 9:12 AM, Anna Zhukova <zhu...@eb...> wrote:

>  Dear Michel,
>
> Thanks for your suggestion for KiSAO.
> I'd like to discuss some of them.
>
>  1. classes
> a. move deprecated classes into another 'development' ontology document so
> they don't show up in the release version
>
>  These (now deprecated) classes were used in the 1.0 version of KiSAO, so
> in KiSAO 2.0 we marked them deprecated (instead of removing) in case someone
> already had references to them. I'd say it's more a problem of an
> appropriate ontology browser. In OBO-Edit these deprecated (obsolete for
> OBO) classes are not shown in the main hierarchy tree, but in a special
> 'Obsolete' branch, which can be folded up. If there is an option to hide
> deprecated classes in Protege (I've sent them such a feature request<https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3160&start=0>),
> then the problem will be solved, won't it?
>
>
hmm - i haven't checked, but do the classes appear in the bioportal version
too?

 b. added disjointness among classes (this helps support reasoning on negated
> existential axioms)
> c. LSODA variants not axiomatically differentiated
>
>  Thanks, we'll do it.
>
>  2. object properties
> a. deprecate 'lacksProperty', as you can create negated existential axioms
>
>  The 'lacksProperty' was added for OWL to OBO conversion: it is not
> possible to represent negation in OBO, so we use ('lacksProperty'  ?X)
> instead of (not 'hasProperty' ?X) in OBO version of KiSAO. So
> 'lacksProperty' is necessary for an OBO version of KiSAO. But you are right,
> we should deprecate it in the OWL version. Thanks.
>
>  b. 'isHybridOf' - more generally - 'is variant of'
>
>  Can you please explain what 'is variant of' will mean?
> Now I don't see the difference between 'is variant of' and inheritance:
> LSODAR and LSODES are variants of Livermore Solver.
>

in strict inheritance, it is the case that the child inherits all attributes
of the parent.

'is variant of' indicates that there is a similarity and difference among
the entities that is rooted in one or more attributes.


> The idea of 'isHybridOf' relation was to show that some algorithm is a
> combination of several other ones: "the whole system is subdivided into
> appropriate parts and different simulation methods operate on these parts at
> the same time." Example of hybrid algorithm is Pahle's method (used in
> COPASI). It combines the stochastic Gibson-Bruck's next reaction method with
> different algorithms for the numerical integration of ODEs. "The biochemical
> network is dynamically partitioned into a deterministic and a stochastic
> subnet depending on the current particle numbers in the system. The
> stochastic subnet contains reactions involving low numbered species as
> substrate or product. All the other reactions form the deterministic subnet.
> The two subnets are then simulated in parallel using the stochastic and
> deterministic solver, respectively."
>
>
right, so 'is hybrid of' considers two things : i) variation in that there
is similarity and differences from another entity and ii) causality - that
portions of that entity have led to this one. in SIO, this would be a
subproperty of 'is variant of' and 'is causally related from'

a. given that you're starting to develop a hierarchy of datatypes, you
> should **strongly** consider converting all of your datatypes into classes
> with restrictions on the kind of value that hold e.g. 'relative tolerance'
> (using manchester owl syntax)
>
> 'relative tolerance'
>  subClassOf
>  'quantity'
>  and 'has value' some decimal
>  and 'has value' only decimal
>
> If there are other aspects that differentiate a 'relative tolerance' from
> 'tolerance', then now you can formalize it with other axioms.
>
>  Just to be sure we talk about the same things: you call them datatypes,
> but they are not datatypes, but datatype properties (linking individuals
> to data values).
>
yes

> I agree the way of representing parameters which you propose is more
> flexible if we decide to add axioms describing aspects other than domain
> (simulation algorithms that uses the parameter)  and range. But it will
> entail the problem with the OBO version of KiSAO. Now we convert the OWL
> datatype properties to OBO relations (and keep information about domains and
> ranges), for example:
>
> [Typedef]
> id: KISAO:0000228
> name: tau-leaping epsilon
> domain: KISAO:0000039 ! tau-leaping method
> range: xsd:decimal
>
>
> But if we do as you propose: replace datatype properties with owl classes,
> their domains with axioms containing object property 'is used in', such as:
>
> 'tau-leaping epsilon'
> subClassOf
> ('is used in' some 'tau-leaping method')
>
>
> and replace ranges with axioms containing datatype property 'has value':
>
> 'tau-leaping epsilon'
>  subClassOf
> ('has value' some xsd:decimal
>  and 'has value' only xsd:decimal)
>
>
> then axioms containing 'is used in' object property can be easily converted
> to OBO:
>
> relationship: 'is used in' 'tau-leaping method'
>
>
> but it's not possible (is it?) to convert axioms containing *datatype*property 'has value', because there's no OBO term for 'xsd:decimal':
>
> relationship: KISAO:0000259 xsd:decimal   ! -- <-- this is not possible as xsd:decimal is not a term
>
> while for the range tag not only terms, but also XML-Schema primitives can
> be used in OBO:
>
> range: xsd:decimal
>
> Do you, probably, see a better solution for OBO?
>
>
OBO is looking more and more like OWL, but without all the necessary
semantics nor analysis required to support the constructs in the language
(consider that OBO 1.4 allows one to place restrictions on transitive
properties - good luck with this in practice).

 My advice is to go with a language for formal knowledge representation that
was designed as such from the beginning, and is an essential part of the
Semantic Web effort.

m.


> Thanks,
>
> Anna Zhukova
>
> Intern, Computational Systems Neurobiology Group,
> European Bioinformatics Institute,
> Wellcome Trust Genome Campus,
> Hinxton, Cambridge
> CB10 1SD, United Kingdom
>
>


-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com

Re: [SED-ML-discuss] KISAO

[Anna Z. <zhu...@eb...>]

Dear Michel,

Thanks for your suggestion for KiSAO.
I'd like to discuss some of them.
> 1. classes
> a. move deprecated classes into another 'development' ontology document so
> they don't show up in the release version
These (now deprecated) classes were used in the 1.0 version of KiSAO, so 
in KiSAO 2.0 we marked them deprecated (instead of removing) in case 
someone already had references to them. I'd say it's more a problem of 
an appropriate ontology browser. In OBO-Edit these deprecated (obsolete 
for OBO) classes are not shown in the main hierarchy tree, but in a 
special 'Obsolete' branch, which can be folded up. If there is an option 
to hide deprecated classes in Protege (I've sent them such a feature 
request 
<https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3160&start=0>), 
then the problem will be solved, won't it?
> b. added disjointness among classes (this helps support reasoning on negated
> existential axioms)
> c. LSODA variants not axiomatically differentiated
Thanks, we'll do it.
> 2. object properties
> a. deprecate 'lacksProperty', as you can create negated existential axioms
The 'lacksProperty' was added for OWL to OBO conversion: it is not 
possible to represent negation in OBO, so we use ('lacksProperty'  ?X) 
instead of (not 'hasProperty' ?X) in OBO version of KiSAO. So 
'lacksProperty' is necessary for an OBO version of KiSAO. But you are 
right, we should deprecate it in the OWL version. Thanks.
> b. 'isHybridOf' - more generally - 'is variant of'
Can you please explain what 'is variant of' will mean?
Now I don't see the difference between 'is variant of' and inheritance:  
LSODAR and LSODES are variants of Livermore Solver.
The idea of 'isHybridOf' relation was to show that some algorithm is a 
combination of several other ones: "the whole system is subdivided into 
appropriate parts and different simulation methods operate on these 
parts at the same time." Example of hybrid algorithm is Pahle's method 
(used in COPASI). It combines the stochastic Gibson-Bruck's next 
reaction method with different algorithms for the numerical integration 
of ODEs. "The biochemical network is dynamically partitioned into a 
deterministic and a stochastic subnet depending on the current particle 
numbers in the system. The stochastic subnet contains reactions 
involving low numbered species as substrate or product. All the other 
reactions form the deterministic subnet. The two subnets are then 
simulated in parallel using the stochastic and deterministic solver, 
respectively."
> a. given that you're starting to develop a hierarchy of datatypes, you
> should*strongly*  consider converting all of your datatypes into classes
> with restrictions on the kind of value that hold e.g. 'relative tolerance'
> (using manchester owl syntax)
>
> 'relative tolerance'
>   subClassOf
>   'quantity'
>   and 'has value' some decimal
>   and 'has value' only decimal
>
> If there are other aspects that differentiate a 'relative tolerance' from
> 'tolerance', then now you can formalize it with other axioms.
Just to be sure we talk about the same things: you call them datatypes, 
but they are not datatypes, but datatype properties (linking individuals 
to data values).
I agree the way of representing parameters which you propose is more 
flexible if we decide to add axioms describing aspects other than domain 
(simulation algorithms that uses the parameter)  and range. But it will 
entail the problem with the OBO version of KiSAO. Now we convert the OWL 
datatype properties to OBO relations (and keep information about domains 
and ranges), for example:

[Typedef]
id: KISAO:0000228
name: tau-leaping epsilon
domain: KISAO:0000039 ! tau-leaping method
range: xsd:decimal


But if we do as you propose: replace datatype properties with owl 
classes, their domains with axioms containing object property 'is used 
in', such as:

'tau-leaping epsilon'
subClassOf
('is used in' some 'tau-leaping method')


and replace ranges with axioms containing datatype property 'has value':

'tau-leaping epsilon'
  subClassOf
('has value' some xsd:decimal
  and 'has value' only xsd:decimal)


then axioms containing 'is used in' object property can be easily 
converted to OBO:

relationship: 'is used in' 'tau-leaping method'


but it's not possible (is it?) to convert axioms containing _datatype_ 
property 'has value', because there's no OBO term for 'xsd:decimal':

relationship: KISAO:0000259 xsd:decimal   ! --<-- this is not possible as xsd:decimal is not a term

while for the range tag not only terms, but also XML-Schema primitives 
can be used in OBO:

range: xsd:decimal

Do you, probably, see a better solution for OBO?

Thanks,

Anna Zhukova

Intern, Computational Systems Neurobiology Group,
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton, Cambridge
CB10 1SD, United Kingdom

Re: [SED-ML-discuss] Proposal by Frank on nested simulations

[Andrew M. <ak....@au...>]

On 23/04/11 01:51, Nicolas Le Novère wrote:
> Hello,
>
> A link to Frank's proposal is now on the site:
> http://sed-ml.org/documents.html
>

Hi all,

I have a few comments on the proposal; some of them also apply to other 
parts of the current version of SED-ML; however, I think that this is an 
opportunity to resolve some of the more general issues, so I am 
reiterating them as they come up in the proposal.

   1) As I have previously noted for SED-ML 'Change' features, I don't 
think the choice of XPath as a way of describing variables is a good 
one, simply because it only works for languages where it is possible to 
reference every variable with XPath (this doesn't work for CellML 1.1 
with imports, and it certainly won't work for any non-XML based 
languages; suggesting that representation languages change to 
accommodate SED-ML doesn't seem like a good approach either). If SED-ML 
is truly going to be model representation language neutral, I would 
suggest that the exact mechanism for referencing variables be model 
representation language specific, and that this functionality be 
referenced everywhere that a variable needs to be targeted.
   2) The concept of 'steady state' without any parameters does not seem 
realistic for solvers that do purely numerical processing of the model; 
finding a definitive steady state requires analytic treatment of the 
model; at the very least, there needs to be some kind of description of 
the algorithm for determining when an acceptable approximation of steady 
state has been reached, along with the parameters of that algorithm.
   3) "then the models time parameter is changed". In some 
representation languages (CellML included) variables like time can be 
defined to anything; I suggest at least writing:
   "then the model's time^1 parameter is changed.
   Footnote 1: In this document, time refers to the bound variable over 
which numerical integration can be performed".
  However, I don't fully understand what it means to change a bound 
variable outside of the numerical integration over which it is bound. Do 
you mean the bottom of the range over which integration occurs 
("starting time")?
   4) I think the name and semantics of OneStep are potentially 
confusing, because there are two possible interpretations: 'one step' of 
a parameter scan, and 'one step' of the underlying solver algorithm. The 
specification says "one integration step of the integrator", but that is 
not what is most useful here. Numerical integrator algorithms that are 
useful for stiff problems have dynamic step sizes, but performing a step 
with a dynamic step size is practically useless for a parameter scan.
   5) The two 'integration task primitives' need a set of parameters 
that depend on the KiSAO algorithm selected; I think a mechanism for 
algorithm specific parameters dependent on the KiSAO ID is required.

The task primitives that I think you actually want are:
   a) Perform a numerical integration over the bound variable of 
integration ('time') between a specified lower and upper value.
   b) Perform a numerical integration over the bound variable of 
integration ('time') between a specified lower value, and an upper value 
n that is not known previously, such that certain termination 
constraints are met based on outputs up to time n.
   c) Perform intervention ('SetValue').
   d) Set all values from previous output (optionally can name the 
output to use; names set on output primitives). I'd suggest that at the 
start of a list of tasks, parameters are reset unless explicitly restored.

Additionally, filter primitives could be available:
   a) All points are added to the vector of outputs.
   b) Points are added to the vector, with a minimum spacing between points.
   c) Only the final point is added to the vector of outputs.

I think that the specification should explicitly say that multiple 
primitives are allowed in the 'task slot', and that they should be 
performed sequentially.

For ranges, I'd suggest the ability to define a bound variable and use 
that as a parameter to algorithms or some other parameter.

Also, I suggest a few examples:
1) Uniform time course, no grid imposed:
      Range: absent
      Tasks:
        * Integrate between start and stop bound variables
            Filter: All points are added to the vector of outputs
            Starting bound variable: 0
            Ending bound variable: 100
            Model: somemodel
            Integration algorithm: 1

2) Uniform time course, regular grid imposed:
      Range: New bound variable x: Step from 0 to 99 in intervals of 1
      Tasks:
        * Integrate between start and stop bound variables
            Filter: Only the final point is added to the vector of outputs.
            Starting bound variable: x
            Ending bound variable: x + 1
            Model: Somemodel
            Integration algorithm: 1

3) One variable steady state sampling sensitivity analysis:
      Range: New bound variable x: Step from 0 to 1 in intervals of 0.01
      Tasks:
        * Set variable x = x
        * Integrate from start bound variable up to where termination 
condition met.
            Filter: Only the final point is added to the vector of outputs.
            Starting bound variable: 0
            Model: Somemodel
            Integration algorithm: 1
            Termination algorithm: 100

4) Two variable steady state sampling sensitivity analysis, on a grid:
      Range: New bound variable x: Step from 0 to 1 in intervals of 0.01
      Tasks:
        * Set variable x = x
        * Nested simulation:
           Range: New bound variable y: Step from 0 to 1 in intervals of 
0.01
           Tasks:
             * Set variable y = y
             * Integrate from start bound variable up to where 
termination condition met.
                 Filter: Only the final point is added to the vector of 
outputs.
                 Starting bound variable: 0
                 Model: Somemodel
                 Integration algorithm: 1
                 Termination algorithm: 100

5) Uniform time course, with intervention:
      Range: absent
      Tasks:
        * Integrate between start and stop bound variables
            Filter: All points are added to the vector of outputs
            Starting bound variable: 0
            Ending bound variable: 50
            Model: somemodel
            Integration algorithm: 1
        * Set variable x = 0
        * Integrate between start and stop bound variables
            Filter: All points are added to the vector of outputs
            Starting bound variable: 50
            Ending bound variable: 100
            Model: somemodel
            Integration algorithm: 1

Best wishes,
Andrew

[SED-ML-discuss] KISAO

[Michel D. <mic...@gm...>]

Hello,
  After Nicolas's presentation at Harmony, i looked into KISAO ontology

http://kisao.svn.sourceforge.net/viewvc/kisao/trunk/kisao-owl/kisao.owl?revision=137

and wanted to share my thoughts:

1. classes
a. move deprecated classes into another 'development' ontology document so
they don't show up in the release version
b. added disjointness among classes (this helps support reasoning on negated
existential axioms)
c. LSODA variants not axiomatically differentiated

2. object properties
a. deprecate 'lacksProperty', as you can create negated existential axioms
b. 'isHybridOf' - more generally - 'is variant of'


3. datatype properties
a. given that you're starting to develop a hierarchy of datatypes, you
should *strongly* consider converting all of your datatypes into classes
with restrictions on the kind of value that hold e.g. 'relative tolerance'
(using manchester owl syntax)

'relative tolerance'
 subClassOf
 'quantity'
 and 'has value' some decimal
 and 'has value' only decimal

If there are other aspects that differentiate a 'relative tolerance' from
'tolerance', then now you can formalize it with other axioms.

Best,

m.

-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com

[SED-ML-discuss] Proposal by Frank on nested simulations

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

Hello,

A link to Frank's proposal is now on the site:
http://sed-ml.org/documents.html

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/