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