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

[Ed Shaya]

Gerard,

    I can't speak for Brian's ultimate motivations, but storage was 
completely peripheral to what I was trying to accomplish.  Rather, the 
motivation was a simple generalized mechanism for describing objects 
(read subjects now) and for access or query to them.  The idea is that 
objects are described by a set of properties/quantities with values 
known  (measured) to be within a range.   The known data on each object 
is describable by a set of  quantities.

O = O(Q1, Q2, ... QN)

These Qs need to hold values, accuracy, and metadata Qs.  And each Q  
needs to allow for arguments of other Qs to fully specify properties 
like flux(position) or M(<r) or densities(r) or column_densities(R), 
because otherwise one is not fully describing the Object. To retrieve 
objects with properties within a certain range, one places constraints 
on all objects to return a set of objects satisfying:

O(return) <--  (C(Q12) and/or C(Q28) and/or C(Q132))

Where the constraints can be on the values V, metadata values Qm, or 
accuracy a.  By a constraint we mean the following in the case with a 
quantity with scalar values and one piece of metadata,

   C(Q_i) <-- O(c1 < V_i <c2) and O(c5 < a_i < c6) and C(Qm) etc

In the case where the values are strings, as in the class name, then one 
constrains by regular expression or string equivalence.  The strings 
that represent the Objects I call literals, and are somewhat distinct 
from quantities.
    Well, it does turn out that in this simple model the Qs happen to 
correspond to columns of data so I can understand people associating the 
model with a storage mechanism.  But I see that as fortuitous 
happenstance.  The intent is to have the simplest  generic descriptive 
and retrieval mechanism for all things.  It will be interesting to check 
if all
use cases are special cases of these two mechanisms.
    Now if you want to call Q a measurement or property or field or 
column or quantity or dataset or info, it is fine with me.  And these 
Q's can and should be subclassed and/or typed.  But there ought to be 
some class with the power of Q.  However, it would be annoying to have 
to query for both the atomicQi and the arrayQi to find all of the Qi's  
that are in range, but I would live.
    So when I heard the call for a simple quantity, I took that to mean 
the simplest quantity based model  of information, not the most atomic 
quantity entity.
    Yes Gerard, we absolutely need a full model of the metadata to fully 
describe the Q's, Qm's and Os and your work is a first rate, first cut 
at that.

Cheers,
Ed





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" ?
>
>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.
>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. 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.
>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
>>
>>
>>
>>    
>>
>
>  
>