Quantity "tables"

[Ed Shaya]

Doug and Tony,
   
    You guys are talking about vocabulary and I am talking about 
grammar.  If  we have a language
that has statements (Object) with subjects (Object/@name) and predicates 
(Object/Quantity) and the predicates have verbs (Quantity/@type)  and 
objects, and the objects can be values (Quantity/value) or other 
statements (Quantity/Object), then we have a very rich language, almost 
as powerful as any spoken language.   It is a starting framework upon 
which we can  hang any specific vocabulary.
    It has it's limits though.  Complex procedures are of course 
difficult to put in.  Not impossible, but unreasonably  cumbersome.   
Here  I am thinking about things like the  interpolation  between  axis 
values in an  image or spectrum  to determine which index value is 
appropriate in a request for a pixel value.  This is not something that 
we are likely to do with XML tools, so we will definitely be needing 
specialized code.
    So you might ask, what do these extracted pixel values look like?  
Let's look at an example.
We have a molecular cloud and we have asked for the central pixel 
luminosity at K-band.  The return is

<Object type="MolecularCloud" name="Rho Oph Cloud">
       <QuantityWithObjects type="observation photometry">
                <Object type="pixel" name="Center of Rho Oph">
                      <Group type="position" equinox="J2000">
                      <RA type="center plus 
width"><value>16:26:20.2</value><units>ra_sexigesimal</units>
                               <width>23</width><units>arcsec</units>
                      </RA> 
                      <DE type="center plus 
width"><value>-23:40:22</value><units>de_sexigesimal</units>
                               <width>28</width><units>arcsec</units>
                      </DE>
                      <Quantity type="flux K-band">
                               <value errorValue="12.2">128.3</value>
                               <units>Jansky</units>
                      </Quantity>
             </Object>
       </Quantity>
</Object>

Here instead of a name, the pixel Object is required to have  a 
position  Group.   If there are more than one pixels, then instead of 
<value> elements, we would have <valueList> elements.  And, really there 
should be additional metadata saying when, where, and who of the 
observation.  Of course, the future structure of these Quantities will 
differ once there is a standard, but this is just to get out the general 
idea.

    Keep in mind that the point to this exercise was to answer Tony's 
question about how can we make maximal use of standard XML, the tools 
and the hierarchical structures.  I now think the answer is that we can 
go a whole lot further than we have gone so far, nevertheless we will 
need to write (or borrow) some specialized code, particularly for the 
more mathematical aspects in astronomy.

Ed


Doug Tody wrote:

>>Your example is fascinating but I wonder if someone else approaching the
>>same set of data would create the same hierarchical structure: ie, how easy
>>is it going to be to get all astronomers to agree on the one hierarchical
>>structure for the representation of astronomical data. Maybe we need to
>>define all the primitives - quantity, ucd, unit, instrument, etc - and some
>>of the most common and agreed simple structures like position and then come
>>up with the ability for astronomers, data centre managers, developers to
>>combine these into appropriate hierarchies for representing metadata. Using
>>the same primitives will at least allow interpretation of results even if
>>they exist in unfamiliar structures.
>>    
>>
>
>Tony - This is exactly what we mean when we talk about component data
>models which can be aggregated and associated to model complex datasets.
>
>We will never develop one data model for all astronomical data (one model
>to rule them all?).  A realistic approach is to model obviously useful
>things which are small enough that we can understand and agree upon them
>(components) and then stick these together to model actual datasets.
>A "spectrum" or "image" model would be assembled from these components.
>A conformant dataset would supply the minimum required elements of the
>dataset, but a given data provider could add other elements as well.
>This would give us, for each dataset, a standard core built from standard
>components, plus the ability for data providers to extend the core model
>with whatever information is required to describe the peculiarities of
>their data.  This would allow the structure we define in VO to evolve to
>work with the real data that data providers will publish to the VO.
>
>	- Doug
>
>  
>