Comments (13)
Its pretty quick to edit with protege. I could give you a quick orientation over Zoom.
I think these terms should be added under a new trunk of the ontology. In addition to the terms you added, we'll need to add a few "organizational" terms to group the terms. This could follow the color groupings in your table.
Regarding tracking support for terms by simulation tools, we could put this in BioSimulators. KiSAO only has a small amount of information about simulation tools. I think that information is better suited for a database than an ontology. This is largely implemented already; it needs to be modified for the SED-ML L1V4 target+symbol scheme.
from kisao.
Sure, I can try that. Should I just do what I can and create a pull request?
The only reason I mentioned simulation tools is that the auto-generated form had a spot asking about them, perhaps to ensure that terms weren't being added that had zero tool support.
from kisao.
That plan sounds good.
Protege is fairly straightforward. These are the key attributes to use:
rdfs:label
(language:en
): primary name of each termskos:altLabel
(language:en
): synonymsskos:definition
(language:en
): descriptionisOrganizational
(xsd:boolean
):true
if the term is an abstract concept (i.e., shouldn't be used in a SED-ML document; only its children should be used in SED-ML documents)rdfs:seeAlso
(xsd:anyURI
): URL for more information (e.g.,https://identifiers.org/doi/XYZ
)rdfs:comment
(language:en
) on this can provide a human-readable citation for the URL
isImplementedIn
(xsd:anyURI
):https://identifiers.org/biosimulators/tellurium
dcterms:creator
: (language:en
):LPS
dcterms:created
: (xsd:date
):2021-06-03
skos:altLabel
, isOrganizational
, rdfs:seeAlso
, isImplementedIn
are optional.
KiSAO does have a slot for implementation information. We could use this. I wouldn't encourage people to rely on that information because its very incomplete. KiSAO isn't really structured to handle information about what simulation tools implement. To begin to handle that better KiSAO would need to have a term for each simulation tool.
from kisao.
from kisao.
It looks like Lucian figured it out. I think the notes above are really all one needs to know about editing the ontology. I copied the notes above to the CONTRIBUTING.md
.
from kisao.
I added missing data types and started to increment the version number for this.
Since KiSAO is largely independent of SBML and SED-ML, I suggest we generalize some of the names of the organizational terms so the names are less tied to their use with SBML, SED-ML, and specific algorithms. For example, "modelling and simulation implied variable" is somewhat specific to SBML's use of "time". NeuroML/LEMS also uses the time symbol, but time is more explicit in that language. "rate of change" is also not necessarily a derived quantity. For FBA, this is the primary result.
- I would group both "time" and "rate of change" under "model and simulation variable"
- Rather than "modelling and simulation value chooser" and its children what about the following?
- a top level organizational term "model and simulation variable characteristic" with children
- "intensive quantity"
- "extensive quantity"
- a top level organizational term "model and simulation variable characteristic" with children
- "modelling and simulation result dimension reducing function" seems like a very specific top-level term. What about creating a top level term "mathematical function" and nesting "modelling and simulation result dimension reducing function" under this with the name "aggregation function"
- I would remove "full" from the names of the terms such as "full eigenvalue matrix". I think this is implied. Instead, I think this could be a synonym.
- To me, "modelling and simulation analysis" sounds like a method rather than an output. How about "model and simulation systems property"?
- I would use "scaled"/"unscaled" consistently.
I pushed my suggestions in another branch: https://github.com/SED-ML/KiSAO/tree/lps-karr-new-terms
from kisao.
The vast majority of these changes look great to me. The minor exceptions:
- I put in 'full' in the definition of the three 'full' versions of the matrices, just to be explicit.
- We still need 'amount' and 'particle number' explicitly, so I made the intensive/extensive quantities categories.
- I'm not sure I like 'rate of change' in the 'model and simulation variable' category, since it's basically the mathematical concept 'derivative' which doesn't really seem like a variable to me (unlike 'time'). I moved it to the 'mathematical function' category, mulled over it a bit, then moved it back, because I'm not sure I like it over there, either. As you mentioned elsewhere, we can always change the organization of this, so there's no rush on this, but the sort of things I would see living with 'time' would be things like 'length' or 'ambient temperature', which are quantities in and of themselves, not a rule about how to obtain a quantity.
Also, you seem to have removed my 'isOrganizational:false' tags, which seems a bit odd to me--surely there aren't defaults for these sorts of things?
At any rate, changes added!
from kisao.
I put in 'full' in the definition of the three 'full' versions of the matrices, just to be explicit.
To me an eigenvector matrix means full unless reduced is specifically stated. For that reason, I thought it makes sense to make ""full eigenvector matrix" a synonym of "eigenvector matrix". Same for the similar terms.
We still need 'amount' and 'particle number' explicitly, so I made the intensive/extensive quantities categories.
My thinking was to use variable characteristics similar to algorithm characteristics. They represent modifiers which be coupled to variables to indicate the specific dimensionality needed for a particular variable. This could avoid the need to create KiSAO terms for each combination of type of variable and possible dimensionality/units. I thought this could work with SBML species: target indicates the species; symbol indicates the dimensionality. However, SED-ML expects individual KiSAO terms rather than expressions involving possibly multiple terms. This means we have to have KiSAO terms for each concrete combination needed.
I suggest we nest particle number, amount, and concentration under "model and simulation variable" and have relationships to "extrinsic property" and "intrinsic property". Because there are multiple ways to categorize terms, we can use other types of relationships to express this rather than parent-child.
I'm not sure I like 'rate of change' in the 'model and simulation variable' category, since it's basically the mathematical concept 'derivative' which doesn't really seem like a variable to me (unlike 'time'). I moved it to the 'mathematical function' category, mulled over it a bit, then moved it back, because I'm not sure I like it over there, either. As you mentioned elsewhere, we can always change the organization of this, so there's no rush on this, but the sort of things I would see living with 'time' would be things like 'length' or 'ambient temperature', which are quantities in and of themselves, not a rule about how to obtain a quantity.
I see your point. How about we remain the category to "model and simulation property" so that it doesn't imply whether its a primary or derived quantity (so it can be used in different modeling frameworks which either is possible)?
Also, you seem to have removed my 'isOrganizational:false' tags, which seems a bit odd to me--surely there aren't defaults for these sorts of things?
I removed this because the convention is that terms are only organizational if isOrganizational
is set to true
. (i.e. no other term has isOrganizational
= false
.) Just trying to stick with the conventions that we've inherited.
from kisao.
re; 'full': your argument makes sense to me and I left the change; I just added '(full)' in the 'skos:definition' field, and left the rest as you had it. I know Tellurium is always explicit in its API about which version you're asking for, so I tend to think of e.g. the reduced stoichiometry matrix as still being a stoichiometry matrix, just not the 'full' one.
re: intrinsic/extrinsic: I'm happy with whatever organizational mode you want; the one you propose sounds good to me. It seems like SED-ML doesn't expressly need the concept of 'extensive' or 'intensive', so if you're not using them as anything organizational, we might not need them at all, but it's fine if they're there.
re: rateOfChange; The category rename sounds perfect.
re: organizational: sounds good! Continuing previous conventions seems fine.
Are you good making these changes, or should I?
from kisao.
I already made these changes. Let me know if you want to make more changes, or I should release this version.
Regarding integration with tellurium, when I release the version, the python package with KiSAO embedded into it will also be pushed to PyPI (pip install kisao >= 2.16
).
re; 'full': your argument makes sense to me and I left the change; I just added '(full)' in the 'skos:definition' field, and left the rest as you had it. I know Tellurium is always explicit in its API about which version you're asking for, so I tend to think of e.g. the reduced stoichiometry matrix as still being a stoichiometry matrix, just not the 'full' one.
Sounds good. I saw this.
re: intrinsic/extrinsic: I'm happy with whatever organizational mode you want; the one you propose sounds good to me. It seems like SED-ML doesn't expressly need the concept of 'extensive' or 'intensive', so if you're not using them as anything organizational, we might not need them at all, but it's fine if they're there.
Yes, in my opinion the "characteristic" terms shouldn't be embedded into SED-ML documents. Nevertheless, I think they're quite useful. This is what I've used to automate algorithm substitution. The characteristics work around the problem that there's no single hierarchy of terms that can capture all relationships among terms.
from kisao.
Works for me--releasing this version sounds great.
from kisao.
I added merged in the terms I started in #85. In particular, this include amount rate, concentration rate, and particle number rate which some requested. This also includes terms for FBA and logical simulations.
from kisao.
Closing. This is already released.
from kisao.
Related Issues (20)
- Add terms for terms of UniformTimeCourse HOT 4
- Release 2.30 not triggered HOT 3
- Automatic update of KISAO on obo foundry and ontology lookup service (OLS) HOT 6
- New terms for mpbn HOT 8
- Enable query algorithms for recommendations for algorithms to be terms for abstract classes of algorithms (e.g., Gillespie-like rather than SSA)
- Fix typo in definition of "biological state optimization method"
- Request: New base 'simulate in time' algorithm HOT 4
- Automatic releases no longer working HOT 2
- New algorithm for GillesPy2 Hybrid Tau-Leaping Method HOT 2
- Add terms for (in)dependent variables of outputs of simulations HOT 11
- Add terms for slices of dimensions of (in)dependent variables of outputs of simulations HOT 2
- Change redirect for biomodels.net from SourceForge to GitHub HOT 1
- Automate release to BioPortal in GitHub action HOT 2
- SED-ML Aggregation function (New terms for count, stddev, variance) HOT 5
- Clarify math functions as to whether to ignore NaN HOT 3
- New terms for uniform time course attributes
- Some KISAO terms do not match KISAO pattern HOT 3
- Some KISAO terms fail lookup with `get_normalized_id` HOT 3
- labels of systems properties should be lowercase HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kisao.