WD-AccessData-1.0-20140312
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Fri May 2 03:32:17 PDT 2014
Dear DAL list,
On Thu, Mar 13, 2014 at 10:30:01AM -0700, Patrick Dowler wrote:
>
> I have (finally) created the AccessData page on the DAL wiki and
> added the uses cases (summary doc from Severin, which also covers
> SIA) and the initial WD there.
>
> The WD is a little rougher than I had remembered when I first wrote
> it, so I added some editor notes (yellow background) with topics that
> we need to think about asap.
>
> http://wiki.ivoa.net/twiki/bin/view/IVOA/AccessData
I would like to, again, propose an alternative approach to
"accessData", where we do not define parameters for the various axes
with special syntaxes but instead go for a simple, easily declarable,
and uniform scheme.
I am still convinced that the easiest and quickest way to get this
specified would be another chapter on the datalink document. If
that's considered extremely inappropriate, I'd not object to a
separate spec with about 2 pages (plus administrativa).
In my proposal below, I still use a _MIN/_MAX scheme for intervals.
With parameters in spaces with odd topologies (for us, spheres in
particular), a ./_SIZE (e.g., RA/RA_SIZE) scheme would be somewhat
more robust, and it would also have the advantage that the UCDs would
look better. I've not switched, though, as the _SIZE approach
doesn't feel terribly natural in the cases where there's just a
standard cartesian-looking axis.
In short: I'm neutral in _MIN/_MAX vs ./_SIZE, but I'm slightly in
favour of committing to one scheme for all parameters over ordered
domains with a metric (having to require a metric with ./_SIZE would
be a bit of an argument for _MIN/_MAX, though I can't think of an
example where that would really matter).
So, here's my proposal for defining accessData services, as datalink
section or (at your option) standalone document (in which case it'd
need some glue prose to show its relation with datalink):
-----------------------8<---------------------------- (cut here)
While Datalink can define and link all kinds of ancillary services
within a Datalink response document, datalink data access services (in
short: accessData services) are a special case. These are services
yielding extractions or otherwise processed versions of the data set
*and* supporting one or more accessData parameters to be defined below.
The intent is to allow clients semantically meaningful queries against
services supporting the accessData parameters the clients understand
while not restraining custom parameters defined by a specific service or
ad hoc by some community.
accessData services MUST include a standardID PARAM with the value
ivo://ivoa.net/std/DataLink#accessData-1
in their service description.
accessData parameters are defined below via triples of (case-sensitive)
name, UCD, and unit. The intent of using such triples rather than the
name exclusively is that operators can support custom parameters without
a significant risk of becoming incompatible as this standard adds
further parameters.
Clients with built-in support for certain standard parameters (say,
cutouts in ICRS coordinates, wavelength, or time) would internally store
the triples for the supported parameters. By comparing this list with
the triples derived from the list of input parameters supplied by the
service, the client can immediately derive what standard accessData
functionality is supported by the service and what additional custom
parameters could be presented to the user.
As an example for how the triple scheme ensures smooth evolution of this
standard as new standard parameters are added, suppose an operator adds
experimental B_MIN/MAX and L_MIN/MAX parameters for cutouts in galactic
longitude and latitude. The operator would choose rad as a unit and
assign the appropriate UCDs. If later standardisation were to decide
that B and L had to have units of degrees, the existing parameters would
be identified as custom parameters by clients. These would therefore not
try to use them as standard parameters, i.e., attempt positional cutouts
using values in degrees on that particular service. A similar reasoning
would hold if later standardization were to define B_MIN/MAX as limits
on some other type of coordinates even if they were in rad, or as limits
on B magnitudes.
In the following table, the reserved triples for accessData parameters
are defined. Clients MUST NOT distinguish between missing and empty
attributes in unit. accessData services MUST NOT employ a triple given
here for parameters not matching the semantics implied here.
paramater name UCD unit remarks
ID meta.id;meta.main (none)
DEC_MIN param.min;pos.eq.dec deg (1)
DEC_MAX param.max;pos.eq.dec deg (1)
RA_MIN param.min;pos.eq.ra deg (1,2)
RA_MAX param.max;pos.eq.ra deg (1,2)
LAT_MIN param.min;(see remark) deg (1)
LAT_MAX param.max;(see remark) deg (1)
LON_MIN param.min;(see remark) deg (2,3)
LON_MAX param.max;(see remark) deg (2,3)
LAMBDA_MIN param.min;em.wl m (4)
LAMBDA_MAX param.min;em.wl m (4)
MJD_MIN param.min;time d (10)
MJD_MAX param.min;time d (10)
FORMAT meta.code.mime (none) (5)
SPECRP spect.resolution (empty) (6)
FLUXCALIB phot.calib (none) (7)
PIX(n)_MIN param.min;pos.pixel.ax(n) pixel (8)
PIX(n)_MAX param.max;pos.pixel.ax(n) pixel (8)
KIND meta.code (none) (9)
Remarks
(1) ICRS coordinates; use LAT, LON for other systems
(2) Stitching line is assumed at 360 degrees; both _MIN and _MAX are
always positive, _MAX may assume values > 360
(3) LAT and LONG can refer to all kinds of spherical coordinate systems,
which will determine the UCD; do declare VOTable STC metadata for these
parameters. UCD fragments legal here include pos.eq.ra,
pos.galactic.lon, pos.supergalactic.lon, pos.ecliptic.lon,
pos.spher.lon for LON, and their lat counterparts for LAT.
(4) Even if a specific community uses frequencies or energy, spectral
cutouts should be possible by wavelength. Additional specificiation
according to community practices is, of course, allowed via custom
parameters, but the preferred solution is conversion on the
presentation layer (i.e., community-targeted UIs presenting
input options according to community practices).
(5) This is for format conversion; the permitted values must be
enumerated in the PARAM's VALUE child
(6) This is for on-the-fly rebinning along spectral coordinates
(7) This is for on-the-fly recalibration; the calibrations understood
by the service must be enumerated in the PARAM's VALUE child.
(8) Here, n is an axis index, 1-based in accordance with FITS usage.
These are intended for pixel-wise cutout, in particular after the
client has obtained dataset metadata.
(9) KIND admits an open enumeration of "things" to ask for. Values
supported by a service must be enumerated in the PARAM's VALUE
CHILD. Predefined values include HEADER (metadata; for FITS images,
the primary header), HEADERn (the n-th header, 1-based, for
compound data), DATAn (the n-th data-metadata combination -- e.g.,
HDU in FITS files -- in compound data). Please use the predefined
values if appropriate for your data, do not use it if these concepts
do not match your data.
(10) Time is given as Modified Julian Date here
More parameters will be added in minor revisions of this document.
-----------------------8<---------------------------- (cut here)
If we can sort-of agree this is at least worth investigating, I'd be
happy to forge this into a nicely ivoadoc-formatted thing. Just let
me know. Also, wishes for more (or modified) parameters are of
course most welcome.
There's also two open points which I'd let open for version 1.0
as I think PDL+VO-DML will give us a solution for free:
* cardinality (e.g., is it ok to repeat the parameter or not)
* dependencies (e.g., you can't use LAT_MIN and DEC_MIN at the
same time)
Cheers,
Markus
More information about the dal
mailing list