New version of SIAV2.0 document : proposed recommandation

[Douglas Tody]

On Thu, 31 Jul 2014, François Bonnarel wrote:

>  after rediscussing  a little with co-authors and Marco the POLarization
> parameters it appears that
>
>    2.1.4 POL (page 13)
>
>       POL=I
>       POL=Q
>       POL=U
>
>       means dataset contains "I OR Q OR U"
> 
> There is currently no way to say that a dataset contains "I AND Q AND U"
> 
> Currently implementations understand POL=I as "contains I" and not as
> "strictly equal to I".

Yes, for discovery this is an OR ("contains").

If we were discovering virtual data then POL would instead select the
planes to be returned in the computed image.

>      * 2.2 {metadata} resource
>
>            The choice made there is to access metadata for one single
> dataset (except if we put several IDS values in the ID parameter)
>        o  In that case {metadata} is very close to {accessdata}
>           resource not in the actual content but in the
>           relationship to query.   The output (one to several full
>           descriptions) is then let open with a single format.
>        o  I had in mind that a totally different mechanism could be
>           usefull: Discovery with full metadata. In that case
>           the {metadata}resource shares the same input parameters
>           with {query}. But the ouptut table (or tables) should be
>           consistent with full Image DM. It is a "long query" in
>           some way ! In other words, WCS is directly available in
>           the response obtained by the full parameter query.

Since the full metadata (WCS etc.) for a single dataset can be very
large, and a discovery query may find many datasets, I think getMetadata
should be a separate operation, restricted to a single image.
Also, for reasons of complexity, only queryData should do discovery,
and getMetadata and accessData should be limited to single datasets.

However, if we want basic WCS info in the discovery query response then
that is possible as we probably do not need full image metadata.  The
minimal stuff we have proposed for ObsTAP 1.1, plus s_region, already
comes close.  If we were to add just a bit more (e.g. reference point
and projection type) then it would suffice for the typical nsubarrays=1
use case.

 	- Doug

> 
> Best regards
> François
> 
>