VOTable 1.5 Working Draft (2023-09-13)

[Mark Taylor]

On Mon, 16 Oct 2023, Francois Ochsenbein wrote:

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

I agree with Francois on this point: COOSYS as a RESOURCE child
is at the wrong level to do the job of referencing FIELDs,
since a FIELD can only appear within a single TABLE.
That doesn't make it impossible for it to do the job proposed,
but it's less elegant, and it also means that clients parsing such
VOTables have to go looking for the COOSYS in the parent RESOURCE
rather than finding it in the TABLE.  When doing this they may find
a COOSYS that belongs in that RESOURCE but is not relevant to the
TABLE of interest (since it refers to another TABLE in the same RESOURCE).
I'd say that is an annoyance on the same level as having to do
ref-ID matching between a GROUP and a COOSYS.

I don't have strong feelings about whether COOSYS is altered or
GROUPs are used for this purpose, except for the point made by Tom:

On Mon, 9 Oct 2023, Tom Donaldson wrote:

> In my reading of the GROUP specification, it is too general to be used
> unambiguously among provider and consumers who have only read the VOTable
> spec.  GROUPs do supply a very good mechanism for peers to convey mutually
> agreed upon information, but since that requires mutual understanding of
> non-public conventions, it cannot be reliably interoperable.  I'd be happy
> to be proven wrong here, but as Markus points out, without an agreed-upon
> standard or convention, there is guesswork in both providing and consuming
> this content.  To me such guesswork is not suitable for interoperability.

GROUPs and ID/ref matching have been used in VOTable for a number
of things in a way that may look obvious to the author but whose
semantics is not at all obvious to client who may have no idea what
is intended by grouping some set of fields and pointing at some
different kind of element.  But I don't think the interoperability
issue is insurmountable, it's just a matter of flagging and
documenting the various usages.

That could be done in the context of this discussion for instance
by putting a utype (with semantics that are documented in the
VOTable document or possibly elsewhere) on the GROUP that links
table columns to an old-style COOSYS, e.g.:

  <VOTABLE>
    <RESOURCE>
      <COOSYS ID="system" system="ICRS"/>
      <TABLE>
        <GROUP utype="votable:skycoords" ref="system">
          <FIELDref utype="votable:LonLatPoint-lon"  ref="id-ra"/>
          <FIELDref utype="votable:LonLatPoint-lat"  ref="id-dec"/>
          <FIELDref utype="votable:ProperMotion-lon" ref="id-pmra"/>
          <FIELDref utype="votable:ProperMotion-lat" ref="id-pmdec"/>
        </GROUP>
        <FIELD name="ra"    ID="id-ra"    datatype="double" unit="deg"/>
        <FIELD name="dec"   ID="id-dec"   datatype="double" unit="deg"/>
        <FIELD name="pmra"  ID="id-pmra"  datatype="double" unit="mas/yr"/>
        <FIELD name="pmdec" ID="id-pmdec" datatype="double" unit="mas/yr"/>
      </TABLE>
    </RESOURCE>
  </VOTABLE>

where the GROUP-qualifying utype "votable:skycoords" is documented
in the same place as the FIELDref-level utype votable:LonLatPoint-lon
and friends.  (I still don't like the names of those utypes, 
and there's probably a better name than "votable:skycoords",
but you get the idea).

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/