Meas/Coord extensions

[mcdittmar]

Sorry for the long list here, I think that by trying to push everything under Measure, this section got rather complicated. We may need to tackle these in waves as we hit the cases in implementation. Some are already mentioned in Issue #26.

• Flag
  • is a non-measure type; suggest modeling as a FlagProperty with status:integer[1] and options: reference to FlagSet?[1] (current FlagSys)
  • Flag as Measure becomes Flag as Property
  • FlagSys becomes FlagSet or FlagSpec or something. Local object not extension of coords:CoordSys
  • removes FlagCoord
• VocabGenericMeasure
  • is a non-measure type; I think this covers the "Classification" type Properties, so suggest modeling as Classification object with value:VocabuartyTerm[1] as a generic representation.
  • VocabGenericMeasure as Measure becomes Classification as Property
  • removes VocabCoordinate
• StringGenericMeasure
  • is a non-measure type; I'm not sure what use case this serves, but value is a simple string, so maybe targeting various string-type columns in catalogs? A specific suggestion would need review of the use case, but I expect if this is needed, it maybe should be served by a sub-class of Property
  • removes StringGenericMeasure, StringCoordinate,
• HardnessRatio
  • is a derived value, so qualifies as a Measure. However, the value is a dimensionless ratio, and has no associated CoordSpace, so is not a Coordinate.
  • I suggest keeping HardnessRatio as a Measure, but collapsing the content which is specific to the Ratio nature
    • value:real[1] == ratio
    • low_band: reference to photDM:PhotometryFilter? (see below)
    • hi_band: reference to photDM:PhotometryFilter?
  • removes HardnessRatioCoord, HardnessRatioSys, and HardnessRatioFrame
• PhotFilter
  • obviously a stub for photDM classes, the text says "compliant with photDM". I don't see a match, but may be out of sync with current work there.
    • ZeroPoint and MagnitudeSystem are elements of photDM:PhotCal
    • name and bandwidth are elements of photDM:PhotometryFilter
    • not sure what 'unit' maps to.
  • in the end, this should go away in favor of importing photDM.. this should be clear in the document
• LonLatSkyPosition
  • we've had some discussion on this.. interest in restoring Space-based coordinates
  • ultimately, these objects should merge into the meas:Position and coords:Point objects
  • but even at this point
    • LonLatPoint:
      • longitude and latitude should be Quantity types (they have units)
      • can refer to coords:SpaceSys which defaults to SphericalCoordSpace; no need for LonLatCoordSys
• Redshift
  • was a concept trimmed from earlier iterations on Meas/Coords to minimize its scope.
  • my understanding is that the modeling of this will depend on which type of Redshift we are talking about
    • z = dimensionless ratio (so OK as real) so, like HardnessRatio maybe is not a Coordinate.
    • with several options for how this is determined
  • at this point, I might suggest this is handled similarly to HardnessRatio
  • as a Measure, it would suffice to extend GenericMeasure and constrain the coord to be unitless.
• Photometry
  • gets us into the magnitude, flux, luminosity thread.. perhaps best a separate topic
  • but as a Measure, these values are Quantities, so maybe best represented as a specialized GenericMeasure
    • PhotometryCoord extends PhysicalCoordinate (Photometry constrains coord to PhotometryCoord)
      • note, this way the coord can serve all three quantities.
    • remove PhotometryCoordSys (no added value)
    • extend coords:GenericFrame to a PhotFrame which references a photDM:PhotCal instance
    • So Photometry has a PhotometryCoord whose coordSys contains a PhotFrame
• Orbit
  • there is no spec here, but I assume this is a complex object rather than a single coord measure, so at this point I'd suggest leaving Orbit as extension of Measure (empty), until the case gets worked.
  • remove OrbitCoord
• Shape
  • a region.. the STC Regions package is a separate beast which has not been refactored to date.
  • should not be extending Measure/Coord
  • my expectation has always been that Regions would use Coords (for the vertices, etc) though the DALI Shape-s work has given me cause to wonder about that. (each vertex doesn't need to reference the coordsys, but the region as a whole does).
• ObjectTypeCoord/ObjectTypeSys
  • I don't see any usage of these.. and object type sounds like an enumeration/Classification so maybe handled by that?
  • remove

[mcdittmar]

I may want to amend my comments on Flag. Looking at the 'Group Columns', it uses the Flag property. There, the Quality Flag is an associated parameter, but is basically an evaluation of the 'goodness' based on the measurement value error.

So, in this usage, Quality is not an independent Property, but a qualifier assigned to a Property. Many Properties could have Quality assignments (derived in different ways). This leads me to think that quality is maybe a attribute on Property.

[lmichel]

I do not seen the gain we have by using a specific attribute for flags instead of using the associatedParameter scheme.

• Most of the properties have no flag at all
• Some have several
• Flag are not related to any specific property (XMM detection flag)

[lmichel]

VocabGenericMeasure StringGenericMeasure

Depends whether Parameter is split or not

HardnessRatio

By doing this, you are breaking the homogenity exposed in #26. It is important to extends somehow to all properties the concept of meas/coord/coord_sys As you look concerned by the way I'm using MCT, we could imagine another pattern linking values, with errors and data spaces where there are valid. So that the Parameter split you proposed in #26 could be shifted into that new pattern and the uniqueness of the interface would possiblybe saved.

Photometry Orbit Shape

Need further discussions with Marco and Jesus

ObjectTypeCoord Simbad usecase not clear yet

[mcdittmar]

I do not seen the gain we have by using a specific attribute for flags instead of using the associatedParameter scheme.

• Most of the properties have no flag at all
• Some have several
• Flag are not related to any specific property (XMM detection flag)

My experience for what we are talking about for Flag is a qualifier on a property

• eg: the Quality of the RadialVelocity Property The Quality Flag itself relates only to the Property.. not the Source

There may be other Qualifiers/Flags which relate to the Source as a whole but are not a Property of the source.

• the XMM detection flag may be one such? indicates how reliable the Source record is?

[mcdittmar]

HardnessRatio

By doing this, you are breaking the homogenity exposed in #26.

Yes, a HardnessRatio (and other similar ratios) are a different kind of Measure, and should be accessed differently. This is exactly why there is an abstract Measure (with no 'coord' at the base level).

It is important to extends somehow to all properties the concept of meas/coord/coord_sys

I strongly disagree here. The model should describe the entities as they are. To force concepts like Error, Coord, CoordSys on entities like StellarClass is a mistake. When you extend Measure, you are saying that "this thing IS a Measure" and the concepts related to it apply.. Error being the most basic.

As you look concerned by the way I'm using MCT, we could imagine another pattern linking values, with errors and data spaces where there are valid. So that the Parameter split you proposed in #26 could be shifted into that new pattern and the uniqueness of the interface would possibly be saved.

I'm not sure what you mean here, but would be happy to discuss alternatives. If you emphatically need classification.error to be part of the API, I'd say that is at the tool implementation level, the Model would have no such concept. This method would always return a NULL.

[mcdittmar]

I do not seen the gain we have by using a specific attribute for flags instead of using the associatedParameter scheme.

• Most of the properties have no flag at all
• Some have several
• Flag are not related to any specific property (XMM detection flag)

The raw file for the "Identity" case is a good example for exercising the Quality usage too. It has ~ 9 Properties, 7 have a Quality assignment, both Measurement and Classification types.

• ObjectType (no Quality)
• Position
• Galaxy Dim (an ellipse)
• ProperMotion
• RadialVelocity
• Redshift (no Quality)
• Parallax
• SpectralType
• MorphologyType

Most of these also have a "Bibcode reference" associated with them. I would not consider these Source Property-s either (they don't pertain to the Source, but rather the Property itself). I'm not sure what these are, or how common in catalog data. If common, could also be an attribute on Property, if not, they maybe part of a local extension, but not part of the core model.

[lmichel]

The raw file for the "Identity" case is a good example for exercising the Quality usage too. It has ~ 9 Properties, 7 have a Quality assignment, both Measurement and Classification types.

I took a Simbad output on purpose, but this very specific. This is an interesting case because all Simbad data are compilation of values extracted from various catalogues. In general we do not have quality flags.

If we reshape Mango with a distinction between physical parameters and let's say labels, bib_code relate to the latest.

[Bonnarel]

HardnessRatio

By doing this, you are breaking the homogenity exposed in #26.

Yes, a HardnessRatio (and other similar ratios) are a different kind of Measure, and should be accessed differently. This is exactly why there is an abstract Measure (with no 'coord' at the base level).

HardnessRatio doesn't belong to direct observational quantities. Can be compared to estimated Physical quantities such as metallicity, density, temperature. All this belong to a physical space where our astronomical objects are located. So they all look like coordinates to my eyes.