[SIAv2] capabilities

[Douglas Tody]

On Tue, 5 Nov 2013, Patrick Dowler wrote:

> I have been working on editing the SIAv2 draft, mainly splitting it up into 
> WD-SIA-2.0 which contains the query and metadata capabilities and the 
> WD-AccessData-1.0 which contains sync and async data access capabilities (the 
> latter two could be thought of as getData and stageData respectively). In 
> making these capablities/resource consistent with DALI, I ran into a few 
> small-ish issues that need some input. This is to start that open 
> discussion...

We agreed to add a separate AccessData capability (as a separate service
I think), however it is not clear if this means that there is no longer
any accessData capability integrated into SIAV2.  If that is your
intention, then it can only work if this revised AccessData is image
specific and based upon the ImageDM - otherwise we have no place to put
the advanced image access capabilities required for large image cubes:
slice/dice, function computation, data format transformation, etc.  If
then AccessData is image-specific it is not clear where we put the
analogous functionality required later for e.g., spectra or time series
data.

StageData (async image generation) is needed to support both virtual
images described in a queryData response, and accessData operations
directly specified by the client.  If stageData is only available as
part of AccessData it is not clear how information from an acref or
pubDiD generated by queryData is communicated.  But that is true for
accessData used to synchronously realize a virtual image specified by
queryData as well.  For this to work there must be some back-channel to
communicate the information required to generate the virtual data
product.  In general this will be implementation-specific, as the
details will depend upon the actual software used for computing on the
back-end.

> 1. I defined the {query} capability as a DAI-sync resource that accepts a 
> certain set of params (REQUEST, RESPONSEFORMAT, MAXREC, plus the actual query 
> params). Does anyone feel that we also need a DALI-async query resource for 
> these simple parameter-based queries? (see *)

Sync is sufficient for this.

> 2. The {metadata} capability returns the complete metadata (as defined by 
> ImageDM) for a single observation discovered via {query} and could also be 
> used with a TAP/ObsCore query response. I have assumed this resource is also 
> a DALI-sync resource and that async is not needed here.

Sync is all that is required for metadata retrieval.

I assume by complete metadata you mean the Data element metadata for all
subarrays for a single observation; the dataset metadata is already
returned in the queryData response (a pubDID value can be specified to
get metadata for a single image dataset).  An option to retrieve both
dataset and Data element metadata in a single response is also possible;
probably that would be a VOTable with two separate table elements.

 	- Doug


> 3. As written, it would be allowed for these two capabilities to be the same 
> resource (different values of REQUEST) or two different resources (each 
> supporting their specific value of REQUEST). That is more flexible than 
> previous SIAv2 drafts, in which only the REQUEST value differed.
>
> Comments?
>
> * One motivation for async query might be that if you also want to redirect 
> the response to some other destination (eg. write response to some vospace 
> location) then that naturally works much better in an async job.
>
> -- 
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9A 2L9
>
> 250-363-0044 (office) 250-363-0045 (fax)
>