[Obi-devel] Data item - discussion points due to terminological differences

[Christian Bölling]

To help single out those discussion points reg. data item that might be due to terminological differences, I'd like to check whether what I understood from today's call is correct:

iao:data items are to be understood are the output of measurements only. Neither predictions nor specifications yield iao:data items, i.e. neither the prediction that tomorrow's average air temperature in a particular spot will be 30°C (as inferred from todays temperature and a meteorological model) nor the information that for my next experiment my incubator should be set to 30°C is a iao:data item. Is this understanding correct?

- Christian

[Melanie Courtot]

Hi Christian, all,

From the point of view of IAO the examples you describe are data item. Outputs of measurements are iao:measurement datum (itself a subclass of data item)
The prediction that tomorrow's average air temperature in a particular spot will be 30°C is an iao: predicted data item while the information that for my next experiment my incubator should be set to 30°C is a iao:setting datum (there is a note on the latter mentioning the "specification" point)

I don't know if the intent of the discussion that happened on the call was to update what is the scope of iao:data item, but restricting it to measurement output seems odd to me.

Cheers,
Melanie

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel

[Alan Ruttenberg]

On Mon, May 13, 2013 at 1:46 PM, Christian Bölling <christian....@gmail.com> wrote:

To help single out those discussion points reg. data item that might be due to terminological differences, I'd like to check whether what I understood from today's call is correct:

iao:data items are to be understood are the output of measurements only.

 

No. There are other items which might be reliably correct, such as certain kinds of news reports, or the stock ticker. Or the price tags in a catalog.

 

Neither predictions nor specifications yield iao:data items, i.e. neither the prediction that tomorrow's average air temperature in a particular spot will be 30°C (as inferred from todays temperature and a meteorological model)

 

Correct. My interpretation is that because at the time your made the prediction, since the situation did not yet exist, it couldn't be about it. Let's copy this to the IAO list to see what other things. In any case, it isn't about the outside in the same way a measurement would be.

nor the information that for my next experiment my incubator should be set to 30°C is a iao:data item.

Correct. Not a data item in my understanding. (I see Melanie's message and will have to respond to her different assessment)

 

Is this understanding correct?

I believe so.

Copying to other infojunkies.

-Alan

[Melanie Courtot]

On 2013-05-13, at 11:14 AM, Alan Ruttenberg wrote:

>
>
>
> On Mon, May 13, 2013 at 1:46 PM, Christian Bölling <christian....@gmail.com> wrote:
> To help single out those discussion points reg. data item that might be due to terminological differences, I'd like to check whether what I understood from today's call is correct:
>
> iao:data items are to be understood are the output of measurements only.
>
> No. There are other items which might be reliably correct, such as certain kinds of news reports, or the stock ticker. Or the price tags in a catalog.
>
> Neither predictions nor specifications yield iao:data items, i.e. neither the prediction that tomorrow's average air temperature in a particular spot will be 30°C (as inferred from todays temperature and a meteorological model)
>
> Correct. My interpretation is that because at the time your made the prediction, since the situation did not yet exist, it couldn't be about it. Let's copy this to the IAO list to see what other things. In any case, it isn't about the outside in the same way a measurement would be.

The current definition of data item is "a data item is an information content entity that is intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and is constructed/acquired by a method which reliably tends to produce (approximately) truthful statements."

If we consider the case of protein structure prediction, we do intend to make a truthful statement, it is about something (at least about the protein) and it is constructed by an expectedly reliable method (bioinformatics tools for example). I am not sure that the argument "the situation does not yet exist" is relevant, as the prediction is anyway about the software used, the experimenter etc, but in any case the protein may exist, may be folded and its structure is unknown - take for example GPCRs for which we have a pretty good idea of the structure but which are only slowly being crystallized and x-rayed.

>
> nor the information that for my next experiment my incubator should be set to 30°C is a iao:data item.
>
> Correct. Not a data item in my understanding. (I see Melanie's message and will have to respond to her different assessment)

I agree that there is a difference between saying "I measured the voltage on my instrument and it was 230V" and saying "the voltage on the instrument should be set to 230V". After thinking about it further I also agree that setting datum seems more like a directive/specification and therefore should be moved there. I however think it is confusing in the sense that when I say "the setting on my instrument was 230V" I would also call this a setting datum. Does that mean that we need both?

>
> Is this understanding correct?
>
> I believe so.
>
> Copying to other infojunkies.

Looking forward to feedback.

Melanie

[Bjoern Peters]

In my mind, we were going to define measurement datum, prediction, setting etc. separately, and later see if it is useful to have a parent class 'data item' for these. 

- Bjoern

---

--

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

[Alan Ruttenberg]

We already have a class 'data item'. There might be some other useful superclass, or we could decide to rename the current 'data item'.  But the current 'data item' as-defined, won't be a parent of all three.

-Alan

[Bjoern Peters]

Agreed. I guess my point was that we should first agree on the definition of 'measurement datum' and the other classes before arguing if they belong under a parent. 

---

[Alan Ruttenberg]

On Tue, May 14, 2013 at 2:49 PM, Bjoern Peters <bpe...@liai.org> wrote:

Agreed. I guess my point was that we should first agree on the definition of 'measurement datum' and the other classes before arguing if they belong under a parent. 

Yup 

[Christian Bölling]

So all of us seem to agree that there are three types of information content entities (and perhaps more and various ways to define subtypes):

(1) those that are the output of a measurement process (whatever this is - see below) and believed to measure something (let's call them measuring data items - MDIs)

(2) those that are the output of a prediction process (whatever this is - see below) and believed to predict something (let's call them predicting data items - PDIs)

(3) those that are part of plans and recipes specifying setting or parameter values (let's call them settings data items - SDIs)

What is common to all of them is in my opinion that they are estimates of certain qualities (in many cases its qualities).

SDIs could perhaps be said to be different in that they specify qualities of things that they bear if they participate in a planned process that realizes a plan that is the concretization of a plan specification which the SDI is part of. So, the information that my incubator should be set at 30°C when performing an experiment of type EXP#1 specifies a quality of my incubator which it bears when it participates in a specific experiment of type EXP#1. If it is not at 30°C then the experiment performed is not of type EXP#1 (for all practical intents and purposes, we would allow a certain tolerance).  For me, such a perspective accounts for both the 'directive' and 'descriptive' aspects of settings which Melanie described above (and which I see too).

I find it much harder to define a difference between (1) and (2) which means to draw a line between measurement and prediction. I can see that there is a difference between estimating the current air temperature in my backyard using a thermometer and estimating tomorrow's air temperature by today's and a meteorological model. But I suspect that it is a very slippery slope from clearcut 'measurement' to clearcut 'prediction, because any observation is interpreted on the background of models. Alan seems to propose a distinction along the lines of 'reliability of correctness' and/or 'timepoint of estimation relative to timepoint of actualization'. I think neither of them is suitable: what is considered reliable may depend on context or discipline or indeed purpose. Timepoint is dubious because we make estimations about events that are not 'now' in science all the time: the assertion that there was a huge meteor impact 65 Million years ago is a prediction inferred on the basis of a number of physical and geological theories. And the biomedical sciences are no different: we use estimates of characteristics of biological entities from observations made in the past to interpret observations made later in time: any diagnosis in a practitioner's office is such an inference. Effectively we predict that patient X has measles because she shows symptoms similar to those of past patients typed as such.

Melanies example of protein structure is another such example: People started developing algorithms to infer 3D-structure on the basis of protein sequence and other characteristics (estimated with yet other methods). They have confidence in these algorithms because these were (I presume) trained using a number of proteins for which there were indeed 3D-structure estimates based on other methods considered adequately reliable (such as X-ray diffraction). Of course, in turn, X-ray diffraction first had to gain that status which it (presumably) gained when models of molecular structure were developed. Nevertheless, there could always be a protein for which a given algorithm fails (as well as another method of estimating its structure).

I think what is far more important, at least for the purpose of knowledge engineering using computational ontologies is to acknowledge that in both measurement and prediction we draw inferences from a background of observations and models (theories). This background is for both 'measuring data items' and 'predicting data items' the basis for plausibility, re-use, further inferences etc. which is why representation of that background is needed in any case to assess the reliability of an estimate, regardless wether it is categorized as 'measurement' or 'prediction'.

Now, by which terms MDIs, PDIs and SDIs should be referenced we should discuss (why not using these) as well as any useful super-classes. I would opt for using 'data item' for any of the three (to me this seems a natural choice and in-sync with lab colleagues) and providing sub-classes as needed to distinguish SDIs and method- or objective-specific measurement/prediction data items as needed. This would require only few changes in IAO, provided that the textual definition fo data item is updated, as I have argued before [1]:

Proposal for new definition:

A data item is an information content entity that is obtained as specified output of some measurement, simulation, prediction or in general a means of obtaining an estimate for a quality of something or specified as value of a quality of something that is refered to in a plan specification.

The linked doc describes many of the aspects mentioned here in more detail. It proposes a number of design patterns and constructs for representation of data items and I'd be keen to discuss this further (it is still sketchy in many places) and develop together as a coherent proposal for changes to the ontology.

[1] https://docs.google.com/document/d/1zL0nW9RVqoC9sg6iajNZHex03JDnYUG4Q5F-e2rlZYg/

- Christian

 

2013/5/14 Alan Ruttenberg <alanrut...@gmail.com>

[Alan Ruttenberg]

On Wednesday, May 15, 2013, Christian Bölling wrote:

So all of us seem to agree that there are three types of information content entities (and perhaps more and various ways to define subtypes):

(1) those that are the output of a measurement process (whatever this is - see below) and believed to measure something (let's call them measuring data items - MDIs)

(2) those that are the output of a prediction process (whatever this is - see below) and believed to predict something (let's call them predicting data items - PDIs)

(3) those that are part of plans and recipes specifying setting or parameter values (let's call them settings data items - SDIs)

What is common to all of them is in my opinion that they are estimates of certain qualities (in many cases its qualities).

SDIs could perhaps be said to be different in that they specify qualities of things that they bear if they participate in a planned process that realizes a plan that is the concretization of a plan specification which the SDI is part of. So, the information that my incubator should be set at 30°C when performing an experiment of type EXP#1 specifies a quality of my incubator which it bears when it participates in a specific experiment of type EXP#1. If it is not at 30°C then the experiment performed is not of type EXP#1 (for all practical intents and purposes, we would allow a certain tolerance).  For me, such a perspective accounts for both the 'directive' and 'descriptive' aspects of settings which Melanie described above (and which I see too).

I find it much harder to define a difference between (1) and (2) which means to draw a line between measurement and prediction. I can see that there is a difference between estimating the current air temperature in my backyard using a thermometer and estimating tomorrow's air temperature by today's and a meteorological model. 

Yes, but prediction has a much wider scope. It can include situations which depend on uncommon or even those which might never exist. For example, perfecting the change in oxygen production on the planet in the case of a 15 deg increase of planet temperature. Or what kinds of life could evolve on the conditions speculated upon to be present in the waters of the moons of Jupiter. 

 

But I suspect that it is a very slippery slope from clearcut 'measurement' to clearcut 'prediction, because any observation is interpreted on the background of models. Alan seems to propose a distinction along the lines of 'reliability of correctness' and/or 'timepoint of estimation relative to timepoint of actualization'. 

A strong distinction, at least, between measurements of things that exist versus those that don't or might not. 

 

I think neither of them is suitable: what is considered reliable may depend on context or discipline or indeed purpose. 

Yes. But in each field there are standards that amount to this, and an understanding of difference between measuring something now versus simulating something that might have been or might be. 

Timepoint is dubious because we make estimations about events that are not 'now' in science all the time: the assertion that there was a huge meteor impact 65 Million years ago is a prediction inferred on the basis of a number of physical and geological theories. 

Yes. I don't think that would be a measurement unless if it wasn't by a method that had sufficient history and independent validation. 

 

And the biomedical sciences are no different: we use estimates of characteristics of biological entities from observations made in the past to interpret observations made later in time: any diagnosis in a practitioner's office is such an inference. Effectively we predict that patient X has measles because she shows symptoms similar to those of past patients typed as such.

Melanies example of protein structure is another such example: People started developing algorithms to infer 3D-structure on the basis of protein sequence and other characteristics (estimated with yet other methods). They have confidence in these algorithms because these were (I presume) trained using a number of proteins for which there were indeed 3D-structure estimates based on other methods considered adequately reliable (such as X-ray diffraction). Of course, in turn, X-ray diffraction first had to gain that status which it (presumably) gained when models of molecular structure were developed. Nevertheless, there could always be a protein for which a given algorithm fails (as well as another method of estimating its structure).

Yes. We predict them. Based on measurements. The difference is sufficient that the language has clearly distinguished it.

 

I think what is far more important, at least for the purpose of knowledge engineering using computational ontologies is to acknowledge that in both measurement and prediction we draw inferences from a background of observations and models (theories). 

Not all predictions are such. 

 

This background is for both 'measuring data items' and 'predicting data items' the basis for plausibility, re-use, further inferences etc. which is why representation of that background is needed in any case to assess the reliability of an estimate, regardless wether it is categorized as 'measurement' or 'prediction'.

As you can tell, I don't agree.  

Now, by which terms MDIs, PDIs and SDIs should be referenced we should discuss (why not using these) as well as any useful super-classes. I would opt for using 'data item' for any of the three (to me this seems a natural choice and in-sync with lab colleagues) and providing sub-classes as needed to distinguish SDIs and method- or objective-specific measurement/prediction data items as needed. This would require only few changes in IAO, provided that the textual definition fo data item is updated, 

The current data item term should remain. It is a useful distinction. If you want to add a term, that seems reasonable, assuming a good definition. You could even perhaps borrow the existing label, but let's discuss this after you give your definition.  

 

as I have argued before [1]:

Proposal for new definition:

A data item is an information content entity that is obtained as specified output of some measurement, simulation, prediction or in general a means of obtaining an estimate for a quality of something or specified as value of a quality of something that is refered to in a plan specification.

This is a bare disjunction. Like: a fruit I like is an apple, orange or plum.   

[Melanie Courtot]

Begin forwarded message:

From: Alan Ruttenberg <alanrut...@gmail.com>

Subject: Re: [Obi-devel] Data item - discussion points due to terminological differences

Date: 15 May, 2013 2:08:52 PM PDT

To: Christian Bölling <christian....@gmail.com>

Cc: OBI Developers <obi-...@lists.sourceforge.net>, Barry Smith <phis...@buffalo.edu>, information-artifact-ontology <information-ar...@googlecode.com>, Werner Ceusters <ceus...@buffalo.edu>

On Wednesday, May 15, 2013, Christian Bölling wrote:

So all of us seem to agree that there are three types of information content entities (and perhaps more and various ways to define subtypes):

(1) those that are the output of a measurement process (whatever this is - see below) and believed to measure something (let's call them measuring data items - MDIs)

(2) those that are the output of a prediction process (whatever this is - see below) and believed to predict something (let's call them predicting data items - PDIs)

(3) those that are part of plans and recipes specifying setting or parameter values (let's call them settings data items - SDIs)

What is common to all of them is in my opinion that they are estimates of certain qualities (in many cases its qualities).

SDIs could perhaps be said to be different in that they specify qualities of things that they bear if they participate in a planned process that realizes a plan that is the concretization of a plan specification which the SDI is part of. So, the information that my incubator should be set at 30°C when performing an experiment of type EXP#1 specifies a quality of my incubator which it bears when it participates in a specific experiment of type EXP#1. If it is not at 30°C then the experiment performed is not of type EXP#1 (for all practical intents and purposes, we would allow a certain tolerance).  For me, such a perspective accounts for both the 'directive' and 'descriptive' aspects of settings which Melanie described above (and which I see too).

I find it much harder to define a difference between (1) and (2) which means to draw a line between measurement and prediction. I can see that there is a difference between estimating the current air temperature in my backyard using a thermometer and estimating tomorrow's air temperature by today's and a meteorological model. 

Yes, but prediction has a much wider scope. It can include situations which depend on uncommon or even those which might never exist. For example, perfecting the change in oxygen production on the planet in the case of a 15 deg increase of planet temperature. Or what kinds of life could evolve on the conditions speculated upon to be present in the waters of the moons of Jupiter. 

True, provided those predictions are " intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and constructed/acquired by a method which reliably tends to produce (approximately) truthful statements." as per the current definition of data item.

I can see how that may be an issue - I am not sure how to constrain "prediction" better. What would you suggest? Taking the protein structure example, this is a case that we need to be able to accommodate.

 

But I suspect that it is a very slippery slope from clearcut 'measurement' to clearcut 'prediction, because any observation is interpreted on the background of models. Alan seems to propose a distinction along the lines of 'reliability of correctness' and/or 'timepoint of estimation relative to timepoint of actualization'. 

A strong distinction, at least, between measurements of things that exist versus those that don't or might not. 

I think we all agree that there is a difference between measurement, prediction and specification, so that seems ok.

 

I think neither of them is suitable: what is considered reliable may depend on context or discipline or indeed purpose. 

Yes. But in each field there are standards that amount to this, and an understanding of difference between measuring something now versus simulating something that might have been or might be. 

Timepoint is dubious because we make estimations about events that are not 'now' in science all the time: the assertion that there was a huge meteor impact 65 Million years ago is a prediction inferred on the basis of a number of physical and geological theories. 

Yes. I don't think that would be a measurement unless if it wasn't by a method that had sufficient history and independent validation. 

 

And the biomedical sciences are no different: we use estimates of characteristics of biological entities from observations made in the past to interpret observations made later in time: any diagnosis in a practitioner's office is such an inference. Effectively we predict that patient X has measles because she shows symptoms similar to those of past patients typed as such.

Melanies example of protein structure is another such example: People started developing algorithms to infer 3D-structure on the basis of protein sequence and other characteristics (estimated with yet other methods). They have confidence in these algorithms because these were (I presume) trained using a number of proteins for which there were indeed 3D-structure estimates based on other methods considered adequately reliable (such as X-ray diffraction). Of course, in turn, X-ray diffraction first had to gain that status which it (presumably) gained when models of molecular structure were developed. Nevertheless, there could always be a protein for which a given algorithm fails (as well as another method of estimating its structure).

Yes. We predict them. Based on measurements. The difference is sufficient that the language has clearly distinguished it.

 

I think what is far more important, at least for the purpose of knowledge engineering using computational ontologies is to acknowledge that in both measurement and prediction we draw inferences from a background of observations and models (theories). 

Not all predictions are such. 

Not all data item are truthful statements, however this is what IAO chose to represent and name data item. We just need to keep in line with that decision and accept that we call predictions those that are "intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and constructed/acquired by a method which reliably tends to produce (approximately) truthful statements."

 

This background is for both 'measuring data items' and 'predicting data items' the basis for plausibility, re-use, further inferences etc. which is why representation of that background is needed in any case to assess the reliability of an estimate, regardless wether it is categorized as 'measurement' or 'prediction'.

As you can tell, I don't agree.  

I agree with Christian. We on purpose discarded "false" data item, such as false claims. I still think this poses a problem, for example when a scientific claim is proven false several years later - it would imply that what was a data item is not anymore. 

Now, by which terms MDIs, PDIs and SDIs should be referenced we should discuss (why not using these) as well as any useful super-classes. I would opt for using 'data item' for any of the three (to me this seems a natural choice and in-sync with lab colleagues) and providing sub-classes as needed to distinguish SDIs and method- or objective-specific measurement/prediction data items as needed. This would require only few changes in IAO, provided that the textual definition fo data item is updated, 

The current data item term should remain. It is a useful distinction.

I am confused - which distinction are you referring to?

If you want to add a term, that seems reasonable, assuming a good definition. You could even perhaps borrow the existing label, but let's discuss this after you give your definition.  

 

as I have argued before [1]:

Proposal for new definition:

A data item is an information content entity that is obtained as specified output of some measurement, simulation, prediction or in general a means of obtaining an estimate for a quality of something or specified as value of a quality of something that is refered to in a plan specification.

This is a bare disjunction. Like: a fruit I like is an apple, orange or plum.   

I think we should concentrate on the current needed terms - measurement, prediction and specification and define those.

Does it change anything at this point to have them be subclasses of data item or not? Note that OBI has positioned them (predicted data item and setting datum) there.

Melanie

------------------------------------------------------------------------------

[Alan Ruttenberg]

On Wednesday, May 15, 2013, Melanie Courtot wrote:

Begin forwarded message:

From: Alan Ruttenberg <alanrut...@gmail.com>

Subject: Re: [Obi-devel] Data item - discussion points due to terminological differences

Date: 15 May, 2013 2:08:52 PM PDT

To: Christian Bölling <christian....@gmail.com>

Cc: OBI Developers <obi-...@lists.sourceforge.net>, Barry Smith <phis...@buffalo.edu>, information-artifact-ontology <information-ar...@googlecode.com>, Werner Ceusters <ceus...@buffalo.edu>

On Wednesday, May 15, 2013, Christian Bölling wrote:

So all of us seem to agree that there are three types of information content entities (and perhaps more and various ways to define subtypes):

(1) those that are the output of a measurement process (whatever this is - see below) and believed to measure something (let's call them measuring data items - MDIs)

(2) those that are the output of a prediction process (whatever this is - see below) and believed to predict something (let's call them predicting data items - PDIs)

(3) those that are part of plans and recipes specifying setting or parameter values (let's call them settings data items - SDIs)

What is common to all of them is in my opinion that they are estimates of certain qualities (in many cases its qualities).

SDIs could perhaps be said to be different in that they specify qualities of things that they bear if they participate in a planned process that realizes a plan that is the concretization of a plan specification which the SDI is part of. So, the information that my incubator should be set at 30°C when performing an experiment of type EXP#1 specifies a quality of my incubator which it bears when it participates in a specific experiment of type EXP#1. If it is not at 30°C then the experiment performed is not of type EXP#1 (for all practical intents and purposes, we would allow a certain tolerance).  For me, such a perspective accounts for both the 'directive' and 'descriptive' aspects of settings which Melanie described above (and which I see too).

I find it much harder to define a difference between (1) and (2) which means to draw a line between measurement and prediction. I can see that there is a difference between estimating the current air temperature in my backyard using a thermometer and estimating tomorrow's air temperature by today's and a meteorological model. 

Yes, but prediction has a much wider scope. It can include situations which depend on uncommon or even those which might never exist. For example, perfecting the change in oxygen production on the planet in the case of a 15 deg increase of planet temperature. Or what kinds of life could evolve on the conditions speculated upon to be present in the waters of the moons of Jupiter. 

True, provided those predictions are " intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and constructed/acquired by a method which reliably tends to produce (approximately) truthful statements." as per the current definition of data item.

Speculation does not  "reliably tend to produce (approximately) truthful statements."

If you can measure it you don't need to predict it. If you can't measure it you can't assess whether the prediction is true. 

I can see how that may be an issue - I am not sure how to constrain "prediction" better. What would you suggest? Taking the protein structure example, this is a case that we need to be able to accommodate.

I don't think it is useful to constrain it because frankly I don't see any problem where Christian does. A class is a subclass if every instance of it is an instance of the superclass. These aren't. 

 

But I suspect that it is a very slippery slope from clearcut 'measurement' to clearcut 'prediction, because any observation is interpreted on the background of models. Alan seems to propose a distinction along the lines of 'reliability of correctness' and/or 'timepoint of estimation relative to timepoint of actualization'. 

A strong distinction, at least, between measurements of things that exist versus those that don't or might not. 

I think we all agree that there is a difference between measurement, prediction and specification, so that seems ok.

 

I think neither of them is suitable: what is considered reliable may depend on context or discipline or indeed purpose. 

Yes. But in each field there are standards that amount to this, and an understanding of difference between measuring something now versus simulating something that might have been or might be. 

Timepoint is dubious because we make estimations about events that are not 'now' in science all the time: the assertion that there was a huge meteor impact 65 Million years ago is a prediction inferred on the basis of a number of physical and geological theories. 

Yes. I don't think that would be a measurement unless if it wasn't by a method that had sufficient history and independent validation. 

 

And the biomedical sciences are no different: we use estimates of characteristics of biological entities from observations made in the past to interpret observations made later in time: any diagnosis in a practitioner's office is such an inference. Effectively we predict that patient X has measles because she shows symptoms similar to those of past patients typed as such.

Melanies example of protein structure is another such example: People started developing algorithms to infer 3D-structure on the basis of protein sequence and other characteristics (estimated with yet other methods). They have confidence in these algorithms because these were (I presume) trained using a number of proteins for which there were indeed 3D-structure estimates based on other methods considered adequately reliable (such as X-ray diffraction). Of course, in turn, X-ray diffraction first had to gain that status which it (presumably) gained when models of molecular structure were developed. Nevertheless, there could always be a protein for which a given algorithm fails (as well as another method of estimating its structure).

Yes. We predict them. Based on measurements. The difference is sufficient that the language has clearly distinguished it.

 

I think what is far more important, at least for the purpose of knowledge engineering using computational ontologies is to acknowledge that in both measurement and prediction we draw inferences from a background of observations and models (theories). 

Not all predictions are such. 

Not all data item are truthful statements, however this is what IAO chose to represent and name data item. We just need to keep in line with that decision and accept that we call predictions those that are "intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and constructed/acquired by a method which reliably tends to produce (approximately) truthful statements."

The definition allows untruthful statements - as long as they were acquired ... 

 

This background is for both 'measuring data items' and 'predicting data items' the basis for plausibility, re-use, further inferences etc. which is why representation of that background is needed in any case to assess the reliability of an estimate, regardless wether it is categorized as 'measurement' or 'prediction'.

As you can tell, I don't agree.  

I agree with Christian. We on purpose discarded "false" data item, such as false claims. I still think this poses a problem, for example when a scientific claim is proven false several years later - it would imply that what was a data item is not anymore. 

Nope. Once it has been acquired, unless the method by which it was acquired was falsely advertised ( paper said mice were weighed, investigation shows there were no mice) then whether a claim of the paper is disproven or not doesn't change the status. 

Now, by which terms MDIs, PDIs and SDIs should be referenced we should discuss (why not using these) as well as any useful super-classes. I would opt for using 'data item' for any of the three (to me this seems a natural choice and in-sync with lab colleagues) and providing sub-classes as needed to distinguish SDIs and method- or objective-specific measurement/prediction data items as needed. This would require only few changes in IAO, provided that the textual definition fo data item is updated, 

The current data item term should remain. It is a useful distinction.

I am confused - which distinction are you referring to?

Between data item as it is defined now and things that are not. 

If you want to add a term, that seems reasonable, assuming a good definition. You could even perhaps borrow the existing label, but let's discuss this after you give your definition.  

 

as I have argued before [1]:

Proposal for new definition:

A data item is an information content entity that is obtained as specified output of some measurement, simulation, prediction or in general a means of obtaining an estimate for a quality of something or specified as value of a quality of something that is refered to in a plan specification.

This is a bare disjunction. Like: a fruit I like is an apple, orange or plum.   

I think we should concentrate on the current needed terms - measurement, prediction and specification and define those

Yes 

Does it change anything at this point to have them be subclasses of data item or not? Note that OBI has positioned them (predicted data item and setting datum) there.

Not worth changing if we plan to define the other terms and fix things before the next release. 

-Alan

Melanie

The linked doc describes many of the aspects mentioned here in more detail. It proposes a number of design patterns and constructs for representation of data items and I'd be keen to discuss this further (it is still sketchy in many places) and develop together as a coherent proposal for changes to the ontology.

[1] https://docs.google.com/document/d/1zL0nW9RVqoC9sg6iajNZHex03JDnYUG4Q5F-e2rlZYg/

- Christian

 

2013/5/14 Alan Ruttenberg <alanrut...@gmail.com>

On Tue, May 14, 2013 at 2:49 PM, Bjoern Peters <bpe...@liai.org> wrote:

Agreed. I guess my point was that we should first agree on the definition of 'measurement datum' and the other classes before arguing if they belong under a parent. 

Yup 

---

We already have a class 'data item'. There might be some other useful superclass, or we could decide to rename the current 'data item'.  But the current 'data item' as-defined, won't be a parent of all three.

-Alan

On Tue, May 14, 2013 at 12:45 PM, Bjoern Peters <bpe...@liai.org> wrote:

In my mind, we were going to define measurement datum, prediction, setting etc. separately, and later see if it is useful to have a parent class 'data item' for these. 

- Bjoern

---

On 2013-05-13, at 11:14 AM, Alan Ruttenberg wrote:

>
>
>
> On Mon, May 13, 2013 at 1:46 PM, Christian Bölling <christian....@gmail.com> wrote:
> To help single out those discussion points reg. data item that might be due to terminological differences, I'd like to check whether what I understood from today's call is correct:
>
> iao:data items are to be understood are the output of measurements only.
>  
> No. There are other items which might be reliably correct, such as certain kinds of news reports, or the stock ticker. Or the price tags in a catalog.
>  
> Neither predictions nor specifications yield iao:data items, i.e. neither the prediction that tomorrow's average air temperature in a particular spot will be 30°C (as inferred from todays temperature and a meteorological model)
>  
> Correct. My interpretation is that because at the time your made the prediction, since the situation did not yet exist, it couldn't be about it. Let's copy this to the IAO list to see what other things. In any case, it isn't about the outside in the same way a measurement would be.

The current definition of data item is "a data item is an information content entity that is intended to be a truthful statement about something (modulo, e.g., measurement precision or other systematic errors) and is constructed/acquired by a method which reliably tends to produce (approximately) truthful statements."

If we consider the case of protein structure prediction, we do intend to make a truthful statement, it is about something (at least about the protein) and it is constructed by an expectedly reliable method (bioinformatics tools for example). I am not sure that the argument "the situation does not yet exist" is relevant, as the prediction is anyway about the software used, the experimenter etc, but in any case the protein may exist, may be folded and its structure is unknown - take for example GPCRs for which we have a pretty good idea of the structure but which are only slowly being crystalli

------------------------------------------------------------------------------

[Christian Bölling]

See inline.

- Christian

2013/5/15 Alan Ruttenberg <alanrut...@gmail.com>

On Wednesday, May 15, 2013, Christian Bölling wrote:

So all of us seem to agree that there are three types of information content entities (and perhaps more and various ways to define subtypes):

(1) those that are the output of a measurement process (whatever this is - see below) and believed to measure something (let's call them measuring data items - MDIs)

(2) those that are the output of a prediction process (whatever this is - see below) and believed to predict something (let's call them predicting data items - PDIs)

(3) those that are part of plans and recipes specifying setting or parameter values (let's call them settings data items - SDIs)

What is common to all of them is in my opinion that they are estimates of certain qualities (in many cases its qualities).

SDIs could perhaps be said to be different in that they specify qualities of things that they bear if they participate in a planned process that realizes a plan that is the concretization of a plan specification which the SDI is part of. So, the information that my incubator should be set at 30°C when performing an experiment of type EXP#1 specifies a quality of my incubator which it bears when it participates in a specific experiment of type EXP#1. If it is not at 30°C then the experiment performed is not of type EXP#1 (for all practical intents and purposes, we would allow a certain tolerance).  For me, such a perspective accounts for both the 'directive' and 'descriptive' aspects of settings which Melanie described above (and which I see too).

I find it much harder to define a difference between (1) and (2) which means to draw a line between measurement and prediction. I can see that there is a difference between estimating the current air temperature in my backyard using a thermometer and estimating tomorrow's air temperature by today's and a meteorological model. 

Yes, but prediction has a much wider scope. It can include situations which depend on uncommon or even those which might never exist. For example, perfecting the change in oxygen production on the planet in the case of a 15 deg increase of planet temperature. Or what kinds of life could evolve on the conditions speculated upon to be present in the waters of the moons of Jupiter. 

 

But I suspect that it is a very slippery slope from clearcut 'measurement' to clearcut 'prediction, because any observation is interpreted on the background of models. Alan seems to propose a distinction along the lines of 'reliability of correctness' and/or 'timepoint of estimation relative to timepoint of actualization'. 

A strong distinction, at least, between measurements of things that exist versus those that don't or might not.

Where does measurement end and where prediction start? How is the threshold defined between firm belief that a certain thing exists for sure, probably exists, may be exists? Can you propose a useful distinction? I believe that in both cases it is a continuum, even simple measurements have a predictive aspect as we acquire beliefs about the outside world. I can't see any useful criterion and frankly, I don't think it is necessary to find one for the purposes (at least I) would like to use the ontologies.

 

 

I think neither of them is suitable: what is considered reliable may depend on context or discipline or indeed purpose. 

Yes. But in each field there are standards that amount to this, and an understanding of difference between measuring something now versus simulating something that might have been or might be.

Which is, as I said before, precisely why those standards, why the methods with which a certain data item was derived must be represented to enable users to judge its reliability (possibly by their own, varying standards). It is this and not a one-fits-all distinction between measurement and prediction what is needed.

 

Timepoint is dubious because we make estimations about events that are not 'now' in science all the time: the assertion that there was a huge meteor impact 65 Million years ago is a prediction inferred on the basis of a number of physical and geological theories. 

Yes. I don't think that would be a measurement unless if it wasn't by a method that had sufficient history and independent validation. 

 

And the biomedical sciences are no different: we use estimates of characteristics of biological entities from observations made in the past to interpret observations made later in time: any diagnosis in a practitioner's office is such an inference. Effectively we predict that patient X has measles because she shows symptoms similar to those of past patients typed as such.

Melanies example of protein structure is another such example: People started developing algorithms to infer 3D-structure on the basis of protein sequence and other characteristics (estimated with yet other methods). They have confidence in these algorithms because these were (I presume) trained using a number of proteins for which there were indeed 3D-structure estimates based on other methods considered adequately reliable (such as X-ray diffraction). Of course, in turn, X-ray diffraction first had to gain that status which it (presumably) gained when models of molecular structure were developed. Nevertheless, there could always be a protein for which a given algorithm fails (as well as another method of estimating its structure).

Yes. We predict them. Based on measurements. The difference is sufficient that the language has clearly distinguished it.

But this is a historical process. May be in 50 years from now deriving estimates of protein structure is conceived as reliable as x-ray diffraction was 50 years ago. Language adapts. What stays and what really enables us to judge such estimates are the methods and their underlying assumptions, regardless of the label 'measurement' or 'prediction'.

 

I think what is far more important, at least for the purpose of knowledge engineering using computational ontologies is to acknowledge that in both measurement and prediction we draw inferences from a background of observations and models (theories). 

Not all predictions are such.

Which aren't (in a scientific context)?

 

This background is for both 'measuring data items' and 'predicting data items' the basis for plausibility, re-use, further inferences etc. which is why representation of that background is needed in any case to assess the reliability of an estimate, regardless wether it is categorized as 'measurement' or 'prediction'.

As you can tell, I don't agree.  

Now, by which terms MDIs, PDIs and SDIs should be referenced we should discuss (why not using these) as well as any useful super-classes. I would opt for using 'data item' for any of the three (to me this seems a natural choice and in-sync with lab colleagues) and providing sub-classes as needed to distinguish SDIs and method- or objective-specific measurement/prediction data items as needed. This would require only few changes in IAO, provided that the textual definition fo data item is updated, 

The current data item term should remain. It is a useful distinction. If you want to add a term, that seems reasonable, assuming a good definition. You could even perhaps borrow the existing label, but let's discuss this after you give your definition.  

 

as I have argued before [1]:

Proposal for new definition:

A data item is an information content entity that is obtained as specified output of some measurement, simulation, prediction or in general a means of obtaining an estimate for a quality of something or specified as value of a quality of something that is refered to in a plan specification.

This is a bare disjunction. Like: a fruit I like is an apple, orange or plum.

I'd rather have you explain what is wrong with the proposed definition.
 

[Philippe]

Leaving aside the distinction between 'measurement' and prediction, I
would like to comment on Christian's actual proposal for representing
measurements:

-----
measurement_data_item subclassOf
data_item
is_specified_output_of some measurement
has_value some xsd:datatype
has_unit some unit
is_about some (bfo:quality and (bfo:inheres_in some bfo:independent
continuant))

-----

I believe what this is what was proposed more or less a year ago before
the notion of 'value specification' was introduced. It my eyes, it is
not needed and would just add weight so the solution outlined here (in
Christian document) is parsimonious , intuitive and straightforward for
users to pick up. These are important issue to keep in mind for ensuring
broad user acceptance.


The one thing to clarify in OBI is our current reliance on UO for
specifying using. It possibly points to an incomplete import of UO class
definition as OBI does not import the quality the Unit is about.

With the solution outlined above, and if UO is used, there seems to be
duplication of information about the quality, even though one may argue
the duplication could allow a more direct query.


As for the current representation relying on 'value specification', my
reading is that it would look like this:

'measurement datum'
and ('has part' some
('scalar value specification'
'has measurement unit label' only 'unit'
'specifies value of' some quality)

I can't see the benefit of that added nesting.



P.

On 16/05/2013 09:45, Christian Bölling wrote:
> See inline.
>
> - Christian
>
>
> 2013/5/15 Alan Ruttenberg <alanrut...@gmail.com

> <mailto:alanrut...@gmail.com>>

> ------------------------------------------------------------------------

>
> We already have a class 'data item'. There might be
> some other useful superclass, or we could decide to
> rename the current 'data item'. But the current
> 'data item' as-defined, won't be a parent of all three.
> -Alan
>
>
> On Tue, May 14, 2013 at 12:45 PM, Bjoern Peters
> <bpe...@liai.org> wrote:
>
> In my mind, we were going to define measurement
> datum, prediction, setting etc. separately, and
> later see if it is useful to have a parent class
> 'data item' for these.
>
> - Bjoern
>

> ------------------------------------------------------------------------

[Bill Hogan]

Two points:

1. Some predictions are rock solid: we can predict very precisely where Jupiter, Saturn, there moons, etc. will be tomorrow, a week from now, a year from now (barring some unforeseen cataclysm, but it's been working for awhile :-)

2. Uncertainty about the present does not relate to prediction in any way.  If I simply don't know whether it rained in Boston tomorrow, but I'm 60% sure it did for some reason, that's no prediction.  That's just my lack of certainty about how the world really is/was.

3. Which means that uncertainty about what WILL happen is fundamentally different from uncertainty about now/past.

Bill

[Alan Ruttenberg]

On Thu, May 16, 2013 at 9:38 AM, Bill Hogan <hog...@gmail.com> wrote:

Two points:

1. Some predictions are rock solid: we can predict very precisely where Jupiter, Saturn, there moons, etc. will be tomorrow, a week from now, a year from now (barring some unforeseen cataclysm, but it's been working for awhile :-)

Agreed. But they are still not measurements. 

2. Uncertainty about the present does not relate to prediction in any way.  If I simply don't know whether it rained in Boston tomorrow, but I'm 60% sure it did for some reason, that's no prediction.  That's just my lack of certainty about how the world really is/was.

3. Which means that uncertainty about what WILL happen is fundamentally different from uncertainty about now/past.

Yup. 

[Bill Hogan]

On Thursday, May 16, 2013, Alan Ruttenberg wrote:

On Thu, May 16, 2013 at 9:38 AM, Bill Hogan <hog...@gmail.com> wrote:

Two points:

1. Some predictions are rock solid: we can predict very precisely where Jupiter, Saturn, there moons, etc. will be tomorrow, a week from now, a year from now (barring some unforeseen cataclysm, but it's been working for awhile :-)

Agreed. But they are still not measurements. 

I agree too.  

[Phillip Lord]

Bill Hogan <hog...@gmail.com> writes:
>> On Thu, May 16, 2013 at 9:38 AM, Bill Hogan

>> <hog...@gmail.com<javascript:_e({}, 'cvml', 'hog...@gmail.com');>

>> > wrote:
>>
>>> Two points:
>>>
>>> 1. Some predictions are rock solid: we can predict very precisely where
>>> Jupiter, Saturn, there moons, etc. will be tomorrow, a week from now, a
>>> year from now (barring some unforeseen cataclysm, but it's been working for
>>> awhile :-)
>>>
>>
>> Agreed. But they are still not measurements.
>>
>
> I agree too.

It's a thin line. If I measure something, then use a calculation to work
out another value, this is some derived data.

But, say I measure voltage my measuring current across a known resistor,
is this derived? Or an implementation detail of my volt meter.

If I how quickly a gap is disappearing, and say "the gap will be gone
tomorrow" is this not just a measurement with an unusual unit.

And not necessarily that unusual. Most electrical hardware comes with a
mean-time-to-failure -- but this is not a prediction, it's a
measurement, based on actual performance, in much the same way that
power consumption is. Just because something concerns events in the
future doesn't mean that it is actually, a prediction.

The same issue holds we "predicted proteins"; this is an interpretation
of a measure. We are not saying "we predict that this protein will occur
in the future". We are saying that we have measured some properties of
this piece of DNA, and are translating it in a particular way.

As always, the issue is not black and white. Having a roughly
appropriate rule of thumb, and then seeing if it works in practice,
whether it is actually useful seems the way forward to me.

Phil

[Alan Ruttenberg]

On Thu, May 16, 2013 at 11:57 AM, Phillip Lord <philli...@newcastle.ac.uk> wrote:

Bill Hogan <hog...@gmail.com> writes:
>> On Thu, May 16, 2013 at 9:38 AM, Bill Hogan

>> <hog...@gmail.com<javascript:_e({}, 'cvml', 'hog...@gmail.com');>

>> > wrote:
>>
>>> Two points:
>>>
>>> 1. Some predictions are rock solid: we can predict very precisely where
>>> Jupiter, Saturn, there moons, etc. will be tomorrow, a week from now, a
>>> year from now (barring some unforeseen cataclysm, but it's been working for
>>> awhile :-)
>>>
>>
>> Agreed. But they are still not measurements.
>>
>
> I agree too.

It's a thin line. If I measure something, then use a calculation to work
out another value, this is some derived data.

But, say I measure voltage my measuring current across a known resistor,
is this derived? Or an implementation detail of my volt meter.

The voltage is a proxy for the thing. This can be represented in OBI should you wish to add the detail. 

 

If I how quickly a gap is disappearing, and say "the gap will be gone
tomorrow" is this not just a measurement with an unusual unit.

I don't think so.

 

And not necessarily that unusual. Most electrical hardware comes with a
mean-time-to-failure -- but this is not a prediction, it's a
measurement, based on actual performance, in much the same way that
power consumption is.

Yes, but it is a measurement that is made on a population. Since there is a single device it can't possibly a property of the single device.

 

Just because something concerns events in the
future doesn't mean that it is actually, a prediction.

Well, yes, it does.

 

The same issue holds we "predicted proteins"; this is an interpretation
of a measure. We are not saying "we predict that this protein will occur
in the future". We are saying that we have measured some properties of
this piece of DNA, and are translating it in a particular way.

Yes, but a predicted protein is not is_a protein. It is a prediction. You know it is a prediction because it has the possibility of decisively being rejected.

 

As always, the issue is not black and white. Having a roughly
appropriate rule of thumb, and then seeing if it works in practice,
whether it is actually useful seems the way forward to me.

We did that with data item. There's no need to change data item, since it is useful. We can certainly add a different term if we have a different commonality. I don't see what, precisely, the problem is.

-Alan

 

Phil

[Phillip Lord]

Alan Ruttenberg <alanrut...@gmail.com> writes:
>> But, say I measure voltage my measuring current across a known resistor,
>> is this derived? Or an implementation detail of my volt meter.
>>
>
> The voltage is a proxy for the thing. This can be represented in OBI should
> you wish to add the detail.

As predictions of the future can be a proxy for the present.

>
>
>> If I how quickly a gap is disappearing, and say "the gap will be gone
>> tomorrow" is this not just a measurement with an unusual unit.
>>
>
> I don't think so.
>
>
>>
>> And not necessarily that unusual. Most electrical hardware comes with a
>> mean-time-to-failure -- but this is not a prediction, it's a
>> measurement, based on actual performance, in much the same way that
>> power consumption is.
>
>
> Yes, but it is a measurement that is made on a population. Since there is a
> single device it can't possibly a property of the single device.

1Tb hard drive.
60W light bulb.

>> Just because something concerns events in the
>> future doesn't mean that it is actually, a prediction.
>>
>
> Well, yes, it does.

Q. How far is it to to the shops?
A. Well, on foot, it will take you five minutes.

Prediction? I think not.

>> The same issue holds we "predicted proteins"; this is an interpretation
>> of a measure. We are not saying "we predict that this protein will occur
>> in the future". We are saying that we have measured some properties of
>> this piece of DNA, and are translating it in a particular way.
>>
>
> Yes, but a predicted protein is not is_a protein. It is a prediction. You
> know it is a prediction because it has the possibility of decisively being
> rejected.

Yesterday, I predict that you had beans on toast for lunch. Decisive
rejection doesn't demonstrate that it's a prediction.

A predicted protein is not the same as a weather prediction. The
first is a statement about a property of today that we may measure
in the future; the other is a statement today about the future of a
property, that we may measure.

That the two are different is easy to demonstate. The measurement about
tomorrows weather prediction can only be made tomorrow. The measurement
that demonstates a predicted protein exists could be made tomorrow. Or
today. Or we could have made it last week, but not intepreted the
results yet.

So, a predicted protein is not a prediction. It's a possibility.

[Alan Ruttenberg]

On Friday, May 17, 2013, Phillip Lord wrote:

Alan Ruttenberg <alanrut...@gmail.com> writes:
>> But, say I measure voltage my measuring current across a known resistor,
>> is this derived? Or an implementation detail of my volt meter.
>>
>
> The voltage is a proxy for the thing. This can be represented in OBI should
> you wish to add the detail.

As predictions of the future can be a proxy for the present.

 

We have a relation called is_proxy_for. Did you read the definition? I used the word "proxy" to mean that relation. 

>
>
>> If I how quickly a gap is disappearing, and say "the gap will be gone
>> tomorrow" is this not just a measurement with an unusual unit.
>>
>
> I don't think so.
>
>
>>
>> And not necessarily that unusual. Most electrical hardware comes with a
>> mean-time-to-failure -- but this is not a prediction, it's a
>> measurement, based on actual performance, in much the same way that
>> power consumption is.
>
>
> Yes, but it is a measurement that is made on a population. Since there is a
> single device it can't possibly a property of the single device.

1Tb hard drive.
60W light bulb.

 Yes? And? 

 

>> Just because something concerns events in the
>> future doesn't mean that it is actually, a prediction.
>>
>
> Well, yes, it does.

Q. How far is it to to the shops?
A. Well, on foot, it will take you five minutes.

Prediction? I think not.

On the way you stop to tie your shoe. Or have some food. Or get splashed. Or stub your toe. 

Prediction? I think so.  

>> The same issue holds we "predicted proteins"; this is an interpretation
>> of a measure. We are not saying "we predict that this protein will occur
>> in the future". We are saying that we have measured some properties of
>> this piece of DNA, and are translating it in a particular way.
>>
>
> Yes, but a predicted protein is not is_a protein. It is a prediction. You
> know it is a prediction because it has the possibility of decisively being
> rejected.


Yesterday, I predict that you had beans on toast for lunch. Decisive
rejection doesn't demonstrate that it's a prediction.

A predicted protein is not the same as a weather prediction. The
first is a statement about a property of today that we may measure
in the future; the other is a statement today about the future of a
property, that we may measure.

That the two are different is easy to demonstate. The measurement about
tomorrows weather prediction can only be made tomorrow. 

The measurement
that demonstates a predicted protein exists could be made tomorrow. Or
today. Or we could have made it last week, but not intepreted the
results yet.

So, a predicted protein is not a prediction. It's a possibility.

Fine. It just isn't a measurement. 

Remind me what the problem is?

(There isn't one)

 

Phil

[Phillip Lord]

Alan Ruttenberg <alanrut...@gmail.com> writes:
> On Friday, May 17, 2013, Phillip Lord wrote:
>

>> Alan Ruttenberg <alanrut...@gmail.com <javascript:;>> writes:
>> >> But, say I measure voltage my measuring current across a known resistor,
>> >> is this derived? Or an implementation detail of my volt meter.
>> >>
>> >
>> > The voltage is a proxy for the thing. This can be represented in OBI
>> should
>> > you wish to add the detail.
>>
>> As predictions of the future can be a proxy for the present.
>
>
> We have a relation called is_proxy_for. Did you read the definition?

It's generally easier to have a discussion if you don't patronize people.

> I used the word "proxy" to mean that relation.

Yes. Never understood why it was limited to continuants.

>> >> If I how quickly a gap is disappearing, and say "the gap will be gone
>> >> tomorrow" is this not just a measurement with an unusual unit.
>> >>
>> >
>> > I don't think so.

Put water into a container. Container has small hole in the bottom.
Unplug hole. Measure time tilll container empties. Time to empty gives
you a measure of quantity.

>> > Yes, but it is a measurement that is made on a population. Since there
>> is a
>> > single device it can't possibly a property of the single device.
>>
>> 1Tb hard drive.
>> 60W light bulb.
>
>
> Yes? And?

If all these are to be measurements made of a population (which they
are), you are going to run out of things which are not.

>> Q. How far is it to to the shops?
>> A. Well, on foot, it will take you five minutes.
>>
>> Prediction? I think not.
>
>
> On the way you stop to tie your shoe. Or have some food. Or get splashed.
> Or stub your toe.
>
> Prediction? I think so.

It's a shame that "you" in English cannot distinguish number.

> The measurement
>> that demonstates a predicted protein exists could be made tomorrow. Or
>> today. Or we could have made it last week, but not intepreted the
>> results yet.
>>
>> So, a predicted protein is not a prediction. It's a possibility.
>
> Fine. It just isn't a measurement.
>
> Remind me what the problem is?
> (There isn't one)

Same problem as always. You are making things too complex. I can sit
here and split hairs as much as you can.

I shall go back to lurking for a while now.

[James A. Overton]

I agree with Philippe. I don't see the need for a "value specification" class when we can just specify the value and the unit on the measurement/prediction/setting item itself. I can see that "value specification" would be needed...

1. if we can have multiple value specifications for a single item, e.g. one "measurement data item" has two or more "value specifications" as parts. But I thought we would use multiple items in a "data set" (or a new alternative) when there are multiple values. Does someone have a clear use case for multiple value specifications on a single measurement/prediction/setting item?

2. if we really need to subclass "value specification" into "mass value specification" etc. But I think that it would be more efficient and effective to draw inferences from the types of the unit, which should distinguish mass, acceleration, concentration, etc. without having to build a new hierarchy. The "categorical value specification" is a difference case, which is not clear to me. Can somebody defend the need for a new hierarchy under "value specification"? (Or point me to an argument for it.)

I think that the main problem is that IAO has many classes with the old approach mixed with a few classes from the new approach. I'm willing to make a clean version for comparison, but I'd like to be clear about the need for a "value specification" class (and hierarchy) before I do that.

Thanks,

James