<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <p>In preparation for the VOTable 1.5 meeting later today, I'd like
      to comment on the previous example. <br>
      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?</p>
    <p><br>
      <font face="monospace">  <VOTABLE><br>
            <RESOURCE><br>
              <COOSYS <font color="#008000"><b>ID="system"</b></font>
        system="ICRS"/><br>
              <TABLE><br>
                <FIELD name="ra"    <font color="#8000ff">utype="votable:LonLatPoint-lon"</font> 
        <font color="#008000"><b>ref="system"</b></font>
        datatype="double" unit="deg"/><br>
                <FIELD name="dec"   <font color="#8000ff">utype="votable:LonLatPoint-lat"</font> 
        <font color="#008000"><b>ref="system"</b></font>
        datatype="double" unit="deg"/><br>
                <FIELD name="pmra"  <font color="#8000ff">utype="votable:ProperMotion-lon"</font>
        <font color="#008000"><b>ref="system"</b></font>
        datatype="double" unit="mas/yr"/><br>
                <FIELD name="pmdec" <font color="#8000ff">utype="votable:ProperMotion-lat"</font>
        <font color="#008000"><b>ref="system"</b></font>
        datatype="double" unit="mas/yr"/><br>
              </TABLE><br>
            </RESOURCE><br>
          </VOTABLE></font></p>
    <p>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.<br>
      Pierre<br>
    </p>
    <div class="moz-cite-prefix">Le 16/10/2023 à 14:17, Mark Taylor a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:fbeec756-6f6d-246f-1c6e-30a098d99531@andromeda.star.bris.ac.uk">
      <pre class="moz-quote-pre" wrap="">On Mon, 16 Oct 2023, Francois Ochsenbein wrote:

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">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 ?
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">
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.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
==> It's worse that this: the referencing may quote FIELDs in different
    TABLEs, which potentially generates a complete mess!
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>          <a class="moz-txt-link-freetext" href="https://www.star.bristol.ac.uk/mbt/">https://www.star.bristol.ac.uk/mbt/</a>
</pre>
    </blockquote>
  </body>
</html>