WD-AccessData-1.0-20140312

[Jose Enrique Ruiz]

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 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




2014-07-31 11:54 GMT+02:00 Markus Demleitner <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140806/b6dac501/attachment-0001.html>