STC and characterization

[Doug Tody]

Hi All -

This property-first alternative seems counter to the whole concept of
Axis-based characterization in the current model.  Agreed, the
Axis-based approach is counter to what we were originally doing
elsewhere (e.g., the most recent version of characterization in
the SSA query response), and I was at first surprised to see this,
but it seems reasonable if we want the flexibility to allow new
characterization axes can be added.  For example if we want to add
a new axis to characterize the spatial frequency axis for radio data
this can be easily done with the current model.

I support use of STC to define reference frames in characterization
and elsewhere in VO, and probably for some things like region
descriptors, which STC is well able to deal with and which are not
currently addressed elsewhere, but not necessarily for something as
simple as a coordinate instance - there are many alternative ways
to represent something that simple.  Why can't a simple coordinate
instance in whatever representation be associated with an STC-defined
reference frame?  In the case of characterization I am really bothered
by the suggestion of seemingly opaque references into bits of STC for
something for which we currently have a simple, direct, parameterized
representation which is defined independently of implementation.

This issue of overlap between STC and Characterization should have
been addressed long ago if we are going to address it at all.
At the moment we are on the third or so iteration of something
which is largely compatible with what the DAL interfaces require,
and are overdue to complete SSA 1.0, having only recently spent weeks
discussing the issues of generic Axis descriptors among other things,
and completely refactoring the model with all that entails is probably
not a viable option.

 	- Doug



On Wed, 24 May 2006, Francois Bonnarel wrote:

> Dear all,
>   I have to discuss the relationship between STC and char
> XML sertialization in the case of the property first option
>
> My starting point is this mail from Jonathan, point of view which
> he also gave in his talk and that was rapidly discussed in
> Victoria. I also had oofline discussion on this with Igor and
> Arnold.
>
>
> <Hi friends
> < I've been talking with Arnold who has provided me with an STC example
> <for Spectrum. I now think I have a better handle on STC. As you know,
> <Arnold has long argued that STC has everything that Characterization has.
> <It's not true, but it's close in terms of actual data in the latest version
> <of STC. I've figured out that *if* we went with the property-first approach,
> < you could make a characterization instance simply with IDREFs to an STC
> <instance; the Characterization then provides extra semantics to specify what
> <the bits of the STC instance actually mean, and you end up with just something
> <like
> < <Characterization>
> <   <Coverage>
> <    <Location ref="AstroCoords"/>
> <    <Bounds ref="AstroCoordArea"/>
> <   </Coverage>
> <   <Resolution ref="ResAstroCoords"/>
> <  </Characterization>
> <
> <I haven't looked at handling sampling this way, and it definitely doesn't
> <support "4th level" (but neither do we).
> <This is an issue for XML serializations of the model, not for the model
> <itself. I think we should at least discuss it at Victoria.
> <I'll try and flesh it out a bit more.
> < - Jonathan
> <
>
>   This point of view mean that we have an AstroCoords and AstroCoordArea
> valid for all axes in that case.
>
>    But in characterization we describe qualitativly and quantitativly
> each axis with the "axisFrame" class (see the serialisation here
>
> <xsd:complexType name="AxisFrameType">
> <xsd:sequence>
> <xsd:element name="axisName" type="xs:anyType"/>
> <xsd:element name="calibrationStatus" type="xs:anyType"/>
> <xsd:element name="ucd" type="xs:anyType"/>
> <xsd:element name="unit" type="xs:anyType"/>
> <xsd:element name="coordsystem" type="stc:coordSysType"/>
> <xsd:element name="ObsyLoc" type="stc:observatoryLocationType" minOccurs="0"/>
> <xsd:element name="accuracy" type="cha:AccuracyType"/>
> <xsd:element name="independantAxis" type="xs:anyType"/>
> <xsd:element name="numBins" type="xs:int"/>
> <xsd:element name="undersamplingStatus" type="xs:anyType"/>
> <xsd:element name="regularsamplingStatus" type="xs:anyType"/>
> </xsd:sequence>
> </xsd:complexType>
> )
> which is really usefull to give some semantics to our axes.
>
> If we want to keep that information and link it to the appropriate
> STC structure we can have Location and bounds as an unlimited
> number of sequences of Astrocoords+axisFrame ref or  AstroCoordArea
> +axisFrameref
>
>    Something like <xsd:complexType name="LocationType">
>                      <xsd:sequence>
>                        <xsd:element name="axisAstrocoords" type="axisAstrocoordstype" maxOccurs="unbounded" />
>                      </xsd:sequence>
>                   </xsd:complexType>
>
> with <xsd:complexType name="axisAstrocoordsType>
>            <xsd:seqquence>
>                 <xsd:element ref="AstroCoords"/>
>                 <xsd:element ref="axisFrame" />
>             </xsd:sequenec>
>       </xsd:complexType>
>
>
> Which I recognize is rather ugly, but let STC unchanged an reuse it exactly
>
>   Another possibility would be to modify a little bit the definition
> of Astrocoords (by extensions) in order that it is possible to refer
> to the axisFrames
>
> Let's change AstroCoords
> <xs:complexType name="astroCoordsType">
> <xs::complexContent>
>      <xs:extension base="coordinateType">
>        <xs:attribute name="unit" type="posUnitType" use="optional"/>
>      </xs:extension>
>    </xs:complexContent>
>  </xs:complexType>nnotation>
> <xs:documentation>The astronomical (STC) coordsType</xs:documentation>
> </xs:annotation>
> <xs:complexContent>
> <xs:extension base="coordsType">
> <xs:sequence>
>  <xs:element name="Time" type="timeCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element ref="Position" minOccurs="0"/>
>  <xs:element ref="Velocity" minOccurs="0"/>
>  <xs:element name="Spectral" type="spectralCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element name="Redshift" type="redshiftCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element name="CoordFile" type="astroCoordsFileType" nillable="true" minOccurs="0">
>    <xs:annotation>
>      <xs:documentation>Some or all coordinate values may be given in  file</xs:documentation>
>    </xs:annotation>
>  </xs:element>
>  <xs:element name="Orbit" type="orbitType" nillable="true" minOccurs="0">
>    <xs:annotation>
>      <xs:documentation>Orbit specified by orbital elements</xs:documentation>
>    </xs:annotation>
>  </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
>
> in
>
> <xs:complexType name="axisAstroCoordsType">
> <xs:annotation>
> <xs:documentation>The astronomical (STC) coordsType</xs:documentation>
> </xs:annotation>
> <xs:complexContent>
> <xs:extension base="coordsType">
> <xs:sequence>
>  <xs:element name="Time" type="axisTimeCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element name="Position" type="axisPosCoordinateType" minOccurs="0"/>
>  <xs:element name="Velocity" type="axisVelCoordianteType />
>  <xs:element name="Spectral" type="axisspectralCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element name="Redshift" type="axisredshiftCoordinateType" nillable="true" minOccurs="0"/>
>  <xs:element name="CoordFile" type="astroCoordsFileType" nillable="true" minOccurs="0">
>    <xs:annotation>
>      <xs:documentation>Some or all coordinate values may be given in  file</xs:documentation>
>    </xs:annotation>
>  </xs:element>
>  <xs:element name="Orbit" type="orbitType" nillable="true" minOccurs="0">
>    <xs:annotation>
>      <xs:documentation>Orbit specified by orbital elements</xs:documentation>
>    </xs:annotation>
>  </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
>
> With all the "axis...CoordinateType" types extended from the STC types in this
> way:
>
>
> <xs:complexType name="axis...CoordinateType" abstract="true">
>    <xs:complexContent>
>      <xs:extension base="...CoordinateType">
>        <xs:attribute name="axisFrameRef" type="xsd:IDref" />
>      </xs:extension>
>    </xs:complexContent>
>  </xs:complexType>
>
> All these extended types will allow each Coordinate element in AstroCoords
> to refer to the appropriate char axisFrame in the Char document.
>
> the same kind of things could be done for AstroCoordsArea
>
> So we could rephrase  Jonathan's proposal this way:
>
> <Characterization>
>   <Coverage>
>    <Location name="axisAstroCoords" type="axisAstroCoordsType" />
>    <Bounds name="axisAstroCoordArea" type="axisAstroCoordAreaTypoe" />
>   </Coverage>
>   <Resolution ref="ResAstroCoords"/>
> </Characterization>
>
>
> I prefer this second option, but it is just reusing stc types by extensions
> not reusing STC elements
>
> What do you think?
>
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
>
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel at astro.u-strasbg.fr
> ---------------------------------------------------------------------
>