WD-AccessData-1.0-20140312

[Patrick Dowler]

Comments in-line:


On 17/03/14 01:50 AM, Markus Demleitner wrote:
 >On AccessData in principle -- is there anything that can be done
 >with the current, 18-page draft with lots of complex syntax and many,
 >many open questions that could not be done with the simple annex to

OK, that's the first time  heard an 18-page IVOA spec called complex :-)

Yes, there are open questions but they are all fairly straightforward. 
They are all details we didn't get to in Hawaii that show up after you 
write the draft.

> On Thu, Mar 13, 2014 at 03:54:09PM -0700, Patrick Dowler wrote:
>>
>>
>> On 13/03/14 03:31 PM, Petr Skoda wrote:
>>> the biggest mistake of SIA 1.0 is there is not primary the concept of
>>> filters built-in - I am just in troubles trying to access the multi
>>> colour survey.
>>>
>>> I do not believe the most use cases can be solved by stating
>>> wavelengths in BAND....
>
>> Or are you talking about creating a virtual R-band image out of a 3d
>> cube? If you are talking about a virtual image from a cube, the only
>> kind of access that is in scope for AccessData-1.0 is simple
>> extraction is subsets. All other kinds of operations are to be
>> considered later in 1.x
>
> I believe Petr is thinking about multi-extension files and getting
> just one extension out of this, referenced by band name.  I agree
> this is an interesting use case, as the question what the "right
> thing" to do when e.g., doing cutouts from multi-extension files is
> tricky indeed and needs to be worked out before we REC anything on
> data access services.  But the difficulty is, at least for me,
> retrieval semantics and not parameter syntax.
>
> For that, I think it's again plain we do not want to allow "either
> range or filter name" in BAND, *if* people agree on the (1)-(3) from
> http://www.ivoa.net/pipermail/dal/2014-March/006674.html (and nobody
> has disagreed).
>
> How would you define that parameter's metadata?  Are you seriously
> considering
>
> <PARAM name="BAND" datatype="char" arraysize="*" unit="m">
>    <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
>      <OPTION value="V"/><OPTION value="B"/>
> </PARAM> ?
>
> A string with a unit, and a wavelength of V meters?  V being between
> 3e-7 and 5e-7?  Oh, horrors.  Please, please, let's not even go near
> such a thing.

Yes, that is pretty horrible and I don't know why you would think anyone 
is proposing that. There is absolutely no intent to mix numeric 
wavelength values with strings like B and V.

Now, if for some reason someone wants to propose that the parameter BAND 
is not the name we use for numeric energy range then that's fine: 
propose another name. The use cases we have to support clearly require 
that search (in SIA query) and simple cutout (in AccessData) using 
numeric energy values.

We chose BAND because that was used before, but we can chose something 
else. If we want to reserve BAND for known energy band names or somesuch 
simlair usage then we could do that. LAMBDA would not be my first choice 
for a numeric energy parameter for a variety of reasons:

- looks optical-centric and radio and high energy people scoff and go away
- in future, when we go on to allow some use of native coordinates that 
will look like a colossal amount of short-sighteness

I recall someone proposing FRAVERGY in the past... I would prefer:

BAND (numeric)
BANDNAME (string) -- not in the current versions, maybe later

> The good news is that something like this can easily be pulled off
> sanity-preservingly:
>
> <PARAM name="LAMBDA" datatype="double" unit="m" ucd="em.wl">
>    <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
> </PARAM>
> <PARAM name="LAMBDA_WIDTH" datatype="double"...>

All this does is use two parameters to perform a search when a single 
parameter with a value range will do. This just isn't in line with what 
did work from what we did before and with the trend in how apps tend to 
work. And it is just not what users ask for, if I can judge by what the 
astronomers that use our apps ask for... they want fewer boxes/params 
with a bit more power in them. That is what ranges (and geometry in POS) 
gives them and they can use them effectively.

Now, if we need to figure out how to describe a param that takes a 
numeric range, then lets figure that out... we don't have to start from 
scratch. While I agree that the descriptor needs to be sane, the 
existing syntax for describing PARAM elements in VOTable is not the 
authoritative limit.

Why not

<PARAM name="LAMBDA" datatype="double" unit="m" ucd="em.wl"
        xtype="dal:range">
     <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
</PARAM>

OK, I just pulled "dal:range" out of thin air and I'm probably abusing 
something horribly... but we have long used range-valued params so we 
need to be able to describe them. The way to describe them should go in 
DataLink, in the service descriptor section. So, how to describe them?




-- 

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

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