VOTable 1.5 Working Draft (2023-09-13)

[Pierre Fernique]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231016/1379ba51/attachment-0001.htm>