SSA working draft

[Inga Kamp]

Hi Doug,

I read through the latest SSA draft (version 0.97, Oct.12) and list my
comments below.

Abstract:

typo - family

I think it's not necessary to state how a dataset was created in the SSA
paper. The SSA should not get into the details about how a datacenter may
choose to serve the datasets. It's up to the datacenters to do that and I
guess there will be as many different ways as there are datacenters.

Same holds for 1.1 where the paper explicitly says that dynamically
created datasets are the way a service will respond. I don't think this is
true. It should be left to the discretion of the service provider to
decide if he wants to deliver dynamically created or static or some
mixture of files.

2.1, 3.3.2.5 are other examples where this comes up.


1.4:

What is the difference between MUST and REQUIRED. It is not explained
anywhere.


1.4.1:

Why do you want to single one type of response format out? Why not have
them all equal?

typo - encoded

Isn't there a gap between query compliant and fully compliant? What is a
service did not implemnt all the "should" elements, but still answers with
SSA-compliant data?


2.3:

How can you have metadata on virtual data? How should we anticipate all
possible ways a user may ask for spectral cutouts, extraction etc. to be
prepared to answer?


2.4.2:

spectral extraction - you may want to mention grism here as well.


3.3.2.3:

I thought that BAND is always a string. How can you have then "If a
bandpass is spcedified as a string it is..."


3.3:

REQ is the abbreviation for recommended and then in the table, you use
REC. This is inconsistent.

Apertures need not be circular, so you may want to phrase the respective
sentence different.


3.3.3.6:

What does a photometric redshift mean in the context of spectra? What is
it you want to allow the user to do? You confuse them by talking about
blueshifts and local neighborhood if what you mean is a galactic
photometric redshift.


3.3.6:

"Hence when data model attributes are indicated as mandatory of
recommended in this document, this overrides any similar requirements
specified in the Spectrum data model document."

I think these are two different things. The spectrum data model tells how
to return the data. The SSA talks about how to contruct the answer to a
request. I think it will happen that the data is returned in whatever
units are appropriate for wavelength and the VOTable answer to the service
is in meters. They are independent.

Do you think exposure time should be given in days? I would think that
second is the fundamental unit to use. And if you think this makes
observing dates look bad, why not allow both, days and seconds.


3.3.11:

I think that we have to solve the problem with spectral resolution. Some
datasets will have the spectral resolution vay substantially over the
spectrum. Thus a mean value or value at mean wavelength might be useless
if the user is interested in the blue or the red part of the spectrum.
Wouldn't it be easier to have two options for resolution reflecting the
two fundamentally different ways instruments operate (either constant
delta lambda or constant lambda/delta lambda)?

The service can then still choose how to answer by using a conversion
(reference wavelength, etc.), but at least it's clear that the metadata is
as accurate as we can get it.


Best wishes,
Inga