oborel / obo-relations

RO is an ontology of relations for use with biological ontologies
http://oborel.github.io/
Other
91 stars 46 forks source link

NTR: 'contains measured amount' #712

Closed jmwhorton closed 8 months ago

jmwhorton commented 1 year ago

Note: this relationship is currently in OBIB (http://purl.obolibrary.org/obo/OBIB_0000038)

Preferred term label

has actual load

Textual definition

A relation that relates a container to a measurement datum that specifies the actual amount of material in the container.

Definition Source

Penn Group

Term Editor

Person: Jie Zheng, Chris Stoeckert

wdduncan commented 1 year ago

By 'amount' do you mean its weight? Or volume? Or would categorical units be allows, e.g. 'half full'.

It was also suggested that 'actual' be removed from the name.

jmwhorton commented 1 year ago

I'm going to tag @zhengj2007 and @cstoeckert to address any feedback on this term.

cstoeckert commented 1 year ago

For the same reasons as commented in https://github.com/oborel/obo-relations/issues/711 I think this should apply to both weight and volume. I also think including "actual" in the label helps distinguish which relation to use for the case of a 50 ml conical tube (has max capacity) containing 25 ml (has actual load). The restriction is for a measurement datum so categorical units are fine for that in my opinion.

wdduncan commented 1 year ago

Thanks @cstoeckert

Do you think the label should be has actual capacity so that it is consistent with has maximum capacity (and other relations of this ilk)?

Re including 'actual' in the label: There was a bit of pushback on this. As for me, I would prefer excluding it (i.e., has load or has capacity). For cases in which min/max is being referenced. E.g.:has maximum capacity, has minimum capacity. I can imaging other capacity relations, e.g. has capacity range.

cc @nataled @bpeters42

nataled commented 1 year ago

Definitely not 'has actual capacity' since that would be synonymous with 'has maximum capacity'. And although I think it's mildly superfluous, I don't have much objection to including 'actual' in the name since people often refer to 'actual amounts' of things.

wdduncan commented 1 year ago

Definitely not 'has actual capacity' since that would be synonymous with 'has maximum capacity'.

Right! My mistake :)

I don't have much objection to including 'actual' in the name since people often refer to 'actual amounts' of things.

Sure ... In most (maybe all) contexts I've dealt with dealing with measurements (e.g., weight, volume, height, duration), 'actual' was assumed, and max/min had to be stated.

cstoeckert commented 1 year ago

I'm OK with a different label than 'has actual load' as long as it is consistent with the definition and is not likely to be confused with other meanings. How about 'has contained amount' ?

wdduncan commented 1 year ago

How about 'has contained amount' ?

'contains amount' sounds more natural to me, but I'm okay with the label 'has contained amount'.

The way definition current reads it would be necessary to import measurement datum to formally specify the range. One way to do this would be to create a COB import that includes measurement datum. @matentzn do you suggest a better way?

@cstoeckert If I assign an IRI for the term are you (or someone in your group) able to make a PR for this?

cstoeckert commented 1 year ago

@wdduncan yes I or someone from OBIB can work on this. Thanks.

wdduncan commented 1 year ago

Thanks @cstoeckert
Please use RO_0017002 as the namespace id in the new term.

wdduncan commented 1 year ago

I am not able to attend the next RO call on May 23. Is there any update on progress for this?

cstoeckert commented 1 year ago

@wdduncan I'm planning to bring this up at the next OBIB call (scheduled for May 25) to get someone to work on it. They will need write access to this repository.

cmungall commented 11 months ago

They will need write access to this repository.

This is not necessary for RO, nor for any other public repo on github. The beauty of github is that anyone can fork and make a PR

Having said that, it's sometimes a bit less hassle to make PRs on origin rather than a fork and we grant access to regular editors for this purpose. But not having merge abilities should never be an obstacle to contribution!

wdduncan commented 11 months ago

@jmwhorton has been submitting terms to RO. Will he be handling this?

jmwhorton commented 11 months ago

I am, yes. This one actually has a pull request, which might not be obvious since a new label was picked (and the pull request named accordingly): #726

wdduncan commented 11 months ago

Thanks @jmwhorton ! I forgot about #726.
Added a 'fixes' comment.