ivoa: DM type system

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Tue Apr 18 20:24:07 CEST 2017


Gerard,


On Tue, Apr 18, 2017 at 1:27 PM, Gerard Lemson <gerard.lemson at gmail.com>
wrote:

> HI Mark
>
> On Tue, Apr 18, 2017 at 12:23 PM, CresitelloDittmar, Mark <
> mdittmar at cfa.harvard.edu> wrote:
>
>> Gerard,
>>
>> I was thinking about this more on the way home yesterday..  I don't think
>> datetime can handle all three cases.
>>   + it certainly handles DATE-OBS, as an instant in time (date+time)
>>   + it may handle MJDREF, as it could be considered different
>> representation of a date+time as 'MJD' date.
>>
>>
>
>>   + TSTART (TIMEOFFSET)  requires additional information (the time0 of
>> the frame) to determine, and can have a variety of units [ms, s, d, m, y,
>> ... ] which the others don't.
>>       while the first two represent an instant in time, this is really a
>> span of time, which can be converted to an instant if you know the start
>> point.
>>       Yes.. that is the same as MJDREF, but MJD has a fixed, known start
>> point while this one is arbitrary and cannot be internalized to the type.
>>
>
> Seems to me your are trying to model a more complex concept here,
> something that could (should?) be captured using a custom DataType with two
> attributes, a time0 (ivoa:datetime) and a time span (ivoa:RealQuantity).
> According to STC, any observation of some property such as a datetime, or
> a position etc needs quite some information for interpretation. I.e. a
> position is not just a realquantity or group of such quantites, it needs a
> zero-point, a reference frame, whatnot. Same with time.
> I am sure there are lots of models where a simple ivoa:datetime,
> serialized for example to '2017-05-01 13:00:00 cet' , would be ok. E.g. to
> "model" the start time of a telecon. This is I guess why a datetime-like
> type exists in databases, programming languages and XML schema for example.
>

???
I'm not sure I follow the above, it sounds just like what we are doing.
This IS for the coords model (a.k.a STC).
The TimeOffset IS a custom DataType and part of a more complex structure,
where the time0 is in the associated Frame along with the other stuff you
mention and illustrated in the UML diagram referenced at the top of the
thread.



> For astronomical observations one may(?:) often need the more involved
> machinery of STC. But then probably one would use realquantity in most
> places and one would not want to add all of this to the basic set of
> primitive types or even quantities.
>

Yes.. exactly.. we're not asking to add 'all this' to the basic set, just
that it help us enable the 'more involved machinery'.

In the time domain, we want to enable users (TimeSeries, Cube, etc..) to
provide Time Data as EITHER a datetime OR a TimeOffset..  aka TimeStamp.
Since they have access to the full complex structure, this is both possible
and reasonable.

In the provided diagram, we have an abstract TimeStamp with sub-classes for
the 2 flavors, but this does not satisfy the additional requirements we are
folding in for 'finding Coords with minimal domain specific knowledge'..
which spawned this restructure and request for ivoa:anyType.

To satisfy both requirements, we need a common ancestor for both
RealQuantity and datetime..

The question is where does this get defined:
  1) as ivoa:anyType base type.. which you've explained would require
restructuring the vo-dml types, so is sub-optimal
  2) as ivoa:DateQuantity base type
  3) as coords:DateQuantity type.. local extension to ivoa:Quantity which
doesn't feel like playing nice with the base types
  4) do you have another proposal?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170418/27a40000/attachment.html>


More information about the dm mailing list