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-PhotDMv1-1-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).

-- JesusSalgado - 2012-10-19 After some discusssion, we will try to implement this approach as per defining TransmissionCurve as an extension of BaseSPS

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 PhotDMv1-1 document any references to the SpectrumDM. The advantage is that the SpectrumDM, which is meant to use PhotDMv1-1, can freely change to accommodate the comments on its contents, without requiring PhotDMv1-1 to change as well. For instance, the hook laid out in PhotDMv1-1 (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 PhotDMv1-1, 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.

-- JesusSalgado - 2012-10-19 UML is going to be modified to clarify the inter-relations

+ 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

-- JesusSalgado - 2012-10-19 This was done in purpose trying to define how to reuse components and the impact on utypes. The approach use allows navigation from parent class

+ More generally, utypes do not follow any consistent pattern:

- PhotometryFilter is not a root class, yet utypes start with PhotometryFilter.*

-- JesusSalgado - 2012-10-19 PhotDMv1-1 has, at least, two root classes. PhotometryFilter and PhotCal.

- 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.

-- JesusSalgado - 2012-10-19 There is not agreement on how to represent elements in a list. This is why the construction of utypes for elements of PhotometricSystem (using PhotometryFilter) is overlooked. In any case, not all the data models can be always navigated from a root class. In the moment that there is a small complexity this approach is not longer valid and you could reach the same attribute from two different ways (mostly, depending on the use case)

- 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.

-- JesusSalgado - 2012-10-19 Discrepancy in the name between UML and text will be solved.

-- JesusSalgado - 2012-10-19 Serialization uses spectrumDM utypes in order to help client applications to understand it. It is not clear if it is invalid to have different utypes for the same field if we use different namespaces. It has to be analyzed how to proceed in this case so I consider the solution an open issue

- For classes reused from CharDM (e.g. SpectralAxis) the utypes terminals from CharDM are embedded in photdm:* utypes, as opposed to what happens for Spectrum utypes, which are reused with the spec: namespace. Also, the SpectralAxis and the FluxAxis keep, in the utypes, the prefix Data, while the Char spectral axis loses the Char prefix.

+ 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.*.

-- JesusSalgado - 2012-10-19 Curation link used to define a possible upgrade of the model has been removed until to have a better idea on how to use it

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?

-- JesusSalgado - 2012-10-19 Yes. This are fields included in a Filter Profile Service implementation. A note is being prepared to standarize it. In principle, it looks connected to provenance and, perhaps, the utypes should be related to that

+ 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.

-- JesusSalgado - 2012-10-19 A note is being prepared as a starting point of a future Filter Profile Service standard

+ 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.