ivoa: DM type system

[Gerard Lemson]

On Mon, Apr 17, 2017 at 10:46 AM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> Gerard,
>
>
> On Sun, Apr 16, 2017 at 9:41 AM, Gerard Lemson <gerard.lemson at gmail.com>
> wrote:
>
>>
>> For example..
>>>    With the recent Coords re-work for the Cube/TimeSeries thread, in
>>> order to satisfy the user-end requirements, we need
>>>    a 'anyType' parent to the primitives in the ivoa model.  Perhaps you
>>> could consider this my formal request to add that
>>>    since this seems like a much more user-friendly modeling  (the
>>> annotations are easier to work with from an application
>>>    point of view).   Whether this is in V1.0, or V1.1, I'm not
>>> particularly concerned, but it would need to go forward with the
>>>    cube/coords work.
>>>
>>> We had a similar issue in SimDM, where we did not know the property that
>> a measurement value represented, and hence we could not predict the
>> datatype. We did not introduce an anyType there for technical reasons, we
>> actually wanted to work with the data model explicitly.
>>
>
> Yes.. this is similar.  We are wanting to go this way so that there is
> common vo-dml annotation for these base (CoordValue) elements which can be
> found by generic utilities.
>
>
>>
>> The 'ivoa' model used to have a similar such type, namely AtomicValue.
>> Had a UCD only, and was base class of a host of "extended" types, including
>> the Quantity types which added a unit. We removed AtomicValue when we
>> removed the ucd attribute as it seemed to become superfluous.
>>
>> Note that the AtomicValue was never a super type of all the types, which
>> I am assuming you want anyType to be the supertype of as many of the types
>> as possible. Correct? Would it be sufficient to make anyType be a supertype
>> of the primitive types only?
>> If we do so (and even if not) I think we should also change the
>> definitions of rational and complex. ISO modelling these explicitly with
>> numerator/denominator and imaginary/real attributes we'd make them
>> primitive types and leave the representation up to the serializer. So then
>> also these types could be subtypes of  the primitive anyType, which as
>> structured types they could not be.
>>
>> If no one sees a problem with adding anyType as a super type to all
>> primitive types, I see no reason to wait for a version 1.1.
>>
>>
> There are, of course, a couple different solutions.
> The proposed modeling is using the anyType here:
>    https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/
> diagrams/alt/base%20diagram.png
>
> And is resolved to particular types in concrete classes:
>    <several>  => Quantity
>    PixelIndex => integer
>    ISOTime   => datetime
>    Polarization domain has enumerated value set, but that is outside of
> this usage as a special type of Discrete.
>
>   So we went the easy way of putting anyType as parent to all types in
> ivoa which allows the most flexibility
>      https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/
> diagrams/alt/ivoa%20types%20diagram.png
>
>   But the immediate requirements can be accommodated by adding a
> DateQuantity with datetime value..
>        * then PixelIndex (integer value) would be handled separately from
> the Quantity set.
>
>   Having anyType as super type to all primitives does not support the time
> domain as we would like
>     * Quantity and datetime would not have a common ancestor, so we could
> not define a TimeStamp
>       which would allow time represented as a RealQuantity OR datetime.
>       https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/
> diagrams/alt/temporal%20domain%20diagram.png
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170417/b1114c53/attachment-0001.html>