VOTable 1.5 Working Draft (2023-09-13)

[Francois Ochsenbein]

Dear Markus,

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

Well, the "old backward referencing" is safe, in the sense that you
can't generate a contradiction, which is fundamental if you want to
ensure the reliability in the description of your data. Accepting both
ways of referencing is opening the door for contradictions…

I would like to emphasize that the COOSYS was defined in VOTABLE, since
the very first version, to accurately DESCRIBE the COOrdinate SYStem(s)
used in a table because the sky position is of particular importance in
all phenomena related to sky observations. It's also why a COOSYS may
exist in the VOTABLE upmost element, or in a RESOURCE (then concerns only
one resource), or in a TABLE (concerns a single table) ; the forward
referencing implies to restrict COOSYS inside a TABLE.

The proposed change in VOTable 1.5 is exacly to assign to COOSYS the role
of a "special" group, as it was several times pointed out by Francois
Bonnarel.

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

If some ambiguity may exist, define a GROUP for this purpose !
In the case a single coordinate system is used over all tables,
there is no need to reference the COOSYS in the FIELDs as long
as UCDs are correcly provided in the fields.

>* 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?

Again, that's exactly why the GROUP exists !

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

Again, COOSYS is there used as a pointer to columns, which is not
its role. Using a GROUP is as safe as the proposed change.

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

Here I don't understand what you mean — which change do you need?

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

That's exactly the discussion I was referring to, this change is a
transformation of COOSYS into a specialized GROUP. But I can't
understand why the code would be more complex if you have the
relationship referenced in a GROUP rather than in a COOSYS playing
the GROUP's role ?

I'm also concerned by the vocabulary proposed in the section 3.4 —
assigning the same utype name to a parallax and a distance seems
inconsistent, and is a potential source for large errors, as was
discussed following Mark Taylor's remarks.

Thank you anyway for the discussions !

François Ochsenbein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231003/7180243b/attachment.htm>