SIAPv2 and datacubes and polarization

Doug Tody dtody at nrao.edu
Wed Mar 25 09:01:44 PDT 2009


Hi -

The current concept is as follows:

     o	Client does a query (normally this is synchronous) and gets
 	back a VOTable as at present, with one line per (possibly
 	virtual) image to be retrieved, containing metadata describing
 	the image.

     o	The acref URL provided can be used to get each individual
 	image in a synchronous fashion as at present (acrefs are
 	normally HTTP GETs but this is not actually required).

 	If this is not possible, e.g., due to sync image generation not
 	being possible before timeout, an error message of some sort
 	will be returned, or possibly we should have such a request
 	initiate a job to create the image, with a subsequent acref
 	serving as a poll to see if it is ready.  Eventually the acref
 	GET would return the actual image and the job and image would
 	be deleted on the server side.

     o	Optionally, the client can explicitly initiate a UWS job to
 	create one or more images in a single job, with full UWS job
 	control etc.  The job request refers to individual images using
 	the information provided in the query, which fully defines the
 	image to be created (e.g., a cutout, reprojection, UV image
 	generation, some slice of a cube, etc.).  It is desirable to
 	be able to request creation of multiple images in a single
 	job to allow the server maximum scope to exploit parallelism
 	and scale up the job.  The individual image generations are
 	independent, so it is little more complex to specify N of
 	them than one, if we are already submitting such a request.

How we refer to query records used to drive an individual image
generation is TBD - either the publisher dataset identifier (DID) or
acref could be used.  The publisher DID is the most flexible as then
the acref can be determined by the image creation job.  Otherwise the
acref ultimately used to reference the image has to be set at query
time (but this could redirect when the image is actually retrieved).
If we use the acref-based approach rather than publisher DID, then some
means of returning the acref to the client is required, e.g. via UWS.

A subtle advantage of the publisher DID approach is that if we
persist these DIDs then we have a true virtual data mechanism -
virtual images can be referred to by the publisher DID, and we can
come back, potentially much later, and generate them.  This feature
would require persisting virtual image metadata in the DBMS indexed
by the publisher DID, but that would not be difficult.  In our case
here the service or archive is the "publisher".

An important feature of this overall approach is that the simple
query-GET pattern works for both simple sync access and async, with
the latter possibly adding a UWS interaction to generate and stage
the data.  Hence basic querying and image retrieval are the same for
both sync and async usage.  Of course, staging the data to a VOSpace
is also possible, in which case a sophisticated client might not need
to do the GET.  But basic usage remains quite simple as at present.

 	- Doug


On Wed, 25 Mar 2009, Anita M. S. Richards wrote:

> On Wed, 25 Mar 2009, Guy Rixon wrote:
>
>>  Anita,
>>
>>  do you find it necessary that the accrefs be returned in a VOTable?
>>  In a "natural" (=simplest) application of UWS, the accrefs would be
>>  obtained separately. Either one job per cube, with one accref per job,
>>  or one job making five cubes returning five accrefs. It's possible to
>>  make the UWS job return a VOTable of accrefs, but it's not worth the
>>  complication unless there's a specific gain.
>> 
>
> Thanks Guy,
>
> The SIAP (old) standard VOTable (containing some WCS and other info and 
> accrefs) has the advantage of being recognised by applications such as 
> Aladin, so that it can be sent thereto, used to provide basic metadata e.g. 
> resolution, position, and the field of view can be visualised wrt other 
> images and then you can use the accref to obtain the images you want.
>
> If, instead, you were to return the accref as you suggest, would it be naked 
> i.e. only accessible by cut and paste? Or in a text file? Or how do you 
> envisage this? Maybe there is a better way I am not seeing...
>
> thanks
>
> Anita
>
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Dr. A.M.S. Richards, UK ARC Node/AstroGrid,
> Jodrell Bank Centre for Astrophysics, Alan Turing Building, University of 
> Manchester, M13 9PL
> +44 (0)161 275 4124
> and
> MERLIN/VLBI National Facility, Jodrell Bank Observatory, Cheshire SK11 9DL, 
> U.K. +44 (0)1477 571321 (tel) 571618 (fax)
>
> "Socialism or barbarism?" Rosa Luxemburg (1915)
>
>



More information about the dal mailing list