ivoa: DM type system

[Gerard Lemson]

HI Mark

On Fri, Apr 14, 2017 at 10:31 AM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> Gerard,
>
>
> On Thu, Apr 13, 2017 at 12:31 PM, Gerard Lemson <gerard.lemson at gmail.com>
> wrote:
>
>> HI Omar
>> Agree with most of what you write, but would like to focus on this
>> proposal:
>>
>>> Only
>>> To recap:
>>>   1. my personal Yay! to removing the ivoa model from the current VODML
>>> PR.
>>>
>>
>> I tried arguing that we need a base model with primitive types to be able
>> to create models.
>> (Unless of course every model would define all their own basic primitive
>> types, something I truly hope no one wants).
>>
>
> I'm sure we agree that a base model for primitives is needed.
>

If there are objects to its use, I am not sure that there is agreement to
its existence.


>
>
>> So if we only have a language but no basic types we have a problem.
>> Now IF you're proposing to still have ivoa model and vo-dml spec go
>> through the process in synch there should be no problem, but if now ivoa
>> model would be delayed, I'd much rather keep it inside the spec.
>>
>
> I think they could go in sync.  The argument for separating is more that
> the content may evolve and change (in the short term.. presumably would
> settle quickly to a static state since it will be so broadly used), without
> the need to modify the vo-dml standard.
>
> Note that the model was never "only" to be defined in the VO-DML spec
document. There were always going to be separate VO-DML/XML and VO-DML/HTML
documents. So now it seems that, after moving the description from an
appendix to a normative section in the vo-dml spec (in reaction to RFC
comments) it is proposed we remove that text completely? Do we need a
separate document with that text, or might it be sufficient to keep only
the VO-DML/XML and VO-DML/HTML? This model is so simple, that might suffice?




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

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.

Cheers

Gerard



> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170416/0343390c/attachment.html>