(r6) PhotDiscussion < IVOA

IVOA Web>IvoaDataModel>PhotometryDataModel>PhotDiscussion (revision 6) (raw view)~~EditAttach~~
---+ 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 IVOA.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<br /> + There is some concern about the circular dependence between the Photometry<br /> 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:

<br /> Section 3.2.10<br /> The referenced file 'will be a spectrum serialization', which means it<br /> must contain all required Spectrum model information, including<br /> - Char.SpectralAxis.*<br /> - Dataset.DataModel<br /> (btw: I believe the UType given in 3.2.10.2 should be "spec:Dataset.DataModel")<br /> - Target.name<br /> There should be instructions on how to resolve the "Char.SpectralAxis"<br /> information of the externally serialized spectrum instance with the<br /> PhotometryFilter.SpectralAxis info.

<br /> In fact, if you take the description of the 'in-line' serialization from 3.2.9<br /> The PhotometryFilter.SpectralAxis.* + PhotometryFilter.transmissionCurve.spectrum<br /> pieces essentially define a Spectrum-like object. With Spectral2.0, PhotometryFilter<br /> could be defined as an extension of the BaseSPS that is VERY similar to Spectrum<br /> in content, with added content for the fps ids and bandpass info, and NO PhotCal,<br /> and presumably, modified required field set (no Target.name).

<br /> But the Spectral Model isn't out yet.. <br /> 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.<br /> 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<br /> extension for the Transmission curve spectrum data as it does for other items<br /> incorporated from external models (Char).<br /> &lt;TABLE utype=photdm:PhotometryFilter.transmissionCurve.spectrum<br /> &lt;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, 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 PhotCal.PhotometryFilter.* utypes) they could be just Curation.*.

<br /> The params, Facility, ProfileReference, and CalibrationReference do not contain<br /> utypes at all. Nor do I find a corresponding description, perhaps these are user<br /> defined extensions?

+ Example C2<br /> - top level Group with UType for spec:Data.FluxAxis.Value doesn't make sense<br /> - UType given for TransmissionCurve reference does not match utype list.<br /> Some areas of concern arise from consideration of how these elements will be used by<br />various consumers such as the NED service and from within Spectrum.

+ Consumer usage<br /> The model represents a view from the Filter Profile Service perspective. From a<br /> consumer perspective, it is not clear how some of the information for defining a<br /> PhotometryFilter is to be obtained. For example, NED will have photometry point<br /> data, along with some 'name' identifying the filter/passband used. This data would<br /> correspond to the PhotometryFilter.name field of the model. At present, there is<br /> no mechanism which they could possibly translate that information to a viable<br /> FPS and ID required to obtain a full description of the passband. We feel there is<br /> a real need for a formalized vocabulary for identifying photometric filters which<br /> can be used to enable this mapping.

+ Connecting the pieces<br /> The model describes the various pieces (PhotometryFilter, PhotCal, PhotometricSystem)<br /> and includes a diagram of their relationships. However, all text and examples keep a<br /> strict isolation of each component from the others. As such, it is unclear to users how<br /> they should construct a full representation of, for example, a PhotometricSystem.<br /> This is of primary concern for the Spectral model work. The expectation is that<br /> the PhotCal object will be incorporated into the model, which will provide the<br /> hook to access PhotometryFilter and ZeroPoint information relevant to the Spectrum.<br /> In none of the examples or defined UTypes is there any connection between these<br /> objects. There must be an explicit linkage between the objects to unambiguously<br /> associate the proper Photometry information with the corresponding FluxFrame<br /> when dealing with data products (Time Series, Catalogues) which will contain multiple<br /> Flux axes.

+ Serialization<br /> The model contains no specified support for FITS serialization, which is a major<br /> transport mechanism for VO data. This generates some compatibility issues for<br /> the Spectral model which has, and must continue to support FITS serialization.<br /> To do so, that model must invent a representation, which is outside of its scope.

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r6 - 2012-09-06 - OmarLaurino
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema