Photometry Data Model 1.1 Proposed Recommendation: Request for Comments

Introduction

PHOTDM v1.1 is a revision of 'PhotDM v1.0', redesigned to follow the rules and constraints set by the VODML meta-model definition.

The goals are :

• warrant backward compatibility as much as possible.
• keep the same concepts as in version PhotDM v1.0
• provide the PhotDMv1-1.vo-dml.xml description of all classes in VODML format.

All relations between classes and attributes are kept as much as possible.

For backward compatibility, Utypes previously defined in the previous Phot DM 1.0 REC document and listed in appendix B should not be changed after this update.

The benefit is to keep interoperability with the SVO Filterprofile service which has grown to a full Filter repository and represents a kind of Filter registry for the Multi-Wavelength astronomical community.

The new VODML representation allows building photometric annotations for various kinds of data products: catalogs, spectra, lightcurves, cubes, etc., using the mapping syntax currently proposed in the DM working group.

Below attached are the VODML documents representing the data model , and the VODML PhotDM1.1 XML document .

---

The latest version of the model and supporting docs:

• RCF Document versions (IVOA repository)
  • PDF
• Development Version: (Git Repository)
  • PhotDM github

Data model reuse and Implementation

• MANGO is a proposal for a model designed to enhance the interoperability of catalogue data. The MANGO model aggregates classes from Meas, Coords and PhotDM.
• VO Model Annotation Syntax (MIVOT) is a draft for an XML schema allowing to map VOTable data on any model. This specification comes with another repository (modelinstanceinvot-code) that gathers codes that are being developped to exercise the mapping syntax on real data. Two of these tools are working with this PhotDMv1.1 model.
• This annotation project contains a few Jupyter notebooks that can be launched online

Implementation 1:

SED Builder: A VOTable that gathers photometric data from XMM, 2MASS, WISE and Gaia has been annotated with PhotDM.

A demo (standalone or notebook ) reads this VOTABLE and plots one SED for each data row after having converted magnitudes into fluxes when requested.

Implementation 2:

Serialization of Filter Profile Service output: A script generates XML snippets from a FPS output applied to a template. These snippets contain XML serializations of both PhotDM:PhotometrySystem and PhotDM:PhotCal that can be used as components for further VOTable annotations.

Comments from the IVOA Community during RFC/TCG review period: 2022-03-07 - 2022-04-22

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments by MarkusDemleitner

Dear Markus,

I have updated the doc on https://github.com/ivoa-std/PhotDM/pull/59 following most of your comments. See responses after your points

-- JesusSalgado - 2022-04-11

(1) I have updated the architecture diagram to use variable-width boxes, which also entailed replacing SpectrumDM (which doesn't exist) with SpectralDM (that's part of PR #50). While doing that, I had doubts that STC should be listed here -- what we're referencing there is a standard that never really made it and that will most likely be replaced by MCT. Perhaps this should be updated? And there's still Utypes in there, which isn't a standard -- here, I'd suggest dropping it entirely. The caption of the figure with the role diagram might also mention that the specific relationships of PhotDM to the standards shown is discussed in the introduction.

STC removed from diagram. Architecture diagram caption enhanced. -- JesusSalgado - 2022-04-11

(2) As a general request, it would be great if lines could be reflowed to <80 characters per line, which is helpful for later edits (avoiding unnecessary conflicts; I had to rebase when creating the PR, and believe me, that was painful with these endless lines) and meaningful diffs. I have not done this in the PR to retain meaningful diffs.

Done for almost all the lines (except a few with formulae and URLs that could affect compilation) -- JesusSalgado - 2022-04-11

(3) Please do not use \cite in ivoatexDoc documents. For consistent formatting of the references, use natbib citep or citet as appropriate. PR #50 does this already for the existing references. Also, in the future, please take IVOA documents from ivoabib.bib; that makes it simpler to update references when new versions are issued. I've done this in the PR for IVOA identifiers, Obscore, SDM, and SSAP, which were partly outdated.

(4) Typographically, I'd suggest to write $\langle F\rangle$ rather than $$. This will let LaTeX choose better spacing, as <> are operators, whereas langle and rangle are delimiters. Also, please do not use paragraphs (well, empty lines) around displayed equations (unless they, indeed, conclude a paragraph, of course), as that, again, leads to bad spacing (see, e.g., the indentation of "so that the effictive flux density"). I have not done this in the PR to keep the diffs reviewable.

Changed to rangle langle

/par from formulae removed. -- JesusSalgado - 2022-04-11

(5) Still typographically, units are conventionally witten in roman rather than italic, and most importantly, letter spacing gets all wrong if they are written in math italic. PR #50 introduces macros for the units used in the document and uses them where I've found badly formatted units. Similar considerations apply to function names (ln, sinh).

(6) In my PR, I am also de-inlining some long URLs into footnotes as recommended by ivoatexDoc.

(7) The document mixes British (e.g., "catalogue") and US (e.g., "characterized") spelling. I don't care too much, and the IVOA don't have a policy on this, so perhaps there's no need to worry about this.

Most changed to British English. A language review by a native speaker will be done on a latest stage -- JesusSalgado - 2022-04-11

(8) p. 10, "PhotCal is the class node where SpectralDM v2.0 interacts." -- since SpectralDM 2.0 has been shelved and it is not yet clear what will replace it, I'd suggest to take that language out.

Language updated to remove specific connections to Spectral DM (SpectralDM was ongoing when the first version of PhotDM was written) -- JesusSalgado - 2022-04-11

(9) In PR #50, I'm taking out a hard page break on p. 10 which ran against the narrative flow. I suppose you have introduced it to move the floating figure into the chapter body. If that is what you are after, just move the figure environment up a bit lexically. In general, avoid \newpage in attempts to fix the positioning of floating elements -- this will lead to semantically unwelcome page breaks as the document evolves. I give you LaTeX's positioning of floats is sometimes nonintuitive, but it's almost always better to figure out why it is confused rather than forcing it with newpage. In the case of figure 2, you basically forced LaTeX to behave unreasonably be making a page-sized float H. "tph" very typically is a more reasonable placement hint.

(10) I'm not a big fan of the colorbox-es for displayed... examples? In particular, I expect these will be a pain in HTML output. Could you consider whether the listings environment (see ivoatexDoc) works for you, and if not, replace the direct markup with some semantic markup (as in: a custom environment)? Ping me for advice.

Colorbox removed. -- JesusSalgado - 2022-04-11

(11) 3.2.2, fpsIdentifier: "The service URL of the filter profile service..." -- the recipe isn't enough to be workable, as a registry record can contain any number of URLs. If you want this to work, you'd at least have to say "Obtain a capability with the standardID suchandsuch and use accessURL(s) given in an XY-interface". From what you write, I don't quite understand how this is intended to work; with some additional information, I can give more specific advice. Of course, if all you're after is associating a URL with the filter, you might consider just dropping this URL into the PhotometryFilter directly. Finally, the question is: Is there room for more than one FPS in the world? Because if not, we could drop this entirely and canonicalise the FPS.

FPS was thought as an open protocol (for filter that cannot be added to the SVO one). We will add a reference to the FPS implementation. I have modified slightly the text but preventing a full explanation.

-- JesusSalgado - 2022-04-11

(12) 3.2.6 Time validity range: "String time format accepted, ISO8601:" -- since ISO 8601 is such a behemoth, I'd much rather read: "The value is specified as in DALI \citep{2017ivoa.spec.0517D} timestamps."

Change done -- JesusSalgado - 2022-04-11

(13) 3.2.7 "gathered directly as a table using TransmissionPoint utypes" -- this is, for all I can say, too vague to ensure interoperarbility. If you have an implementation of that, please document more precisely what it produces/expects. If you don't then consider dropping this feature, as having something that's half specificed normally causes a lot more confusion than if it's not specified at all (I'm mentioning utypes themselves as an exemplary case for that).

Reference changed to the FPS serialisation section to preven ambiguities. Reference also added into bibliography -- JesusSalgado - 2022-04-11

(14) 3.2.9.1.1 -- I'm not at all a fan of the "\hspace{0pt} \\" hacks sprinkled in there. If you really don't like the default formatting of \paragraph headings, talk to me and I'll work something out.

At this level of hierarchy (5th level) the template does not work very well, without leaving a new line. This trick, at least, help to have a visual good aspect. See point 17 -- JesusSalgado - 2022-04-11

(15) 3.2.9.2 transmissionPoint -- In general, the whole section leaves a somewhat unfinished impression, starting with the somewhat clumsy part "Example: em.wl Where em.wl indicates...". Also "The Unit and UCD strings follow specific constraints..." seems a bit superfluous -- and you have not said where the unit string is supposed to end up in. See my point (13) above.

Reference to FPS implementation added to bibliography. We prevent to provide these details into PhotDM -- JesusSalgado - 2022-04-11

(16) 3.2.10.4 (PhotometryFilter.bandwidth.start, and analogously for .stop): "In practice, this could be taken as the minimum value of the filter transmission curve" -- this would conventionally mean "the minium flux value", which isn't what is meant here. So, perhaps change the text into "the minimum value of the support for the filter transmission curve" or similar (well: since the actual support of these functions normally isn't terribly compact, perhas we should rather talk about "a reasonable lower limit on the spectral axis" or so).

Added "reasonable value" for the definition of the minimum and maximum values. -- JesusSalgado - 2022-04-11

(17) Many \paragraph items in the document still have hard-coded section numbers, which are quite possibly wrong already, and certainly will be the next time someone touches the document. Please let!LaTeX number these, if you really feel the need to number them. If you need help with that, ping me.

\subsubsubsection is not implemented so they have been replaced by paragraph. This could be redefined as a command into the IVOA LaTeX template

The text follows the recommendation:

https://tex.stackexchange.com/questions/60209/how-to-add-an-extra-level-of-sections-with-headings-below-subsubsection

(First answer on this thread). -- JesusSalgado - 2022-04-11

(18) 3.3 (PhotCal Class): "Class to describe the use of a photometry filter" -- this is an incomplete sentence; on the following pages, there are quite a few articles missing ("Reference magnitude is a dimensionless variable").

I have added the articles you mentioned although a review by a English native speaker will be done -- JesusSalgado - 2022-04-11

(19) 3.3.1 (PhotCal.identifier): Couldn't this simply re-use the Photometry Filter identifier? The prose could be a good deal shorter if you just said: "This is the Photometry Filter unique identifier concatenated with a slash and the photometric system type".

The convention you mentioned is the one used by the Spanish VO FPS but it could be a different one (as defined in the reference) so we maintaine the freedom on the identifier construction -- JesusSalgado - 2022-04-11

(20) 3.4.4 ("ZeroPoint.type" and the following sections): "In the ZeroPoint class we define two conversion functions" -- ummm, no :-). I think you should base the document on the VO-DML structure, and that has no notion of functions or methods. Can't you just pull out the material on these operations into a separate section "Conversion between magnitude and flux using PhotDM" or so?

That was one of the discussions we had during the PhotDM 1.0 review. PhotDM has an UML diagram behind although most of the IVOA data models are more like ERDs. As you know, ERDs are composed by:

• Entities
• Attributes
• Relationships

And UML diagram are composed by:

• Classes
• Attributes
• Methods
• Relationships I think most (almost all) the IVOA DMs are not setting methods because we usually think on IVOA DMs as a way to connect metadata entities that we store into the DB but if you think on the client side implementation, these details are quite important when you want to create a client class extracted from the parsing of a serialised object.

In summary, there is a lack of support on methods on VO DMs (probably we can modify the term function by method in the text) but this is essential on the data model because ZeroPoint types are extensions of a basic (probably abstract) ZeroPoint class where the methods to convert magnitude to fluxes and vice versa are overrided (and other new attributes could appear). This way to extend mother classes, as you know, is quite general so I think to hide it (because, e.g. we do not know how to represent it in VO/DML) would be a mistake.

In any case, I think this is out of the scope of the present 1.1 update so it was already decided on the standard 1.0 to go in this way. At PhotDM level, the implementation of the methods should be maintained. -- JesusSalgado - 2022-04-11

(21) 3.8.2 (MagnitudeSystem.referenceSpectrum): "This is a URL, pointing to a published IVOA resource location containing the reference spectrum used." -- Umm... what exactly does this mean? Wouldn't it be much better to just say "retrieve the URI to obtain the spectrum"?

Text simplified. -- JesusSalgado - 2022-04-11

(22) 4 (Use Cases) Well, as long as there's just one, I'd perhaps use a singular in the section title. But then, in case Ada's time series serialisation is compliant with this (is it?): perhaps that should be the second use case? And if it's not: shouldn't we update that Note then?

Not sure of the status of Ada’s time series serialisation so, in order to prevent couplings, I have updated the title of the section to singular -- JesusSalgado - 2022-04-11

(23) A.1 (Zero point magnitude): "Taking the previous equation and clearing the magnitude" -- this is at the very beginning of a major section, and so it is somewhat inappropriate to reference a "previous equation", not to mention that the lexcally preceding equation does not seem to be what the next line derived from (for b!=0). Perhaps for this relatively equation-heavy document you ought to switch on equation numbering anyway?

Equation numbering set with references and added correct reference. -- JesusSalgado - 2022-04-11

(24) A.2 (Interrelation between...): "Although, as can be seen in the previous calculation" -- this sentence is missing something like "is possible, that practice" or so.

Text updated to be clearer. -- JesusSalgado - 2022-04-11

(25) Appendix B: The over-wide tables with wild hyphenations, too many rules, and run-in page numbers are... not pretty. Do you give me a license to re-format them (which would of course incur breaking the monstrous utypes, but, really, if you insist on the monsters, there's no way around that)?

Still pending on this. We will try to simplify the tables and we we ask for support if we find problems.

About the monsters, I assume this is already in use by some clients and servers so we do not have the freedom to change then into a minor version. Also, they follow the construction rules of other classical DMs -- JesusSalgado - 2022-04-11

(26) Appendix B: "The proposed Utypes are defined following the IVOA rules... from a simplified XML schema" -- well, since that schema, for all I can see, no longer is part of the document (and there are not IVOA rules on utypes), I'd say this information neither helpful nor relevant nor, indeed, correct. It would perhaps be useful to say how these utypes can be derived from the VO-DML if that's possible. But, really, can't you just say: "The utypes given here are to be considered opaque strings [folding case, perhaps?] by consumers of instance documents" and remove all the existing prose from Appendix B? Or am I missing something positive these explanations could do?

I do not remember the origin of this text but, obviously, it was added during the review and now it is not really consistent.

I have simplified in the line you suggested and I have maintained the zero points implementation reflexion that explains exactly the point you raised before (definition on the implementation of functions in a DM is somehow peculiar but it is the only mode found to cover the zero points implementation). As said this point was already discussed at that point and it looks out of the scope of a minor version review -- JesusSalgado - 2022-04-11

(27) Appendix D "Test listing in XML" -- this clearly wasn't intended to be an appendix of its own. And there's some detritus ("begin test syntax highlight") in there that should be removed. Since I'm not sure what this is intended to be, I have not touched anything. But then I'd say anything using dm:mapping shouldn't be in a REC before DM mapping is in late PR at the very least, and so I'd say this thing ought to be removed anyway.

Yes, that was removed -- JesusSalgado - 2022-04-11

(28) Appendix D again: The VOTable given uses the ancient version 1.1 schema. At least that reference (and the version tag) should be updated. A bit of a comment what this is and who should consider, imitate, or whatever that example would also be useful.

Still pending. Iteration needed with FPS developer -- JesusSalgado - 2022-04-11

(29) Appendix D.1 (Photometric Data in Cone Search): I'm really no fan of considerations like this ("could include", "will be as follows"). Mind you, referencing Sébastien's note and commenting if the current update in some way changes what's in there would be highly welcome (and that should be in the introduction). But please decide whether or not you want do define something implementable in there (then make it concrete) or not (then let's please drop it).

I think the language looks ambiguous but the implementation was defined. So, when it says: could include, it tries to say: For catalogues that include photometric measurements… And when it says: will be as follows: it tries to say: The workflow to make use of this capability is the following:

I have modified the text in this line. Just to mention that this capability was integrated into ViZieR in the server side and in VOSpec in the client side as reference implementations. -- JesusSalgado - 2022-04-11

(30) D.2 "Serialization using VO/DML model": This still has "Test" in the caption and repeats what I have complained about in (27). And I'd again say: Let's avoid any of that while the mapping spec still isn't even a WD.

The Test caption was removed.

About the need or not of this mapping example, it is true that the mapping spec is still a WD but this is a chicken and egg problem as the only way to check that the VO/DML support is doable is through the mapping. The only options I see are either to remove it and go ahead with PhotDM or maintain it with a note on the possible evolution of the mapping. We prefer to maintain it even in the form of an example

Thanks for the review Markus! -- JesusSalgado - 2022-04-11

-- MarkusDemleitner - 2022-03-17

Comments from TCG member during the RFC/TCG Review Period:

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Photometry DM 1.1 minor revision brings the model up to date with the VO-DML representation.

It does so keeping current implementation of photometry resources compatible with the newer specification.

The revision was done in a reasonable time frame and all comments from the community have been taken into account.

Applications Working Group

minor comment on the text in 2 Astronomical Photometry problem with some links

https://www.stsci.edu/resources/software_hardware/stsdas/synphot/SynphotManual.pdf not accessible

neither access to fits via http://www.stsci.edu/instruments/observatory/cdbs/calspec

New version has updated these dead links to the new location everithing fine -- PierreLeSidaner - 2022-09-06

-- JesusSalgado - 2022-08-02

in C.1 the votable example there is typo <!—here the points of the response curve are stored directly in an attached tableà the comment should be closed

in utype= T"photDM.TransmissionPoint.transmission.value" there is a T

Typo corrected in a previous version

-- JesusSalgado - 2022-08-02

if possible could you change the begining by

<VOTABLE version="1.1" xmlns="http://www.ivoa.net/xml/VOTable/v1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://ivoa.net/xml/VOTable/VOTable-1.1.xsd">
much more easy to validate

Could you please identify further where the change should be done?

-- JesusSalgado - 2022-08-02

Data Access Layer Working Group

Fig 2 - the significance of blue and beige background is not described

Explanation added

-- JesusSalgado - 2022-09-08

p33 - photdm:PhotometryFilter.transmissionCurve.access.size does not appear in the table should it?

Same with later three values of photDM.PhotometryFilter.transmissionCurve.transmissionPoint

Fields added to the table

-- JesusSalgado - 2022-09-08

p35 - should photdm:PhotometryFilter.dateValidityFrom and dateValidityTo be in the table on p32?

Fields added to the table

-- JesusSalgado - 2022-09-08

p35 - should the ucd for photdm:PhotCal.magnitudeSystem.ReferenceSpectrumURI be meta.ref.uri not meta.ref.url ?

UCD changed

-- JesusSalgado - 2022-09-08

I've also raised a PR for small fix.

-- JamesDempsey - 2022-08-06

Thanks James. All your comments have been included into the new version

-- JesusSalgado - 2022-09-08

Data Model Working Group

All changes on the spec are now covered and considered minor

-- JesusSalgado - 2022-09-29

Grid & Web Services

No particular comments from my side, I read the document as it is at 2022-09-15 and it includes all the comments and suggestions from the other WGs. The document is clear and well done. The version on Git differs from the one in the IVOA doc repo (dated March 2022) but I guess it is not a big problem at this stage.

We approve the standard. -- GiulianoTaffoni

Section 2, page 8

Linking to an external web page or document is fragile, the resource may change over the lifetime of the standard. The reference to a figure in the Synphot manual should specify the version (publication date (December 1998)) of the document it refers to.

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L401-L404

-- DaveMorris - 2022-10-04

Date added

-- JesusSalgado - 2022-10-07

Section 2, page 8

Do you mean figure 2.1 (Vega Photon Spectra) rather than 3.1 (plband Plot of Johnson V and WFPC2 Bandpasses) ?

-- DaveMorris - 2022-10-04

The document probably changed. Adding the date and removing the section number (in case the old version cannot be found in the future) looks to be the best way to proceed

-- JesusSalgado - 2022-10-07

There are a number of different forms of the long and short name for the Photometry Data Model, this pull request makes them more consistent:

https://github.com/ivoa-std/PhotDM/pull/118

-- DaveMorris - 2022-10-04

Section 3.2.7.2, page 18

This sentence is not 100% clear as to exactly what it means:

The serialisation of the transmission curve factorises the (unit, ucd) pair for all points of course.

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L882

Does this mean it is invalid to have different pairs for different points in a curve? If so, then why enforce this at the serialisation level ? Is it valid to have different values in a database, but not valid to serialse them ?

Suggested alternatives:

• The unit and ucd values SHOULD be the same for all TransmissionPoints in a TransmissionCurve.
• All the TransmissionPoints in a TransmissionCurve SHOULD have the same unit and ucd values.

-- DaveMorris - 2022-10-04

This section has been rewritten in one of the last pull request adding more info

-- JesusSalgado - 2022-10-07

Appendix C, page 31

Is PhotCalDM a valid data model identifier?

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L1577

-- DaveMorris - 2022-10-04

Changed to PhotDM as it was a typo

-- JesusSalgado - 2022-10-07

Appendix D.1, page 36

'Photometry Filter DM' should probably be 'PhotDM PhotometryFilter'

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L2051

-- DaveMorris - 2022-10-04

Changed

-- JesusSalgado - 2022-10-07

Section 3.3, page 21

'PhotDM' should be 'PhotCal'

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L1000

-- DaveMorris - 2022-10-04

This was already covered in a previous pull request

-- JesusSalgado - 2022-10-07

Section 3.1.2, page 13

Missing close bracket ')'

https://github.com/ivoa-std/PhotDM/blob/52e41bd652f70090fb65afc1c43d2be14169a3a3/PhotDM.tex#L599

-- DaveMorris - 2022-10-04

bracket removed

-- JesusSalgado - 2022-10-07

Everything covered in

https://github.com/ivoa-std/PhotDM/pull/124

-- JesusSalgado - 2022-10-07

Registry Working Group

R1) Section 2, p8

A convenient graphical representation of these systems is shown in Figure 3.1 of the Synphot manual:

http://www.stsci.edu/resources/software_hardware/stsdas/synphot/ SynphotManual.pdf.

=> broken link: DNS lookup failure for: zopeproxy.stsci.edu

Link updated to http://stsdas.stsci.edu/Files/SynphotManual.pdf

-- JesusSalgado - 2022-08-02

R2) Section 2, p8

Although the agreed Vega spectrum has changed histor- ically, the commonly referred to spectrum of Vega in digital form described in (Bohlin and Gilliland, 2004) is available as file at alpha_lyr_stis_002.fits at:

http://www.stsci.edu/instruments/observatory/cdbs/calspec

=> broken link: 404

Link updated to https://archive.stsci.edu/hlsps/reference-atlases/cdbs/current_calspec/

-- JesusSalgado - 2022-08-02

R3) Section 3.2.2 p14

Whenever the definition of the FPS filter profile service is standardised, the service url of the filter profile service could be obtained from the registry by requesting the associated information of this registry resource, e.g., once registered the service URL associated to this Filter Profile Service would be, e.g.: http://svo.cab.inta-csic.es/theory/fps/

=> typo in “standardised” => “standardized”

Document written in British English so standardised is fine

-- JesusSalgado - 2022-08-02

=> suggestion: This seems to be an acronym definition => “filter profile service” should be in parenthesis and with capital letters: “(Filter Profile Service)” or just replace “FPS filter profile service” by “Filter Profile Service” like elsewhere in the document ?

Done

-- JesusSalgado - 2022-08-02

R4) Section 3.2.9.2

unit, type Unit, with the unit used for the specralValue. This is also linked to the type of spectral coordinate used

=> typo in “specralValue” => “spectralValue”

Changed

-- JesusSalgado - 2022-08-02

=> suggestion: use the new DM Measurements for the type of spectralErrorValue ? I am not an expert, but it seems that spectralErrorValue might be an error of a measurement, and its type could benefit from the new DM ?

That's a good suggestion but it breaks backwards compatibility within this minor version. Point taken for a future PhotDM 2.0

-- JesusSalgado - 2022-08-02

R4) Section 3.2.10.4 PhotometryFilter.bandwith.start: real

and Section 3.2.10.5 PhotometryFilter.bandwith.stop: real

=> suggestion: while not exactly the same concept, use the same words as in other standards (RegTAP uses “stop” vs “end” in RegTAP’s std_spectral.spectral_start and spectral_end) in https://ivoa.net/documents/RegTAP/20220519/WD-RegTAP-1.2-20220519.html#tth_sEc8.17 This might not be a very important point, but could help to add coherence to our nomenclature.

Same as before, this is a good comment but we cannot change utypes used by implementations into a minor version. To be done for PhotDM 2.0

-- JesusSalgado - 2022-08-02

R5) Section 3.4.2 ZeroPoint.referenceMagnitude.value: real

and Section 3.4.3 ZeroPoint.referenceMagnitude.error: real

=> question: maybe use the new DM Measurements for the type of ZeroPoint.referenceMagnitude.error => sysError ?] Similar remark as above for Section 3.2.9.2, (discussed with Pierre Le Sidaner who agrees with this suggestion.)

Same as before, this is a good comment but we cannot change utypes used by implementations into a minor version. To be done for PhotDM 2.0

-- JesusSalgado - 2022-08-02

R6) Section 3.8.2 MagnitudeSystem.referenceSpectrum: URI

This describes the spectrum of an astronomical object used as reference to perform photometric calibration.

This points to a Spectrum object as defined in the IVOA spectrum data model (McDowell and Tody et al., 2011). Instead of having the whole spec- trum attached, we define a link to it as referenceSpectrumURI. The spectrum will be retrieved by invoking the URI. For example: http://svo2.cab.inta-csic.es/theory/fps/morefiles/vega.dat

=> suggestion: use a VOTable with metadata rather than an ASCII file with 2 columns and NO metadata. As a general comment, we think that within the VO, we should try to avoid files with no metadata. Although the context in this document well describes the contents of the file, one might stumble upon this file outside of any context.

That a good suggestion but, unfortunately, these calibration files are out of the scope of the PhotDM. These spectral files are used by tools using this format. We will derive the comment to the FPS implementors

-- JesusSalgado - 2022-08-02

R7) Annex D.2 Photometric Data in Cone Search

Catalogs could include photometric measurements in some columns. In order to allow the publication of these measurements in a. e.g., cone search service, the creation of a new capability has been proposed.

The workflow to make use of this capability will be as follows:

A cone search (or a future TAP service) will be registered with a certain agreed capability, e.g., Photometry.

=> change title include TAP which is discussed in the paragraph

• • TAP added in title -- MireilleLouys - 2022-09-15

=> clarify the meaning of capability here (cf VOSI 3.1 - discussion of capability https://ivoa.net/documents/VOSI/20170524/REC-VOSI-1.1.html#tth_sEc3.1)

=> clarify where and when the creation of a new capability has been proposed ? (if possible)

=> clarify whether “capability” here actually means using the capability/dataModel mechanism (which, according to Markus is deprecated) described in IVOA Identifiers v2.0 Recommendation 2016 section 4.2. If not do you mean a new standard_id ? Or a new version of ConeSearch ? This would be our remark with the higher priority regarding the Registry WG: in our opinion this paragraph must be clarified to include references and a more thorough discussion of the mechanism proposed to include photometric measurements to catalogs.

• I have updated this appendix and removed the capability discussion in this document.
• Capabilities definition: This is an interesting point to discuss, namely because we may want to distinguish between Mivot annotated serialisation in VOTable and former Utypes annotated serialisations for any model, but also for serialised datasets using the PhotDM data model.
• The topic belongs to cross WG discussions and could be tackled in a frame larger than this particular specification update. -- MireilleLouys - 2022-09-16
• Representing Photometry in a Conesearch response was discussed and proposed by S. Derriere into the technical note:https://wiki.ivoa.net/internal/IVOA/PhotometryDataModel/NOTE-PPDMDesc-0.1-20101202.pdf

-- JesusSalgado - 2022-08-02

R8) What is the relationship between sections 3.2.7 and 3.2.9, both of which are named "PhotometryFilter.transmissionCurve"? Should they be combined?

First item was an introduction and the second a detailed utypes list but it is true that this is confusing. Both points combined into the same item as suggested

-- JesusSalgado - 2022-08-02

-- RenaudSavalle - 2022-07-29

Semantics Working Group

(1) Semantics is not overjoyed to see em.wl used as the UCD for photDM.PhotometryFilter.transmissionCurve.transmissionPoint.spectralValue.value and in some other places; unless I'm missing something major, the model is built such that the field could contain a frequency or an energy (or a wave number?), too, right? If so, you should either drop the UCD for this field or ask adopters to give whatever applies of em.wl, em.wavenumber, em.freq, or em.energy.

• This is a good point. The PHOTDM1.0 was intended to represent all filters in the same spectral coordinate, here wavelength, in order to compare the spectral coverage of various filters in one go. The definitions of each attribute of the Bandwidth class (section 3.2.10) allow this already. UCD and units can be specified according to the spectral coordinate chosen to represent the transmission curve. This would then need conversions when when comparing different radio regimes, for instance. -- MireilleLouys - 2022-04-08
• • Hm... so, what does this mean? Are people allowed to have spectral coordinates other than em.wl or are they not? -- MarkusDemleitner - 2022-09-15
  • PHotDM1.1 allows dataproviders to use appropriate ucd and unit for their prefered spectral regime: em.freq, em.energy instead of em.wl, with compatible units. The text in sections 3.2.7 , 3.2.8 and the data summary tables p33 and 34 have been updated accordingly. -- MireilleLouys - 2022-09-15

(2) Similar consideration make me doubt whether pre-setting PhotometryFilter.spectralLocation.UCD to "em.wl" is a good idea. I'd prefer to require deployers to be explicit about this fundamental point. If you follow this reasoning, you should also un-default the spectral units. Personally, I'm not too happy abound having them in the DM in the first place, as you'll have units in the VOTable, too, and specifying the same thing in two places generally is something I'd rather avoid.

• The VOTable Format serializes the features defined in the model. In order to compare instruments' various filters in bandwidth and response, it is important to define the spectral nature (freq, wl, energy) and the units for some regimes where they are usually compared. -- MireilleLouys - 2022-04-22
  • That is exactly the reason why I suggest to have not defaults. There's nothing wrong with requiring the UCD and unit, but there should not be defaults, as that comes with the massive risk that people forget to give things, and then wrong defaults kick in. -- MarkusDemleitner - 2022-09-15
  • Defaults removed -- MireilleLouys - 2022-09-15

(3) I can't quite tell from the document how PhotCal.magnitudeSystem.ReferenceSpectrumURI is intended to be resolved, but I have a hard time figuring out how making this a meta.ref.ivoid (as opposed to meta.ref.uri or perhaps url) could be right -- you're not planning to store spectra in the Registry, are you?

• agreed , no need for a an ivoid. Changed as meta.ref.uri. -- MireilleLouys - 2022-04-22

(4) I think I'm also not too happy about calling the asinh softening parameter an obs.param. Isn't this more a parameter of the data reduction (if anything)? I give you stat.fit.param isn't all ideal for that either, but it's more plausible than obs.param in my book. Or what about phot.calib? I suppose my vote would be for ;phot.calib if there were a generic parameter atom...

• in this intermediate version 1.1, we aim at keeping backward compatibility. A better term will be choosen for PhotDM2.0. -- MireilleLouys - 2022-04-22

-- MarkusDemleitner - 2022-03-17

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

I'm not a spectrscopist, so mainly I'm reading this from the point of view of someone who maintains spectral metadata for my archive and would be looking to try to map this model to my own. From that point of view the method and approach seem clear, and my comments, consequently, are mainly about readability and clarity of description.

• Section 2, page 8, first paragraph. The sentence beginning "mR is most often chosen..." has too many instances of the words "most" and "usually". Combined with the parenthetical remark, the net effect is to render the sentence nearly meaningless (e.g.: "mR is most often chosen to be zero, except when it isn't, and even when it is zero it isn't zero because the system changes."). A rewriting as a set of simpler, direct statements might be helpful.

A simplification of the sentence has been added following the spirit of the original text -- JesusSalgado - 2022-04-25

• Section 3.8.1: The statements "Possible values are:" and "The list is not exhaustive" seem to contradict each other. If the list is not exhaustive, then these would be better described as "example values". A reference to the location of the current exhaustive list of valid values would be helpful. Also, there is a reference saying "See section 2.2.3 for a detailed description," but there is no section 2.2.3 in this document and no other document is named.

Done and reference updated -- JesusSalgado - 2022-04-25

• Section 3.8.2, third paragraph: I suspect this paragraph (beginning "This URL, ...") should instead be a continuation of the previous paragraph (otherwise "This" is undefined). It might even have been intended to be a parenthetical clarification of "referenceSpectrumURI". In fact, all five of these single-sentence paragraphs would be better formulated as a single paragraph. I am not able to make any sense of the end of the fourth paragraph, starting at about "...for instance or re-use PublisherDID which is a...". There is certainly some punctuation missing, but has a word or two has been dropped as well? Or maybe there's a reference to another model/standard that is missing? I am not sure what "This mechanism" at the beginning of the fifth paragraph is referring to. The examples that follow do not include URIs, and thus do not help to demystify the text.

Previous text tries to use a registration/discovery system that was not used at the end and complicates the access. Example added and text simplified -- JesusSalgado - 2022-04-25

• Section A.1 refers to "Taking the previous equation", but there is no previous equation in either section A.1 or Section A. References to equations that depend on document order tend to be problematic when documents are updated. I recommend numbering the equation and referring to the number instead of the current relative position in the document.

Already done as it was also recommended by other reviewers -- JesusSalgado - 2022-04-25

• Section B: This table is pretty hard to use. In the PDF, the page numbers occur in the middle of the first column, and despite the wideness of the table some values still wrap, while others overwrite each other. The "Meaning" and "Default Value" columns are particularly difficult to disentangle from each other. Given the point size of type considered acceptable in Figures 1 and 2, it seems like a better solution might be obtainable here...

Tables updated -- JesusSalgado - 2022-04-25

• Section C: The indenting seems to follow no specific pattern. Is it meaningful? If not, why bother?

The only intention at this stage is to produce an output that could be read easily. Still some work on this area is ongoing -- JesusSalgado - 2022-04-25

Typos:

• Section 3.2.5: "discourage" should be "discouraged".
• Section 3.2.7, third paragraph: "modifies" should be "modify".
• Section 3.2.7, last sentence: There is an extra '.' at the end of the last sentence.
• Section 4.1, second bullet: Should "photdm:PhotCal.identifie" be "photdm:PhotCal.identifier"?
• Section B, page 35, second paragraph: There seems to be a spurious line break before "However, the data structure...".
• Section B, page 35, last paragraph: "using array" should be either "using an array" or "using arrays".
• Section C1, page 36, last FIELD: I suspect 'utype= T"photDM...' should be 'utype="photDM...".
• Section C3, page 45, "Transmision Curve" should be "Transmission Curve" (in XML comment)

Typos corrected. Thanks for the review Anne -- JesusSalgado - 2022-04-25

-- AnneRaugh - 2022-04-20

Theory Interest Group

Time Domain Interest Group

The following is a review of the PDF dated 2022-04-22 from the Git repository, which appears to include the twiki items dated 2022-04-25.

Overall.. nice job with the conversion to VODML. I think the comments below look worse than they are. I consider them rather minor details which may help avoid confusion in future readers of the document.

Question: Is there a schema file for the model? I don't see one in the repository.

Typo-s:

• Section 3, paragraph 7: “PhotCal is the class node where data model describing spectral data interacts”
  • Removal/Substitution of “Spectral DM V2.0” here left the sentence a bit non-sensical
    • “where another data model describing spectral data interacts”
    • “where a data model describing spectral data interacts”
    • “where a spectral data model interacts”

Done. -- JesusSalgado - 2022-06-28

• • extra space.. “the calibration configuration used , bringing”

Done. -- JesusSalgado - 2022-06-28

• Section 3.1.2: “At current state, this list is exhaustive”
  • Not the best phrasing, but not bad.. “At present, “ or “At the time of this writing, “ might be more clear.

Done. -- JesusSalgado - 2022-06-28

• Section 3.2.7: “serialised” -> “serialized”

The standard is written in British English. -- JesusSalgado - 2022-06-28

• Section 3.2.10.4: “Also called in the rest of the document”.. lost lambda-min

Done. -- JesusSalgado - 2022-06-28

• Section 3.2.10.5: the formula shows “min = “ rather than “max = “ was OK in V1.0

Done. -- JesusSalgado - 2022-06-28

• Section 3.8: Tables missing vertical bars

Single cell table. In any case, I have reformatted it to simplify the look and feel of the table

-- JesusSalgado - 2022-06-28

• Section 4:
  • bullet 1 - extra space in canonical utype declaration “ spec:Spectrum.Data.FluxAxis.value”

Done -- JesusSalgado - 2022-06-28

• • bullets 2,4 - uses “photdm:” for the UType 'namespace' rather than “photDM:” in the UType table and elsewhere in the text.
    • NOTE - this is true in V1.0 as well, but should maybe be corrected.
    • NOTE - Appendix C.3 also uses “photdm:” for the vodml-id namespace, but this could actually be different.

Changed everything to photdm: -- JesusSalgado - 2022-06-28

Diagram errors/inconsistent with text:

• Section 3.2.2 - “PhotometryFilter.fpsIdentifier” is “fpsidentifier” in the diagram. (lower case ‘I’)
• Section 3.2.5 - “PhotometryFilter.bandName” is “bandname” in diagram. (lower case “N”)

Changed as suggested in the Modelio project and derived files and diagrams . Documentation in html and PhotDM VOdml.xml rebuilt. -- MireilleLouys - 2022-07-01

ISOTime type

• Section 3.2.6: “Validity time stamps are expressed as ISOTime as specified in DALI (Dowler and Demleitner et al., 2017) timestamps.”
  • This is a pseudo-type for "string of a particular format", I don't see a definition of an ISOTime type in either V1.0 or V1.1.
    • so use of it as a 'type' in the diagrams and text may lead to confusion.
    • the UType table shows these elements as 'string' type.
  • NOTE: this definition is consistent with the Coords model “ISOTime” type. The Coords model does not reference DALI, but the language is intentionally aligned with the referenced DALI content. In Coords, I’ve used the ivoa:datetime type for the base value type.. rather than 'ivoa:string'.

The Base type diagram in fig.3 shows how ISOTime is introduced as a derivation from the ivoa:datetime class. Such a type is defined in DALI and can be used widely in other specifications. Including it in the ivoa: template model would be useful in other use-cases. -- MireilleLouys - 2022-07-01

UCD type:

• Figure 2: diagram shows SpectralLocation.ucd, Bandwidth.ucd, TransmissionPoint.ucd, Flux.ucd as “UCD” type, which is not a defined type.
  • similar to ISOTime, the text describes these as a String type with specific constraints (complies with UCD standard).
    • Section 3.2.9.2.1: TransmissionPoint.spectralValue.UCD == String type with specific constraints (UCD)
    • Section 3.2.10.1: PhotometryFilter.bandwidth.UCD == String type with specific constraints (UCD)
    • UType Table: UCD elements of type ‘string’
• Appendix C.3 - VODML serialization: dmtype=“ivoa:UCD”, which is not a thing.

The Base type diagram in fig.3 shows how UCD is introduced as a derivation from the ivoa:string class type. Such a semantic label is defined in other IVOA models Spectrum, ObsCore, MANGO, etc. and can be used widely in other specifications. Including it in the ivoa: template model would be useful in other use-cases -- MireilleLouys - 2022-07-01

PhysicalQuantity:

This version appears to have dropped the PhysicalQuantity types, and dispersed the attributes into objects.
The UTypes for the endpoints are unchanged, so I suppose the thought is that this is sufficient for backward compatibility..

• • Examples:
    • ZeroPoint.referenceMagnitude => referenceMagnitudeValue + referenceMagnitudeError
    • TransmissionPoint.spectralValue —-\ transmissionValue + spectralValue + spectralErrorValue + unit
    • TransmissionPoint.transmissionValue —/
    • PhotometryFilter.spectralLocation => SpectralLocation

However, Section 3.2.9.2: TransmissionPoint.spectralValue and transmissionValue describes TransmissionPoint content as a PhysicalQuantity with a specified UType.

PhysicalQuantity proposal was removed from the model -- JesusSalgado - 2022-06-28

The former PhotDM v1.0 used physical quantity classes which used to aggregate all the basic fields that compose a physical measurement : value, error, units, etc. However, here in the present specification we describe individual attributes of the different quantities separately. This is due to the fact that the granularity of quantities as defined in the former PhotDM 1.0 did not match the one proposed in the VODML ivoa template. -- MireilleLouys - 2022-07-01

• • this text is unchanged from V1.0
  • the UType given, is NOT in the UType table of either version, but this could be considered a declaration of the UType for a PhysicalQuantity serialization
  • however, without PhysicalQuantity, the elements involved can not be encapsulated in a single ‘Quantity’ type and single UType pointer
    • TransmissionPoint.unit
    • TransmissionPoint.spectralValue
    • TransmissionPoint.spectralErrorValue

Section 3.4.2: zeroPoint.referenceMagnitude.value

Text modified to cover the new TransmissionPoint elements decomposition. -- JesusSalgado - 2022-06-28

• • “The reference magnitude is a dimensionless variable. It is modeled using a PhysicalQuantity object type of appropriate precision (float,double).”
    • but it is not.. it is now just a ‘real’

Reference to physicalquantity removed -- JesusSalgado - 2022-06-28

-- IVOA.MarkCresitelloDittmar - 2022-05-17

Operations

Mostly looks OK but a few comments.

• Sec 1: "This document proposes a standardization of a protocol to be used by Filter Profile Services." I don't see any standardization of a protocol here. The use case in Section 4.1 talks about "Query[ing] the filter profile service" but doesn't explain how to do this. Am I missing something? As a DM document rather than a DAL one I don't say this document has to explain the protocol, but it shouldn't claim to do so if it doesn't.
  • agreed. Introduction section changed . Filter Profile service can implement this model for representing Filters. -- MireilleLouys - 2022-04-22
• Sec 3.2.2: the example IVOID is "ivo://svo/fps". That IVOID doesn't exist, but "ivo://svo.cab/fps" does. It's only an example, so not necessarily required to reference a real service, but it seems like it might as well do so.
  • changed as suggested -- MireilleLouys - 2022-04-22
• Some of the document references could be updated, e.g. the citation to IVOA Identifiers is for v1.0 (2007) not v2.0 (2016).
  • updated , as well as some iother ivoa standard references . -- MireilleLouys - 2022-04-22
• Sec 3.2.6: the ISOTime format specification should possibly defer to DALI for consistency. If not, allowing the 'T' without a trailing time part is a bit strange. And there should possibly be some discussion of time zone. But really: is there ever going to be a case for sub-day resolution here? My uninformed guess is not, in which case it could be simplified to "YYYY-MM-DD". But if there's some good reason to stick with the text as written I don't insist on changes.
  • modified with reference to DALI -- MireilleLouys - 2022-04-22
• Sec 3.4.4: the data type listed in the section heading is "enum", but "integer" is given for a similar usage in sec 3.1.2, and "integer" is also the term used for ZeroPoint.type in the table in Appendix B. Make it consistent?
  • Done. -- MireilleLouys - 2022-04-22
• Sec 3.8.2: capitalization and spelling of the terms VEGmag, ABmag, STmag is different from that presented in sec 3.8.1 (VEGAmag, ABMag, STMag)
  • Changed. -- MireilleLouys - 2022-04-22
• Several of the items in the model are given with datatype "double", both in section 3 and Appendix B. In the examples in appendix C.1 and C.2 they are mostly written in the VOTables with datatype="float". This sort of thing has caused problems with several standards in the past; I suggest making it clear somewhere that these model data types are allowed to use any floating point (or any numeric) type, e.g. by using a neutral term like "real" in the definitions.
  • Changed accordingly -- MireilleLouys - 2022-04-22
• Appendix B: the tables are quite hard to read in the PDF; I know it's hard to format these things, but there is quite a bit of unused whitespace leading to overheight pages, so probably it could be improved.
  • Hard to reach a good compromise for lisibility with Latex . Not changed in the document. Model components in XML will be available on git repo -- MireilleLouys - 2022-04-22
• Appendix C.1: indentation seems arbitrary for some of the listed XML, which makes it harder to read than necessary. Delete empty unit="" and ucd="" attributes unless there's some good reason for them.
  • Improved with the listing Latex environment. -- MireilleLouys - 2022-04-22
• Appendix C.1: there are some errors in the VOTable. Use stilts votlint to diagnose and fix. I can help on request
  • Done. -- MireilleLouys - 2022-04-22

-- MarkTaylor - 2022-03-15

Following recent fixes version 20220915 is mostly OK; some of the equation formatting is still degraded from earlier versions due to version control mishaps, but mostly not too seriously. But there are still one or two mistakes(?) that should be checked/remedied before publication:

• Fig 2 and the examples in Appendix D.3 refer to ZeroPoint.Flux.unitexpression, but the text refers to ZeroPoint.flux.unit.expression . Choose either unitexpression or unit.expression and use it consistently
• Sec 3.3: "PhotDM is a class..." -> "PhotCal is a class..." ?
• Sec 3.3.1: "the main requirement of the uniqueIdentifier is..." -> "the main requirement of the identifier is..."
• Sec 3.6.2: "$m_0$ is the reference magnitude" -> "$m_R$ is the reference magnitude" ?
• Equations (32), (33), (42) use the coefficient 3.631, while equations (9), (11), (39), (40), (43) use 3.63. For all I know that might be correct, but it looks a bit suspicious, can you check.

-- MarkTaylor - 2022-10-06

Thanks again for these corrections. I have ammended them in commit

https://github.com/ivoa-std/PhotDM/pull/122/commits/d4f6a11d9b807d04b7e182542beee433a516485e

-- JesusSalgado - 2022-10-06

Good! Thanks. Approved.

-- MarkTaylor - 2022-10-06

Standards and Processes Committee

---

TCG Vote :

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group	Yes	No	Abstain	Comments
TCG	X
Apps	X
DAL	X
DM	X
GWS	X			Minor changes and typos
Registry	X
Semantics	X
DCP
KDIG
SSIG	X			typos noted
Theory
TD
Ops	X
RadioIG
StdProc

---

<!-- Set ALLOWTOPICRENAME =<span> TWikiAdminGroup

<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup