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

'Radioactive decay' parent change #157

Open
PaulNSchofield opened this issue Apr 28, 2023 · 10 comments
Open

'Radioactive decay' parent change #157

PaulNSchofield opened this issue Apr 28, 2023 · 10 comments

Comments

@PaulNSchofield
Copy link
Collaborator

'Radioactive decay' is currently coming up as a planned process and an energy transfer process. Its certainly not OBI planned process and its an RBO class, so not sure how it ended up here. It INVOLVES energy transfer, I think but its now best placed under 'subatomic process' when that class is made.

@PaulNSchofield
Copy link
Collaborator Author

PaulNSchofield commented May 21, 2023

Discussed and this seems correct so please make a child of "subatomic process" when that class is added. Im assuming that by flagging candidate release confirmed this is a sign that it can now be be added to the ontology/changed?

@reality
Copy link
Collaborator

reality commented May 21, 2023

this is already implemented in kch branch. just to check that changes should be checked in this particular version at this link: https://github.com/Radiobiology-Informatics-Consortium/RBO/blob/kch/rbo-full.owl

@PaulNSchofield
Copy link
Collaborator Author

PaulNSchofield commented May 21, 2023

Thanks Luke, so if they are looking OK what do I do about the issue, close it, change the label? I think we need to change the case of the class label for Radioactive decay as well. Is it possible to remove the second parent, the old one? "planned process"

@reality
Copy link
Collaborator

reality commented May 21, 2023

the meaning of the labels are:

  • awaiting implementation: i or someone else needs to make the change in the ontology
  • awaiting confirmation and closing: the changes have been implemented, someone (usually you at the moment) needs to check that they were made correctly (in the OWL file for the link i gave above). if they are implemented correctly, you can change the label to 'candidate release confirmed' or if there is a problem, back to 'awaiting implementation' along with a comment on what was wrong
  • candidate release confirmed: someone has confirmed that the change was successfully made, and the issue will be closed when we merge the branch/do a release
  • awaiting input: someone needs to respond to a question
  • awaiting discussion: we need to discuss the issue in the meeting and decide what to do

i will change this one back to awaiting implementation since i will remove the planned process superclass

@reality
Copy link
Collaborator

reality commented May 21, 2023

so if you check a 'awaiting confirmation and closing' one and it all looks good, all you need to do is change the label to 'candidate release confirmed'

@PaulNSchofield
Copy link
Collaborator Author

Thanks!

@reality
Copy link
Collaborator

reality commented May 25, 2023

so this is a little complicated: planned process subclass is inferred via:

image

changing this to awaiting discussion

@DanBerrios
Copy link
Collaborator

Luke to confirm if this domain restriction is real.

@DanBerrios
Copy link
Collaborator

Luke to try moving radioactive decay to process

@DanBerrios
Copy link
Collaborator

Reviewing this issue again, the cause of inferring a parent can be "planned process" is the 2 axioms "has_specified_input" and "has_specified_output". To correct this, these axioms need to be dropped. In addition, we can add "has_participant" "radiation" to keep the connection with that concept.

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

No branches or pull requests

3 participants