NTR: measures characteristic

[ddooley]

This proposed relationship would attach between an assay (a measurement process), and a characteristic being measured on the assay's measurand. Also shown is "is measurement of characteristic" just to show near-future context.

label: measures characteristic
inverse label: characteristic measured during
definition: A relation between an assay and a characteristic, in which the assay generates a data item which is a measure of a characteristic related to the assay's measurand.
parent: (I think it would be top level?)
domain: assay
range: characteristic

Pierre suggests for label: "includes measurement of"
Nico suggests for inverse label: "characteristic measured by"

This allows that a process can have a characteristic. One example given is for a "5 finger coin pickup mobility assessment" assay that would yield data items about mobility/dexterity.

One task is to review OBI assays to see if each can be said to be measuring a characteristic.

#535

Note this doesn't address a possible relation between devices and the characteristics they measure.

[jamesaoverton]

The domain of 'is about' is 'information content entity'. Characteristics and assays are not information content entities, so that are not about things. So I don't understand what you mean by "a characteristic may be about a process" and "review OBI assays to see if each can be said to be about measuring a characteristic".

The ugliest but perhaps most clear labels might be 'assay measures characteristic' and 'characteristic measured by assay'. Despite the greater clarity, I would prefer shorter labels.

[matentzn]

Not to make things complicated but can we omit the "assay" part in the label and simply say "characteristic measured by"? Else we will only start adding more and more relations for cases where a non-assay observation is used to observe a characteristic. Also it would help to advertise the relation a bit more outside the obi world where the word assay will cause confusion when used in conjunction with a clinical diagnostic procedure or some such.

[ddooley]

@jamesaoverton , sorry, instead of "This allows that a characteristic may be about a process" I should have said:
"This allows that a process can have a characteristic"
and about the assays:
"Review OBI assays to see if each can be said to be measuring a characteristic"

[jamesaoverton]

@matentzn OBI:0000070 assay is defined as "A planned process with the objective to produce information about the material entity that is the evaluant, by physically examining it or its proxies.". What non-assay process do you have in mind that measures something?

[matentzn]

I am mostly concerned about the optics here - it's an important relation and it may be a bit confusing to mix terminological concerns (many people would probably stumble across your definition of assay) and the formalisation. My feeling is that for cob and domains and ranges a more neutral term then assay should be used as a range for such a relation - even if it is not about modelling concerns, but about marketing.

[ddooley]

@matentzn Do you mean some wordsmithing like: "A relation between a measurement process (assay) and a characteristic, in which the process generates a data item which is a measure of a characteristic related to the process's measurand."

[wdduncan]

I agree with @matentzn
The domains and ranges within RO should be as general as possible. Let's just use process as the domain:

"A relation between a process and a characteristic, in which the process generates a data item which is a measure of a characteristic related to the process's measurand."

@ddooley

measure of a characteristic related to the process's measurand.

Can you shorten to "measure of the characteristic"?

Isn't the 'measurand' the thing being measured?
I.e., The measurand is the characteristic being measured.

If so, it seems like you are saying:
"measure of a characteristic related to the (characteristic being measured)"

[ddooley]

[edited] In OBI land it seems to me only planned processes output measurement data items, so that suggests "planned process" for the domain?

How about this definition tweak:

definition: A relation between an assay and a measurand's characteristic, in which the assay generates a data item which is a measure of the characteristic.

[wdduncan]

@ddooley Any update on this issue?

[ddooley]

I have new pull request #717

label: measures characteristic
definition: A relation between a process and a characteristic, in which the process generates a data item which is a measure of a characteristic.
parent: (top level)
domain: process
range: characteristic
inverse: "characteristic measured by"

[bpeters42]

Going back through the issue, I don't understand why the domain is suddenly 'process' and not 'assay' ? At a very minimum 'planned process'? There is no update here after James comment on Dec 13 that clarifies what kind of non-assay processes are supposed to domain of this relationship?

[ddooley]

I think domain "process" was motivated by the idea that if we generalized this beyond "planned process", then we can describe what biological sensors do. We can say things like " 'photoreceptor cell' 'measures characteristic' some color". Bill or others want to comment? Or is there some other relation already that allows us to describe biological sensors? Anticipate distinguishing assay vs other kinds of sensing process?

[nataled]

@bpeters42 are you not seeing the nine or so following comments? Unless I misinterpret something, the concern about assay is that (1) domains/ranges for COB should be as neutral (generic?) as possible (a view shared by @matentzn and @wdduncan), and (2) that people might stumble over the use of 'assay' (@matentzn). Regarding these concerns, I personally see no issue with 'assay' unless there are measurements (for example, determining the length of something with a ruler) that are not considered 'assay' but do measure characteristics. If there are no such measurements, then assay is already the broadest possible domain. That being said, if users tend to have a preconceived notion that 'assay' does NOT include all possible measurements, then I see why it should be avoided.

[bpeters42]

- I did read the 9 following comments. That is why I am complaining. Where is the response to concerns from Damion, James, and myself? Clearly there is no consensus? - assay is a term in COB. How much more neutral can we get? - assay is defined as: " "A planned process with the objective to produce information about the material entity that is the evaluant, by physically examining it or its proxies.". That includes using a ruler. - If we now suddenly want to include 'environmental sensing', that broadens it to the point of uselessness. Do slime molds measure the nutrient environment around them? A rusting roof measure rain acidity? calcium channels measure voltage differences? Why ruin a perfectly good relationship? - The label 'assay' has been discussed ad nauseum, and until someone comes up with a better label, let's please not do that again. Some of these discussions are on the OBI list, as that is the source of the term assay. The last one was here, and closed by Nico: obi-ontology/obi#1635

…

On Tue, May 23, 2023 at 11:40 AM Darren A. Natale ***@***.***> wrote: @bpeters42 <https://github.com/bpeters42> are you not seeing the nine or so following comments? Unless I misinterpret something, the concern about assay is that (1) domains/ranges for COB should be as neutral (generic?) as possible (a view shared by @matentzn <https://github.com/matentzn> and @wdduncan <https://github.com/wdduncan>), and (2) that people might stumble over the use of 'assay' ***@***.*** <https://github.com/matentzn>). Regarding these concerns, I personally see no issue with 'assay' unless there are measurements (for example, determining the length of something with a ruler) that are not considered 'assay' but do measure characteristics. If there are no such measurements, then assay is already the broadest possible range. That being said, if users tend to have a preconceived notion that 'assay' does NOT include all possible measurements, then I see why it should be avoided. — Reply to this email directly, view it on GitHub <#658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IQ6GGBL3LJWM6SOCFLXHUACBANCNFSM6AAAAAAS5T5VAQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Bjoern Peters Professor La Jolla Institute for Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[nataled]

Thanks for the clarification. I misinterpreted what you meant by "There is no update here" and wished to summarize the succeeding comments. I now see what you're saying. Apologies for that.

Having my one question answered in the way I thought it should be ("includes rulers"), I agree that 'assay' makes most sense. I also agree that 'environmental sensing' should be out of scope. I exclude such on the basis that a measurement must have some value associated with it. As environmental sensing produces no such value in and of themselves, they should not qualify.

[bpeters42]

Understood @nataled! So to be clear, I am proposing is to go back to 'assay' rather than 'process' where 'assay' is OBI:assay which is = COB:assay. This would be reflected in the modified request below.

label: measures characteristic
definition: A relation between an assay and a characteristic, in which the assay generates a data item which is a measure of a characteristic.
parent: (top level)
domain: assay
range: characteristic
inverse: "characteristic measured by"

[ddooley]

Ok, and so "measures" carries the day here - it does convey assay is at work. Will do. I think we should start to import these terms by way of COB import module.

[ddooley]

Just one side note. I want to simplify food processing models so that human vs device sensory activity is easily swappable. Say I want to ensure a soup is hot. I do a temperature assay - assessed either with thermometer, but also can assess with taste. In a recipe "protocol" can I say "if you don't have a thermometer, taste it to see if it is hot"? So human is used as device, I presume OBI doesn't have a problem with that?

Humans will need to be referenced as devices in many situations where cooking (or laboratory processes) depend on humans for sensory assessments, and as well for actuation (material processing/transporting).

[nataled]

I would characterize the above as highlighting a difference between measurement (quantitative) and an assessment (qualitative).

[ddooley]

@nataled , ok, I recall now that OBI has precedent for a kind of assay which is a questionnaire that collect qualitative data. So we could have a general "hotness assay" that generates a qualitative "hot/warm/cool" output, and we can say " 'hotness assay' 'measures characteristic' some temperature", without committing to that characteristic being measured numerically?

An instance of "hotness assay" could either:

1. make use of a "thermometer assay" part that does output numeric result, and then a data transformation that converts this numeric range to the "hot/warm/cool" scale.
   OR
2. just list a human as a device, and (perhaps implicitly) a survey question about the substance temperature as a plan specification for the "hotness assay" to execute.

All good? I'm needing to understand consensus here in order to explore process modelling plug-and-play flexibility.

[nataled]

That all seems a bit twisty to me, requiring a couple of odd maneuvers to make work. Much simpler would be to have a 'measures characteristic' relation and an 'assesses characteristic' relation (maybe as a parent to 'measures characteristic'?), with the former being qualitative and the latter being quantitative.

(FYI I'm leaving for vacation shortly and will not be able to follow-up until Tuesday. I think I made my points to my satisfaction, and I'm happy to accept whatever decision comes from the discussion)

[ddooley]

I can see we might want some information about the way a process measures a characteristic - whether the measure is quantitative, or qualitative, i.e. not calibrated with a quantitative scheme. Say our temperature thermometer device output [0,1,2] in an ordinal scale say - that's quantitative, but is it mappable to a standardized scale? (e.g. 0: <= 20C, 1: <= 120C, 2: > 120C). If so, that info could attach to the process or the output datum. In that respect "measures characteristic" could carry more information, and necessitate a general "assesses characteristic" parent property that does not promise this info.

OR we just keep "measures characteristic", and leave the nature of the measure to the process or datum to detail.

Others opinions?

[bpeters42]

- We have always allowed for both qualitative and quantitative measurements in OBI (many classical assays are qualitative e.g. 'presence of a band in a gel'.). - There is nothing wrong with using a 'human' as a device for making a measurement or all kinds of things. But it must be made as part of a planned process with the objective to produce reliable information (that could be written down, or communicated, or used for follow up decisions). So "Determine the temperature of your pan by putting in a piece of butter. Once it melts, the pan has reached the desired temperature" is a (crude) measurement. What is not a measurement is a bit of butter melting in the sun that you forgot to put in the fridge. So as always with planned processes, the intent matters.

…

On Thu, May 25, 2023 at 2:45 PM Damion Dooley ***@***.***> wrote: I can see we might want some information about the way a process measures a characteristic - whether the measure is quantitative, or qualitative, i.e. not calibrated with a quantitative scheme. Say our temperature thermometer device output [0,1,2] in an ordinal scale say - that's quantitative, but is it mappable to a standardized scale? (e.g. 0: <= 20C, 1: <= 120C, 2: > 120C). If so, that info could attach to the process or the output datum. In that respect "measures characteristic" could carry more information, and necessitate a general "assesses characteristic" parent property. OR we just keep "measures characteristic", and leave the nature of the measure to the process or datum to detail. Others opinions? — Reply to this email directly, view it on GitHub <#658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IRW7RNOML4IZMPZWXTXH7HFZANCNFSM6AAAAAAS5T5VAQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Bjoern Peters Professor La Jolla Institute for Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[ddooley]

Ok, one last thing re. assay vs. planned process as domain. COB is allowing characteristic to include process characteristics? In that case we'd better use "planned process" as domain rather than "assay" which restricts analysis to material entities.

[ddooley]

And for range we're using PATO:0000001 characteristic (currently "quality" in RO)

[wdduncan]

Sorry ... getting to the party late. I've been traveling.

Lots of interesting discussions!

I just want to note that there is an open issues about importing COB terms: #716

[ddooley]

Sooo, I thought why not try importing into RO from COB. COB's "planned process" is COB_0000082 , and that imports fine now via a new ro-odk.yaml config. But as an aside, I did a test to import OBI:0000011 (now "completely executed planned process") through that, but it wouldn't import (no error). Is this absence a function of where ODK is fetching COB from?

[ddooley]

Lastly, given that we may want to express that a process measures a characteristic regardless of whether it completes or not, I will use COB "planned process".

[ddooley]

The pull request #717 is ready for review!

[bpeters42]

Using 'planned process' rather than 'assay' defeats the whole purpose of COB. If you want to include incomplete and failed assays, those aren't 'planned processes' either; you would have to go to 'process'. And how do you think the relation is supposed to hold in a failed process measurement?

I take the point about the need to consider measurement of process characteristics. But that would make me want to broaden the OBI/COB definition of assay.

Overall, the whole point to me here is (as you had at the start of this discussion) to introduce a relationship that will make it easy to utilize OBI/COB compatible modeling of how measurements are done. But if we loosen the relationship so much that the connection is lost, people will start introducing parallel hierarchies to assays in COB, and no reasoner would complain, and we have to have these discussions over and over. So I strongly oppose putting in a misleading shortcut relationship like this.

[ddooley]

"And how do you think the relation is supposed to hold in a failed process measurement?" - this is getting at designing for the use-case I was perceiving, one where this "measures characteristic" is a way of expressing the objective of a measurement process, whether it succeeds or not. That way for a given characteristic we could look up say 3 possible ways to measure it, and chose from them, before having gone and collected any "completely executed planned process" data. Since assay can only be named for completely executed planned processes, we couldn't search for possible assays to apply by using this "measures characteristic" as a criteria.

I do think we can state objectives of a planned process regardless of whether it is successful or not - whenever it might actually be attempted?[edit]

[ddooley]

Perhaps I'm mistaking the semantics of "completely executed planned process"! Maybe that is to be taken as "here is what a process x looks like when all its parts and potential final output are examined", rather than "only refer to me if you have some instance data and nothing went wrong"! Is that the case?

If so then yes "assay" could be the domain as long as we loosen its definition, as you say. We can take this over to OBI, but how about:
assay definition: "A planned process with the objective to produce information about the entity that is the evaluant, by examining it or its proxies."

[bpeters42]

You got the first part right about what 'completely executed planned process" is supposed to mean. That is by the way what we always imply in ontologies; when we have a class like 'mouse' we refer to it also when we talk about mice that we want to order for an experiment that might not exist as specific instances yet.

Regarding the assay definition revision for process charactersistics, that absolutely has to be taken into OBI, where there were already other revisions planned, which will not be straightforward. I would ask to make sure that there is consensus on these things before putting out pull requests.

[ddooley]

Absolutely, it takes a village to make this language work. I perceived some curve balls started showing up after I got this pull going. Will confirm "assay" use over on OBI side, then return to this.

[ddooley]

I've just made a few changes to pull request to use OBI assay for domain, and tweak relation names.