DARPA-ASKEM / Model-Representations

Modeling framework representations for ASKEM
https://darpa-askem.github.io/Model-Representations/
8 stars 2 forks source link

Inconsistency between state and transition names #51

Open jpfairbanks opened 1 year ago

jpfairbanks commented 1 year ago

I just noticed that in the petri net schema the state names are properties of the state objects, but the transition names are nested inside a property dictionary.

  "model": {
    "states": [
      {
        "id": "S",
        "name": "Susceptible",
        "description": "Number of individuals that are 'susceptible' to a disease infection",
        "grounding": {
          "identifiers": {
            "ido": "0000514"
          }
        },
        "units": {
          "expression": "person",
          "expression_mathml": "<ci>person</ci>"
        }
      },

....

    ],
    "transitions": [
      {
        "id": "inf",
        "input": [
          "S",
          "I"
        ],
        "output": [
          "I",
          "I"
        ],
        "properties": {
          "name": "Infection",
          "description": "Infective process between individuals"
        }
      },

...

    ]
  },

These should probably be harmonized at / after the hackathon.

liunelson commented 1 year ago

I don't recall who (might be @bgyori) told me but this inconsistency in the location of name is on purpose.

bgyori commented 1 year ago

I find this a little bit odd as well but when @mehalter, @brandomr and I were coming up with this, there was some logical thought that resulted in this. I believe the main argument was that transitions should highlight their basic structure front and center and everything else about them should be "hidden" under property (which at the time included rate laws and such). In contrast, states don't have any structural implications beyond their existence and so you can just put all their properties in as primary keys.

mehalter commented 1 year ago

Basically there are no structural pieces to the states so the table is just its properties table. This was a design choice rather than having each state always be a table with a single key properties and then all the details inside of it. Transitions have structural details of inputs and outputs so the properties go into a properties table

mehalter commented 1 year ago

Yeah @bgyori that is correct :D

mehalter commented 1 year ago

This also made sense in the beginning because initially the states and transitions were keyed tables rather than arrays, so I guess you could say that id is considered "not" a property now