getCapabilities in SSAP

[Doug Tody]

Hi Igor -

> On Fri, 23 Feb 2007, Igor Chilingarian wrote:
>
> Dear Doug and DAL group,
>
> We are working on the SSA access to the spectra of Be stars (project
> by Bertrand de Batz and Coralie Neiner at the Observatory of Paris).
> We would like to implement the service, fully-compliant to the latest
> version of the SSAP document. Several questions have raised during the
> process of implementation.

It is good to hear that you are working on such an SSAP service.
There are still some remaining open issues with the SSAP specification,
which you will indeed run into if you do a full implementation, and
resolving these is part of the point of these initial implementations.


> 1) REQUEST=getCapabilities. In the version of the document, which we
> use (v0.97) it is written that "getCapabilities" should be similar to
> VOResource.  And no more details. We have tried to check the examples
> on the SSAP services you had announced a couple of weeks ago, and we got
> "HTTP-404 error" for the .xml file corresponding to this query. Could you
> please provide an example of such a response? We would like to implement
> some service-specific parameters, which have major scientific interest,
> but we do not know how to describe them in the getCapabilities.

While getCapabilities has been prototyped in the DALServer reference
implementation, we do not yet have a specification for the information
which is returned, only a sketch which Ray and I prepared (based on the
service metadata used in the Registry).  It is best to just leave this out
of your service for now, and add it later when we have a specification.
If you can't wait a month or so you could prototype something which
implements the getCapabilities operation but just returns the parameter
information in some temporary form.  In fact, it would be useful to
know what information is needed for your use-case.

(Thanks for pointing out the HTTP-404 error, which is "file not found".
This is just because when the service was deployed to the server you
are accessing, the referenced data files were not configured.  Easy to
fix but probably not important since the capabilities data you would
get back is just a sketch at this point in any case).


> 2) Query Response metadata. There are several parameters specified
> as MANDATORY, such as Char.SpatialAxis.Coverage.Location.Value,
> Char.SpatialAxis.Coverage.Bounds.Extent, and
> Char.TimeAxis.Coverage.Location.Value, which are not applicable for some
> sorts of data, such as synthetic spectra, or even for observations of
> point sources (e.g. stars), where "aperture angular diameter" does not
> bear much useful information and is quite often unknown. The question is:
> are we allowed to put "N/A" as the values for mandatory metadata fields?

How to deal with a case such as this for synthetic spectra, is a good
question which is still an open issue.  We will either have to come
up with a convention such as you suggest (N/A), or possibly specify
separately what is required for different classes of data.  My preference
would probably be something like N/A, since it is more explicit.


> 3) Multi-language support for the descriptions of parameters. For a
> particular case of Be stars database we have all the descriptions made in
> several languages, and it seems to be very useful to be able to display
> them in the client application correspondingly to the language setting
> there (e.g. Aladin with multi-language support, announced yesterday
> by CDS). What do you think about adding one more query parameter
> (RECOMMENDED or OPTIONAL), for example, LANG accepting the I18N values
> such as "en","fr","sp","it", etc. with the default setting to English?

I suggest that you provide this feature using a service-specific optional
parameter, with English being returned if the parameter is not specified.
So long as the parameter is optional I don't see any reason why we could
not consider including support for this in the standard, but this is a
general issue which needs to be considered more carefully.  I like your
suggestion of using LANG and I18N for the parameter.

	- Doug