Coords/Measurement model RFC comment response

[Markus Demleitner]

Hi Mark,

Just two quick responses:

On Thu, Feb 20, 2020 at 02:11:16PM -0500, CresitelloDittmar, Mark wrote:
>     *) Domain specific Measurement types ("Time", "Position",
> "Polarization" ) vs "GenericMeasure"
>         *RESPONSE:*  We feel there is a distinct advantage to being able to
> define that Field X is a "Time" and Field Y is a "Position", rather than
> having everything be a generic measurement type.

Well, for such a rather fundamental design decision I frankly would
like to have a somewhat stronger reason.

In particular: Where would this end?  Will we have
TemperatureMeasure, MassMeasure, MetallicityMeasure,
EuropiumAbundanceMeasure?  And if not, why not, when we have special
classes for some other measurements?

As usual, I'd say it would help a lot if there were a clear scenarios
how a client would use the particular distinction in these classes
for something it could not otherwise do  (where, of course, I do not
deny that clients will have to know that a certain field fills the,
say, time role in some space-time position -- but that's up to a
coordinates model, not a measurement model).

> *Implementation/Serialization:*
>   This stems from the specific note in the RFC comments by Markus, and
> follow-up discussion among the TCG at the interop.
>   My point of view, is that the DM group approved a set of implementation
> requirements which does not limit to any particular serialization standard.
> This is important since the data models themselves are typically several
> layers below the level of interoperable implementations of science
> threads.  These models have been serialized using real-world data, in
> multiple formats (VOT, Annotated VOT, XML) each validating against their
> schema.  This demonstrates the usability of the models.  Interoperabile
> implementations only requires multiple clients to select a common format.
> There is no need to delay the model progress to REC pending the approval of
> a specific annotation syntax.

The problem is not serialisation, it is deserialisation into what
clients actually want to process, and in my experience only when
doing this do modelling problems become apparent.  However, PyVO,
stilts, and their brethren won't even try this as long as all we can
say when they ask about serialisation is the equivalent of "we could
do it this way.  Or this other way".

What we are dealing with in measurements and coordinates is so
fundamental that even minor problems will have a profound impact
later on -- and I actually see several rather fundamental problems,
in particular the entanglement of STC and Measurements; how this
entanglement can be avoided becomes really apparent only if we look
at serialisations.

Conversely, I can't see any particular urgency to pass these
standards as long as we can't serialise instances anyway -- we're not
blocking any applications, as these by necessity deal with serialised
data.

So, again, my appeal would be to freeze this and start an all-out
effort to finally work out how we want to annotate VOTables so the
DMs can actually be used.

         -- Markus