[QUANTITY] Data Model for Quantity v0.5

[Jonathan McDowell]

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?