Spectrum 1.2 Proposed Recommendation: Request for Comments

Introduction

The Spectrum Data Model describes the structure of spectrophotometric datasets with spectral and temporal coordinates and associated metadata.

This update satisfies an enhancement request by IPAC to add support for the following use cases:

• 1-D spectra from Spitzer’s Infrared Spectrograph have multiple spectral orders
  • Spectral orders can overlap in wavelength
  • Plotting a Spitzer spectrum without accounting for orders gives you a mess
• SEDs often include limits on measurements
  • these can be upper or lower limits
  • Plotters need to indicate limits clearly to avoid scientific misunderstanding
  • SDM1.1 has an ad-hoc representation for upper limits (only) which may be usable, but is conceptually incorrect.

The main changes in the v1.2 document are:

• Section 4.1.1: addition of 'order' and 'relorder' attributes
• Section 4.6.3: addition of 'UpperLimit' and 'LowerLimit' to explicitly express these concepts
• Corrected UTypes in VOTable example #1
• Updated diagrams to proper UML with improved consistency with the schema and text.

Latest version of SpectrumDM can be found at:

• https://www.ivoa.net/documents/SpectrumDM/20230907/index.html
  • associated schema: https://www.ivoa.net/xml/Spectrum/Spectrum-1.2.xsd

The GitHub repository for issues and model development can be found at:

• https://github.com/ivoa-std/SpectrumDM

The IVOA Twiki page for the project can be found at:

• https://wiki.ivoa.net/twiki/bin/view/IVOA/Spectrum

Reference Interoperable Implementations

The implementation level for this RFE is not as comprehensive as we would typically look for in a REC.

The DM working group consulted with the TCG prior to the start of this RFC and it was agreed that given

• this is a minor revision based on a specific institution request
• the request is targeted to serve a very specific purpose
• the model is not VO-DML compliant, so the level of effort required to produce additional implementations, serializations, validators is out of proportion to the impact of the RFE.

the level of implementation for this enhancement is acceptable.

Data Providers:

• GAVO: Updated SSA Server to
  • include a PARAM with UTYPE="spec:Spectrum.Data.SpectralAxis.order" into each Spectrum Table.
  • also includes other changes/corrections from a review of the output against the Spectrum model document.
    • example file: http://dc.zah.uni-heidelberg.de/getproduct/flashheros/data_raw/ca98/blue/n0393.mt

Applications:

• IPAC Firefly Archive toolkit:
  • "For some time, IPAC's Firefly archive GUI toolkit has taken advantage of IVOA Spectral Data Model (SDM) v1.1 to provide users with automatic plots of spectra that are the result of a query or have been uploaded to the tool. The plotting capability uses the SDM to identify which data to plot on the x and y axes and to change units. Firefly has recently been updated to recognize the new utypes specified in the proposed Spectral Data Model v1.2, namely:
    
    spec:Spectrum.Data.SpectralAxis.Order
    spec:Spectrum.Data.FluxAxis.Accuracy.LowerLimit
    spec.Spectrum.Data.FluxAxis.Accuracy.UpperLimit
    
    The toolkit uses these new utypes to plot orders (as found in e.g. Spitzer spectra) as separate traces, and to plot upper and lower limits as arrows (as found in e.g. SEDs). These changes are currently in test and will be released in May. Upon release, these features will be available in IRSA, Rubin, and NED interfaces, all of which are built upon the open-source Firefly toolkit.
    In a future release, Firefly will recognize the spec:Spectrum.Data.SpectralAxis.RelOrder utype proposed in SDMv1.2. When Firefly encounters a spectrum with only RelOrder and not Order, it will automatically plot each unique RelOrder as a different trace, analogous to how it treats Order. If a spectrum contains both Order and RelOrder, Firefly will automatically plot traces based on Order but will provide the user a toggle to plot RelOrder."

Implementations Validators

There is no dedicated validator for Spectrum data model instances to update for this enhancement.

Since this is not a VO-DML compliant model, the mechanisms for

• validating the data model itself
• generating and validating example serializations in VOTable, XML, etc.
• generating model based code

are not available.

---

---

Comments from the IVOA Community during RFC/TCG review period: 2023-09-11 - 2023-10-23

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)

Comment by JesusSalgado

This is a preliminary comment: Version 1.0 had a java library implemented by Kelly McCusker (not in IVOA anymore) and Jonathan McDowell that allowed parsing and writing of spectral data compatible with 1.0. It would be great to obtain a version of this library and adapt it for these minor changes.

This library was used by some tools (e.g. VOSpec)

JesusSalgado - 2023-09-22

---

---

Comments from TCG member during the RFC/TCG Review Period: 2023-09-11 - 2023-10-23

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

With review and knowledge that this was a specific update to meet the needs of project feedback, and with the provision in the document identifying the limited change, the TCG chair and V Chair approve and vote positively with the WG/IGs.

Applications Working Group

We appreciate the initiative to evolve the spectrum data model, which needs it.
Compared with other IVOA standards, there is a lot of work to be done in the document to bring it up to date with the advances made by other working groups since the initial version.
Paragraph 3.3 Units should be replaced by VO Units
paragraph 3.4 UCD should be updated
Usage of STC is a reference to STC 1.0

ref CoordSystem should be listed elsewhere to allow evolution of the document or presented as a possible choice to be consistent with the xsd schema
<xs:complexType name="coordFrameType">
<xs:annotation>
<xs:documentation>Simplification of STC version: RefPos is string</xs:documentation>

VOTable serialisation is 1.1 version
DM's initiative to unify data models seems to have a place in the redesign of spectrum data model, as it would be a textbook case.

minor thing
on VOTABLE serialisation example it seem that there is problem on validation for
ucd="sdm:spect.frame"
on <PARAM there is no datatype on 3 of them

Response by (MarkCresitelloDittmar - 2023-11-11)

• Similar to the Semantics group comments, we wanted to keep the scope of this update focused on the requested updates. The items you mention are good candidates for additional updates, and we can add Issues for them in the Spectrum repository. I believe many were included in the Spectrum2.0 effort back in 2016 which was tabled partially from lack of implementation, and partially because of the DM model refactoring effort. The 'plan' for the evolution of this model has been to represent it as a specialization of the Cube model, much like TimeSeries. We're happy to work with anyone interested in exercising that workflow!.
• Re: the invalid ucd. There are several invalid and incorrect ucds in the document, this is issue #7 in the Spectrum repository. It was decided in the context of the recent Cone Search (?) that the documented UCDs should not be consided normative. For this reason we did not perform a sweep to resolve and correct the listed ucds.
• Re: PARAM with no datatype, this could be resolved with this update.
• To address the concerns about the outdated practices and references, we will add two statement to the document
  • To the abstract (and landing page), a statement to the effect of: "This is a minor update to the model to satisfy a specific request. We acknowledge that there are elements to the model which do not follow current IVOA practices and would benefit from modernization. This was intentionally not done during this revision to minimize the impact on existing implementations. They can be addressed in a subsequent update to the model."
  • To the UCD section, a statement to the effect of: "The UCDs specified in this document are non-normative, and should be considered as suggested or example values to convey the intent. Users should take care to select and validate UCDs which are appropriate and valid for their data."

Data Access Layer Working Group

Good to see support of orders as this has been raised by the community.

-- JamesDempsey - 2023-11-07

Data Model Working Group

Grid & Web Services Working Group

Changes are minimal and controlled from the previous version. The only point raised about the reference implementation (there was one that could be modified easily, I think, to cope with the changes but it is quite old so I am not even sure if the code is recoverable) (reference, java library implemented by Kelly McCusker and Jonathan McDowell (maybe Jonathan could help on this)). This library is a full implementation able to read and write SpectrumDM 1.1 compatible files.

Maybe there is another implementation. Could you clarify it?

In any case, as the changes are fully controlled, we approve the update.

JesusSalgado - 2023-11-06

Response by: MarkCresitelloDittmar - 2023-11-10

I agree that this would be a good thing to work toward, and will make an effort to track down the library and see if there is a path toward updating it to V1.2.

Registry Working Group

Semantics Working Group

• In section 3.3 Units, it is stated that the unit formatting standard is WCS/OGIP convention for unit. Is there any reason not to use the VOUnit formalism (see ongoing RFC)? It would be a pity if we can't converge here.

• In section 3.4 UCDs there seems to be a typo at the end of the first paragraph: [...] so you can’t put a literal em.* in a UTYPE field [...]. Do you mean UCD field ?

• In section 5.1 CoordSys Fields, the proposed list of terms should be submitted as a VEP to Semantics, in order to update the RefPosition vocabulary. And then refer to that vocabulary for acceptable values.

• In section 5.1.5 STC, the same remark concerning the RefFrame vocabulary

• On pages 17-19, the table mentions "TimeFrameUCD", SpaceFrameUCD ": I don't see what this refers to.

BaptisteCecconi - 2023-11-09

• Response * The goal for this RFE was to keep the changes as focused on the request as possible. I agree with your statements and I suggest we add these as Issues on the Spectrum project to be addressed in a 'modernizing' RFE. I will correct the typo.

MarkCresitelloDittmar - 2023-11-10

• General comment: I think it is a bad idea to adopt a document which so much outdated.

• In UCD section, it is stated that UCDs should be case insensitive. If you use UCDs, you don't change the definition/usage/syntax of UCDs in tis document. This sentence MUST be removed.

BaptisteCecconi - 2023-11-11

• see bullet in Applications section regarding addtions to the document abstract and UCD section to address the concerns about outdated modeling practices in the model.

MarkCresitelloDittmar - 2023-11-11

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Nothing to add at this time. Encourage continuing efforts to adopt smaller changes as they can be generally agreed on, to help minimize delays involved in working out larger, more controversial topics. - Steve Groom - 2023-11-11

Radio Astronomy Interest Group

Solar System Interest Group

Nothing to add.

-- Anne Raugh - 2023-11-10

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

---

TCG Vote : Vote_start_date - Vote_end_date

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	*
Apps	*
DAL	*
DM	*
GWS	*
Registry	*
Semantics	*			Semantics WG comments should be addressed in next version
DCP
Edu
KDIG	*
Ops	*
Radio
SSIG	*
Theory
TD
<nop>StdProc

---