Discussion page for Photometry data model : Calibration and Filter definitions
The current Working draft is available at
http://wiki.ivoa.net/internal/IVOA/PhotometryDataModel/WD-PhotDM-1.0-20111013.pdf
Previous versions and linked efforts on Photometry are available on the main photometry page
PhotometryDataModel
Here is the place to add your comments and suggestions about the document. Thanks for your input and feedback.
Comments on the Proposed Recommendation
Omar Laurino (with the VAO Standards and Infrastructure group)
For the model proper
+ There is some concern about the circular dependence between the Photometry
Model and Spectrum Model. This is both a formal problem and a concrete issue, as described in what follows, where we also suggest a possible solution:
Section 3.2.10
The referenced file 'will be a spectrum serialization', which means it
must contain all required Spectrum model information, including
-
SpectralAxis.*
-
DataModel (btw: I believe the UType given in 3.2.10.2 should be "spec:Dataset.DataModel")
- Target.name
There should be instructions on how to resolve the "Char.SpectralAxis"
information of the externally serialized spectrum instance with the
SpectralAxis info.
In fact, if you take the description of the 'in-line' serialization from 3.2.9
The
SpectralAxis.* +
PhotometryFilter.transmissionCurve.spectrum
pieces essentially define a Spectrum-like object. With Spectral2.0,
PhotometryFilter could be defined as an extension of the
BaseSPS that is VERY similar to Spectrum
in content, with added content for the fps ids and bandpass info, and NO
PhotCal,
and presumably, modified required field set (no Target.name).
But the Spectral Model isn't out yet..
Historically, the Photometry DM was meant to be used by a next version of the
SpectrumDM that wasn't ready yet and that was supposed to be developed in parallel.
While this suggests that the two documents are actually a single document, a solution is to take away from the
PhotDM document any references to the
SpectrumDM. The advantage is that the
SpectrumDM, which is meant to use
PhotDM, can freely change to accommodate the comments on its contents, without requiring
PhotDM to change as well. For instance, the hook laid out in
PhotDM (
SpectrumDM::Characterization.Coordsys) is obsolete and needs to be changed (we suggest that it is removed altogether).
In fact, the
SpectrumDM has evolved (
SpectralDM) so that it can now represent a
PhotometryFilter as a class derived from
BaseSPS, using the concepts and classes defined in
PhotDM, solving both the formal and concrete issues.
+ The relationship between the
PhotCal class and the
PhotometryFilter class is unclear. From the UML diagram it seems that one
PhotometryFilter instance can have several
PhotCal instances. However, from the text (section 3.3) it looks like
PhotClass has one field of the
PhotometryFilter class. In any case there are neither
PhotCal.photometryFilter.* utypes, nor
PhotometryFilter.photCal.* utypes.
+ Example C1 does not make use of current practices (but since there is no standard this is open to discussion) for namespace and utype
extension for the Transmission curve spectrum data as it does for other items
incorporated from external models (Char).
<TABLE utype=photdm:PhotometryFilter.transmissionCurve.spectrum
<FIELD utype=spec:Data.SpectralAxis.value
+ More generally, utypes do not follow any consistent pattern:
-
PhotometryFilter is not a root class, yet utypes start with
PhotometryFilter.*
-
PhotometryFilter class is a field of both
PhotCal (if our interpretation of the text is correct) and
PhotometricSystem (as a list). This would lead to two different sets of utypes according to the usual
UML2Utype convention. However, neither of those utypes are listed.
-
PhotometryFilter.transmissionCurve.transmissionCurveSpectrum (as indicated in the UML diagram,
PhotometryFilter.transmissionCurve.spectrum according to the text and utypes list) and
PhotometryFilter.transmissionCurve.access are siblings and are both classes reused from other documents, yet they are serialized in different ways: the spectrum instance is serialized by creating a table with a photdm:* utype that contains fields with the spec:* utypes (notice that the table doesn't contain a valid Spectrum instance according to
SpectrumDM), while the Access instance is serialized by creating a set of photdm:* utypes that embed the
.Access. terminals.
- For classes reused from
CharDM (e.g.
SpectralAxis) the utypes terminals from
CharDM are embedded in photdm:* utypes, but they lose the "Char" part (as opposed to what happens for Spectrum utypes, which are reused with the spec: namespace, and to what happens to Access utypes, which are reused with both the photdm: namespace
and the "Access" part.
+ No utypes are listed for Curation (according to the usual practices it should be
PhotCal.Curation.*, but for internal consistency (there are no
PhotometryFilter.* utypes) they could be just Curation.*.
The params, Facility,
ProfileReference, and
CalibrationReference do not contain
utypes at all. Nor do I find a corresponding description, perhaps these are user
defined extensions?
+ Example C2
- top level Group with UType for spec:Data.FluxAxis.Value doesn't make sense
- UType given for
TransmissionCurve reference does not match utype list.
Some areas of concern arise from consideration of how these elements will be used by
various consumers such as the NED service and from within Spectrum.
+ Consumer usage
The model represents a view from the Filter Profile Service perspective. From a
consumer perspective, it is not clear how some of the information for defining a
PhotometryFilter is to be obtained. For example, NED will have photometry point
data, along with some 'name' identifying the filter/passband used. This data would
correspond to the
PhotometryFilter.name field of the model. At present, there is
no mechanism which they could possibly translate that information to a viable
FPS and ID required to obtain a full description of the passband. We feel there is
a real need for a formalized vocabulary for identifying photometric filters which
can be used to enable this mapping.
+ Connecting the pieces
The model describes the various pieces (
PhotometryFilter,
PhotCal,
PhotometricSystem)
and includes a diagram of their relationships. However, all text and examples keep a
strict isolation of each component from the others. As such, it is unclear to users how
they should construct a full representation of, for example, a
PhotometricSystem.
This is of primary concern for the Spectral model work. The expectation is that
the
PhotCal object will be incorporated into the model, which will provide the
hook to access
PhotometryFilter and
ZeroPoint information relevant to the Spectrum.
In none of the examples or defined UTypes is there any connection between these
objects. There must be an explicit linkage between the objects to unambiguously
associate the proper Photometry information with the corresponding
FluxFrame when dealing with data products (Time Series, Catalogues) which will contain multiple
Flux axes.
+ Serialization
The model contains no specified support for FITS serialization, which is a major
transport mechanism for VO data. This generates some compatibility issues for
the Spectral model which has, and must continue to support FITS serialization.
To do so, that model must invent a representation, which is outside of its scope.