SSA working draft

[Inga Kamp]

Hi Doug,

thanks for your fast reply. I would just like to follow up on a few things
below.

On Mon, 20 Nov 2006, Doug Tody wrote:

> Hi Inga -
>
> Thanks for the timely comments.
>
> > 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.
>
> The CreationType refers to what the service does to create the data
> returned to the client, defined relative to the DataSource.  This is
> necessary to describe virtual data, and is a function of the service,
> not what the data center does to produce a data product (that is the
> more general data provenance problem and would be described elsewhere).
>
> > 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.
>
> If the service generates cutouts, filters the data, does spectral
> extraction, etc., this can *only* be done at access time, because
> these are intrinsically on-demand operations driven by parameters
> supplied by the client at access time.

I would filtering on the database level not describe as a dynamic creation
of the dataset. At least it confuses people the way it's phrased now.

>
> If you are referring to pre-generating SSA compliant versions
> of archival spectra, e.g., for Echelle data, then you probably
> have DataSource=pointed and CreationType=archival.  As you say,
> in principle we don't know in this case if the data product was
> pre-generated and cached.
>
>
>
> > Why do you want to single one type of response format out? Why not have
> > them all equal?
>
> Not sure what you are referring to here; 1.4.1 describes the levels of
> compliance of a service, not response formats.

This was referring to "if you provide only one format, then VOTable is the
preferred".

>
> > 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?
>
> This is what on-demand data generation and virtual data are all about.
> The service describes the metadata of the virtual data product it would
> generate.
>
> There are an infinite number of possible virtual data products.
> You don't have to describe them all, rather, given what the client
> requested, the limitations of your service, and the characteristics
> of the data, you describe what the service would generate to best
> match what the client requested.
>
> A simple example is if the client requests a certain bandpass range
> and you have a cutout service, the virtual data product would be a
> spectrum covering only the given wavelength region (or however close
> the service can get given a range of other details).
>
> If the query is detailed enough, the query response may refer to a
> single data product.  Hence, the query mechanism may be used not only
> for data discovery, but to negotiate with the service on the details
> of the data product to be generated.
>

How do you know the SNR ratio a priori for all possible spectral cutouts?

> > 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..."
>
> BAND is either a numerical bandpass (wavelength in vacuum in meters)
> or a bandpass name (unspecified; prior discovery is needed to determine
> the possible values).

Yes, but the type is always string and never real number. It's confusing.

> > Apertures need not be circular, so you may want to phrase the respective
> > sentence different.
>
> Only circular apertures are currently supported for on-demand spectral
> extraction and this should be adequate for point-source or compact
> objects (even for Grism data).  We could generalize this if needed,
> but it complicates the interface.
>

How do you avoid confusion when people actually want to search for a
particular observing aperture? Wouldn't it be better to make this clear in
the name like EXTRACT_APER?

> Thanks again Inga - these are the first careful comments we have gotten
> back on this!
>
>  	- Doug
>

Cheers,
Inga