|
META TOPICPARENT |
name="IvoaDAL" |
SSA-1.1 and Spectrum-1.1 Proposed Recommendation: Request for Comments
This document serves as the RFC center for the Proposed Recommendation entitled "Simple Spectral Access, Version 1.1".
At the same time the Spectrum Data model document has been updated
in order to correct minor inconsitencies in notation with respect to the SSA protocol standard document ( Utypes mispell, UCD, Fits keywords completed.)
The latest version of SSA after TCG review is:
The input for TCG review is:
Latest version of Spectrum Data Model can be found at:
Additional discussion about any of the comments or responses can be conducted on the Data Access Layer mailing list, dal@ivoa.net and on the Data Model mailing list, dm@ivoa.net However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Reference Interoperable Implementations
Implementations Validators
RFC Review Period: 20 Apr 2011 - 17 May 2011
TCG Review Period: 01 June 2011 - 28 June 2011
Comments from the IVOA Community during RFC period: 20 Apr 2011 - 17 May 2011
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 from TCG member during the TCG Review Period: 01 June 2011 - 28 June 2011
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)
Comments on SpectrumDM 1.1 - ChristopheArviset 2011-06-07
All my comments are mainly editorial or related to document formatting. I'll be happy to approve SpectrumDM 1.1 once they've been addressed.
[Section 1 Introduction and Motivation]
This section should already clearly indicate the reason for SpectrumDM 1.1, which is mainly for corrections coming from feedback implementation and does not represent any fundamental changes wrt the existing Recommended SpectrumDM 1.03 released on 29 October 2007. It should also indicate its "pairing" with SSAP 1.1.
[Section 1.1 Change log]
This section should also clearly indicate the Recommended SpectrumDM 1.03 released on 29 October 2007
[Section 1.2 IVOA Architecture]
Last paragraph should either be rewritten to better reflect the relationship between SpectrumDM 1.03, SpectrumDM 1.1 and the upcoming SpectrumDM 1.2 or should be removed (one could argue why we need a reference to SpectrumDM 1.2 in the SpectrumDM 1.1 document?).
[References]
The references section should be udpated with latest version of standards and should contain all IVOA standards introduced in Section 1.2
Various formatting issues:
- Blank pages that should probably be removed: 18, 22, 66, 81
- Landscape pages that are cut on the border: 19, 20, 21, 23, 24, 25, 26
- Pages cut on the border due to too long text: 40, 41, 55, 57
Comments on SSAP 1.1 - ChristopheArviset 2011-06-07
All my comments are mainly editorial. I'll be happy to approve SSAP 1.1 once they've been addressed.
[Page 2] Reference to VOSI should be updated as it has now become a REC
[Section 1] Introduction
As agreed, together with the IVOA Architecture Diagram, some text should explain the relationship between SSAP and the other IVOA Standards present on that diagram.
The SSAP text used for the IVOA Architecture document could probably be inserted as is:
Simple Spectra Access Protocol (SSAP) defines a uniform interface to remotely discover and access one dimensional spectrum coming from data and metadata collections. SSAP is based on the Spectrum Data Model (itself making reference to the CharDM) that is capable of describing most tabular spectrophotometric data, including time series and spectral energy distributions (SEDs) as well as 1-D spectra. SSAP can be used from VO applications to access the associated spectrum resources.
As with most of the IVOA Data Access Protocols, SSAP makes use of VOTable for metadata exchange, STC, UCD, Utypes and Units for metadata description.
An SSAP service is to be registered into the VO Registry, using the associated registry standards (in particular Resource Metadata, VOResource and SimpleDALRegExt specifically for Data Access Protocols such as SSAP). Once registered, an SSAP service will get a unique IVOA Resource Identifier. Furthermore, an SSAP service should be registered with its supported interfaces through the VOSI standard.
Applications Working Group (Tom Mcglynn, Mark Taylor)
Approved - TomMcGlynn 2011-06-12
(but fix or remove reference in SSA Section 8.10.2 which contains the text "see also section 8.10.2" -- MarkTaylor - 04 Jul 2011)
Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)
Approved - PatrickDowler 2011-06-01
Data Model Working Group (Jesus Salgado, Omar Laurino)
Approved - JesusSalgado 2011-07-01
Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )
Approved - AndreasWicenec
Registry Working Group (Gretchen Greene, Pierre Le Sidaner)
Approved with comments - GretchenGreene 2011-09-19
1.3.2 Parameters
Suggest version should be defined via VOSI not in the protocol definition (twice describe and moreover it's not mandatory)
2.1 Dataset and Data Collection
possbily add link to the VODataService document where all voservice concepts defined
same comment on 4.1.2.14 COLLECTION
2.4 Virtual data
do not understand this sentence, it is a capability of cutout. This should be decribe in vosi or regex
It's more important in the case of cutout or slice cut of spectral cube.
2.5.1 Data Source
artificial : Artificial or simulated data. This is similar to theory data but need not be based
on a physical model, and is often used for testing purposes.
do not understand the interest of this item : the main purpose is the input parameter that make a
difference between simulated and observational data. Why don't we simply keep simulated or theoretical data
2.7 Services, Interfaces, and Protocols
is the meaning of this paragraph that it's a HTTP protocol ?
2.8 Dataset Identifiers
Why reinventing the wheel ?
There is an IVOA docume "IVOA Identifiers" If it need some evolution. Then it should be in this document not in SSA.
2.9 Provenance
No mention of DM provenance or VOResource
2.10 Data Association
Should be described in the registry, same for all protocols
3.2 Methods & Protocols
Does anyone want to implement SSAP in SOAP ?
May be say also REST ?
the 3.3.1 GetCapabilities and 3.3.3 GetAvailability can mention that this is under definition in the VOSI document
and make a ref at the end to the proposed recommendation version at least
ref http://www.ivoa.net/Documents/VOSI/20101206/PR-VOSI-1.0-20101206.pdf
instead of http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupport
InterfacesMandatory-0.26 . pd f
at the end of the document
3.3.2 StageData
you mention " is not planned for SSA V1.0", may be it's 1.1
4.1.1.5 FORMAT
"If FORMAT is omitted, FORMAT=ALL should be assumed" don't you think
it verbosity will increase really the size of the output. What not default to votable ?
8.10.2 Overflow
Previous point made, ? understanding the new changes
in case of overflow no client yet redo the query with maxrec
don't you think the service should answer Overflow an produce a query response
containing the maximum number of records. Then the client could at once give to the user the first N response and inform that there is an overflow.
is it still compliant with
4.1.2.16 MAXREC
" A service should typically have a
fairly small default MAXREC, provided to improve the query response time, and a large
upper limit on MAXREC, provided to enable large queries."
that mean that the service will all the time answer an overflow and will not provide data ?
-- 2011-10-18 PatrickDowler
Response:
* reference to VOSI updated to point to latest version (slightly hard since the actial VOSI-1.0 REC is not on the repository yet)
* other changes were considered beyond the scope if this update, but future DAL standards will try to be more clear where this is possible.
Semantics Working Group (Sebastien Derriere, Norman Gray)
Spectral DM 1.1 Approved with comments. SD 2011.10.05
Some minor typographic corrections, but also many tedious small fixes to UCDs and units that should improve consistency with other standards.
p15 : Unified Content Descriptors (not Uniform)
Table 1 2nd line of table p19 has shift in columns (UCD1+ column should be empty)
same on p21 for Char.FluxAxis.Calibration
I would have written p19 ucd="arith.zp;time" for CoordSys.TimeFrame.Zero
p23 Char.SpatialAxis.SamplingPrecision.SampleExtent has rather
ucd="phys.angSize;instr.pixel"
p23 the 3 ucds for filling factors should be stat.filling (not
stat.fill). The last one has an extra "time" should be stat.filling;time
p24 the mandatory Data.FluxAxis.value and Data.SpectralAxis.value utypes
could have a ucd "see sec.4.1 (or table 3)" and "see sec. 4.2 (or table 2)"
p26 the BinLow/High utypes can have ucds time.start;time.interval
and time.end;time.interval
In all table 1, utypes ending in .UCD or .ucd can have the UCD
column set to "meta.ucd". The utypes in .unit can have UCD set
to "meta.unit".
In Table 2 on p27, Angstrom (twice) should be written in lower case "angstrom",
following OGIP use, and as in Table 3.
(same remark in section 7.2, multiple occurrences of Angstrom)
p32 "arith.ratio" is a UCD secondary word, so to be used as suffix not
prefix: should be prefixed -> should be suffixed
p34 in section 5.1.3, last paragraph: "the the" -> the
p41: "of an dataset" -> of a dataset
Last paragraph: pectral -> spectral
The JHU SDSS VOTable example uses bad units in some cases :
"A" is the symbol for Ampere, but means Angstrom : use "angstrom" instead
(11 occurrences, as "A" or "10**(-17) erg/cm**2/s/A").
"yr" must be used instead of "y" for year
Many UCDs used in the XML and VOTable examples are not valid or
inconsistent with the ones given in table 1. Here is a list of suggested
changes to improve the examples :
In 7.2
Extent ucd="pos.region.diameter" -> ucd="pos.angDistance;instr.fov"
BinLow ucd="stat.min;em.wavelength" -> ucd="em.wl;stat.min"
BinHigh ucd="stat.max;em.wavelength" -> ucd="em.wl;stat.max"
FluxAxis ucd="phot.flux.density;em.wavelength" -> ucd="phot.flux.density;em.wl"
SpectralFrame ucd="em.wavelength" -> ucd="em.wl"
GenericCoordFrame ucd="phot.fludens;em.wl" -> ucd="phot.flux.density;em.wl"
Publisher ucd="meta.organization;meta.curation" -> ucd="meta.curation"
PublisherID ucd="meta.curation.pubid" -> ucd="meta.ref.url;meta.curation"
Name ucd="meta.human;meta.curation" -> ucd="meta.bib.author;meta.curation"
DataID / Creator ucd="meta.curation.creator" -> ucd="meta.curation"
Date ucd="time;soft.dataset;meta.curation" -> ucd="time.epoch;meta.dataset"
Version ucd="soft.dataset.version;meta.curation" -> ucd="meta.version;meta.dataset"
Instrument ucd="inst.id" -> ucd="meta.id;instr"
Logo ucd="meta.curation.logo" -> ucd="meta.ref.url"
In 8.2
PARAM name="System" utype="spec:CoordSys.SpaceFrame.Name" ucd="frame.pos.system"
-> ucd="pos.frame"
PARAM name="TimeFrame" utype="spec:CoordSys.TimeFrame.Name" ucd="frame.time.scale"
-> ucd="sdm:time.frame"
PARAM name="SpectralFrame" utype="spec:CoordSys.SpectralFrame.RefPos" ucd="frame.em.system" -> ucd="sdm:spect.frame"
PARAM name="SkyExtent" utype="Char.SpatialAxis.Coverage.Extent" ucd="pos.region.diameter"
-> ucd="pos.angDistance;instr.fov"
PARAM name="TimeObs" utype="Char.TimeAxis.Coverage.Location.Value" ucd="time.obs"
-> ucd="time.epoch;obs"
PARAM name="TimeStart" utype="Char.TimeAxis.Coverage.Bounds.Start" ucd="time"
-> ucd="time.start"
PARAM name="TimeStop" utype="Char.TimeAxis.Coverage.Bounds.Stop" ucd="time"
-> ucd="time.end"
(time.start and time.end can be used in both Coverage.Bounds and Coverage.Support)
PARAM name="Publisher" utype="spec:Curation.Publisher" ucd="meta.organization;meta.curation" -> ucd="meta.curation"
PARAM name="PubID" utype="spec:Curation.PublisherID" ucd="meta.curation.pubid"
-> ucd="meta.ref.url;meta.curation"
PARAM name="Contact" utype="spec:Curation.Contact.Name" ucd="meta.human;meta.curation"
-> ucd="meta.bib.author;meta.curation"
PARAM name="Creator" utype="spec:Segment.DataID.Creator" ucd="meta.curation.creator"
-> ucd="meta.curation"
PARAM name="DataDate" utype="spec:DataID.Date" ucd="time;soft.dataset;meta.curation"
-> ucd="time.epoch;meta.dataset"
PARAM name="Version" utype="spec:DataID.Version" ucd="soft.dataset.version;meta.curation"
-> ucd="meta.version;meta.dataset"
PARAM name="Instrument" utype="spec:DataID.Instrument" ucd="inst.id" datatype="char"
-> ucd="meta.id;instr"
PARAM name="Filter" utype="spec:DataID.Collection" ucd="inst.filter.id"
-> ucd="instr.bandpass"
PARAM name="Logo" utype="spec:DataID.Logo" ucd="meta.curation.logo"
-> ucd="meta.ref.url"
PARAM name="Resolution" utype="spec:Data.SpectralAxis.Resolution"
ucd="spect.resolution;em.wave" -> ucd="spect.resolution;em.wl"
FIELD name="Coord" ID="Coord" utype="spec:Data.SpectralAxis.Value" ucd="em.wavelength" -> ucd="em.wl"
FIELD name="BinLow" ID="BinLow" utype="spec:Data.SpectralAxis.BinLow"
ucd="stat.min;em.wavelength" -> ucd="em.wl;stat.min"
FIELD name="BinHigh" ID="BinHigh" utype="spec:Data.SpectralAxis.BinHigh"
ucd="stat.max;em.wavelength" -> ucd="em.wl;stat.max"
FIELD name="Flux" ID="Flux1" utype="spec:Data.FluxAxis.value" ucd="phot.flux.density;em.wavelength" -> ucd="phot.flux.density;em.wl"
In JHU SDSS output :
FIELD ID="DataSpectralBinLow" name="DataSpectralBinLow" datatype="double" ucd="em.wl" -> ucd="em.wl;stat.min"
FIELD ID="DataSpectralBinHigh" name="DataSpectralBinHigh" datatype="double" ucd="em.wl" -> ucd="em.wl;stat.max"
FIELD ID="DataFluxValue" name="DataFluxValue" datatype="double" ucd="phot.fluDens;em.wl" -> ucd="phot.flux.density;em.wl"
FIELD ID="DataFluxStatErrLow" name="DataFluxStatErrLow" datatype="double" ucd="phot.fluDens;em.wl" -> ucd="phot.flux.density;em.wl"
FIELD ID="DataFluxStatErrHigh" name="DataFluxStatErrHigh" datatype="double" ucd="phot.fluDens;em.wl" -> ucd="phot.flux.density;em.wl"
PARAM ID="TimeFrameName" datatype="char" name="TimeFrameName" ucd="time.scale" -> ucd="sdm:time.frame"
PARAM ID="SpectralLocation" datatype="double" name="SpectralLocation" ucd="em.wl;bandpass" -> ucd="instr.bandpass"
PARAM ID="SpectralStart" datatype="double" name="SpectralStart" ucd="em;stat.min" -> ucd="em.wl;stat.min"
PARAM ID="SpectralStop" datatype="double" name="SpectralStop" ucd="em;stat.max" -> ucd="em.wl;stat.max"
PARAM ID="SpectralBinSize" datatype="double" name="SpectralBinSize" ucd="em;spec.binSize" -> ucd="spect.binSize"
PARAM ID="TimeExtent" datatype="double" name="TimeExtent" ucd="time.expo" -> ucd="time.duration;obs.exposure"
PARAM ID="TimeStart" datatype="double" name="TimeStart" ucd="time.expo.start" -> ucd="time.start;obs.exposure"
PARAM ID="TimeStop" datatype="double" name="TimeStop" ucd="time.expo.end" -> ucd="time.end;obs.exposure"
PARAM ID="FluxAxisUcd" datatype="char" name="FluxAxisUcd" utype="spec:Spectrum.Char.FluxAxis.Ucd" value="phot.fluDens;em.wl" -> ucd="phot.flux.density;em.wl"
PARAM ID="DataFluxUcd" datatype="char" name="DataFluxUcd" utype="spec:Spectrum.Data.FluxAxis.Ucd" value="phot.fluDens;em.wl" -> ucd="phot.flux.density;em.wl"
Note that time.frame and spect.frame do not exist in the current list
but have been requested and will likely be included in the next list.
Meanwhile, I added a sdm: namespace above, as is allowed by the UCD standard.
SSAP 1.1 Approved with comments. SD 2011.10.07
p23, the value given as unit for SPECRP is not really the unit,
but an explanation of how the quantity is obtained (this is
clear from 4.1.2.2, so could be removed from the table)
p37 section 4.2.5.9, replace "phot.fluDens;em.wl" by "phot.flux.density;em.wl"
p52, in the VOTable snippet, the third attribute of the first param should be unit, not units.
p54, according to SpectralDM table 1 p19
for param Publisher, ucd="meta.curation"
for PubID, ucd="meta.ref.url;meta.curation"
for FIELD vturb, ucd="phys.veloc.microTurb" (also on p.56)
p55, ucd="VOX:Spectrum_units" can be replaced by ucd="meta.unit" (also on p.56)
p56, utype for FIELD FluxAxis is misspelled : change FluxAsix -> FluxAxis
p62, PARAM ID="DisplayRef" should have ucd="meta.ref.url", and there is
an extra ssa: in the utype
p63 ucd="time.expo" -> ucd="time.duration;obs.exposure"
ucd="time.expo.start" -> ucd="time.start;obs.exposure"
ucd="time.expo.end" -> ucd="time.end;obs.exposure"
p66 stat.fill;em -> stat.filling;em
p67 time.stop;obs.exposure -> time.end;obs.exposure
time;stat.fill;time -> stat.filling;time
The unit for logg, if expressed as per the OGIP convention, should be
unit="log(cm/s**2)" (p54, 56)
p59 for DatasetSize" unit="bytes" -> unit="byte"
There is a missing opening bracket for one PARAM
p63 for SpaceFrameEquinox unit="y" -> unit="yr" ( unit should really be "yr" - 18 Oct 2011)
And minor remark, the & in the two TD of appendix A p57, and in the
webtest URL p59 will make
an invalid XML without encoding...
-- 16 Oct 2011 JesusSalgado
After discussion at TCG level these are the conclusions:
- Impact on implementations has been considered. UCDs change do not look to break client applications. Servers will be published with a different versioning metadata. The main impact expected would be in validators
- UCDs will be updated into the document plus all minor editorial comments suggested on the TCG review. This will done as soon as possible.
- Major comments will be incorporated in SpectrumDM 1.2
-- 2011-10-18 PatrickDowler
The SSA-1.1 document has been updated to fix typos, units, ucds, and XML correctness issues.
VOEvent Working Group (Matthew Graham, Roy Williams)
I approve this document.
-- MatthewGraham - 13 Oct 2011
Data Curation & Preservation Interest Group (Alberto Accomazzi)
Knowledge Discovery in Databases Interest Group (Giuseppe Longo)
Theory Interest Group (Herve Wozniak, Franck Le Petit)
Approved - HerveWozniak 2011-07-04
Standards and Processes Committee (Francoise Genova)
<--
-->
|