ivoa: DM type system

[Gerard Lemson]

HI Mark



> -----Original Message-----

> From: CresitelloDittmar, Mark [mailto:mdittmar at cfa.harvard.edu]

> Sent: Monday, April 17, 2017 10:46 AM

> To: Gerard Lemson <gerard.lemson at gmail.com>

> Cc: Laurino, Omar <olaurino at cfa.harvard.edu>; <dm at ivoa.net>

> <dm at ivoa.net>

> Subject: Re: ivoa: DM type system

>

> Gerard,

>

>

>

> .....

>

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

>

I will not comment on the model here, though I want to reiterate that model
evaluation should be part of the evaluation of requirements/requests on the
modelling language.

>

>

>

> ...

>

>

> 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-
<https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/base%20diagram.png>

> 2.0/doc/diagrams/alt/base%20diagram.png
<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-
<https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/ivoa%20types%20diagram.png>

> 2.0/doc/diagrams/alt/ivoa%20types%20diagram.png
<https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/ivoa%20types%20diagram.png>

>

This is technically illegal in VO-DML. Though ValueType is a common base
class of PrimitiveType, Enumeration and DataType, it is abstract and cannot
be explicitly instantiated. Hence if you'd want to define ivoa:anyType, it
must be one of the three concrete value types.

IF we'd make ValueType concrete and "allow" a <valuetype> instantiation for
it in VO-DML, we could define a common super type for all value types.

This anyType would basically be the only reason to allow this I think, so
rather ugly.



Alternatively we could follow the UML treatment of value types, which is to
have DataType be the common base class, and have enumeration and
primitiveType be subtypes of this, where the inheritance relations should
be seen as a kind of restriction. But a weird one, adding the implicit
value, and removing any roles. I'd almost prefer making ValueType concrete.





>

>   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-
<https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/temporal%20domain%20diagram.png>

> 2.0/doc/diagrams/alt/temporal%20domain%20diagram.png
<https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/temporal%20domain%20diagram.png>

>



So are you saying you'd like a DatetimeQuantity? With only a "datetime
unit" being sufficient?

I had hoped   'ivoa:datetime' would be sufficient and the precise
representation would be left to the mapping.



Cheers

Gerard



>

> Mark

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170417/42c6b845/attachment.html>