Relationship between Q and STC
dsb at ast.man.ac.uk
Mon May 10 13:29:43 PDT 2004
> > Because an axis is not a Quantity, it's a phenomenon.
> That is not true. An axis is a phenomena that describes one dimension
> of another phenomena. For example, "FLUX(Time)" [flux measurements
> recorded for a particular time] is a 1-dimensional quantity where the
> "TIME" quantity is both a phenomena (of "time") AND describes a
> dimension of (and is thus an "axis") of another.
The point I was making that an axis *describes* a phenomenon but does not
provide any values for that phenomenon. So:
1) "topcentric radio velocity in units of km/s" *is* an axis and is
equivalent to a 1D Frame. This is "the phenomenon".
2) "23.345 34.23 100.23" are values and can be stored in a ValuesList or
generated by a Mapping.
3) Put together the Frame and the Mapping (or ValuesList) and you have a
Quantity, That is, a a list of values for some phenomenon.
This is why I say an axis by itself (without any associated axis *values*)
is not a Quantity, it's a Frame.
> > An STC document does not specify any particular *positions* in space-time
> > coordinates, it just describes a coodinate system, so what values are
> > you going to put into an STC Quantity?
> It doesn't have to be providing the actual positions to be a Q. All that
> is needed is that I pair a value with it (Frame information is *optional*,
> and in the STC variant I provide, you cant put coordSystem information
> on any of the STC components as that would be wrong).
> Certainly, for the STC components there are enumerated values (as
> I previously described) which are allowed to be there. Are there no phenomena
> for which a limited, discrete set of values exist? I think so, and hence,
> STC *can* and *is* a Q.
> > > > But a Quantity should be "a rule for obtaining values", and STC
> > > > specifically excludes issues to do with obtaining values - its just
> > > > defines the coordinate syetem and so is a Frame, not a Q.
> > >
> > > Thats not true. I see components of the STC as quantities,
> > > for example "StandardReferencePosition" is a quantity, albeit one
> > > which is allowed to take one of a restricted set of values, e.g.
> > > "GEOGENTER", "BARYCENTER", etc.
> > "StandardReferencePosition" simply corresponds to a property of the Frame
> > described by the STC document. There is no need to consider it to be a
> > Quantity.
> > > And if I can get all the component parts of the ST to be Q's (and
> > > I can) then this means at the STC itself can be a Q (as StandardQ
> > > allows holding "member" Q's).
> > But again, the whole notion of an STC document is that it describes a
> > coordinate system without specifying any positions within that coordinate
> > system.
> Quit getting hung up on the values of the actual coordinates, thats a
> red herring. The STC is a quantity that provides meta-data about coordinates,
> the actual coordinate values are held by a parent Q.
This comes back to what a Quantity is. The above says that STC *is a*
Quantity, but it has no values (the values are held elsewhere, in a
"parent" Quantity). So we come back to the same point, is the
purpose of a Quantity to hold *measured values* for some
phenomenon. Presumably you would say not since you say that STC is an
example of a Quantity which does not contain any values.
> > Your star catalogue has columns corresponding to RA and Dec, the
> > associated STC document describes this (RA,Dec) system but does not itself
> > include the numerical values stored in the table columns. The STC document
> > is the Frame, the table columns are the ValuesLists, and both *together*
> > form a Quantity.
> *sigh* I guess I will have to grab an example and put it in the email since
> nobody is actually looking at the tarball. Please take a look and comment
> on the example.
Apologies! Your example made me realise that I have not been very precise
about what I mean by "STC". I have been equating "STC" with the
"CoordSystem" element. So in my previous points, make a global edit of
"STC"->"CoordSystem". Obviously the STC schema also includes the "Coords"
element which *does* include axis values, and so *is* equivalent to a
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
More information about the dm