WD-AccessData-1.0-20140312

[Patrick Dowler]

The SELECT and COORD params were included the the WD to support SimDAL 
use cases and are not really expected to be useful for access to 
observational data.

COORD is indeed intended for arbitrary axes, but it presupposes detailed 
knowledge of the data, which SimDAL would deliver through it's own 
theory-specific discovery/metadata interace(s).

SELECT is also conceived for SimDAL, where there numerous properties 
available at each coordinate axis "location" (numerous being 1000s 
potentially) and the caller only wants a small selection of them.

Neither of these was discussed or even thought of in the context of 
observation data. I added the flippant comment about "COORD wave ..." 
bein equivalent to "BAND ..." simply to show/imply that all the features 
and examples earlier could also be done with COORD, not to imply that 
this is a well-conceived or consistent idea.

Pat

On 06/08/14 08:20 AM, Jose Enrique Ruiz wrote:
> Hi all
>
> I support the line proposed by Markus that AccessData does not need to
> be thoroughly consistent with DAL S*AP discovery interfaces, and hence I
> do not see it either a goal in itself. Discovery and Access are in y
> principle different methods at their basis, and I think we should keep
> in mind that AccessData should be open enough to address use cases
> others than those related with SIA or SimDAL. Considering this, and
> moreover if we see Access methods as very accurate extractions of
> multidimensional sub-regions for a given dataset, I must say I'd rather
> prefer the "three-factor semantics", though this is just a matter of
> preference.
>
> In relation to:
> "Can we use the SELECT feature to extend to extraction of ranges on
> other parameters such as RadVel/Redshift (observations)?"
>
> I think the COORD feature could in principle be used to define
> extraction regions for other non-yet standard axes/params, but a bit
> more characterization for that axis/param is needed in the case of
> RadVel/Redshift observations (i.e. for velocity at least the units and
> the emission line observed to derive the velocity of the gas, maybe also
> a reference system as well) Moreover, for the sake of interoperability I
> guess it will be also useful to provide some info on units and reference
> points for the potential values of the SELECT param.
>
> My 2c
>
>
> --
> Jose Enrique Ruiz
> Instituto Astrofisica Andalucía - CSIC
> Glorieta de la Astronomía s/n
> 18009 Granada, Spain
> Tel: +34 958 230 618 <tel:%2B34%20958%20230%20618>
>
>
>
>
> 2014-07-31 11:54 GMT+02:00 Markus Demleitner
> <msdemlei at ari.uni-heidelberg.de <mailto:msdemlei at ari.uni-heidelberg.de>>:
>
>     Hi DAL,
>
>     On Thu, Jul 31, 2014 at 09:42:59AM +0200, François Bonnarel wrote:
>      >    I encourage people to (re)start to send comments on the current
>      > draft (see below) and have in mind we had on this before and during
>      > the last interop in may.
>      >
>      >    What we have for interface is basically sufficient for the first
>      > priority cutouts and selection requirements from the CSP. It has the
>      > great advantage to be consistent with the SIA query interface. An
>      > update of the draft to take into account last evolutions of SIAV2 is
>      > needed
>
>     I'd *really* like AccessData to not only work with SIAv2; we have our
>     SSAP use cases, for instance.  Hence, while I've given up resistance
>     against the POS alphabet soup, I *really* think (in particular
>     version 1) of AccessData should contain the "three-factor semantics"
>     (as discussed in my Madrid talk
>     http://wiki.ivoa.net/internal/IVOA/InterOpMay2014DAL/flexdatalink.pdf)
>     -- a.k.a. simple, atomic parameters with strong metadata.
>
>     In that vein I'd also argue that consistency with the SIA "query
>     interface" is not a goal in itself; as I won't tire to mention, the
>     conventional DAL S*AP interfaces have serious issues (mainly in
>     interface discoverability), and I'd prefer not to be consistent with
>     those.
>
>     The big advantage of adopting three factor semantics for "non-magic"
>     parameters is that we don't have to wait for "getMetadata" or
>     a similar mechanism to allow clients to discover allowed ranges and
>     such and actually provide meaningful user interfaces.
>
>     The POS alphabet soup could still be part of this; it'd be another
>     parameter, possibly even a mandatory one if you insist (although I'd
>     consider this unwise), identified through a UCD and without further
>     metadata until the time ImageDM is ready and we have good ways to
>     serialise instances of it.
>
>     TIME, BAND, POL, SELECT from the existing AccessData could fit fairly
>     well into the sanitised parameters (ok, TIME should become TIME_MAX
>     and TIME_MIN, BAND LAMBDA_MIN, LAMBDA_MAX, but that's details).
>
>     I'd be happy to contribute the prose for this.  For that, however, I
>     believe the standard text should go into version control.  I've been
>     planning to do an ivoatex package for authoring IVOA standards in
>     LaTeX (based on what Mark Taylor uses for VOTable and SAMP) since
>     Madrid; can the authors imagine moving over the document to such a
>     system?
>
>     Cheers,
>
>               Markus
>
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)