STC in VOTable: Common container?

[Markus Demleitner]

Dear DAL and DM folks,

First off, sorry for this long mail.

As you know, I'm currently revising the STC-in-VOTable note

(http://www.ivoa.net/cgi-bin/twiki/bin/preview/IVOA/STCInVOTable)

I'm setting out to include the feedback I've received recently -- in
particular, there will be a "for the impatient" section that should
cover at least 80% of the use cases with 20% of spec effort -- and to
correct some conceptual errors that had sneaked in.

So far, I've basically maintained the basic premises of the original
note.  Now, Arnold Rots suggests putting everything belonging to a
specific coordinate system into one common container.  I like this idea
very much because it would simplify implementation considerably (I say
this as someone who has implemented the current scheme).

The downside is that the internal re-use of coordinate systems becomes
impossible.  I personally believe this is far outweighed by the
simplifications afforded by doing away with the separate groups, but I'm
told other people are very fond of having ID and ref on these groups.

So, before reworking the note to reflect the one-group-per-coords
approach, I thought I'd solicit feedback -- either to the list or to me
personally, or to the wiki, to which I'll summarize everything happening
in mails -- on what I'm proposing.

I guess an example should do to illustrate the main point.  First, here's a
sketch (cut some crap manually for clarity) of a VOTable with embedded
STC according to the current scheme:

<VOTABLE xmlns="http://www.ivoa.net/xml/VOTable/v1.2" version="1.2">
  <RESOURCE>
    <TABLE name="twosystems">
      <GROUP utype="stc:AstroCoordSystem" ID="lmpbpsh">
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor" 
          value="SPHERICAL" name="CoordFlavor"/>
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" 
          value="ICRS" name="CoordRefFrame"/>
      </GROUP>
      <GROUP utype="stc:AstroCoords" ref="lmpbpsh">
        <PARAM 
          utype="stc:AstroCoords.Epoch"
          value="J2010.0" name="Epoch"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2" ref="de"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1" ref="ra"/>
        <FIELDref utype="stc:AstroCoords.Velocity2D.Value2.C2" ref="pmde"/>
        <FIELDref utype="stc:AstroCoords.Velocity2D.Value2.C1" ref="pmra"/>
      </GROUP>

      <GROUP utype="stc:AstroCoordSystem" ID="llbbpsh">
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor" 
          value="SPHERICAL" name="CoordFlavor"/>
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" 
          value="GALACTIC_II" name="CoordRefFrame"/>
        <PARAM 
         utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition" 
          value="BARYCENTER" name="ReferencePosition"/>
      </GROUP>
      <GROUP utype="stc:AstroCoords" ref="llbbpsh">
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2" ref="glat"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1" ref="glon"/>
      </GROUP>

      <FIELD name="glon" datatype="float" ID="glon"/>
      <FIELD name="glat" datatype="float" ID="glat"/>
      <FIELD name="ra" datatype="float" ID="ra"/>
      <FIELD name="de" datatype="float" ID="de"/>
      <FIELD name="pmra" datatype="float" ID="pmra"/>
      <FIELD name="pmde" datatype="float" ID="pmde"/>
    </TABLE>
  </RESOURCE>
</VOTABLE>

As you can see, there are two coordinate systems; each is defined in a
group.  The actual coordinates are defined using FIELDrefs in groups
with utype AstroCoords; these are tied to the system using their ref
attribute; thus, a single AstroCoordSystem can be used by several
AstroCoords groups (I'm saying this because that's the only thing we're
losing with the new scheme).

This is basically what the current note suggests.  The downside of this
is that the software has to split up (and bring together on parsing)
AstroCoords, AstroCoordAreas, and AstroCoordSystem utypes that
presumably start out in a single data structure, that you need to manage
id/ref pairs both on writing and on parsing, and that you cannot
sensibly have FIELDrefs in AstroCoordSystem groups since they might be
referred to from other tables.

In view of these issues, I'm all in favour of scrapping the split.  The
table above would then look like this:


<VOTABLE xmlns="http://www.ivoa.net/xml/VOTable/v1.2" version="1.2">
  <RESOURCE>
    <TABLE name="twosystems">
      <GROUP utype="stc:ObservationLocation">
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor" 
          value="SPHERICAL" name="CoordFlavor"/>
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" 
          value="ICRS" name="CoordRefFrame"/>
        <PARAM 
          utype="stc:AstroCoords.Epoch"
          value="J2010.0" name="Epoch"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2" ref="de"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1" ref="ra"/>
        <FIELDref utype="stc:AstroCoords.Velocity2D.Value2.C2" ref="pmde"/>
        <FIELDref utype="stc:AstroCoords.Velocity2D.Value2.C1" ref="pmra"/>
      </GROUP>

      <GROUP utype="stc:ObservationLocation">
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor" 
          value="SPHERICAL" name="CoordFlavor"/>
        <PARAM 
          utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" 
          value="GALACTIC_II" name="CoordRefFrame"/>
        <PARAM 
         utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition" 
          value="BARYCENTER" name="ReferencePosition"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2" ref="glat"/>
        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1" ref="glon"/>
      </GROUP>

      <FIELD name="glon" datatype="float" ID="glon"/>
      <FIELD name="glat" datatype="float" ID="glat"/>
      <FIELD name="ra" datatype="float" ID="ra"/>
      <FIELD name="de" datatype="float" ID="de"/>
      <FIELD name="pmra" datatype="float" ID="pmra"/>
      <FIELD name="pmde" datatype="float" ID="pmde"/>
    </TABLE>
  </RESOURCE>
</VOTABLE>


While it doesn't seem much shorter, as I said it's much nicer to
implement, and a simultaneous row I'm having with Arnold on proper
referencing would become moot.

For purposes of illustration, with an STC library coordinate system,
you'd have

  <GROUP utype="stc:ObservationLocation">
    <PARAM
      utype="stc:AstroCoordSystem.href"
      value="ivo://STClib/CoordSys#UTC-ICRS-TOPO"/>
    <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2" ref="de"/>
    <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1" ref="ra"/>
  </GROUP>

-- which is almost down to the nice conciseness of the old COOSYS
element (Alberto?  Don't you agree?)

However, it's a significant deviation from what the current note
specifies, so before basically rewriting the note I'd like to give you a
chance to protest[1].

Also, I'm not quite sure what utype to use for the enclosing group.  The
stc:ObservationLocation I'm proposing in the examples is IMHO nice
since, if you want, you could have stc:ObservatoryLocation GROUPs as
well.


So: What do all of you think[2]?


Cheers,

          Markus


PS: Mireille, is there some consensus already on how to include the
model URI?  stc:DataModel?  stc:DM_URI?  stc:Version? I'd really like
to have this note finished by the interop, so it'd be nice if I had the
DM group's blessing for some "standard" reserved utype for this purpose.


[1] Of course, the whole point of the mail is that I can later smugly
say "Hey, you had your chance to protest" :-)


[2] To add some incentive for people to answer, I herewith proclaim
that I'll send everyone a nice picture postcard who says something in
this debate and gives me some address I am to send the postcard to.