[QUANTITY] Data Model for Quantity v0.5

[Martin Hill]

Mostly happy with that as a summary (although I have put in some 
comments recently about removing Mapping and applying it rather than 
including it).

How about this as a suggested approach change:

We define things like Frame, Accuracy, Co-ordinate systems, etc.  We 
then have two Quantities (CoreQuantity and StdQuantity) that implement a 
particular assembly of these things and act as examples for transforms, 
etc.  People can then assemble quantities or subclass from Quantities as 
they see fit.

Jonathan McDowell wrote:

> Here I try and summarize my understanding of the comments on the OBS and Q
> models, with a few replies by me. I have made minor updates to obs.tex/ps/pdf
> and qty.tex/ps/pdf on hea-www.harvard.edu/~jcm/www/vo/docs 
>  - Jonathan
> 
> OBS:
> 
> Bonnarel and Louys proposed a Packaging section. After minor
> editing I've included it in Obs.tex.
> 
> [But I think we need more than this: if we are to have an XML wrapper
> of FITS data, we need to have a way of identifying *parts* of the FITS
> file with metadata in the XML - a FITS path like XPATH which can
> be tied to XML elements or UTYPE entries.]
> 
> Gerard: need for identifiers for datasets. 
> 
> [Yes, I think we should just use the one developed by the journals,
> which is being adopted by the registry group]
> 
> Gerard: data trees as only one possible view of the archive complexity.
> 
> Gerard: change name of Provenance to Experiment (can other people vote
> on this please?)
> 
> Anita: Radio DM draft - bravo! Will reply in detail on this one soon.
> 
> QTY:
> 
> Suggested approach changes:
> 
> - Don't have a Q container model at all, every piece of data is its
> own class with a corresponding definition in the schema. (Hill)
> 
> - Build bicycles not jet fighters (Micol and Didelon).
> 
> [I concede that Q is rather complicated. But it does provide a nice path
> from the rather simple BasicQ, which does what Pierre et al. want, to
> the fancy StdQ, which does the jet fighter job. I think Brian's
> message today did a good job of summarizing the model, and we
> need something like this early on in the doc. I agree with David that
> existing astronomy systems are rather complicated and a too-simple model
> will not be able to interface with them. I believe that elaboration of
> the Observation model and its detailed application to real archival
> datasets will quickly lead us to using some of the fancier features of
> Q. In general though I think that computer scientist/programmers will 
> understand Q, and VO data center astronomers will work mostly with
> Observation and some specialized things derived from Q that Observation
> will need. The programmers will eventually be happy with the elegance 
> that all of the specialized things are just different forms of Q. If I'm
> right, this will fall out when we continue work on Observation and
> particularly on its serialization, so I'm hoping we can discuss that in
> the next couple of weeks prior to Interop.]
> 
> Suggested model changes
> 
> - I haven't seen any specific proposed changes to the Q model itself,
>   beyond suggestions that the whole idea is silly.
> 
> Suggested serialization changes:
> 
> - Array values tagged rather than space-separated (Hill)
> 
> Documentation:
> 
> - More detailed explanation of Phenomenon concept (Hill)
> - More astronomy language and less computer language (Micol)
> 
> 
> What have I missed?
> 


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