Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency between state and transition names #51

Open
jpfairbanks opened this issue Jun 30, 2023 · 5 comments
Open

Inconsistency between state and transition names #51

jpfairbanks opened this issue Jun 30, 2023 · 5 comments

Comments

@jpfairbanks
Copy link
Collaborator

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
Copy link
Member

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

@bgyori
Copy link
Collaborator

bgyori commented Jul 12, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator

Yeah @bgyori that is correct :D

@mehalter
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants