VOTable 1.5 Working Draft (2023-09-13)

[Mark Taylor]

Markus has provided his answers to that question earlier in this thread
(http://mail.ivoa.net/pipermail/apps/2023-October/001609.html):
referential integrity, one-role-limitation, implementational
inconvenience.

On Mon, 16 Oct 2023, Pierre Fernique wrote:

> 
> In preparation for the VOTable 1.5 meeting later today, I'd like to comment on
> the previous example.
> Why not simply use what is already defined in the current standard. Place the
> utype on the fields to simplify recognition of their role, and add a "ref" to
> the associated COOSYS?
> 
> 
>   <VOTABLE>
>     <RESOURCE>
>       <COOSYS *ID="system"* system="ICRS"/>
>       <TABLE>
>         <FIELD name="ra" utype="votable:LonLatPoint-lon" *ref="system"*
> datatype="double" unit="deg"/>
>         <FIELD name="dec" utype="votable:LonLatPoint-lat" *ref="system"*
> datatype="double" unit="deg"/>
>         <FIELD name="pmra" utype="votable:ProperMotion-lon" *ref="system"*
> datatype="double" unit="mas/yr"/>
>         <FIELD name="pmdec" utype="votable:ProperMotion-lat" *ref="system"*
> datatype="double" unit="mas/yr"/>
>       </TABLE>
>     </RESOURCE>
>   </VOTABLE>
> 
> No need to change the standard for that. And it is exactly what Aladin Desktop
> uses for years (except these utypes). And we just wait MIVOT for a more
> generic solution.
> Pierre
> 
> Le 16/10/2023 à 14:17, Mark Taylor a écrit :
> > 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/
> 

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