[QUANTITY] and [OBSERVATION] data models: new drafts - comments on Quantity

[David Berry]

Martin,
        Some selected responses...

> Phenomenon: Perhaps a bit more clarity here.  Does a 'phenomenon' embrace value,
> name, error etc all in one lump?  Or is it just the name/identifier of a
> property? Can we just call it 'property' if that's the commonly used term?

It's just the "name/identifier".

> Coordinates: Are you saying that a Coordinate is a Quantity of quantities?  Is
> this just a general case of Array Axes?  If not, let's leave out the references
>   Array Axes as it just confuses me!

I think the idea is that in general there may be several different
coordinate systems which you can use to describe positions within the
array of values in a Quantity. If your Quantity values are organised as
(say) a n-D cube, then you address them ultimately using a set of n
"pixel coordinates" (generalising the word "pixel" to mean an element of
any n-d array). But it is posible to allow other coordinate systems to be
used (e.g. (RA,Dec), etc), in which case the Quantity must contain
information which describes these coordinate systems, and which describes
how to map positions into pixel coordinates. The current draft of the
Quantity doc sees such extra coordinate systems as "Quantities" in their
own right, contained within their parent Quantity. This may take a bit of
getting used to because many people probably think of a "Quantity" as one
or more discrete sampled values for some stated phenomenon, whereas they
may think of an "axis" as a description of a continuous line with no
sampled values (e.g. "declination" is an axis, but it is not defined by
a discrete set of sampled numerical values). This issue generated much
robust discussion amongst the current contributors to the document, but
in the end we went with a compromise in which (to quote section 6) "a
Quantity object can be thought of as a rule for getting values together
with a Frame (context) for those values". The idea is that this "rule" may
take the form of simply looking the value up in an array, but may also
take the form of applying a Mapping to an externally supplied input value
to obtain the required Quantity value. The first form of the rule can be
used to describe arrays of discrete sampled values, and the second form
can be used for describing coordinate axes or for describing Mappings of
the discrete sampled values into other data value systems (e.g.
alternative calibrations, etc). In principle, the roles of these two forms
of the "rule" could be swapped.

> 4.13 Data Type: I don't understand sufficiently how Quantities and their
> internals can be arranged to give the examples at the bottom of the page.  Could
> this be written more explicitly?  eg, how can a Quantity of array of 2 doubles
> *not* be of type "array of 2 doubles" ?!

The issue of data type refers to the question "if I get a single element
out of this Quantity, what will its data type be?". So the paragraph is
saying that a Quantity containing 2 doubles can be of two types - in one,
a "single element" corresponds to one double and the Quantity contains two
elements; in the other, a single element corresponds to two doubles and
the Quantity contains only one element.

> 5 BasicQuantity Model: For clarity, could the diagram list the properties of
> BasicQuantity, not the methods?

We specifically chose to focus on methods (i.e. interfaces) in order to
model what you can *do* with a Quantity rather than how it is stored. This
to me is an important part of the distinction between a "data model" and a
"data format".

> I'd also suggest that BasicQuantity should be
> (largely) immutable (ie users cannot arbitrarily change individual properties).
>   Allowing users of it to change, for example, the coordinate system of an
> existing BasicQuantity does not make sense (because either the value was wrong
> before, or it will be afterwards), and will cause problems when other users have
> a handle on it.  Similarly units, and data types.

I'd probably agree with BasicQuantity. CoreQuantity is another matter
though. For instance, you have a StandardQuantity representing a surface
brightness image of a galaxy, and this StandardQuantity contains a
CoreQuantity which defines an ICRS (RA,Dec) calibration for the image
(i.e. it contains an (RA,Dec) Frame, together with a Mapping between
pixel coords and (RA,Dec)). Let's say a user wants to use J2004.0 FK5
(RA,Dec) instead of ICRS when interacting with the Quantity. To do this
they would use methods of the CoreQuantity class to change the properties
of the (RA,Dec) Frame appropriately. The CoreQuantity class would also
then modify its Mapping to retain the integrity of the pixel<->(RA,Dec)
relationship.

> Out of curiosity, why do the  set methods return boolean?

I seem to recall it is to indicate whether the operation has suceeded (a
platform-neutral alternative to throwing an exception).

> p18-19 - before doing the difficult example, can you include a simple one?  So
> we can see how a straightforward mapping might work for example?

Mappings are the subject of another document which hopefully will be out
shortly.

> In the more complex example - what will V1 and V2 represent?  ie after
> all that work, what are we getting?

V1 and V2 are flux values ultimately stored in the "Flux" CoreQuantity.

> 7.4 - pedantic point end of para 3; I believe the text should refer to the
> 'superclass', rather than the owning 'parent', unless I've misunderstood a lot!

I agree. Brian?

> In general however I feel the XML shows up one of the problems of using Quantity
> to represent data types that are naturally different. We can't, for example,
> validate that a quantity is a correct observation.

What do you mean by a "correct observation"? The Quantity class is really
just meant as a general purpose bucket to put stuff in. It is the job of
higher level models such as Observation to manage and validate these
buckets in a way which makes sense in the context of the higher level
model.

> I don't think we need a 'metadata' section - by this I mean the values should
> not be lumped under such a heading.  Some quantities will be considered metadata
> by some people but not others, so can they not just go in as peer elements?

Good point.


David



----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX                                Tel. 01772 893733
                                             01257 273192