[QUANTITY] Data types question (Was: Re: [QUANTITY] The discussion so far

[Brian Thomas]

On Friday 31 October 2003 10:22 am, Gerard Lemson wrote:
> Hi Brian
> My answer must be seen against a question I pose in my reply to Jonathan.
> I would really like to get feedback to this one:
>
> which concept(ion) of Quantity are we really trying to model in the
> "Quantity modeling effort" ?

	Hi Gerard,

	Its a good question, if not, "THE" question. I can only answer from
	my point of view right now, BUT, I believe that requirements will be
	the decider for what the community feels 'the quantity' is.

>
> At ADASS we seemed to agree somewhat that your and our models diferred
> along the lines that
> your model seems to model physical/persistent/stored representations of
> (collections of) numbers.

	But also (not that this is significant departure from your description) its 
	a model for enabling data fusion, slicing and transport. The 'slicing' functions
	are present to aid in fusion and search. In that sense, our "search" part overlaps
	a little with your conceptual model, which is geared towards data discovery (I think).
	
	I tend to think of your part as being a mixture of "component" and "basic" parts;
	depending on the implementation. As things stand right now, there is a "measurement",
	class being talked about and I consider this the absolute "basic" component of the DM,
	not a "component" (as all components will need to know how to deal with measurements).

	Its not too hard to marry both our models up, but its pointless if we cant get the 
	others in the DM group to agree with how we see things (or, alternatively, for us to
	change our picture to more closely match what the community wants).

> Ours is a conceptual model indicating what other (meta-)data/information is
> required to make
> scientific sense of these numbers.
> If Jonathan's suggestion is that it is harder to describe and implement a
> storage model for
> complex types I might agree. 

	Well, I should add that I feel there is an IO part which isnt being addressed 
	right now (and that might be the domain of the DAL group anyway). But the
	difficulties of storage would be faced most fully there not in "quantity".

> To describe a conceptual Quantity correctly
> using a complex type is
> less of a problem though, we've already done it. But even in the former
> case it seems that we
> better very quickly learn how to deal with types complexer than a single
> number, seeing the
> request/proposal for grouping in VOTables (and even UCDs) for example.

	Yeah, I suppose I agree, but to pick up on the sentiment I see in this group,
	we need to proceed in an orderly fashion implementing. As I said before,
	"Position" or other complex objects may be implemented/tested, but dont 
	count on them being "accepted" formally into "the model" (which in this
	sentence I mean not "quantity" but some other base package.  As per Pat's 
	diagram, I tend to see  data types, units, errors as a separate packages from 
	"quantity").

	Regards,

	-b.t.


> Gerard
>
> --
> * Gerard Lemson                       * Tel: +49 (0)89 30000-3316
> *
> * MPI fuer extraterrestische Physik   * Fax: +49 (0)89 30000-3569
> *
> * Giessenbachstrasse                  *
> *
> * Postfach 1312                       *
> *
> * D-85741 Garching, GERMANY           * email: gerard.lemson at mpe.mpg.de
> *
>
> > -----Original Message-----
> > From: Brian Thomas [mailto:brian.thomas at gsfc.nasa.gov]
> > Sent: Friday, October 31, 2003 4:02 PM
> > To: Gerard Lemson; dm at ivoa.net
> > Subject: [QUANTITY] Data types question (Was: Re: [QUANTITY] The
> > discussion so far
> >
> > On Friday 31 October 2003 08:34 am, Gerard Lemson wrote:
> > > > Does Q support complex types?
> > > >  Dowler::Type = Ellipse2D, Oct 27
> > > >  Dowler, polygon types (Oct 29)
> > > >  McDowell: suggest we not rule this out, but an initial
> > > > implementation would only support basic datatypes.
> > >
> > > I think we have to immediately, for example Position.
> >
> > 	Gerard,
> >
> > 	Well, I think the gist of Jonathan's comment is that we create a
> > 	basic interface. This won't preclude trying to come up with more
> > 	complex objects by some, but the focus for "blessed" types will
> > 	be the basic ones. I agree with you that we need to "test" the
> > 	interface with interesting types like Position. I agree
> > with Jonathan
> > 	that the intial focus are the "primatives" (but I bet thats pretty
> > 	easy to knock off).
> >
> > 	Regards,
> >
> > 	-b.t.
> >
> >
> > --
> >
> >   * Dr. Brian Thomas
> >
> >   * Code 630.1
> >   * Goddard Space Flight Center NASA
> >
> >   *   fax: (301) 286-1775
> >   * phone: (301) 286-6128

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128