ivoa: DM type system

[Gerard Lemson]

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



> So, I still think we need both.
>
> So I wonder whether we do.

Gerard



> Mark
>
>
>
> On Tue, Apr 18, 2017 at 11:07 AM, Gerard Lemson <gerard.lemson at gmail.com>
> wrote:
>
>> Hi Mark
>>
>> On Mon, Apr 17, 2017 at 11:51 AM, CresitelloDittmar, Mark <
>> mdittmar at cfa.harvard.edu> wrote:
>>
>>>
>>>
>>> ...
>>>>
>>> I don't think this needs to be complicated, so let's put these on the
>>> back burner.
>>>
>>> Thanks!
>>
>>>
>>> >>     * 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.
>>>
>>> This sounds like you are suggesting that 'ivoa:datetime' should suffice
>>> for all uses.
>>>    MJDREF  = 50814.02               / [d] zero point for times - MJD
>>>    TSTART  = 84244214.7546979934 <(754)%20697-9934>    / [s]
>>> Observation start time
>>>    DATE-OBS= "2000-09-02T01:10:14"  / Date and time of observation start
>>>
>>> I want all of these to be a TimeStamp type (abstract).
>>>   * datetime = has vodml/html description:  "Represents a moment in time
>>> using a date+timestamp."
>>> which covers 'DATE-OBS', the other 2 are satisfied by RealQuantity.
>>>
>>> But.. since RealQuantity and datetime do not have a common ancestor, I
>>> cannot define TimeStamp without either an anyType or a DateQuantity.
>>>
>>>
>> Yes, that is correct, but I see now (I think) what might cause confusion,
>> namely the description of  ivoa:datetime in the model as
>> "Represents a moment in time using a date+timestamp". What was meant
>> there is that it is not just a day/date (2017-04-18), and not just a time
>> ("13:00:01.3"), but the fully specified moment in time.
>> In the current description it does indeed sound as if date and time must
>> be represented, i.e. too much like a prescription for valid serializations.
>> This was NOT intended.
>> ivoa:datetime is supposed to represent the concept of a Timestamp as you
>> mention it, and it should be up to serialization prescriptions to take care
>> of valid representations.
>>
>> So if that interpretation is given to ivoa:datetime, would that type be
>> sufficient for your requirements?
>>
>> Cheers
>> Gerard
>>
>>
>>
>>
>>> Mark
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170418/3b666b46/attachment-0001.html>