[QUANTITY] Requirements and apology
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Thu Oct 30 10:31:56 PST 2003
Hi Dave,
On Thu, 30 Oct 2003, David Berry wrote:
> The other issue is that Ray's model doesn't include a QUALITY component.
(I was hoping what I posted were requirements and not a model itself ;-)
> I think a useful
> working principle for a Quantity would be that you should be able to
> interpret and use it independantly of its parent structure. That is, if
> you extract a Quantity from its parent structure you should still be
> able to make use of it. This would argue in favour of putting the QUALITY
> information *inside* the Quantity.
I actually disagree with this principle (at least in how its applied).
Each level of a data model has information in it. If you separate a
component from its enclosing parent structure, you naturally lose
information. So certainly in that case, you cannot do as much with it as
you could when it was part of its parent; nevertheless, it may still be
useful in its simplest form, either because there is a context assumed by
the application or because that "lost" information is just not important
(or known).
Suppose we have a more complex measurement model for a Flux that includes
an observation frequency. The frequency can be described as a quantity.
Does that quantity need a quality flag? Does it need a WCS? For many
uses of the Flux, the answer would be no.
I think a better principle is that the Application (e.g. a Web Service
interface, a function interface, etc.) declares the level of detail it
requires. This determines whether a high level model is needed or a
low-level one is sufficient.
My concern about "quality" is that how one might rate a measurement may
depend greatly on what the measurement is; thus, I would prefer to leave
it out. Nevertheless, it is not unlike "error", so I can see an argument
for keeping it in. "WCS" I'm much less inclined toward: this metadata is
really about relationships between the quantity and other
contextual concepts. This says to me that it should be at a higher level.
"Error" can illustrate how we might put in "hooks" inside a "quantity". I
would recommend that the base model define an abstract error class with a
small set--the obvious 2 or 3--sub-classes of error (e.g. standard
deviation, confidence range). More complex forms can be defined outside
the core model. Something similar could be done with "quality", but we
should proceed cautiously. We should be inclined towards simpler models.
cheers,
Ray
More information about the dm
mailing list