VOTable 1.5 Working Draft (2023-09-13)

[Markus Demleitner]

Dear François,

Good to hear from you!

On Wed, Sep 27, 2023 at 03:56:56PM +0200, Francois Ochsenbein wrote:
> permit a definition of this relation in both directions, as pointed out by
> Pierre Fernique. The safe way of doing this in a relational model is to
> insert the reference (foreign key) in each of the n components,
> not the other way.

Um... I don't think I understand that point.  If this is advocating
the old "backward referencing" use of FIELD/@ref: the reason we have
been struggling with COOSYS all these years and still can't reliably
do automatic epoch propagation is exactly that FIELD/@ref is
insufficient in several ways:

* Referential integrity: a single COOSYS element can be referenced by
  multiple, say, longitude-like FIELDs: which one would by use to
  build the position?

* One-role-limitation: a field can be part of multiple coordinate
  sets; consider a time that is both a mean epoch in a COOSYS and a
  value in a TIMESYS (from where it would receive its time metadata);
  which of the two would @ref point to?

* Role identification: To reconstruct a coordinate set from COOSYS
  and the FIELD-s and PARAM-s @ref-ing it, you have to figure out
  which is the longitude, latitude, derivatives, etc.  So far, the
  only way to do that is the UCDs, but that's fragile and guesswork.
  You could try putting the utypes the present proposal introduces
  into the FIELD-s' @utype-s, but then you are back to the problems
  for referential integrity and the one-role limitation.

* Implementational inconvenience: you have to change FIELDs to
  express metadata external to the FIELD itself, which makes for
  complicated and fragile code when writing VOTables.  With forward
  referencing, the metadata resides in isolated blocks that you can
  add easily as soon as the FIELD-s have an @ID.

These points are also the reason why MIVOT also employs
forward-referencing (and all its predecessors did the same).

> Several groups of positions may moreover exist in the table: for example in
> a list of clusters, two barycenters are given, one from what was detected
> in the optical, and a second from radio detections, and both positions are
> (hopefully!) given in the same coordinate system. The enumeration of the
> FIELDs giving both positions within the COOSYS would be quite confusing,

No -- you would then simply have two nicely isolated COOSYS elements.

I have no principled objections to use some extra GROUP to link
COOSYS and FIELDs, which would let you get away with just one COOSYS
element in this situation, at the expense of significantly more
complicated code in both the client and the server side.  As I said
in
<https://github.com/ivoa-std/VOTable/pull/40#issuecomment-1719256399>:
If someone else writes that code for the client side, I'll do it on
the server side; but I suspect if you try to write such code, you
will find it's a complication that's probably simply not worth it.

         -- Markus