Currently we define DV_QUANTIFIED.accuracy as a DV_QUANTITY. This means that the accuracy itself can be a quantity just like the quantity referring to it, e.g. 85kg +/- 2kg, or it can be a percentage, e.g. 85kg +/- 2%. Note that the former is absolute (doesn't change with the magnitude of the value) and the latter is proportional (does change). There is an argument that says that only percentages are ever really needed. If so, this would simplify the model, since we can just have a REAL number rather than a whole other DV_QUANTITY.
Thoughts?
- thomas beale
Currently we define DV_QUANTIFIED.accuracy as a
DV_QUANTITY. This means
that the accuracy itself can be a quantity just like the quantity
...
There is an argument that says that only percentages are
ever really
needed. If so, this would simplify the model, since we
can just have a
REAL number rather than a whole other DV_QUANTITY.
Thoughts?
For the model, DV_QUANTIFIED.accuracy is more appropriate. If, in
an implementation, the developers want to accommodate users (person,
instrument or external application) with a quantity. Then it can be
converted to a percentage for storage and back again for display if
desired. My point is that I agree with simplifying when something
can/should be an implementation issue.
Tim Cook
Open Paradigms, Consulting
Open Source Applications Support
Tim Cook wrote:
For the model, DV_QUANTIFIED.accuracy is more appropriate. If, in
an implementation, the developers want to accommodate users (person,
instrument or external application) with a quantity. Then it can be
converted to a percentage for storage and back again for display if
desired. My point is that I agree with simplifying when something
can/should be an implementation issue.
so in other words: represent and store as a % but allow input and display as DV_QUANTITY or %? Hm... this might need an extra flag if the DV_QUANTIFIED object is to remember whether it was originally in % or quantity form. But that's still quite a bit simpler than what we are doing now (especially as we have to have extra constraints in there saying that DV_QUANTIFIED.accuracy.is_simple, meaning it cannot have its own accuracy, as this would be meaningless. It would be nice to get rid of this. I think I am convinced that just by storing a percentage, we get the same effect as the current model.
- thomas beale
so in other words: represent and store as a % but allow input and
display as DV_QUANTITY or %? Hm... this might need an
extra flag if the DV_QUANTIFIED object is to remember whether it
was
originally in % or quantity form.
Extra flag (attribute) good point.
DV_QUANTIFIED.is_quantity BOOLEAN
of this. I think I am convinced that just by storing a
percentage, we get the same effect as the current model.
I agree.
Tim Cook wrote:
For the model, DV_QUANTIFIED.accuracy is more appropriate. If, in
an implementation, the developers want to accommodate users (person,
instrument or external application) with a quantity. Then it can be
converted to a percentage for storage and back again for display if
desired. My point is that I agree with simplifying when something
can/should be an implementation issue.
so in other words: represent and store as a % but allow input and display as DV_QUANTITY or %? Hm... this might need an extra flag if the DV_QUANTIFIED object is to remember whether it was originally in % or quantity form. But that's still quite a bit simpler than what we are doing now (especially as we have to have extra constraints in there saying that DV_QUANTIFIED.accuracy.is_simple, meaning it cannot have its own accuracy, as this would be meaningless. It would be nice to get rid of this. I think I am convinced that just by storing a percentage, we get the same effect as the current model.
- thomas beale
Would it not be more elegant to make the (natural) assumption that the 'accuracy' will always have the same absolute unit as the primary quantity, with a separate flag to indicate a need to _display_ as "%"?
This may have an additional advantage with downstream processing, since most useful calculations (eg statistical or difference comparisons) will be looking for absolute values.
tony grivell
Would it not be more elegant to make the (natural)
assumption that
Hmmmm, you are quite correct Tony.
Your solution is much more natural/obvious.