VOTable 1.5 Working Draft (2023-09-13)

[Francois Ochsenbein]

Dear Markus,


>Dear François,
>
>On Mon, Oct 16, 2023 at 09:05:50AM +0200, Francois Ochsenbein wrote:
>> VOTable is an important component in the VO, and I'm really not sure
>> it's worth to change the VOTable schema as proposed in section 3.4 —
>> and is it
>
>Well, it's a non-intrusive change that doesn't break anything, so I'd
>say the cost is very low indeed.

==> Sorry, but I disagree on this point: it IS intrusive because:
    "COOSYS element SHOULD also be used to group and label coordinates"
    while in the previous versions care was taken to avoid specific
    requirements about ucd or utypes — in other words keeping VOTable
    generic; it's up to applications to define such requirements. It is
    therefore, at least in my mind, a major change in the VOTable scope.

>> components should be placed ? Also don't forget that the COOSYS
>> element was up to now located at the RESOURCE level, and from there
>> you can't safely reference FIELDs which may exist in several TABLEs;
>> should COOSYS become as a sub-TABLE element? Could the example
>> proposed at the end of section 3.4 work is there are several TABLEs
>> in the RESOURCE ?
>
>Ah: is that the "safely" in you original mail?  Let me try to
>re-phrase it:
>
>  If COOSYS contains references into a TABLE and that TABLE is
>  taken out when re-organising the VOTable, the references in the
>  COOSYS will be dangling.

==> It's worse that this: the referencing may quote FIELDs in different
    TABLEs, which potentially generates a complete mess!

>If that is your concern, it is a valid one, but, really, whenever you
>are manipulating a VOTable by adding or replacing TABLE-s, you have
>to check and re-do all references because, for starters, you may have
>colliding identifiers. When you do that the proposed COOSYS
>references would probably be your least concern.
>
>The difficulties of maintaining referential integrity when writing or
>modifying VOTables are exactly why I am not so enthusiastic about
>your proposal of doing
>
>  <GROUP ucd="pos" ref="coosys-reference">...
>
>-- against having the references as children of COOSYS, it's just one
>extra reference that people need to maintain and work out.
>
>But as I said: If people like the extra GROUP *that* much better than
>a slight extension of COOSYS, they are welcome to write an
>alternative specification (including "how *exactly* are clients know
>a GROUP is defining a set of coordinates) and then change the astropy
>pull request. Very frankly: I expect that these exercises will
>convince just about everyone that just extending COOSYS is the
>rational way to go.
>
>But if not and the extra effort seems worth it, that's fine with me
>as well, and I will fix my server-side implementation to generate
>such GROUP-s.
>
>It's just that *I* don't want to spend a lot of work on what I think
>incurs a significant complication for almost no benefit at all; I
>hope you can sympathise with that sentiment.
>
>For reference:  François'
>
>> <RESOURCE>
>> <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter" />
>> <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"
>> refposition="barycenter" />
>> ...
>>
>> <TABLE>
>>
>> <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg"
>> ref="ICRS-2016"/> <FIELD ID="col2" name="Dec" ucd="pos.eq.dec"
>> unit="deg" ref="ICRS-2016"/> ...
>> <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"
>> ref="ICRS-geo"//>
>> <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"
>> ref="ICRS-geo"/>
>> <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" >
>> <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" >
>> ...
>>
>> <GROUP name="astrometry-main" ucd="pos" ref="ICRS-2016">
>>   <DESCRIPTION>Components of the position at the mean
>> epoch</DESCRIPTION> <FIELDref ref="col1" utype="LonLatPoint-lon" />
>>   <FIELDref ref="col2" utype="LonLatPoint-lat" />
>>   ...
>> </GROUP>
>>
>> <GROUP name="astrometry-predicted" ucd="pos" ref="ICRS-geo">
>>   <DESCRIPTION>Individual geocentric computations at reported
>> dates</DESCRIPTION>
>>   <FIELDref ref="col11" utype="LonLatPoint-lon" />
>>   <FIELDref ref="col12" utype="LonLatPoint-lat" />
>>   <FIELDref ref="col13" ucd="time.epoch" />
>>   <FIELDref ref="col14" ucd="pos.distance" />
>>   ...
>> </GROUP>
>> ...
>> </TABLE>
>> </RESOURCE>
>
>would simplify to
>
>  <RESOURCE>
>  <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter">
>    <FIELDref ref="col1" utype="LonLatPoint-lon" />
>    <FIELDref ref="col2" utype="LonLatPoint-lat" />
>  </COODYS>
>  <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"
>  refposition="barycenter" >
>    <FIELDref ref="col11" utype="LonLatPoint-lon" />
>    <FIELDref ref="col12" utype="LonLatPoint-lat" />
>    <FIELDref ref="col13" ucd="time.epoch" />
>    <FIELDref ref="col14" ucd="pos.distance" />
>  </COOSYS>
>  <TABLE>
>
>  <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg"
> ref="ICRS-2016"/> <FIELD ID="col2" name="Dec" ucd="pos.eq.dec"
> unit="deg" ref="ICRS-2016"/> ...
>  <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"
>  ref="ICRS-geo"//>
>  <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"
>  ref="ICRS-geo"/>
>  <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" >
>  <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" >
>  ...
>
>  </TABLE>
>  </RESOURCE>
>
>(where I'd have to see some code exploiting FIELDrefs with ucds
>rather than utypes before I'd admit that's a good idea).  I think you
>can guess that in particular in parsing code, that's *a lot* easier
>to deal with.
>

==> It looks like a joke, where is the simplification ? The change
    proposed in COOSYS is not robust, since references can only be
    placed BEFORE their definition, therefore forbidding a simple
    streaming processing; and the FIELDs required for a complete
    interpretation of the astrometry may concern other components
    not concerned a priori by the coordinate system, like time or
    wavelength. Putting those in a COOSYS envelope looks at least
    strange…

>
>             Markus

Cheers, François
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231016/fd19902a/attachment.htm>