ivoa: DM type system

[CresitelloDittmar, Mark]

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/5f5b10c1/attachment.html>