<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1379470901;
mso-list-template-ids:1497300260;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1776292285;
mso-list-template-ids:-1949529360;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-AU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">We are in the process of testing out our new cut-out functionality for CASDA at the moment, so we have been looking closely at interacting
with this service. Our cut-out service is intended to be SODA compliant (it is currently based on the old AccessData spec).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Parameter ranges are really useful, and one of our early testing tools was a page which has RA/Dec entry fields that default to the
centre of the image cube to be processed. However to me aggregate ranges seem a lot less useful, e.g. a range covering three cubes with narrow spectral ranges that are widely spaced from each other will leave plenty of room for empty result sets. The reference
values for a data product are in the ObsTAP/SIA2 response and I’d not like to duplicate them elsewhere. Thus I’m in favour of the current draft text over Markus’ suggestion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Note: This is based on the assumption that a client app would have to be ObsTAP/SIA2 aware to use SODA.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Perhaps table 2 could be expanded to list the ObsCore fields that define the range for the parameter, or those could be included in
the parameter’s subsection?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">One related observation – in sections 2.6.1 and 3.2.2, BAND has a UCD of “em”. Should this instead be “em.wl” to provide an exact match
with the ObsCore em_min and em_max fields and be clear that it is a wavelength? This will help client apps to make the link and will guide users such as radio astronomers who work more often in frequency terms.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">James Dempsey<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> dal-bounces@ivoa.net [mailto:dal-bounces@ivoa.net]
<b>On Behalf Of </b>François Bonnarel<br>
<b>Sent:</b> Friday, 8 January 2016 2:26 AM<br>
<b>To:</b> dal@ivoa.net<br>
<b>Subject:</b> Auxiliary answer to Re: SODA gripes (1): The Big One<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Dear all,<br>
In my main answer to Markus last tuesday I wrote<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> 2 ) the discussion on the solution proposed in Markus' version of the WD promise to be long. I am strongly against some of the involved features. This includes proposing a concurrent technology for describing the domains as
we have allready the description in the Obscore table. This also includes describing the data content in the DataLink response which should be agnostic to the content of the dataset to which it is relating resources. I will develop this in another email
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal">I am proceeding to this development here. Sorry to be long, but this is a major discussion.<br>
Cheers<br>
François<br>
<br>
A ) The upcoming new protocols (DataLink as well as ObsTAP or SIAV2 and SODA) are independant but they are part of the same scheme. They could have been merged in a single protocol. Modularity allow some flexibility but imposes some precautions in order not
to diverge and create unconsistencies.<br>
<br>
B ) SODA standard Parameters (as well as SIAV2.0 PARAMETERS of which they are a sublist) are consistent with Obscore model fields.<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
ID is related to obs_publisher_did<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
POS is related to s_region<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
BAND is related to em_min and em_max<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
TIME is related to t_min and t_max<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
and POL is related to pol_states <o:p></o:p></li></ul>
<p class="MsoNormal"> The input PARAMETER domain valid for each dataset is exactly given by a combination of these Obscore table FIELDS. Let's detail this<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
s_region gives the spatial support of the dataset as an STC AStroCoord Area (could be a POLYGON, a CIRCLE, a 2D-INTERVAL (or RANGE), etc ...). Any valid value of the SODA POS parameter for a given dataset should be a region included in the region specified
by s_region value.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
em_min and em_max give the bounds of the dataset on the spectral axis. This is exactly the valid domain for a given dataset of the SODA BAND parameter.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
t_min and t_max give the bounds of the data set on the time axis. This is exactly the valid domain for a given dataset of the SODA TIME parameter.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
pol_states gives the list of polarization states present in a dataset. This is exactly the valid list of polarization states in which the SODA POL parameter can select.
<o:p></o:p></li></ul>
<p class="MsoNormal">C ) the {link} resource of the DataLink spec is working like a glue between datasets and additional resources such as fixed links or services applied on a given dataset. It contains external descriptions of the links and resources, and
of services input PARAMETERS. It should not contain description of the dataset themselves which is the work of discovery services or accessData or server side processing WEB services ( as SODA is intended to be), in order to avoid confusion between the role
of each module in the whole DAL scheme.<br>
<br>
D) As the consequency of the opinions exposed above I have severe concerns with Markus approach of the input PARAMETER domain metadata issue (see
<a href="http://docs.g-vo.org/SODA-r3192.pdf">http://docs.g-vo.org/SODA-r3192.pdf</a> ,section 6 for his views and compare with the same section in the editor WD).
<br>
I propose a mechanism which I think is more consistent with what we allready have and the general DAL architecture. However I don't wnat to push it now in the WD and in the spec, because I Think we have time to discuss these matters until the next version of
SODA, SIAV2 and DataLink. In my first email I tried to convince you that we allready have, without that "domain metadata" feature a workable spec to fulfill the basic CSP spec.
<br>
The solution is based on the inclusion of "ref" attributes in the service descriptor PARAMETER elements for all the standard input PARAMETERS. ref to the appropriate Obscore FIELD/PARAMETER or GROUP of FIELDS/PARAMETERS. This can be done in the discovery
service response, or in the response given by the SODA service queried with the unique ID="dataset_id" constraint. Let's see how it can work with examples in E and F.<br>
<br>
E ) Example with the SODA service descriptor in the sia2 discovery response<br>
<br>
Query example<br>
<a href="http://dalservices.ivoa.net/sia2/query?POS=CIRCLE">http://dalservices.ivoa.net/sia2/query?POS=CIRCLE</a> 2.8425 74.4846 0.1 &BAND=0.0002&BAND=0.00006&COLLECTION=IRAS-IRIS<br>
<br>
excerpt of query example response<br>
<br>
<?xml version="1.0" encoding="UTF-8" ?><br>
<VOTABLE version="1.2" xmlns:xsi = <a href="http://www.w3.org/2001/XMLSchema-instance">
"http://www.w3.org/2001/XMLSchema-instance"</a> xsi:noNamespaceSchemaLocation = "xmlns:<a href="http://www.ivoa.net/xml/VOTable-1.2.xsd">http://www.ivoa.net/xml/VOTable-1.2.xsd</a>" >
<br>
<RESOURCE type="meta" utype="adhoc:service" name="this"><br>
<PARAM name="standardID" datatype="char" arraysize="*" value="ivo://ivoa.net/std/SODA#sync-1.0" /><br>
<PARAM name="accessURL" datatype="char" arraysize="*" value=<a href="http://example.com/SODA/sync">"http://example.com/SODA/sync"</a> /><br>
<GROUP name="inputParams"><br>
<PARAM name="ID" ucd="meta.id" datatype="char" arraysize="*" xtype="ivoident" ref="pdid" /><br>
<PARAM name="POS" ucd="pos" unit="deg" datatype="char" arraysize="*" xtype="polygon" ref="sreg" /><br>
<PARAM name="BAND" ucd="em" unit="m" datatype="double" arraysize="*" xtype="interval" ref="sbound" /><br>
<PARAM name="TIME" ucd="time" unit="d" datatype="double" arraysize="*" xtype="interval" ref="tbound"/><br>
<PARAM name="POL" ucd="pol" datatype="char" arraysize="*" xtype="Stokes" ref="pstates" /><br>
</GROUP><br>
</RESOURCE> <br>
<RESOURCE type="results”><br>
<INFO name="QUERY_STATUS" value="OK"/><br>
<TABLE><br>
<GROUP ID="tbound"><br>
<FIELDref ref="tmin"/><br>
<FIELDref ref="tmax"/><br>
</GROUP> <br>
<GROUP ID="sbounds"><br>
<FIELDref ref="smin"/><br>
<FIELDref ref="smax"/><br>
</GROUP> <br>
<FIELD name="dataproduct_type" ucd="meta.id" datatype="char"utype="obscore:ObsDataSet.dataProductType" arraysize="*" /><br>
<FIELD name="calib_level" ucd="meta.code;obs.calib" datatype="int" utype="obscore:ObsDataSet.calibLevel" /><br>
<FIELD name="obs_collection" datatype="char" ucd="meta.id" utype="obscore:DataID.Collection" arraysize="*" />
<br>
<FIELD name="obs_id" ucd="meta.id" datatype="char" utype="obscore:DataID.observationID" arraysize="*" /><br>
<FIELD ID ="pdid" name="obs_publisher_did" ucd="meta.ref.url;meta.curation" datatype="char" utype="obscore:Curation.PublisherDID" arraysize="*" /><br>
.......................... (removed fields)<br>
<FIELD ID="sreg" name="s_region" datatype="char" ucd="phys.angArea;obs" utype="obscore:Char.SpatialAxis.Coverage.Support.Area" arraysize="*" unit="deg" /><br>
..... (removed fields)<br>
<FIELD ID="tmin" name="t_min" datatype="double" ucd="time.start;obs.exposure" utype="obscore:Char.TimeAxis.Coverage.Bounds.Limits.StartTime" unit="s" /><br>
<FIELD ID="tmax" name="t_max" datatype="double" ucd="time.end;obs.exposure" utype="obscore:Char.TimeAxis.Coverage.Bounds.Limits.StopTime" unit="s" /> ......... (removed fields)<br>
<FIELD ID="smin" name="em_min" datatype="double" ucd="em.wl;stat.min" utype=" obscore: Char.SpectralAxis.Coverage.Bounds.Limits. LoLimit " unit="m" />
<br>
<FIELD ID="smax" name="em_max" datatype="double" ucd="em.wl;stat.max" utype="obscore:Char.SpectralAxis.Coverage.Bounds.Limits.HiLimit" unit="m" /><br>
..................(removed fields)<br>
<FIELD name="instrument_name" ucd="meta.id;instr" datatype="char" arraysize="*" utype="obscore:Provenance.ObsConfig.instrument.name" /><br>
<br>
<DATA><br>
<TABLEDATA><br>
<TR><br>
<TD>cube</TD><br>
<TD>1</TD><br>
<TD>IRAS-IRIS</TD><br>
<TD>I422B2H0</TD><br>
<TD>ivo://cds.u-strasbg.fr/IRAS-IRIS/25MU/I422B2H0</TD><br>
<TD><![CDATA[<a href="http://aladix.u-strasbg.fr/cgi-bin/nph-Aladin++dev.cgi?out=image&position=0.000000+80.000000&field=I422B2H0&survey=IRAS-IRIS&color=25MU&mode=view">http://aladix.u-strasbg.fr/cgi-bin/nph-Aladin++dev.cgi?out=image&position=0.000000+80.000000&field=I422B2H0&survey=IRAS-IRIS&color=25MU&mode=view</a>]]></TD><br>
<TD>image/fits</TD><br>
<TD>1600</TD><br>
<TD>I422B2H0</TD><br>
<TD>0.000000 </TD><br>
<TD>80.000000 </TD><br>
<TD>0.5</TD><br>
<TD>POLYGON 30.0 200.0 32.0 200.0 32.0 198.0 30.0 198.0</TD><br>
<TD></TD><br>
<TD></TD><br>
<TD></TD><br>
<TD>1000</TD><br>
<TD>1.0</TD><br>
<TD>0.20</TD><br>
<TD>0.22</TD><br>
<TD>5.0</TD><br>
<TD></TD><br>
<TD>StokesQ,StokesU,StokesV</TD><br>
<TD>IRAS-IRIS</TD><br>
<TD></TD><br>
</TR> <br>
...........................<br>
<br>
<br>
F ) Example with the SODA service descriptor in the SODA response <br>
<br>
Query example to the soda service (with unique ID=.... filled parameter)<br>
<a href="http://dalservices.ivoa.net/soda?ID=">http://dalservices.ivoa.net/soda?ID=</a>"ivo://cds/IRAS-IRIS/25MU?...."<br>
<br>
The response will be the PARAM description with Domain metadata "à la" Obscore<br>
<?xml version="1.0" encoding="UTF-8" ?><br>
<VOTABLE version="1.2" xmlns:xsi = <a href="http://www.w3.org/2001/XMLSchema-instance">
"http://www.w3.org/2001/XMLSchema-instance"</a> xsi:noNamespaceSchemaLocation = "xmlns:<a href="http://www.ivoa.net/xml/VOTable-1.2.xsd">http://www.ivoa.net/xml/VOTable-1.2.xsd</a>" >
<br>
<RESOURCE type="meta" utype="adhoc:service" name="this"><br>
<PARAM name="standardID" datatype="char" arraysize="*" value="ivo://ivoa.net/std/SODA#sync-1.0" /><br>
<PARAM name="accessURL" datatype="char" arraysize="*" value=<a href="http://example.com/SODA/sync">"http://example.com/SODA/sync"</a> /><br>
<GROUP name="inputParams"><br>
<PARAM name="ID" ucd="meta.id" datatype="char" arraysize="*" xtype="ivoident" value="ivo://cds/IRAS-IRIS/25MU?...." /><br>
<PARAM name="POS" ucd="pos" unit="deg" datatype="char" arraysize="*" xtype="polygon" ref="sreg" />
<br>
<PARAM name="BAND" ucd="em" unit="m" datatype="double" arraysize="*" xtype="interval" ref="sbound" /><br>
<PARAM name="TIME" ucd="time" unit="d" datatype="double" arraysize="*" xtype="interval" ref="tbound"/><br>
<PARAM name="POL" ucd="pol" datatype="char" arraysize="*" xtype="Stokes" ref="pstates" /><br>
</GROUP><br>
<GROUP name="DomainMetadata"><br>
<GROUP ID="tbounds"><br>
<FIELDref ref="tmin"/><br>
<FIELDref ref="tmax"/><br>
</GROUP> <br>
<GROUP ID="sbounds"><br>
<FIELDref ref="smin"/><br>
<FIELDref ref="smax"/><br>
</GROUP> <br>
<PARAM ID="sreg" name="s_region" datatype="char" ucd="phys.angArea;obs" utype="obscore:Char.SpatialAxis.Coverage.Support.Area" arraysize="*" unit="deg" value="POLYGON 30.0 200.0 32.0 200.0 32.0 198.0 30.0 198.0"/><br>
<PARAM ID="tmin" name="t_min" datatype="double" ucd="time.start;obs.exposure" utype="obscore:Char.TimeAxis.Coverage.Bounds.Limits.StartTime" unit="s" value="52300.5"/><br>
<PARAM ID="tmax" name="t_max" datatype="double" ucd="time.end;obs.exposure" utype="obscore:Char.TimeAxis.Coverage.Bounds.Limits.StopTime" unit="s" value="52300.6"/><br>
<PARAM ID="smin" name="em_min" datatype="double" ucd="em.wl;stat.min" utype=" obscore: Char.SpectralAxis.Coverage.Bounds.Limits. LoLimit " unit="m" value="0.20"/><br>
<PARAM ID="smax" name="em_max" datatype="double" ucd="em.wl;stat.max" utype="obscore:Char.SpectralAxis.Coverage.Bounds.Limits.HiLimit" unit="m" value="0.22"/><br>
<PARAM ID="pstates" name="pol_states" datatype="char" ucd="meta.code;phys.polarization" utype="obscore:Char.PolarizationAxis.stateList" arraysize="*" value="StokesQ,StokesU,StokesV"/><br>
</GROUP><br>
</RESOURCE><br>
<br>
<br>
<br>
On 05/01/2016 08:51, Markus Demleitner wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Dear Colleagues,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>On Thu, Dec 24, 2015 at 03:40:21PM +0100, François Bonnarel wrote:<o:p></o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre> This close-to-christmas email to announce that SODA1.0 (previously<o:p></o:p></pre>
<pre>known as AccessData1.0) WD has been released last monday. See :<o:p></o:p></pre>
<pre><a href="http://www.ivoa.net/documents/SODA/20151221/index.html">http://www.ivoa.net/documents/SODA/20151221/index.html</a><o:p></o:p></pre>
<pre> There has been very long discussions among authors and we made some<o:p></o:p></pre>
<pre>progress in convergence. However there is still points hardly debated. This<o:p></o:p></pre>
<pre>is my responsability of editor as well as DAL chair to provide now a version<o:p></o:p></pre>
<pre>which is regarded as insufficient according to some of us but is nonetheless<o:p></o:p></pre>
<pre>fulfilling the CSP and community basic requirements according to me.<o:p></o:p></pre>
<pre>Probably the discussion will start very soon on the DAL mailing list.<o:p></o:p></pre>
</blockquote>
<pre><o:p> </o:p></pre>
<pre>Indeed -- there are of order 10 topics on which I'd like to see<o:p></o:p></pre>
<pre>discussion on this draft (there's a list of them at the end of this<o:p></o:p></pre>
<pre>mail). <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I'd like to start with the Big One (this is probably also going to be<o:p></o:p></pre>
<pre>the longest mail in this series; please indulge me). In one<o:p></o:p></pre>
<pre>sentence, it's<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> The protocol must be written such that clients can work out what<o:p></o:p></pre>
<pre> parameter values will probably yield useful results.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>This, in my opinion, is really the make-or-break thing, i.e., what<o:p></o:p></pre>
<pre>decides whether what we write will actually be useful as a generic<o:p></o:p></pre>
<pre>access protocol, or whether it will be a source of constant annoyance<o:p></o:p></pre>
<pre>all around[1].<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>So -- even if you have only marginal interest in SODA, and even if this<o:p></o:p></pre>
<pre>is a long mail, please take a few 10s of minutes to try and make up your<o:p></o:p></pre>
<pre>mind based on the two drafts mentioned below. You'd have my blessing to<o:p></o:p></pre>
<pre>ignore the remaining SODA discussions if you are so inclined.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The premise above applied to SODA becomes: All parameters (except for<o:p></o:p></pre>
<pre>the oddball POS, which really has a special position; but I'll revisit<o:p></o:p></pre>
<pre>that in a later mail) must be fully declared by the service (including<o:p></o:p></pre>
<pre>VALUES and OPTION elements as appropriate) and be systematically<o:p></o:p></pre>
<pre>discovered for UI/API generation by the client in a SODA exchange.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I've written standards prose for that already that I think is about what<o:p></o:p></pre>
<pre>a standards document can do to mandate such practices (of course, this<o:p></o:p></pre>
<pre>is largely a matter of implementation style, which is hard to regulate).<o:p></o:p></pre>
<pre>It's been in the text in volute rev. 3192 [2]; for your convenience, I<o:p></o:p></pre>
<pre>have built the document as of that revision and put it on<o:p></o:p></pre>
<pre><a href="http://docs.g-vo.org/SODA-r3192.pdf">http://docs.g-vo.org/SODA-r3192.pdf</a>. The contentious prose starts at<o:p></o:p></pre>
<pre>page 8 -- if you'd be so kind as to read sect. 2.6 ("three-factor<o:p></o:p></pre>
<pre>semantics", 4 pages).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>You can comapare with sect. 2.6 as published (the published version is<o:p></o:p></pre>
<pre>in effect volute rev. 3200, in case you'd like to see a diff). Let me<o:p></o:p></pre>
<pre>again bambi-eye all around and ask everyone with even a remote<o:p></o:p></pre>
<pre>involvement in the cube thing to try and make up their minds and speak<o:p></o:p></pre>
<pre>up, even if this thing appears a bit complicated at first, in particular<o:p></o:p></pre>
<pre>because, in a way, it's really part of datalink and cannot be understood<o:p></o:p></pre>
<pre>without it (I've argued it should really have been part of datalink in<o:p></o:p></pre>
<pre>the first place).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>If there's anything we can do to help comprehensability, let us know,<o:p></o:p></pre>
<pre>too.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Meanwhile, allow me to once more try to argue why it is so important to<o:p></o:p></pre>
<pre>urge services to provide consistent, dataset-specific metadata and the<o:p></o:p></pre>
<pre>clients to use it in SODA.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>SODA is designed to operate on concrete datasets -- you've discovered<o:p></o:p></pre>
<pre>something that looks like it might be interesting, but you're only<o:p></o:p></pre>
<pre>interested in a small part or a particular mogrification of the dataset,<o:p></o:p></pre>
<pre>so your client gets information on the dataset and then figures out what<o:p></o:p></pre>
<pre>to do to retrieve the information relevant to you. This means that you<o:p></o:p></pre>
<pre>cannot just put in some value into a service parameter and watch what's<o:p></o:p></pre>
<pre>coming out -- you'll almost always get nothing back because the coverage<o:p></o:p></pre>
<pre>of a typical dataset is small and not easily predictable.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The "horror vacui", the dreaded moment in GUIs when an input field is<o:p></o:p></pre>
<pre>displayed and users have no idea what to put there, with SODA therefore<o:p></o:p></pre>
<pre>isn't a minor usability issue, it's a protocol killer.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>It has been put forward that clients could infer the domains of the<o:p></o:p></pre>
<pre>parameters (the "good" values) from a previous discovery query (e.g.,<o:p></o:p></pre>
<pre>from SIAv2, they'd know the spatial and spectral coverage).<o:p></o:p></pre>
<pre>Unfortunately, this line of reasoning is flawed in at least to respects:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>(1) The results of the discovery query might not be available to the<o:p></o:p></pre>
<pre>client dealing with the SODA descriptor<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>(2) This technique breaks down with the first custom parameter (is the<o:p></o:p></pre>
<pre>corresponding item in the discovered metadata? And what does the<o:p></o:p></pre>
<pre>parameter correspond to in the first place?), and that would, again, be<o:p></o:p></pre>
<pre>a killer for SODA's usefulness.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Let me dwell on both points for a little while.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ad (1). I expect the most common source for SODA descriptors will be<o:p></o:p></pre>
<pre>Obscore (and it's a CSP-official usecase in case you don't agree).<o:p></o:p></pre>
<pre>There, the access URL for cubes and other large datasets won't be the<o:p></o:p></pre>
<pre>dataset itself, because you don't want people blindly pulling several<o:p></o:p></pre>
<pre>100s of gigabytes (or just one gigabyte, really). Instead, you return a<o:p></o:p></pre>
<pre>datalink document, which contains the SODA descriptor. We at Heidelberg<o:p></o:p></pre>
<pre>already occasonally do that, the CADC has datalink documents throughout<o:p></o:p></pre>
<pre>IIRC (although I think they don't have custom SODA descriptors yet).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>To query Obscore, people typically use TAP, and their queries will<o:p></o:p></pre>
<pre>fairly typcially not be just "select * from" but very possibly rather<o:p></o:p></pre>
<pre>something like "select access_url, target_name from ivoa.obscore<o:p></o:p></pre>
<pre>join...." Hence, a client doesn't have access to the obscore metadata,<o:p></o:p></pre>
<pre>and even if it had, it might have a hard time recognising it in the<o:p></o:p></pre>
<pre>possibly wide result tuples coming back from the database.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Another scenario in which dataset metadata possibly obtained during<o:p></o:p></pre>
<pre>discovery would get lost is when sending the datalink document (URL)<o:p></o:p></pre>
<pre>through SAMP. Whether we like it or not, our users love SAMP more than<o:p></o:p></pre>
<pre>anything else we've come up with so far, and telling them SODA doesn't<o:p></o:p></pre>
<pre>play with SAMP isn't going to make SODA popular.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ad (2). The dataset operations that data providers will want to enable<o:p></o:p></pre>
<pre>through SODA are essentially endless -- rebinning, renormalisation,<o:p></o:p></pre>
<pre>format conversion, "logical" cutouts (e.g., on selected extensions<o:p></o:p></pre>
<pre>only), etc. Making SODA something that (to some extent) works with a<o:p></o:p></pre>
<pre>select set of standard parameters but fails (in the sense of: client<o:p></o:p></pre>
<pre>behaviour is unpredictable) as soon as a service needs a bit more is<o:p></o:p></pre>
<pre>going to render it almost useless, and data providers will keep doing<o:p></o:p></pre>
<pre>things through custom web pages. It's the situation we have with SSAP;<o:p></o:p></pre>
<pre>although that, as a discovery protocol, at least can limp along to some<o:p></o:p></pre>
<pre>extent. SODA, as an access protocol, wouldn't even limp.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>So, we need to say: "A well-behaved SODA client will do X any Y and<o:p></o:p></pre>
<pre>*not* ignore Z" to give data providers the confidence that independent<o:p></o:p></pre>
<pre>of the client their users choose they still see whatever operations they<o:p></o:p></pre>
<pre>consider important. That's what I've tried in rev. 3192 section 2.6.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>As an additional indication that full metadata in the SODA descriptor is<o:p></o:p></pre>
<pre>a very good idea, let me mention in passing that <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>(3) it would enable usable interfaces in stop-gap XSLT-based datalink<o:p></o:p></pre>
<pre>interfaces (as discussed in Sydney,<o:p></o:p></pre>
<pre><a href="http://wiki.ivoa.net/internal/IVOA/InteropOct2015DAL/datalink-xslt.pdf">http://wiki.ivoa.net/internal/IVOA/InteropOct2015DAL/datalink-xslt.pdf</a>)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Just so nobody can't say later I didn't warn them: Yes, this means that<o:p></o:p></pre>
<pre>the datalink document that contains the SODA descriptor has to be<o:p></o:p></pre>
<pre>tailored for each dataset. But that's really not a big deal, because<o:p></o:p></pre>
<pre>the datalink documents themselves vary with dataset (well, typically) --<o:p></o:p></pre>
<pre>previews, plots, provenance, whatever all depend on the dataset.<o:p></o:p></pre>
<pre>Dropping in the limits into the SODA descriptor in addition at least for<o:p></o:p></pre>
<pre>me hasn't been a major additional implementation burden.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>That's it for my first SODA gripe, and thanks for making it here. I<o:p></o:p></pre>
<pre>plan to have, roughly weekly, additional SODA gripes, one after the<o:p></o:p></pre>
<pre>other to allow productive discussions on each point. To give you an<o:p></o:p></pre>
<pre>idea what I have up my sleeve here's a tentative programme:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>(2) Spatial coverage discovery and the RA and DEC parameters<o:p></o:p></pre>
<pre>(3) Pixel coutouts: PIXEL_n<o:p></o:p></pre>
<pre>(4) Mandated multiplicities considered harmful<o:p></o:p></pre>
<pre>(5) Behaviour for no-ID queries? For queries with only ID?<o:p></o:p></pre>
<pre>(6) No gratuitous xtypes<o:p></o:p></pre>
<pre>(7) POS doesn't have an xtype<o:p></o:p></pre>
<pre>(8) Examples stuff: example example, and perhaps a dl-id term?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>If this sounds scary, don't worry -- this kind of thing has IMHO worked<o:p></o:p></pre>
<pre>great for datalink.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Cheers,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Markus<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>[1] Incidentally, it also coincides with my conviction that in protocol<o:p></o:p></pre>
<pre>development in the VO, we should be thinking much more than in the past<o:p></o:p></pre>
<pre>from the client perspective, even if most of the protocol developers sit<o:p></o:p></pre>
<pre>on the server side.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>[2] To get the source from the repository, use something like<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>svn co -r 3192 <a href="https://volute.g-vo.org/svn/trunk/projects/dal/SODA">https://volute.g-vo.org/svn/trunk/projects/dal/SODA</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>