Code Monkey home page Code Monkey logo

Comments (13)

jonrkarr avatar jonrkarr commented on August 23, 2024

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.

luciansmith avatar luciansmith commented on August 23, 2024

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.

jonrkarr avatar jonrkarr commented on August 23, 2024

That plan sounds good.

Protege is fairly straightforward. These are the key attributes to use:

  • rdfs:label (language:en): primary name of each term
  • skos:altLabel (language:en): synonyms
  • skos:definition (language:en): description
  • isOrganizational (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.

matthiaskoenig avatar matthiaskoenig commented on August 23, 2024

from kisao.

jonrkarr avatar jonrkarr commented on August 23, 2024

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.

jonrkarr avatar jonrkarr commented on August 23, 2024

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"
  • "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.

luciansmith avatar luciansmith commented on August 23, 2024

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.

jonrkarr avatar jonrkarr commented on August 23, 2024

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.

luciansmith avatar luciansmith commented on August 23, 2024

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.

jonrkarr avatar jonrkarr commented on August 23, 2024

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.

luciansmith avatar luciansmith commented on August 23, 2024

Works for me--releasing this version sounds great.

from kisao.

jonrkarr avatar jonrkarr commented on August 23, 2024

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.

jonrkarr avatar jonrkarr commented on August 23, 2024

Closing. This is already released.

from kisao.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.