Data service types

[Doug Tody]

On Fri, 17 Oct 2003, martin hill wrote:

> One thing that didn't seem very clear from the meetings was what DAL was all 
> about.  We talked about the technicalities of two particular services: Images 
> and Spectra, but the rather larger set including stellar catalogues and other 
> databases of information wasn't considered (as if we didn't have enough to 
> talk about!).

The scope of DAL was a major topic of the May WG meeting in Cambridge.
The current thinking on the range of DAL services is summarized on the
DAL Wiki page and in the documents

    http://ivoa.net/internal/IVOA/IvoaDAL/IVOA-DAL-Jul03.pdf
    http://ivoa.net/internal/IVOA/IvoaDAL/DAL-Cambridge-Report.pdf

> Are we assuming just now that we are working on three services: images (SIAP 
> as cutout and 'as-stored'), spectra (SSA in early stages) and stellar 
> catalogues (as SkyNode2, being defined)?  Asan Astrogrid datacenter developer 
> I need to know who I should be talking to about making sure things are 
> compatible! Will & I have already been talking, but if the group feels that 
> SkyNode2 will be the *defining* interface for ADQL-querying VO datacenters, 
> and NVO Cone Searches for http/get VO datacenters, then we shall happily work 
> towards that (and provide input to that!).  If not we need to know!  We have 
> now 3 astrogrid datacenters running in various versions, and by Christmas 
> expect to have around 6-10 homogenous, so we need to know...! 

The plan for the next six months at least is OpenSkyNode for query-based
catalog access, retaining cone search for simple HTTP GET queries.
There will be a new version of SIA once the infrastructure (dataset
IDs, DM, UCD, VOTable, etc.) develops enough to make this wortwhile.
SSA of course is actively in development.  We need to experiment with
web services versions of all the DAL services.  This is likely to keep
us busy through next summer.

(Note SIAP can do generated image mosaics or arbitrary sky projections
as well as simple cutouts or static imagefiles).

> Also a suggestion that I think came up somewhere in the meeting, that we make
> the formats of the http/get urls similar.  This (might?) save having to use
> template urls (if that's what was meant by them).  For example, at the moment
> the SIAP uses a comma to separate RA/DEC, whereas NVO cone search specifies
> them explicitly. 

These are two different things.  SIA came after cone search, and the thinking
at the time was that a position "object" encoded as the POS string made sense
since this grouped the elements of the position, and provided a means for
generalizing POS in the future by adding more syntax.

The issue of templating URLs refers to the image access reference URL in SIA
(which is very different from the query URL).  The question here is whether
we want to parameterize the image access reference, rather than enumerate
every possible combination of parameters in the query response table.
An alternative might be to add a getImage method to the interface.

On the general issue of making the service interfaces more similar -
at some point we will want to update all these services to use the
latest technology.  At that time we can make them more uniform as well.
We don't want to be changing things too frequently, so this is probably
best done as an upgrade to all the services, once things have evolved
enough to make it worthwhile.

> Finally (really) I would also like to find out here what services people want
> to publish to the VO and some idea of the structure of that data, so we can
> build an overall picture of what the VO is likely to be serving.

As I say the current thinking on the range of services (data types) is
summarized in the documents above.  The structure of the data to be returned
is still being worked out.  For science-formatted data we are probably
looking mainly at some combination of FITS (at least for "image"-like data),
plus a more general XML encoding (e.g., in VOTable) of the VO data models
currently under development.  The idea is to define component data models
to characterize the attributes of a dataset, and model complex datasets
by aggregating these in some sort of XML container.  Where FITS is used,
the query response table can be used to return standard metadata (using
the component data models) describing the FITS-encoded object.

	- Doug