<div dir="ltr"><br>Dear Markus,<br><br>>Dear François,<br>><br>>Good to hear from you!<br>><br>>On Wed, Sep 27, 2023 at 03:56:56PM +0200, Francois Ochsenbein wrote:<br>>> permit a definition of this relation in both directions, as pointed<br>>> out by Pierre Fernique. The safe way of doing this in a relational<br>>> model is to insert the reference (foreign key) in each of the n<br>>> components, not the other way.  <br>><br>>Um... I don't think I understand that point.  If this is advocating<br>>the old "backward referencing" use of FIELD/@ref: the reason we have<br>>been struggling with COOSYS all these years and still can't reliably<br>>do automatic epoch propagation is exactly that FIELD/@ref is<br>>insufficient in several ways:<br><br>Well, the "old backward referencing" is safe, in the sense that you<br>can't generate a contradiction, which is fundamental if you want to<br>ensure the reliability in the description of your data. Accepting both<br>ways of referencing is opening the door for contradictions…<br><br>I would like to emphasize that the COOSYS was defined in VOTABLE, since<br>the very first version, to accurately DESCRIBE the COOrdinate SYStem(s)<br>used in a table because the sky position is of particular importance in <br>all phenomena related to sky observations. It's also why a COOSYS may<br>exist in the VOTABLE upmost element, or in a RESOURCE (then concerns only<br>one resource), or in a TABLE (concerns a single table) ; the forward<br>referencing implies to restrict COOSYS inside a TABLE.<br><br>The proposed change in VOTable 1.5 is exacly to assign to COOSYS the role<div>of a "special" group, as it was several times pointed out by Francois<br>Bonnarel.<br><br>>* Referential integrity: a single COOSYS element can be referenced by<br>>  multiple, say, longitude-like FIELDs: which one would by use to<br>>  build the position?<br><br>If some ambiguity may exist, define a GROUP for this purpose !<br>In the case a single coordinate system is used over all tables,<br>there is no need to reference the COOSYS in the FIELDs as long<br>as UCDs are correcly provided in the fields.<br><br>>* One-role-limitation: a field can be part of multiple coordinate<br>>  sets; consider a time that is both a mean epoch in a COOSYS and a<br>>  value in a TIMESYS (from where it would receive its time metadata);<br>>  which of the two would @ref point to?<br><br>Again, that's exactly why the GROUP exists !<br><br>>* Role identification: To reconstruct a coordinate set from COOSYS<br>>  and the FIELD-s and PARAM-s @ref-ing it, you have to figure out<br>>  which is the longitude, latitude, derivatives, etc.  So far, the<br>>  only way to do that is the UCDs, but that's fragile and guesswork.<br>>  You could try putting the utypes the present proposal introduces<br>>  into the FIELD-s' @utype-s, but then you are back to the problems<br>>  for referential integrity and the one-role limitation.<br><br>Again, COOSYS is there used as a pointer to columns, which is not<br>its role. Using a GROUP is as safe as the proposed change.<br><br>>* Implementational inconvenience: you have to change FIELDs to<br>>  express metadata external to the FIELD itself, which makes for<br>>  complicated and fragile code when writing VOTables.  With forward<br>>  referencing, the metadata resides in isolated blocks that you can<br>>  add easily as soon as the FIELD-s have an @ID.<br><br>Here I don't understand what you mean — which change do you need?<br><br>>These points are also the reason why MIVOT also employs<br>>forward-referencing (and all its predecessors did the same).<br>><br>>> Several groups of positions may moreover exist in the table: for<br>>> example in a list of clusters, two barycenters are given, one from<br>>> what was detected in the optical, and a second from radio<br>>> detections, and both positions are (hopefully!) given in the same<br>>> coordinate system. The enumeration of the FIELDs giving both<br>>> positions within the COOSYS would be quite confusing,  <br>><br>>No -- you would then simply have two nicely isolated COOSYS elements.<br>><br>>I have no principled objections to use some extra GROUP to link<br>>COOSYS and FIELDs, which would let you get away with just one COOSYS<br>>element in this situation, at the expense of significantly more<br>>complicated code in both the client and the server side.  As I said<br>>in<br>><<a href="https://github.com/ivoa-std/VOTable/pull/40#issuecomment-1719256399">https://github.com/ivoa-std/VOTable/pull/40#issuecomment-1719256399</a>>:<br>>If someone else writes that code for the client side, I'll do it on<br>>the server side; but I suspect if you try to write such code, you<br>>will find it's a complication that's probably simply not worth it.<br><br>That's exactly the discussion I was referring to, this change is a<br>transformation of COOSYS into a specialized GROUP. But I can't<br>understand why the code would be more complex if you have the<br>relationship referenced in a GROUP rather than in a COOSYS playing<br>the GROUP's role ? </div><div><br>I'm also concerned by the vocabulary proposed in the section 3.4 —<br>assigning the same utype name to a parallax and a distance seems<br>inconsistent, and is a potential source for large errors, as was<br>discussed following Mark Taylor's remarks.<br><br>Thank you anyway for the discussions !<br><br>François Ochsenbein<br><br></div></div>