Spectral v2.0 Proposed Recommendation: Request for Comments

This page records the public discussion for round 2 of the Spectral2.0 Data Model Proposed Recommendation. The initial pass went through RFC to TCG where it received significant input. These were addressed, and it was decided that the document should pass through RFC again.

Initial RFC/TCG review comments can be found here:

Latest version of Spectral2.0 can be found at: NOTE: No new capabilities have been added to the document over what was presented at the IVOA interop in Sesto. The intent is that this document fulfills the requirements of its commissioning. A new project will be initiated to expand the capabilities for unsupported types (eg: Echelle spectra), and to cast the model in terms of the DatasetMetadata/CubeDM models now in progress.

Reference Interoperable Implementations

1) Speclib Java library: can be found here.

Java library for interpreting Spectral-2.0 model serializations.

  • loads model definition from ancillary file, with design capable of supporting alternate storage mechanisms (DB, vo-dml, etc)
  • interprets data file according to the model definition.
  • implements interfaces for model components, supports all primitive datatypes, Quantity, Lists which are used in the Spectral model Note: This library is a work in progress, and is being updated to include:
  • support for multiple data models ( Spectrum-1.1; Dataset; NDCube; etc )
  • enhanced validation capabilities
2) Serializations utilizing Spectral 2.0 model specifications
  • GAVO: GAVO DC Software Distribution DaCHS
  • SVO: TSAP - Theorical Spectral Model Service (Not available?)
3) Interoperability demo

A demonstration utility (speclist) was generated and demonstrated at the Sesto interop. This utility queries the GAVO database for spectral data and generates a simple plot with metadata browser. Users can explore the metadata space, and zoom on plot details.

Implementations Validators

At present, the speclib library is not ready to support 'validation', but is fairly strict in the interpretation of serializations in terms of the data model. Issues and non-compliant elements will produce exceptions or be interpreted as custom elements.

RFC Review Period: 21 Sep 2015 - 16 Oct 2015



Comments from the IVOA Community during RFC period: 21 Sep 2015 - 16 Oct 2015

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

Comments by Markus Demleitner

As the author of one reference implementation cited (DaCHS) I must make the reservation that I am only implementing what was already part of SDM 1; I am essentially mapping SSA to SDM2, which works. I am, however, not implementing photometry points, transformations, or any other advanced feature.

Minor details aside, I am still unsure whether we should bother passing this recommendation when it is clear that major use cases (time series, compound spectra) are not covered. I would not mind so much if we expected a smooth evolution (version 2.1) towards these new use cases, but I understand that fairly fundamental changes (alignment with the future image DM, introduction of a principled serialisation) will be necessary to get there, so implementors of this will have no advantage when implementing what will presumably have to be SDM 3.

In the remainder I list some minor issues, taken from last TCG review where I think they still stand. Note that I don't think any of these are actually showstoppers, and I'll accept "see last review answers" for each of them; I hope a quick overview over these potential issues here, might be useful for other reviewers, though.

  • Given the number of cross references in the document, it would really help if cross-references could be hyperlinks.
  • I still believe we should remove TimeSI, FluxSI, and SpectralSI -- applications cannot rely on them anyway, and we've had VOUnits for, what, two years by now (including two implementations serving C, Java, and python), so applications can be expected to migrate there.
  • I still believe modelling the CoordSys both in characterisation and toplevel is asking for trouble. There may be datasets out there that require this kind of modelling, but if the model is really out to describe those in that level of detail, there needs to be a better explanation, and guidance what to do in the typical (simple) case.
  • I'd like one of ResolPower.refVal and Resolution to go
  • I still don't quite get why 4.4 has empty subsections for each of the three following sections (but then I didn't really try hard). Why not pull 4.5 through 4.7 into subsections of 4.4?
  • Since case-insensitivity is a pain, I'd still like to strike the case-insensitivity of dopplerDefinition strings.
  • I still don't believe TimeFrame.zero has a Benefit/Cost ratio even approaching 1. From below.

-- MarkusDemleitner - 2015-09-30



Edit | Attach | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2015-09-30 - MarkusDemleitner
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback