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

Wed May 5 03:14:43 PDT 2004

Thanks David that's helped a lot!  Please could many of these answers go 
into the document?

A couple of minor points:

 >>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.
 >

This suggests that the desired (J2004.0 FK5) frame is 'applied' as part 
of the interaction with a Quantity set in its own frame. Or, better, we 
should have a conversion process that creates a new CoreQuantity with 
the new (J2004.0 FK5) frame from the CoreQuantity with the old (ICRS) 
frame.  Otherwise we get all kinds of nasty problems when several bits 
of code are using the same Quantity instance, each one expecting it to 
have a certain frame.

 >>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".

When I say 'properties' (not 'fields') this is a bit of software 
engineers term but does not represent storage.  It merely says 'this 
object is an assembly of these things _from the outside_ '.  As soon as 
you specify methods you specify implementation - for example, whether a 
'set' method returns a boolean 'success/fail' or throws an exception is 
language dependent.  (eg Java implementations should throw exceptions).

Cheers,

Martin

David Berry wrote:

> 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

-- 
Martin Hill
www.mchill.net
07901 55 24 66