[QUANTITY] Data Model for Quantity v0.5

[Brian Thomas]

On Monday 10 May 2004 10:10 am, 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.

	I believe that packaging belongs at a more fundamental level than
	observation. In order to satisfy the requirement that quantities be
	exchangeable, and be able to wrap legacy (ASCII/Binary) data, they
	need access and to work in tandem with to the packaging information.

	I'm OK with a separate namespace, that is co-equal with "quantity"
	to hold packaging information. Don't make this a highlevel model.

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

	Our group has such a model based on the packaging resource schema which	
	were passed around the observation/quantity groups this past week.
	No UTYPE needed. UTYPE is a VOTable-ism, and not general in nature.

>
> 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?)

	What if the data are theoretical in nature? If I have a numerical model of
	a galaxy and then serialize that, is it an "Experiment"? Or am I confusing
	the semantics with "Measurement" (e.g. no measurement is theoretical in
	origin)?

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

	To be clear, this approach means to throw away doing any quantity at all.

	In the end, this will be very complex model with no reusable parts. The supporting
	library is likely to be quite large and complex and difficult to implement and
	understand and maintain.

	I don't see how this will be extensible either as it amounts to proscibing a universal model
	(or set of models) for all, from which nobody can extend without breaking the functionality 
	of the VO as a whole. I vote "no!" for this. Proponents: please outline how you can satisfy 
	VO needs with this kind of approach.

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

	I disagree. First: the present serialization *does* allow for tagged values.
	There is an *option* to not tag values. Why? For several important reasons:

	1. Compactness (tags may double or triple data size. For large amounts of data, this is
            unacceptable)
	2. Compatability with legacy data.

	Furthermore, (and perhaps I am wrong, someone please confirm/deny) You CAN have
	PCDATA that are separated by whitespace and have it validate by a schema, so this 
	sort of thing *is* allowed in the XML (schema) spec, as far as I'm aware. If an application
	breaks because of space-delmits, then its because the app is not completely XML compliant.

	[And its simply not that hard to parse a set of datum that are separated by strings!!]

	I'll admit that we *could* put the space-delimited data sections within a "packaging" package
	that the Q could call. But thats only shifting the functionality over to another part
	of the serialization.

>
> Documentation:
>
> - More detailed explanation of Phenomenon concept (Hill)
> - More astronomy language and less computer language (Micol)
>
>
> What have I missed?

	I have some other minor edits for Q, which I will wait for IVOA to name.


	cheers,

	=b.t.

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]