Date of measurement

[andredekker]

[not sure if this classifies as an issue]

Our use case is the mapping of clinical data to a knowledge graph based on OBO foundry ontologies. We are trying to conform to the OBI and specifically the below approach (which I adapted from http://obi-ontology.org/docs/data-intro/)

My question is how to model the date of the mass measurement. What happens in reality is that the GP will look at her watch for today's date and enter this (together with the weight) into her computer. Our suggestion is to model this as follows:

We chose this approach as we did not find in OBI or other OBO foundry ontologies another way to do this. We considered "Time measurement datum" but this is about the duration of a process and is a scalar measurement datum which needs a numeric value and unit which we don't have. We also considered "Time stamped measurement datum" but this is a subClass of "has time stamp" some "Time measurement datum" which seems incorrect.

Question: Do you agree with our approach or would you consider to do this differently?

[jamesaoverton]

Hi @andredekker. You're right that we don't have a good standard way to do this yet. Your diagrams are helpful. I'm worried that the link between the xsd:date and xsd:decimal literals is quite long and may be difficult to query. Maybe this would be more clear with an example in Turtle/SPARQL syntax.

OBI and OBO developers have been working on improvements to the value specification approach for some time. This is the most recent discussion document. I'll be picking this work back up in the next month, and would appreciate feedback from people with use cases like yours.

[andredekker]

Thanks for your reply. The discussion document contains lots of nuggets which are relevant for our use case so certainly willing to give feedback.

My main concern is not so much the distance between the two literals xsd:date and xsd:decimal, it will be a long SPARQL but we can hide that complexity and/or can assert shortcuts if needed. My main concern is that the instance of GP looking at her watch has no semantics associated with it. I would have liked to be able to state that this instance is rdf:type a process in which absolute (well actually relative to the birth of Christ) time is measured - but there is no assay for this in OBO to the best of our knowledge. As discussed in the discussion document handling time as such is a huge challenge in itself - but I think it makes sense to see the measurement of absolute time as "just another assay".

[ddooley]

One abstraction for OBI to consider is a generic "observation process" that outputs an "observation record" and that has as input a specimen (John, an instance possibly located somewhere) and output a dataset including mass, time, etc, and which is about that instance of John. There is an IAO timestamped measurement datum but that doesn't account for the whole who, where, when context of a measurement.

[ddooley]

I totally agree that a data collection process can have "time measurement process" as a part, referencing clocks or other devices - for full provenance. That "John standing on a scale in GP office" process could be broken down into collecting the measure, collecting the time (all that looks fine), and if relevant, the location, the GP involved. All this could be a specific model of doctor-patient encounter; but we could offer shortcuts as you say, and just have a set of outputs of the process, in more of a static view. This could be generalized into an "observation record", minus relations to an observation process entity itself. I will draft this notion up.

P.s. its neat to see you reuse that diagram style (I came up with it a few years ago). I'll be writing a paper soon to explain it as a set of diagram patterns, so I welcome suggestions about improving it too.

[bpeters42]

I am probably missing all kinds of nuances, so apologies in advance. But I would like to make sure that any approach to capture time when something was done will expand beyond assays. We will want to capture vaccination dates, hospitalization dates, clinical visit dates, birth dates, etc. And we will want to distinguish between when an assay was performed vs. when the sample the assay was performed on was collected. There are all kinds of complexities. But ultimately I think all we need to be able to do is to tie a process to a time (or time-span), and capture that when we describe data. I hope this is making some sense.

• Bjoern

On Tue, Oct 4, 2022 at 10:38 PM Damion Dooley @.***> wrote:

I totally agree that a data collection process can have "time measurement process" as a part, referencing clocks or other devices - for full provenance. That "John standing on a scale in GP office" process could be broken down into collecting the measure, collecting the time (all that looks fine), and if relevant, the location, the GP involved. All this could be a specific model of doctor-patient encounter; but we could offer shortcuts as you say, and just have a set of outputs of the process, in more of a static view. This could be generalized into an "observation record", minus relations to an observation process entity itself. I will draft this notion up.

P.s. its neat to see you reuse that diagram style (I came up with it a few years ago). I'll be writing a paper soon to explain it as a set of diagram patterns, so I welcome suggestions about improving it too.

— Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/1560#issuecomment-1267966196, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2IUPLEESHLE23LFH6F3WBUH5DANCNFSM5ZPJQ57Q . You are receiving this because you are subscribed to this thread.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]

@andredekker to note that OBI is backing away from value specification towards the proposed COB model that allows value statements from context of subject, or context of data (examples 4 and 5).

@bpeters42 all good - in a health-care encounter and others, there are collections of processes, each measuring or documenting some aspect of the encounter. If we strip away all the process modelling, as is usually done in more vague medical and other record keeping, ideally we can still be left with the data item outputs of those processes in some organized fashion.

Naming kinds of date seems to be a solution here. We can precompose common terms like "birth date" (date on which birthing process ends), "Sample collection date", "assay date" etc. James' COB data model suggests using OWL time relations to describe the values for these dates. I'm also proposing OBO allow "process" to have OWL time durations and start/end instants.

Above "todays date entered in computer" could be an instance of "examination date", as an umbrella for any other measurements happening on that day. Or do we try to make it as general as possible - "observation date"?

[andredekker]

@ddooley : looking at examples 4 and 5 - those will also work for us, but it is quite different (shorter) from the value specification. Also some of those classes/properties seem not yet to be there (e.g. scalar value, has quantity, has unit, etc.). What would be the expected timeline to move to the COB style of working?

[ddooley]

I'm checking with James about that. I'll try to facilitate speeding up COB implementation.

[ddooley]

James, I'm wondering if we can phase COB data model in such that remaining sticky problems such as units of measure involving (cell) counts per [context] etc can be isolated into separate work?

[ddooley]

Damion will check-in with Bill about model at: https://qqv.ontodev.com/primer.html Email to OBO Operations about approving data model. Point out a fatal flaw - OR provide solution or alternative. OBO adoption strategy can be topic of feedback. Make a COB issue if anything comes up.
@zhengj2007 : Use cases of different kinds of value specification, and documentation of them. Measurement datum hierarchy repercussions will have to be dealt with (measured, calculated, simulated, so simplifying measurement datum branch...) Need to coordinate OBO wide about new data predicates. Previously IAO/OBI had lead this.