[QUANTITY] Requirements and apology

[Ray Plante]

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