Time stamp in EpochPosition

[lmichel]

Problem

There are 2 issues with EpochPosition.epoch, which is currently typed as a Coords:Epoch primitive type (B/J<year>)

1. (raised by @gilleslandais ) Mapping native data on this field is difficult because the epoch in column can be MJD/ISO/year/....
   If the EpochPosition.epoch attribute refers to one of these serializations, the model will miss the serialization mode.
2. The B/J prefix can make the mapped epoch conflicting with the time coordinate system attached to the EpochPosition.

Solution

To solve these 2 issues, EpochPositio.Epoch can be typed as a coords:TimeInstant (see standard P 18) which is an abstract type with 3 subtypes currently supported: JD, MJD and ISO.
In addition to this, Mango should extend coords:TimeInstant with 2 types: Years and Seconds

Proposed actions

1. Duplicate coords:TimeInstant in Mango to avoid mixing components of different models in one Mango class (see Error types and relation to Measurement model Uncertainty #60)
2. Extend it with 2 ivoa:real subtypes: Year and Seconds
3. Set EpochPosition.epoch as a mango:TimeInstant

[mcdittmar]

My thoughts:

re: Problem

• There is no counterpart to the EpochPosition.epoch in the Measurements model.. it was removed until a proper workflow would be able to exercise it (like this!).
• The coords:Epoch is currently used only for the SpaceFrame.equinox, where the 'B1950" type format most often comes into play. There was some discussion (Francois?) about adding it to the TimeInstant types. I think that didn't happen because I felt it needed more justification.
• So, I don't see a problem with NOT using the coords:Epoch type for the mango:EpochPosition.epoch if it isn't a good fit in the workflow.

re: Solution(s)

• since coords:Epoch is a primitive type, Mango could enhance the allowed 'representations' it should expect. Given that the values are apparently well represented by the coords:TimeInstant, this doesn't seem like a good solution.
• IF the "J2000.0" form is to be allowed/expected at the mango:EpochPosition.epoch, then I do think that is added justification into bringing the Epoch type into the TimeInstant grouping. But your point about "B1950" possibly conflicting with the associated frame could be problematic.
• Your proposal for extend coords:TimeInstant with 2 types: Years and Seconds
  • I don't quite follow these.. can you give an example? They sound like the "coords:TimeOffset" type, "Seconds since T0" or "Years since T0"... both of which would be handled by that type.
  • could you're EpochPosition.epoch be satisfied by the 'coords:TimeStamp' ?

[lmichel]

re: Problem

I note an agreement for not using coords:Epoch anymore.

[lmichel]

since coords:Epoch is a primitive type, Mango could enhance the allowed 'representations' it should expect. Given that the values are apparently well represented by the coords:TimeInstant, this doesn't seem like a good solution.

The implementation of primitive type representations, especially with Mivot is not clear for me. I get it as a complex type, giving the representation (e.g. ISO), wrapping a primitive value (an ISO string).

[lmichel]

Your proposal for extend coords:TimeInstant with 2 types: Years and Seconds

The epoch is often given as a year (e.g. 2015.5) without any frame reference. This is not a time offset, but an absolute date. Of course, it can be argued that any absolute coordinate is an offset from the origin of the system, but if you say 2015.5, everyone understands it as 6 months after the year 2015 in the christian calendar, not as a 2015.5 years offset.

For the seconds, I've in mind the Unix time which is the number of seconds from 1970-01-01 (https://www.unixtimestamp.com/). I admit that I've no concrete astronomical example for this, and that his representation can be discarded.

[lmichel]

The current proposal looks like this (Seconds should be pushed out)

• In blue: the data types duplicated from CoordsDM with a major difference which is that mango:TimeInstant does not explicitly refer to a TimeSys, but implicitly to this of the EpochPositon object.
• In yellow the the representations added by Mango.

All of the epoch package data types belong to Mango: no cross-model import.

[mcdittmar]

Your proposal for extend coords:TimeInstant with 2 types: Years and Seconds

The epoch is often given as a year (e.g. 2015.5) without any frame reference. This is not a time offset, but an absolute date. Of course, it can be argued that any absolute coordinate is an offset from the origin of the system, but if you say 2015.5, everyone understands it as 6 months after the year 2015 in the christian calendar, not as a 2015.5 years offset.

For the seconds, I've in mind the Unix time which is the number of seconds from 1970-01-01 (https://www.unixtimestamp.com/). I admit that I've no concrete astronomical example for this, and that his representation can be discarded.

So this is consistent with the Astropy implementation as well..
https://docs.astropy.org/en/stable/time/index.html#time-format

The current coords model TimeStamps map to the 'TimeJD', 'TimeMJD', 'TimeISOT' or perhaps 'TimeFITS'. TimeOffset is a generalization of 'TimeCxcSec'. These new ones seem to map to 'TimeDecimalYear' and 'TimeUnix'.

So I can see these as extensions of coords:TimeInstant as well.

[mcdittmar]

All of the epoch package data types belong to Mango: no cross-model import.

As for this, I think this further illustrates the problem with arbitrarily consolidating objects from the imported models.
Now, you want to use other types from the coords model, but they don't quite fit the consolidated measure type, so you need to 'duplicate' that content with slight differences.

A producer/consumer of Mango will now need to be able to recognize and distinguish the handling of:

• mango:EpochPosition -> meas:Position, ProperMotion, RadialVelocity
• mango:epoch.JDTime, epoch.MJDTime, epoch.ISOTime -> coords:JD, MJD, ISOTime
• mango.error.PErrorSym1D, error.PErrorAsym1D, error.PError2D, error.PErrorEllipse -> mea:Symmetrical, Bounds1D, Bounds2D, Ellipse

Is this really the path we want to take?

[lmichel]

I do not think that producer/consumer of Mango will now need to be able to recognize and distinguish the handling of:

• The MANGO specification contains everything the producer needs to map its data.
• The MIVOT annotation contains everything the consumer needs to properly interpret this mapping
• The data can be mapped on other models than MANGO, this is the responsability of the producer

I understand you are in trouble with the fact the same quantities are present in different models. This has been already discussed and it turned out that:

• MANGO use cases and requirement are not properly covered by Meas/Coord (and user expectations)
• Building classes mixing components from different models leads to a useless complexity in the workflow.

That is why I argue that in our situation, if some quantities are present in different models, we need to make sure that they have the same definition. The most important thing is to have one definition for one concept. This is what I have done in the MANGO specification, by referring to the Meas/Coords document every time MANGO borrows an element of these models.The model workflow could have been designed in a different way, but from my point of view, it is too late to do it.

[lmichel]

The three cases you mention are all related to the EpochPosition which design has been approved by the community

mango:EpochPosition ..

Is much more than a (meas:Position, ProperMotion, RadialVelocity) set. This justifies a specific design.

mango:epoch.JDTime, ...

To be used within the EpochPosition which has a global timeSys. Thus, we cannot use coords:TimeStamp which requires it own timeSys. Futhermore it should be extended with the Years timestamp.

mango.error.PErrorSym1D,...

Mango use cases require errors to have a confidence level, no provided by Meas yet. This requires to use error classes deriving from a super data type carrying that confidence level.

Looking out of the EpochPosition case, we can see that Coords coordinate systems and PhoDM photometric calbiraton are smoothly integrated to MANGO.

[loumir]

Looking at the extension diagram above ( #85 (comment)) , I find it strange to have an attribute named 'date' in the 2 classes : Seconds and Years . it sounds misleading .
how can we rename this 2 classes ?
reuse the same names as Astropy ? 'TimeCxcSec' and 'TimeDecimalYear'.
do we need 'TimeUnix' in the use-cases ?

[mcdittmar]

I understand you are in trouble with the fact the same quantities are present in different models. This has been already discussed and it turned out that: ...

I'm not wanting to re-hash the discussion, but do feel its important to point out the consequences of these choices, and how I view them.

I do not think that producer/consumer of Mango will now need to be able to recognize and distinguish the handling of:

I'm not sure we're on the same page here. A full Mango instance describing catalogue content will very likely have elements from both the Meas/Coords models AND the EpochPosition with its variations on those elements.

• Meas/Coords instances through the mango:PhysicalProperty->Measurement
  • which could easily be other Positions, Times, Velocities
  • including the Uncertainties and Coordinates which are duplicated but tweaked in mango.
• EpochPosition instance(s) through mango:EpochPosition

Similarly, if comparing/combining instances pulled from 2 resources, one may use EpochPosition, the other not.

There will be a need for annotators and interpreters to recognize/handle things like:

• the mango:error.Ellipse pulled from the EpochPosition is structurally different from the meas:Ellipse pulled from the mango:PhysicalProperty->meas:Position
• The path for finding the Frame of the mango:epoch.ISOTime is different from that of the coords:ISOTime.

As the number of these things grows, I think it will become a nuisance for implementors.

[lmichel]

Reply to @loumir comment.
Mireille, you are right, the list of the supported date serialization must be refined and data is not a good name for the value attribute.

[lmichel]

Mark,

I understand and share your concern, although I'm a little less worried than you.

Everything we're talking about concerns only EpochPosition, which is the very heart of Mango.
From the client’s point of view, the question is how to handle either e.g. a mango:EpochPosition or a meas:Position.

• The important thing for the client is not to know how these classes have been built, but how to use them in his own API.
• The content of each of these classes is perfectly defined in each of the models and the provides clients with everything they need.

However, I think it's important to keep name spaces consistent.
We must avoid a situation where, in one case, our epoch is a coords.MJD (from Coords DM) and in another case a mango:DecimalYear (from Mango DM).

• Epoch must always be a Coords object or a Mango object, never one or the other.

This is already the case with errors, since all supported errors derive from mango:PropertError. With this in mind, I've renamed the Mango classes to avoid name collisions with the Meas classes.
it's my mantra that classes should be made up of elements that all come from the same model.

Considering that we agreed on the error case, let's have a look at the Epoch, for which I have the following proposal

[lmichel]

Use-case

The Epoch is one of the EpochPosition attributes that allows us to compute the position of a star at a given time.
Considering that the order of magnitude of proper motions is mas/year, we do not need a high accuracy in the time definition, but a robust way to describe this timestamp to avoid that clients have to make inferences to interpret it.

Vizier experience

After discussions with Vizier people, it turned out that epochs are usually given as ISO dates, decimal years, or MJ dates, and without any time frame reference (often missing in Vizier).
Moreover, in my experience, this Epoch can be defined globaly as a CooSys or TimeSys attribute or be specific to each row of data (Epoch column).

Proposal

This makes it difficult to model, but if we look at the real needs of the client, we just have to expose the Epoch value and the way it is serialized.
There's no need to expose the time coordinate system at this level.
That's why I'm proposing a single class for the Epoch, with two attributes (see pseudo code below)

<INSTANCE dmrole="mango.EpochPosition.epoch" dmtype="mango:Epoch">
    <ATTRIBUTE dmrole="mango.Epoch.format" dmtype="ivoa:String" value="TimeCxcSec"/>    
    <ATTRIBUTE dmrole="mango.Epoch.value" dmtype="ivoa:String" value="63072064.184"/>
</INSTANCE>

• value: always represented as a string
• format: serialization mode defined by a vocabulary derived from Astropy definitions.

This way to proceed provides clients with what they need, avoid cross-model and polymorphism issues.

It's perhaps a step towards the polymorphism of primitive types that you proposed a short while ago.

[mcdittmar]

This makes it difficult to model, but if we look at the real needs of the client, we just have to expose the Epoch value and the way it is serialized. There's no need to expose the time coordinate system at this level. That's why I'm proposing a single class for the Epoch, with two attributes (see pseudo code below)

<INSTANCE dmrole="mango.EpochPosition.epoch" dmtype="mango:Epoch">
    <ATTRIBUTE dmrole="mango.Epoch.format" dmtype="ivoa:String" value="TimeCxcSec"/>    
    <ATTRIBUTE dmrole="mango.Epoch.value" dmtype="ivoa:String" value="63072064.184"/>
</INSTANCE>

This is a valid alternate modeling for coords:TimeInstant, and one I believe we considered at some point. I think we went with the classes so they could be annotated with a single element, rather than 2. And yes, I think this does step in the direction of modeling a 'Primitive'.. and defining the supported representations.

Note however, that the AstroPy Time is not free of the time coordinate system.
From the Examples section of their documentation (link above in this tread)

Time(times, format='isot', scale='utc')

The constructor takes in the time scale as well..

In the end, this solution is not really different from the previous one. This is an alternate representation of the coords model elements, without the direct coordinate system association. So, I think you should choose whichever you prefer.