/[volute]/trunk/projects/dal/SODA/SODA.tex
ViewVC logotype

Contents of /trunk/projects/dal/SODA/SODA.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3723 - (show annotations)
Thu Nov 17 16:15:45 2016 UTC (4 years, 8 months ago) by msdemlei
File MIME type: application/x-tex
File size: 40905 byte(s)
SODA: Replaced 4.3 with a somewhat more normative-sounding text.

Feature change: Interval limits are now contained in MIN/MAX rather than
MAX alone.


1 \documentclass[11pt,a4paper]{ivoa}
2 \input tthdefs
3
4 \newcommand{\xtype}[1]{\texttt{#1}}
5 \newcommand{\ucd}[1]{\texttt{#1}}
6
7 \usepackage{listings}
8 \lstloadlanguages{XML,sh}
9 \lstset{flexiblecolumns=true,basicstyle=\small,tagstyle=\ttfamily}
10 \usepackage[utf8]{inputenc}
11 \usepackage{todonotes}
12
13 \title{IVOA Server-side Operations for Data Access}
14
15 \ivoagroup{Data Access Layer Working Group}
16
17 \author{Fran\c cois Bonnarel}
18 \author{Markus Demleitner}
19 \author{Patrick Dowler}
20 \author{Douglas Tody}
21 \author{James Dempsey}
22
23 \editor{Fran\c cois Bonnarel, Patrick Dowler}
24
25 \previousversion{PR-SODA-1.0-20160429}
26 \previousversion{WD-SODA-1.0-20151221}
27 \previousversion{WD-AccessData-1.0-20151021}
28 \previousversion{WD-AccessData-1.0-20140730}
29 \previousversion{WD-AccessData-1.0-20140312}
30
31
32
33 \begin{document}
34
35 \begin{abstract}
36 This document describes the Server-side Operations for Data Access
37
38 (SODA) web service capability. SODA is a low-level data access
39 capability or server side data processing that can act upon the data
40 files, performing various kinds of operations: filtering/subsection,
41 transformations, pixel operations, and applying functions to the data.
42 \end{abstract}
43
44 \section*{Acknowledgments}
45 The authors would like to thank all the participants in DAL-WG discussions for
46 their ideas, critical
47 reviews, and contributions to this document.
48
49 \section*{Conformance-related definitions}
50
51 The words ``MUST'', ``SHALL'', ``SHOULD'', ``MAY'', ``RECOMMENDED'', and
52 ``OPTIONAL'' (in upper or lower case) used in this document are to be
53 interpreted as described in IETF standard RFC2119 \citep{std:RFC2119}.
54
55 The \emph{Virtual Observatory (VO)} is a
56 general term for a collection of federated resources that can be used
57 to conduct astronomical research, education, and outreach.
58 The \href{http://www.ivoa.net}{International
59 Virtual Observatory Alliance (IVOA)} is a global
60 collaboration of separately funded projects to develop standards and
61 infrastructure that enable VO applications.
62
63
64 \section{Introduction}
65 The SODA web service interface defines a RESTful web service for
66 performing server-side operations and processing on data before
67 transfer.
68
69 \subsection{The Role in the IVOA Architecture}
70
71 \begin{figure}
72 \centering
73
74 \includegraphics[width=0.9\textwidth]{archdiag.png}
75 \caption{SODA in the global VO architecture}
76 \label{fig:architecture}
77 \end{figure}
78
79 Figure~\ref{fig:architecture} shows how SODA fits into the IVOA architecture.
80 SODA services conform to the Data Access Layer Interface (DALI,
81 \citet{std:DALI}) specification,
82 including the Virtual Observatory Support Interfaces (VOSI,
83 \citet{std:VOSI}) resources.
84
85 Within the IVOA architecture, SODA services could be found and used in
86 several ways. First, a SODA service could be found in the IVOA Registry
87 and used directly. A description of a SODA service may be found along
88 with specific dataset metadata at either the data discovery phase using
89 Simple Image Access (SIA, \citet{std:SIAv2}) or Table Access Protocol
90 (TAP, \citet{std:TAP}) and the ObsCore data model \citep{std:OBSCORE} or
91 via a DataLink \citep{std:DataLink} service. The service descriptors and
92 three-factor semantics rely on UCDs \citep{std:UCD} and the VO Unit
93 specification \citep{std:VOUNIT}. Since the discovery of SODA services
94 makes use of DataLink service descriptor(s) to provide parameter
95 metadata, the VOSI-capabilities specified in
96 Section~\ref{sec:capabilities} do not make use of a registry extension.
97
98 \subsubsection{SODA Service in the Registry}
99
100 Resources in the IVOA Registry may include SODA capabilities. In order to
101 use such services, clients require prior knowledge of suitable
102 identifiers that are usable with a registered SODA service. This
103 scenario is described in more detail below in
104 Section~\ref{sec:reg-soda}.
105
106 \subsubsection{SODA Service from Data Discovery}
107
108 In the simplest case, the identifiers found via data discovery can be
109 used directly with an associated SODA service. The query response (from
110 SIA or TAP) would include one or more DataLink service descriptor(s)
111 that describe the available SODA capabilities. This scenario is described
112 in detail in Section~\ref{sec:disc-soda}.
113
114 \subsubsection{SODA Service from DataLink}
115
116 In the general case, data discovery responses may direct clients to an
117 associated DataLink service where access details can be obtained. The
118 DataLinks output will in turn provide service descriptor(s) of the
119 associated SODA service(s). Service providers may choose this approach
120 for several reasons; for example, one entry from data discovery may lead
121 to multiple files or resources, or access via services such as SODA may
122 be considered the primary access mode and direct download is not
123 available or discouraged. This scenario is described in detail in
124 Section~\ref{sec:disc-links-soda}.
125
126
127 \subsection{Motivating Use Cases}
128 Below are some of the more common use cases that have motivated the
129 development of the SODA specification. While this is not complete, it
130 helps to understand the problem area covered by this specification.
131
132 \subsubsection{Retrieve Subsection of a Datacube}
133 \label{sec:use-cube}
134
135 Cutout a subsection using coordinate axis values. The input to the
136 cutout operation will include one or more of the following:
137
138 \begin{itemize}
139 \item a region on the sky
140 \item an energy value or range
141 \item a time value or range
142 \item one or more polarization states
143 \end{itemize}
144
145 The region on the sky should be something simple: a circle,
146 a range of coordinate values, or a polygon.
147
148 \subsubsection{Retrieve subsection of a 2D Image}
149 This is a special case of \ref{sec:use-cube},
150 where the cutout is only in the spatial axes.
151
152 \subsubsection{Retrieve subsection of a Spectrum}
153
154 This is a special case of \ref{sec:use-cube},
155 where the cutout is only in the spectral axis.
156
157 \subsection{Anticipated Future Use Cases}
158
159 \subsubsection{Provide the data in different formats}
160
161 Examples are images in PNG, or JPEG instead of FITS and spectra in csv,
162 FITS or VOTable.
163
164 \subsubsection{Flatten a Datacube into a 2D Image}
165
166 This use case will be developed and supported in the
167 SODA-1.1 (or later) specification.
168
169 \subsubsection{Flatten a Datacube into a 1D Spectrum}
170
171 This use case will be developed and supported in the
172 SODA-1.1 (or later) specification.
173
174 \subsubsection{Rebin Data by a Fixed Factor}
175
176 This use case will be developed and supported in the
177 SODA-1.1 (or later) specification.
178
179 \subsubsection{Reproject Data onto a Specified Grid}
180
181 This use case will be developed and supported in the
182 SODA-1.1 (or later) specification.
183
184 \subsubsection{Compute Aggregate Functions over the Data}
185
186 This use case will be developed and supported in the
187 SODA-1.1 (or later) specification.
188
189
190 \subsubsection{Apply Standard Function to Data Values}
191
192 It could be
193 ``denoising'' with standard methods or ``on the fly'' recalibration.
194 This use case will be developed and supported in the SODA-1.1 (or later)
195 specification.
196
197 \subsubsection{Apply Arbitrary User-Specified Function to Data Values}
198
199 This use case will be developed and supported in the
200 SODA-1.1 (or later) specification.
201
202 \subsubsection{Run Arbitrary User-Supplied Code on the Data}
203
204 This use case will be developed and supported in the
205 SODA-1.1 (or later) specification.
206
207
208 \section{Resources}
209 \label{sec:resources}
210
211 SODA services are implemented as HTTP REST \citep{richardson07} web
212 services with a \{sync\} resource that conforms to the DALI-
213 sync resource description.
214
215 \begin{table}[ht]
216 \begin{tabular}{rrr}
217 \sptablerule
218 \textbf{resource type}&\textbf{resource name}&\textbf{required}\cr
219 \sptablerule
220 \{sync\}&service specific&\cr
221 \{async\}&service specific&\cr
222 {DALI-examples}&/examples&no\cr
223 {VOSI-availability}&/availability&yes\cr
224 {VOSI-capabilities}&/capabilities&yes\cr
225 \sptablerule
226 \end{tabular}
227 \caption{Endpoints for AccessData services}
228 \end{table}
229
230 A stand-alone SODA service may have one or both of the \{sync\} and
231 \{async\} resources. For either type, it could have multiple resources
232 (e.g. to support alternate authentication schemes). The SODA service may
233 also include other custom or supporting resources.
234
235 Either the \{sync\} or \{async\} SODA capability may be included as part
236 of other web services. For example, a single web service could contain
237 the SIA-2.0 \{query\} capability, the DataLink-1.0 \{links\} capability,
238 and the SODA \{sync\} capability. Such a service must also have the
239 VOSI-availability and VOSI-capabilities resources to report on and
240 describe all the implemented capabilities.
241
242 \subsection{\{sync\} resource}
243 \label{sec:sync}
244
245 The \{sync\} resource is a synchronous web service resource
246 that conforms to the DALI-sync description. Implementors
247 are free to name this resource however
248 they like, except that the name must consist of one URI segment only (i.e.,
249 contain no slash). This is to allow clients, given the access URL,
250 can reliably find out the URL of the capabilities endpoint.
251 Clients, in turn, can find the resource path using the
252 VOSI-capabilities resource, but will in general be provided the access
253 URLs through a previous data discovery query or through direct user
254 input.
255
256 The \{sync\} resource performs the data access as specified by
257 the input parameters and returns the data directly in the
258 output stream. Synchronous data access is suitable when the
259 operations can be quickly performed and the data stream can
260 be setup and written to (by the service) in a short period
261 of time (e.g. before any timeouts).
262
263 \subsection{\{async\} resource}
264 \label{sec:async}
265
266 The \{async\} resource is an asynchronous web service resource
267 that conforms to the DALI-async description. The considerations on
268 naming the resource given in sect.~\ref{sec:sync} apply for it.
269
270 The \{async\} resource performs the data access as specified
271 by the input parameters and either (i) stores the results
272 for later transfer or (ii) pushes the results to a specified
273 destination (e.g. to a VOSpace location). Asynchronous data
274 access usually introduces resource constraints on the
275 service (which may be limited) and usually imposes a higher
276 latency before any results can be seen because the location
277 of results does not have to be valid until the data access
278 job is complete. Asynchronous data access is intended for
279 (but not limited to) use when the operations take
280 considerable time and results must be staged (e.g. some
281 multi-pass algorithms or operations that result in multiple
282 outputs).
283
284 \subsection{Examples: DALI-examples}
285 \label{sec:examples}
286
287 SODA services should provide a DALI-examples resource
288 with one example invocation that shows the variety of
289 operations the service can perform. Example operations using
290 the \{sync\} resource and that output a small data stream are
291 preferred, as the examples may be used by automatic validators doing
292 relatively frequent (of order daily) queries.
293
294 Parameters to be passed to the service must be given using the DALI
295 \texttt{generic-parameter} term.
296
297
298 \subsection{Availability: VOSI-availability}
299 \label{sec:availability}
300
301 A SODA web service must have a VOSI-availability
302 resource \citep{std:VOSI} as described in DALI \citep{std:DALI}.
303
304 \subsection{Capabilities: VOSI-capabilities}
305 \label{sec:capabilities}
306
307 A web service that includes SODA capabilities must
308 have a VOSI-capabilities resource \citep{std:VOSI} as described in DALI
309 \citep{std:DALI}. The standardID for the \{sync\} resource is
310 $$\hbox{\texttt{ivo://ivoa.net/std/SODA\#sync-1.0}}$$
311
312 The standardID for the \{async\} resource is
313 $$\hbox{\texttt{ivo://ivoa.net/std/SODA\#async-1.0}}$$
314
315 All DAL services must implement the \texttt{/capabilities} resource.
316 The following capabilities document shows the minimal
317 metadata for a stand-alone SODA service and does not
318 require a registry extension schema:
319
320 \begin{lstlisting}[language=XML]
321 <?xml version="1.0"?>
322 <capabilities
323 xmlns:vosi="http://www.ivoa.net/xml/VOSICapabilities/v1.0"
324 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
325 xmlns:vod="http://www.ivoa.net/xml/VODataService/v1.1">
326
327 <capability standardID="ivo://ivoa.net/std/VOSI#capabilities">
328 <interface xsi:type="vod:ParamHTTP" version="1.0">
329 <accessURL use="full">http://example.com/data/capabilities</accessURL>
330 </interface>
331 </capability>
332
333 <capability standardID="ivo://ivoa.net/std/VOSI#availability">
334 <interface xsi:type="vod:ParamHTTP" version="1.0">
335 <accessURL use="full">
336 http://example.com/data/availability
337 </accessURL>
338 </interface>
339 </capability>
340
341 <capability standardid="ivo://ivoa.net/std/SODA#sync-1.0">
342 <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
343 <accessURL use="full">
344 http://example.com/data/sync
345 </accessURL>
346 </interface>
347 </capability>
348
349 <capability standardid="ivo://ivoa.net/std/SODA#async-1.0">
350 <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
351 <accessURL use="full">
352 http://example.com/data/async
353 </accessURL>
354 </interface>
355 </capability>
356 </capabilities>
357 \end{lstlisting}
358
359 Note that the \{sync\} and \{async\} resources do not have to be
360 named as shown in the accessURL(s) above. Multiple
361 interface elements within the \{sync\} and the \{async\} capabilities
362 may be included; this is typically used if the differ in
363 protocol (http vs. https) and/or authentication
364 requirements.
365
366
367 \section{Parameters for SODA \{sync\} and \{async\}}
368 \label{sec:parameters}
369
370 The \{sync\} and \{async\} resources accept the same set of
371 parameters. Support for multiple values of parameters is optional.
372 If a request includes multiple values for a parameter and the
373 service does not support multiple values for that parameter, the
374 request must fail with the MultiValuedParamNotSupported error listed
375 below (\ref{sec:error-codes}). For example, a service may
376 allow only single values for ID but multiple values for cutout parameters.
377 Supported multiplicity may also differ between {sync} and {async} requests.
378
379 \enlargethispage{\baselineskip}
380
381 In general, services would support multi-valued parameters as they may be
382 able to provide more efficient access to data files. Clients may attempt to use
383 multi-valued parameters, but must be prepared to fall back to multiple requests
384 if the service indicates this is not supported. A future version of
385 DataLink
386 \citep{std:DataLink} should provide a mechanism to describe parameter
387 multiplicity.
388
389 \subsection{Common Parameters}
390
391 \subsubsection{ID}
392 \label{sec:ID}
393
394 The ID parameter is used to specify the dataset or file to
395 be accessed. The values for the ID parameter are generally
396 discovered from data discovery or DataLink requests. The
397 values must be treated as opaque identifiers that are used
398 as-is. The DataLink specification \citep{std:DataLink} describes mechanisms
399 for conveying opaque parameters and values in service
400 descriptor resources that can be used by clients to set the
401 ID parameter.
402
403 The UCD \citep{std:UCD} describing the ID parameter is\\
404 \ucd{meta.ref.url;meta.curation}.
405
406 \subsection{Filtering Parameters}
407
408 Filtering parameters are used to extract subsets of larger
409 datasets or data files.
410
411 \subsubsection{CIRCLE}
412 \label{sec:CIRCLE}
413
414 The CIRCLE parameter defines a spatial region using the \xtype{circle}
415 xtype defined in DALI \citep{std:DALI}.
416
417 Example: a circle at (12,34) with radius 0.5:
418
419 \begin{lstlisting}
420 CIRCLE=12 34 0.5
421 \end{lstlisting}
422
423 The UCD \citep{std:UCD} describing the CIRCLE parameter is
424 \ucd{phys.angArea;obs}.
425
426 CIRCLE is equivalent in functionality to \texttt{POS=CIRCLE ...} but
427 with type-safe serialised value and unit metadata.
428
429 \subsubsection{POLYGON}
430 \label{sec:POLYGON}
431
432 The POLYGON parameter defines a spatial region using the \xtype{polygon}
433 xtype defined in \citep{std:DALI}.
434
435 Example: a polygon from (12,34) to (14,34) to (14,36) to (12,36) and
436 (implicitly) back to (12,34):
437
438 \begin{lstlisting}
439 POLYGON=12 34 14 34 14 36 12 36
440 \end{lstlisting}
441
442 The UCD \citep{std:UCD} describing the POLYGON parameter is
443 \ucd{phys.angArea;obs}.
444
445 POLYGON is equivalent in functionality to \texttt{POS=POLYGON ...} but
446 with type-safe serialised value and unit metadata.
447
448 \subsubsection{POS}
449 \label{sec:POS}
450
451 The POS parameter defines the positional region(s) to be
452 extracted from the data using the \xtype{region}
453 xtype defined in \citep{std:DALI}. The value is made up of a shape
454 keyword followed by coordinate values. The
455 allowed shapes are given in Table~\ref{tab:shapetypes}.
456
457 \begin{table}[h]
458 \begin{tabular}{ll}
459 \sptablerule
460 \textbf{Shape}&\textbf{Coordinate values}\cr
461 \sptablerule
462 \texttt{CIRCLE}&\texttt{<longitude> <latitude> <radius>}\cr
463 \texttt{RANGE}&\texttt{<longitude1> <longitude2> <latitude1> <latitude2>}\cr
464 \texttt{POLYGON}&\texttt{<longitude1> <latitude1> ... (at least 3 pairs)}\cr
465 \sptablerule
466 \end{tabular}
467 \caption{POS Values in Spherical Coordinates}
468 \label{tab:shapetypes}
469 \end{table}
470
471 As in DALI intervals, open ranges use -Inf or +Inf as one limit.
472
473 \goodbreak
474 Examples for POS values:
475
476 \begin{itemize}
477 \item A circle at (12,34) with radius 0.5:
478
479 \begin{lstlisting}
480 POS=CIRCLE 12 34 0.5
481 \end{lstlisting}
482
483 \item A range of [12,14] in longitude and [34,36] in latitude:
484
485 \begin{lstlisting}
486 POS=RANGE 12 14 34 36
487 \end{lstlisting}
488
489 \item A polygon from (12,34) to (14,34) to (14,36) to (12,36) and
490 (implicitly) back to (12,34):
491
492 \begin{lstlisting}
493 POS=POLYGON 12 34 14 34 14 36 12 36
494 \end{lstlisting}
495
496 \item A band around the equator:
497
498 \begin{lstlisting}
499 POS=RANGE 0 360 -2 2
500 \end{lstlisting}
501
502 \item The north pole:
503
504 \begin{lstlisting}
505 POS=RANGE 0 360 89 +Inf
506 \end{lstlisting}
507 \end{itemize}
508
509 All longitude and latitude values (plus the radius of the
510 CIRCLE) are expressed in degrees in ICRS. A future
511 version of this specification may allow the use of other
512 reference systems (specifically the native system of the
513 data).
514
515 The UCD \citep{std:UCD} describing the POS parameter is \ucd{phys.angArea;obs}.
516
517 Since it is string-valued, POS is unitless; however, the numeric values
518 contained in the the string are all in decimal degrees. In VOTable, the
519 POS parameter has \texttt{datatype="char"} and \texttt{arraysize="*"}.
520
521
522
523 POS is included in SODA for consistency with the SIA-2.0
524 \citep{std:SIAv2} query parameter of the same name. Note that use of the
525 POS parameter with shape keyword ``circle'' provides the equivalent
526 spatial region as the CIRCLE parameter and POS with the shape keyword
527 ``polygon'' is equivalent to the POLYGON parameter. There is no
528 type-specific parameter that is equivalent to the ``range'' shape
529 keyword. There is no way for a service provider to declare support for a
530 subset of the POS shape keywords in a DataLink \citep{std:DataLink}
531 service descriptor; either POS is included or not and if included then
532 all keywords must be supported.
533
534
535 \subsubsection{BAND}
536 \label{sec:BAND}
537
538 The BAND parameter defines the energy interval(s) to be extracted from
539 the data using a floating point interval (\texttt{xtype="interval"}) as
540 defined in \citep{std:DALI}. The value is an open or closed numeric
541 interval with numeric values interpreted as wavelength(s) in metres. As
542 in DALI, open intervals use -Inf or +Inf as one limit.
543
544 \begin{itemize}
545 \item The closed interval [500,550]:
546
547 \begin{lstlisting}
548 BAND=500 550
549 \end{lstlisting}
550
551 \item The open interval (-inf,300]:
552
553 \begin{lstlisting}
554 BAND=-Inf 300
555 \end{lstlisting}
556
557 \item The open interval [750,inf):
558
559 \begin{lstlisting}
560 BAND=750 +Inf
561 \end{lstlisting}
562
563 \item The scalar value 550, equivalent to [550,550]:
564
565 \begin{lstlisting}
566 BAND=550 550
567 \end{lstlisting}
568
569 \end{itemize}
570
571 Extracting using a scalar value should normally extract a
572 single pixel along the energy axis of the data; extracting
573 using an interval should extract one or more pixels.
574
575 All energy values are expressed as barycentric wavelength in
576 meters. A future version of this specification may allow the
577 use of other reference systems (specifically the native
578 system of their data).
579
580 The UCD \citep{std:UCD} describing the BAND parameter is \ucd{em.wl}.
581
582
583 \subsubsection{TIME}
584 \label{sec:TIME}
585
586 The BAND parameter defines the time interval(s) to be extracted from the
587 data using a floating point interval (\texttt{xtype="interval"}) as
588 defined in DALI \citep{std:DALI}. The value is an open or closed
589 interval with numeric values interpreted as Modified Julian Date(s) in
590 UTC. As in DALI, open intervals use -Inf or +Inf as one limit.
591
592 \begin{itemize}
593 \item An open interval from the MJD 55100.0 and all later times:
594
595 \begin{lstlisting}
596 TIME= 55100.0 +Inf
597 \end{lstlisting}
598
599 \item A range of MJD values:
600
601 \begin{lstlisting}
602 TIME=55123.456 55123.466
603 \end{lstlisting}
604
605 \item An instant in time using Modified Julian Date:
606
607 \begin{lstlisting}
608 TIME=55678.123456 55678.123456
609 \end{lstlisting}
610 \end{itemize}
611
612 The UCD \citep{std:UCD} describing the TIME parameter is
613 \ucd{time.interval;obs.exposure}.
614
615
616 \subsubsection{POL}
617 \label{sec:POL}
618
619 The POL parameter defines the polarization state(s) (Stokes)
620 to be extracted from the data.
621
622 \begin{itemize}
623 \item Extract the unpolarized intensity:
624 \begin{lstlisting}
625 POL=I
626 \end{lstlisting}
627 \item Extract the standard circular polarization:
628 \begin{lstlisting}
629 POL=V
630 \end{lstlisting}
631
632 \item Extract only the IQU components:
633 \begin{lstlisting}
634 POL=I
635 POL=Q
636 POL=U
637 \end{lstlisting}
638 \end{itemize}
639
640 As shown in the example above, the POL parameter must support multiple values
641 for both \{sync\} and \{async\} requests. Unlike general filtering parameters,
642 all values of POL are combined into a single filter; for example, if the request
643 includes the three values above, the job would generate one result with
644 some or all of these polarization states (per combination of ID and
645 other filtering parameters).
646
647 The UCD \citep{std:UCD} describing the POL parameter is
648 \ucd{meta.code;phys.polarization}.
649
650
651 \subsubsection{Filtering parameters and ObsCore data model}
652
653
654 Filtering parameters drive the generation of virtual datasets. The ObsCore model is perfectly valid to describe virtual data that SODA is able to generate. Hence all SODA Filtering parameters are coupled with some Obscore model concepts.
655
656 The spatial parameters (CIRCLE, POLYGON and POS) constrain the spatial support of the output virtual dataset. (The ObsCore attribute name is s\_region - utype "obscore:Char.SpatialAxis.Coverage.Support.Area" -). The spatial support of the output dataset is included in the spatial support of the archived dataset.
657
658
659 The TIME parameter constrains the time bounds of the SODA output virtual dataset (Obscore feature of utype: \\
660 "Char.TimeAxis.Coverage.Bounds.Limits"). The time bounds of the output dataset are limited by the time bounds of the archived dataset.
661 The BAND parameter constrains the spectral bounds of the SODA output virtual
662 dataset (Obscore feature of utype: \\ "Char.spectralAxis.Coverage.Bounds.Limits").
663 The spectral bounds of the output datasets are limited by the spectral bounds of
664 the archived dataset.
665
666
667 The POL parameter constrain the list of polarization states in the output virtual dataset (ObsCore feature of name "pol\_states" \\
668 - utype "obscore:Char.PolarizationAxis.stateList"). The
669 valid values for this param are included in the list given by the value
670 of the pol\_states attribute of the archived dataset.
671
672 \subsection{Three-Factor Semantics}
673
674 Parameters in SODA are uniquely defined by the triple of name, UCD
675 \citep{std:UCD}, and unit \citep{std:VOUNIT}. Data services are free to
676 support as many such parameters as is appropriate for their datasets, in
677 addition to supporting standard parameters. With the three factors, it
678 is unlikely that two service providers will by accident use the same
679 three factors for parameters of differing semantics.
680
681 With standard parameters as defined in this document, clients can rely
682 on certain semantics and exploit that knowledge in the provision of
683 special UIs or APIs. Standard parameters defined so far are given
684 in table~\ref{table:standardpars}. Instructions for how to propose
685 additional standard parameters are given on the landing page of the IVOA
686 DAL working group\footnote{At the time of writing, this is
687 \href{http://wiki.ivoa.net/twiki/bin/view/IVOA/DefiningServiceParameters}{http://wiki.ivoa.net/twiki/bin/view/IVOA/DefiningServiceParameters}.}.
688
689 \begin{table}[mht]
690 \begin{tabular}{l l l l}
691 \sptablerule
692 \textbf{Name}&\textbf{UCD}&\textbf{Unit}&\textbf{Semantics} \cr
693 \sptablerule
694 ID&meta.ref.url;meta.curation&&cf.~sect.~\ref{sec:ID} \cr
695 CIRCLE&phys.angArea;obs&deg&cf.~sect.~\ref{sec:CIRCLE} \cr
696 POLYGON&phys.angArea;obs&deg&cf.~sect.~\ref{sec:POLYGON} \cr
697 POS&phys.angArea;obs&&cf.~sect.~\ref{sec:POS} \cr
698 BAND&em.wl&m&cf.~sect.~\ref{sec:BAND} \cr
699 TIME&time.interval;obs.exposure&d&cf.~sect.~\ref{sec:TIME} \cr
700 POL&meta.code;phys.polarization&&cf.~sect.~\ref{sec:POL} \cr
701 \sptablerule
702 \end{tabular}
703 \caption{Three-Factor Semantics for standard SODA parameters}
704 \label{table:standardpars}
705 \end{table}
706
707 Both standard and non-standard parameters should follow DALI conventions
708 if at all possible. Roughly, float-valued target fields should be accessed or
709 constrained via interval-valued parameters (i.e., do not split up
710 minimum and maximum into separate parameters). Depending on their
711 semantics, integer parameters should either be intervals or enumerated
712 parameters (which typically can be repeated). Geometry fields should be
713 accessed or constrained using geometry values (circle and polygon xtypes
714 from DALI \citep{std:DALI}), following the examples of CIRCLE
715 (\ref{sec:CIRCLE}) and POLYGON (\ref{sec:POLYGON}).
716
717 Parameter metadata, including three-factor semantics, is conveyed to
718 clients via DataLink \citep{std:DataLink} service descriptor(s) as
719 described in Section~\ref{sec:integration}.
720
721 \section{Integration of Service Capabilities}
722 \label{sec:integration}
723
724 Finding and using SODA services depends on several other standards;
725 service providers can follow one or more strategies in integrating a
726 range of standard and custom services with their SODA implementation.
727 Here we describe these strategies and show how to use the standards
728 together.
729
730 Within the IVOA architecture, SODA services could be found and used in two
731 ways. First, a SODA service could be found in the IVOA Registry and used
732 directly. Second, a description of a SODA service may be found along
733 with specific dataset metadata; this is the primary anticipated usage:
734 clients discover applicable SODA services while doing data discovery
735 queries.
736
737 The DataLink \citep{std:DataLink} recommendation provides a mechanism
738 to include ``a description of a SODA service'' using a standard resource
739 called a service descriptor. The service descriptor is included in any
740 VOTable \citep{std:VOTable} output and can describe the parameters for
741 use with a DALI-sync or DALI-async compliant capability. Aside from DALI
742 \citep{std:DALI} compliance, this may be a standard service or a custom
743 service. Since the service descriptor can describe all input parameters,
744 it can declare available standard parameters, extensions (custom
745 parameters in standard services), and parameters for custom services.
746 This mechanism is expected to be the primary means of finding and using
747 a SODA service.
748
749 A generic SODA sync service descriptor describing the standard
750 parameters (see sect.~\ref{sec:parameters}):
751
752 \begin{lstlisting}[language=XML]
753 <RESOURCE type="meta" ID="soda-sync" utype="adhoc:service">
754 <PARAM name="standardID" datatype="char" arraysize="*"
755 value="ivo://ivoa.net/std/SODA#sync-1.0" />
756 <PARAM name="accessURL" datatype="char" arraysize="*"
757 value="http://example.com/soda/sync" />
758 <GROUP name="inputParams">
759 <PARAM name="ID" ucd="meta.ref.url;meta.curation"
760 ref="idcolumn-ref"
761 datatype="char" arraysize="*" value="" />
762 <PARAM name="POS" ucd="phys.angArea;obs"
763 datatype="char" arraysize="*" value="" />
764 <PARAM name="CIRCLE" unit="deg" ucd="phys.angArea;obs"
765 datatype="double" arraysize="3"
766 xtype="circle" value="" />
767 <PARAM name="POLYGON" unit="deg" ucd="phys.angArea;obs"
768 datatype="double" arraysize="*"
769 xtype="polygon" value="" />
770 <PARAM name="BAND" unit="m" ucd="em.wl"
771 datatype="double" arraysize="2"
772 xtype="interval" value="" />
773 <PARAM name="TIME" ucd="time.interval;obs" unit="d"
774 datatype="double" arraysize="2"
775 xtype="interval" value="" />
776 <PARAM name="POL" ucd="meta.code;phys.polarization"
777 datatype="char" arraysize="*" value="" />
778 </GROUP>
779 </RESOURCE>
780 \end{lstlisting}
781
782 This service descriptor is generic because the ID parameter uses a
783 \xmlel{ref} attribute to specify that identifier values come from
784 elsewhere in the document (usually this refers to a FIELD element that
785 describes a table column within another RESOURCE element). Thus, this
786 descriptor can be used with any ID values in that column.
787
788 The PARAM with \texttt{name="standardID"} specifies that this service is
789 a SODA sync service. The standardID values for SODA are specified in
790 Section~\ref{sec:capabilities}.
791
792 The GROUP with \texttt{name="inputParams"} shows the standard
793 description of the standard SODA parameters as defined in
794 Section~\ref{sec:parameters}. Services should only include parameter
795 descriptions for supported parameters; in a generic service descriptor
796 ``supported'' means supported by the implementation and does not imply
797 that use of that parameter is applicable to all data (e.g. to all
798 possible identifier values).
799
800
801 All PARAMs in the descriptor may include a "<VALUES>" subelement. This element is providing PARAMETER domain limits or list of admitted values. See section 4.3 for a full description of the usage of this feature.
802
803 \subsection{SODA Service in the Registry}
804 \label{sec:reg-soda}
805
806 Resources in the IVOA Registry may include SODA capabilities. However,
807 in order to
808 use such services, clients require prior knowledge of suitable
809 identifiers that are usable with a registered SODA service. As a result,
810 finding and
811 using a SODA service via the registry is not expected to be a common
812 usage pattern.
813
814
815 \subsection{SODA Service Descriptor from Data Discovery}
816 \label{sec:disc-soda}
817
818 In the simplest case, the identifiers found via data discovery (e.g. the
819 \texttt{obs\_publishder\_did} in Obscore \citep{std:OBSCORE}) can be
820 used directly with an associated SODA service. The query response from
821 SIAv2 \citep{std:SIAv2} or TAP \citep{std:TAP} should include one or
822 more DataLink \citep{std:DataLink} service descriptors that describe the
823 SODA capabilities. These would have a \texttt{standardID} parameter
824 specifying SODA \{async\} or SODA \{sync\} as specified in
825 Section~\ref{sec:capabilities} and an appropriate \texttt{accessURL}
826 parameter for the service. If the service is registered, the provider
827 can include a \texttt{resourceIdentifier} parameter. The supported SODA
828 service parameters (standard and custom) would be declared in the
829 inputParams group of the service descriptor.
830
831 The declaration of the ID parameter will specify which column in the
832 data discovery response contains the suitable identifier; although this
833 is usually the obs\_publisher\_did from the ObsCore data model, this is
834 not required and the provider may have the ID parameter reference
835 another (possibly custom) column.
836
837 The data discovery response will in general contain metadata the client
838 can use to determine the values of SODA filtering parameters that will
839 yield valid subsets of the data. For example, standard data discovery
840 using either SIAv2 or TAP and Obscore will provide metadata for
841 specifying POS, CIRCLE, and POLYGON (s\_region, s\_ra, s\_dec, s\_fov),
842 BAND (em\_min, em\_max), TIME (t\_min, t\_max), and POL (pol\_states)
843 parameters.
844
845 When a service descriptor for a SODA service is provided in the data
846 discovery response, it should be a generic descriptor (see above) for
847 use with multiple ID values. Thus, there will normally be a single
848 service descriptor for each available service.
849
850
851 \subsection{SODA Service Descriptor from DataLink}
852 \label{sec:disc-links-soda}
853
854 The alternative scenario has the discovery service return Datalink
855 documents (see \citet{std:DataLink} for ways to do that). These
856 Datalink documents can then contain one or more SODA descriptor(s),
857 most typically one per dataset described. To allow SODA clients
858 the inference of parameter ranges and the presentation of useful
859 user interfaces, data providers SHOULD communicate the admissable
860 ranges of the parameters in question using the VOTable
861 \xmlel{VALUES} element.
862
863 For float-valued intervals (e.g., the standard BAND and TIME
864 parameters), \xmlel{VALUES/MIN} and \xmlel{VALUES/MAX} are used to
865 communicate the range of values for which clients can expect to
866 receive data. Example:
867
868 \begin{lstlisting}[language=XML]
869 <PARAM name="BAND" unit="m" ucd="em.wl"
870 datatype="double" arraysize="2"
871 xtype="interval" value="">
872 <DESCRIPTION>The wavelength intervals to be extracted</DESCRIPTION>
873 <VALUES>
874 <MIN value="3e-7"/>
875 <MAX value="8e-7"/>
876 </VALUE>
877 </PARAM>
878 \end{lstlisting}
879
880 Enumerated values, both for integeral and textual types, use
881 \xmlel{VALUES/OPTION} elements unless there are too many possible
882 values. Again, only values for which nonempty responses can be
883 expected for the described dataset should be listed. Example:
884
885 \begin{lstlisting}[language=XML]
886 <PARAM name="POL" ucd="meta.code;phys.polarization"
887 datatype="char" arraysize="*" value="">
888 <DESCRIPTION>Polarization states to be extracted.</DESCRIPTION>
889 <VALUES>
890 <OPTION>I</OPTION>
891 <OPTION>V</OPTION>
892 </VALUE>
893 </PARAM>
894 \end{lstlisting}
895
896 In case the option enumeration becomes too large, the descirption
897 of the parameter should carefully describe what values are
898 admissable, e.g., by providing a link to an enumeration in the
899 \xmlel{DESCRIPTION}.
900
901 Intervals of integers are described analogous to float-valued
902 intervals, i.e., using \xmlel{MIN} and \xmlel{MAX} elements.
903
904 Standard VOTable semantics are insufficient for the metadata of the SODA
905 POLYGON and CIRCLE parameters. We therefore define special cases for
906 the \xmlel{xtype}s \emph{circle} and \emph{polygon} at least until such
907 time as a proper data model for space-time coordinates defines a
908 different way to communicate such coverages within VOTables.
909
910 For CIRCLE, only a \xmlel{MAX} is given. It contains three
911 floating point values, separated by whitespace. These correspond
912 to the RA and Dec of the center of a spherical circle covering the
913 dataset, and a radius of such a covering circle. Data providers
914 SHOULD make sure they choose the center and radius such that the
915 covering circle is close to the minimal one of the dataset.
916 Example:
917
918 \begin{lstlisting}[language=XML]
919 <PARAM name="CIRCLE" unit="deg" ucd="phys.angArea;obs"
920 datatype="double" arraysize="3"
921 xtype="circle" value="">
922 <DESCRIPTION>
923 A spherical circle to be contained by the cutout
924 </DESCRIPTION>
925 <VALUES> <MAX value="12.0 34.0 0.5"/> </VALUES>
926 </PARAM>
927 \end{lstlisting}
928
929 For POLYGON, again only a \xmlel{MAX} is given. It consists of
930 a sequence of floating-point values, again separated by blanks,
931 describing RA and Dec of the vertices of a spherical polygon
932 covering the dataset. Data providers are encouraged to choose a
933 minimal polygon. Example:
934
935 \begin{lstlisting}[language=XML]
936 <PARAM name="POLYGON" unit="deg" ucd="phys.angArea;obs"
937 datatype="double" arraysize="*"
938 xtype="polygon" value="">
939 <DESCRIPTION>A polygon to be contained by the cutout</DESCRIPTION>
940 <VALUES>
941 <MAX value="11.5 33.5 12.5 33.5 12.5 34.5 11.5 34.5"/>
942 </VALUES>
943 </PARAM>
944 \end{lstlisting}
945
946 Angles in both CIRCLE and POLYGON are in degrees. As in the input,
947 the ICRS reference system is assumed, with no further metadata (e.g.,
948 reference position) prescribed by this standard. Further metadata may
949 should be given using standard STC annotation when the formalism to do
950 that is finalised.
951
952 For POS, useful metadata cannot be given. Services supporting POS
953 should therefore provide POLYGON as well, and clients wishing to
954 use POS should infer sensible values for that parameter from
955 \xmlel{VALUES} given for POLYGON.
956
957
958 \section{\{sync\} Responses}
959
960 All responses from the \{sync\} resource follow the rules for
961 DALI-sync resources, except that the \{sync\} response allows
962 for error messages for individual input identifier values.
963
964 \subsection{Successful Requests}
965
966 Successfully executed requests should result in a response
967 with HTTP status code 200 (OK) and a response in the format
968 requested by the client or in the default format for the
969 service.
970
971 If the values specified for cutout parameters do not include
972 any pixels from the target dataset/file, the service must
973 respond with HTTP status code 204 (No Content) and no
974 response body.
975
976 The service should set the following HTTP headers to the
977 correct values where possible.
978
979 \begin{tabular}{rr}
980 \sptablerule
981 Content-Type&mime-type of the response\cr
982 Content-Encoding&encoding/compression of the response (if applicable)\cr
983 \sptablerule
984 \end{tabular}
985
986 Since the response is usually dynamically generated, the
987 Content-Length and Last-Modified headers cannot usually be
988 set.
989
990 \subsection{Errors}
991 \label{sec:error-codes}
992
993 The error handling specified for DALI-sync resources applies
994 to service failure. Error documents should be text using the
995 text/plain content-type and the text must begin with one of
996 the following strings:
997
998 \begin{table}[h]
999 \begin{tabular}{l l}
1000 \sptablerule
1001 \textbf{error code} & \textbf{description} \cr
1002 \sptablerule
1003 Error&General error (not covered below) \cr
1004 AuthenticationError&Not authenticated \cr
1005 AuthorizationError&Not authorized to access the resource \cr
1006 ServiceUnavailable&Transient error (could succeed with retry) \cr
1007 UsageError&Permanent error (retry pointless) \cr
1008 MultiValuedParamNotSupported&request included multiple values for a parameter\cr
1009 &but the service only supports a single value \cr
1010 \sptablerule
1011 \end{tabular}
1012 \caption{error messages with their meaning}
1013 \end{table}
1014
1015 \section{\{async\} Responses}
1016
1017 The \{async\} resource conforms to the DALI-async resource
1018 description, which means the job is a UWS job with all the
1019 job control features available. All result files are to be
1020 listed as children of the UWS results resource. The service
1021 provider is free to name each result.
1022
1023 When multiple values of input parameters are accepted,
1024 each combination of values produces one result. For
1025 example, if an \{async\} job included two CIRCLE and two BAND
1026 values, there must be four results. If a combination
1027 of input parameters does not produce a result (e.g. there is no
1028 overlap between the parameter values and data extent), the job results
1029 must contain a result entry that indicates this. This should be
1030 a result URL which returns a text/plain document with a message
1031 starting with one of the error labels in Section~\ref{sec:error-codes}
1032 above.
1033
1034
1035 \section{Changes from Previous Versions}
1036
1037 \subsection{Changes from PR-SODA-20160429}
1038 \begin{itemize}
1039 \item Make multiple values for all parameters optional in both {sync} and
1040 {async} requests and introduce a specific error message if multiplicity of
1041 a parameter is not supported.
1042 \item Added section introducing the different usage scenarios for SODA
1043 and how they can interact with other DAL capabilities. Moved the bulk of
1044 the normative text to an integration section so that it follows the
1045 primary specification of SODA resources and parameters.
1046 \item re-organised so that UCDs for parameters are only specified once
1047 in the section on three-factor semantics.
1048 \item Added CIRCLE AND POLYGON ``double array'' parameters. POS is
1049 retained for consistency with SIA-2.0 query.
1050 \item Interval xtype as strict arraysize=2 array consistently with DALI 1.1
1051 \item SODA autodescription is postponed to version 1.1.
1052 \end{itemize}
1053
1054 \subsection{Changes from WD-SODA-1.0-20151212}
1055 \begin{itemize}
1056 \item POS is now unitless
1057 \item Aligned parameter UCDs with what is in ObsCore
1058 \item Removed gratuitous xtypes.
1059 \end{itemize}
1060
1061 \subsection{Changes from WD-SODA-1.0-20151120}
1062
1063 Change the name of the protocol. Suppression of SELECT and COORD. xtype description are in DALI. Reference to this has been added.
1064
1065 \subsection{Changes from WD-AccessData-1.0-20151021}
1066
1067 Added general introduction on PARAMETER description to
1068 section 3. Modified SELECT and COORD sections in order to
1069 detach them from SimDal. Added Appendix on xtype description
1070 with BNF syntax.
1071
1072 \subsection{Changes from WD-AccessData-1.0-20140730}
1073
1074 \begin{itemize}
1075 \item Removed REQUEST parameter since the DAL-WG decision to not
1076 include it when there is only one value.
1077
1078 \item Clarified that ID and filtering parameters are single
1079 valued for \{sync\} and multi-valued for \{async\}, wth POL
1080 being multi-valued but still being treated as a single
1081 filter.
1082 \end{itemize}
1083
1084 \subsection{Changes from WD-AccessData-1.0-20140312}
1085
1086 This is the initial document version.
1087
1088 \bibliography{ivoatex/ivoabib}
1089
1090 \end{document}

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26