From Chris Myers
The ALGORITHM_WITH_DETERMINISTIC_RULES does not seem to work. I think your kisao version is missing a lot of terms which is likely part of the problem. Again, likely low priority, since I should be using the Kisao library.
--- old+++ new@@ -1 +1,2 @@+From Chris MyersThe ALGORITHM_WITH_DETERMINISTIC_RULES does not seem to work. I think your kisao version is missing a lot of terms which is likely part of the problem. Again, likely low priority, since I should be using the Kisao library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a look at this - yes, the .obo file was very out of date! .obo no longer seems supported - probably not rich enough compared to owl, so have performed various manipulations to get latest KISAO into jlibsedml.
tidying up some loose ends - e.g. id: KISAO_0000435
name: embedded Runge-Kutta 5(4) method - lacks an ' is-a 'relation in obo format. Looking at owl file the definition is complicated and probably some info is lost in obo conversion. So I've arbitrarily made it an isa KISAO_302 which is at least partially true.
some terms have vanished e.g. KISAO_0000035 'general ODE'
the identifiers specified in SEDML schema - KISAO:XXXXX are now KISAO_XXXXX
All this makes me realise that 1) We don't want KISAO hard-coded and 2) as you say probably better to delegate to libKisao. I don't really want to add dependency on libKisao - it's not maintained, not in maven etc - so propose to develop a simple KisaoProvider interface that you can plugin libKisao or a parsed KISAO ontology from another source. The default could remain the hardcoded version if nothing is supplied. Supported methods would include very basic reasoning used to determine if a SedmlExecutor can execute the algorithm requested by the SEDMLfile. This again could be extensible/pluggable for more complex reasoning by a jlibsedml client application.
How does this sound as a plan?
Last edit: Richard Adams 2016-07-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds fine. I did not realize libkisao was not maintained. Probably best to update hard-coded version periodically. I don’t think Kisao is changing very frequently.
I had a look at this - yes, the .obo file was very out of date! .obo no longer seems supported - probably not rich enough compared to owl, so have performed various manipulations to get latest KISAO into jlibsedml.
- downloading kisao.owl from http://svn.code.sf.net/p/kisao/code/tags/kisao-owl-latest/kisao.owlhttp://svn.code.sf.net/p/kisao/code/tags/kisao-owl-latest/kisao.owl
converting to obo using the Java OWL API
tidying up some loose ends - e.g. id: KISAO_0000435
name: embedded Runge-Kutta 5(4) method - lacks an ' is-a 'relation in obo format. Looking at owl file the definition is complicated and probably some info is lost in obo conversion. So I've arbitrarily made it an isa KISAO_302 which is at least partially true.
some terms have vanished e.g. KISAO_0000035 'general ODE'
the identifiers specified in SEDML schema - KISAO:XXXXX are now KISAO_XXXXX
All this makes me realise that 1) We don;t want KISAO hard-coded and 2) as you say probably better to delegate to libKisao. I don't really want to add dependency on libKisao - it's not maintained, not in maven etc - so propose to develop a simple KisaoProvider interface that you can plugin libKisao or a parsed KISAO ontology from another source. The default could remain the hardcoded version if nothing is supplied. Supported methods would include very basic reasoning used to determine if a SedmlExecutor can execute the algorithm requested by the SEDMLfile. This again could be extensible/pluggable for more complex reasoning.
Status: accepted
Group: 2.3
Created: Wed Jul 13, 2016 09:03 PM UTC by Richard Adams
Last Updated: Mon Jul 25, 2016 07:31 AM UTC
Owner: Richard Adams
From Chris Myers
The ALGORITHM_WITH_DETERMINISTIC_RULES does not seem to work. I think your kisao version is missing a lot of terms which is likely part of the problem. Again, likely low priority, since I should be using the Kisao library.
Diff:
Yes, the Kisao terms are hardcoded as a resource file and are probably out of date.
I had a look at this - yes, the .obo file was very out of date! .obo no longer seems supported - probably not rich enough compared to owl, so have performed various manipulations to get latest KISAO into jlibsedml.
downloading kisao.owl from http://svn.code.sf.net/p/kisao/code/tags/kisao-owl-latest/kisao.owl
converting to obo using the Java OWL API
name: embedded Runge-Kutta 5(4) method - lacks an ' is-a 'relation in obo format. Looking at owl file the definition is complicated and probably some info is lost in obo conversion. So I've arbitrarily made it an isa KISAO_302 which is at least partially true.
some terms have vanished e.g. KISAO_0000035 'general ODE'
the identifiers specified in SEDML schema - KISAO:XXXXX are now KISAO_XXXXX
All this makes me realise that 1) We don't want KISAO hard-coded and 2) as you say probably better to delegate to libKisao. I don't really want to add dependency on libKisao - it's not maintained, not in maven etc - so propose to develop a simple KisaoProvider interface that you can plugin libKisao or a parsed KISAO ontology from another source. The default could remain the hardcoded version if nothing is supplied. Supported methods would include very basic reasoning used to determine if a SedmlExecutor can execute the algorithm requested by the SEDMLfile. This again could be extensible/pluggable for more complex reasoning by a jlibsedml client application.
How does this sound as a plan?
Last edit: Richard Adams 2016-07-26
This sounds fine. I did not realize libkisao was not maintained. Probably best to update hard-coded version periodically. I don’t think Kisao is changing very frequently.
Chris
Related
Bugs: #8