New version of SIAV2.0 document : proposed recommandation

[Jose Enrique Ruiz]

Hi François, all
please find some comments below:

----

[Abstract]
+ "SIA provides capabilities for image discovery and *access*, but
capabilities for access are defined elsewhere."  (?!)

[1.2.1. Simple Data Discovery]
+ "find data within a range of exposure (integration) time" I guess this
requirement directly translates to searching data with flux in a specified
range. I do care about integration time only if all observations have been
made with the same instrumental set-up/sensitivity, which is not the case
in broadcasted discovery queries.

+ I can think on other requirements related to spectral radio velocity
datacubes.
"find data observed for a specific spectral line"
"find data within a specified range of velocity for a specific spectral
line"

[2. Resources]
+ In the table, what does the asterisk mean in no* ?

[2.1.2 BAND]
This is a major point.

I would use this param to search for datasets that have been *observed* in
a specific range of wavelengths. The doc states that "values used in the
BAND parameter are always assumed to (vacuum) wavelength with UNKNOWN
reference position" I have to admit that I do not fully understand this
sentence. Does it mean that I have to provide in my query *corrected from
redshift values* instead of the actual frequency values in the instrumental
set-up of the observational dataset?

If this is the case, this perfectly answers how could I search for spectral
velocity radio datacubes that have been observed for a specific emission
line (independently of its redshift) But what if I am searching for data
within a specified range of velocity for a specific spectral line?

My proposition is to keep BAND as *observed* wavelength, and add a param
for LINE, and another one for VELOCITY.


[2.1.6 SPATRES]
I just draw your attention to a particular point in radio interferometry
observations. There is an instrumental param called "Maximum Angular Scale"
that provides the maximum angular scale structure that may be recoverable,
which results in the fact the larger structures in the sky are "resolved
out" and cannot be detected. A potential use case could be to find
observations performed with a particular "Maximum Angular Scale" so we are
sure we do not miss any structure in the sky smaller that this param. I
guess this use case cannot be addressed with values for SPATRES.

[2.1.7 EXPTIME]
As I said previously, I only see this param useful in the case I'm
searching for observations that have been made with the same instrumental
set-up/sensitivity, which in general it's not the case for broadcasted
discovery queries.

[2.1.8 ID]
Do we have a use case for broadcasted discovery using obs_publisher_did?
"should this parameter override the normal case-sensitive string equality
comparison?"
I would say yes.

[COLLECTION, FACILITY, INSTRUMENT, TARGET]
I think it is important to reach an agreement on what to do wrt.
case-sensitivity and strict-equality for these string-valued params. I
personally see them more in the realm of use cases for search of services
in the registry, with the exception of target that could be translated to
coordinates by a name/coords look-up service like Sesame.


[2.1.16 SPECRP]
In spectral velocity radio datacubes, resolving power (more used in optical
wavelength observations) may have its analogue in the concept of "channel
width" usually measured (again) in units of velocity.

[2.1.18 UPLOAD]
It could be good to have an example of how to reference (from any input
param) a column in a VOTable provided by UPLOAD (I guess only tabular data
in VOTables allowed?).

[page 19]
"Note that the {query} resource does not have to be named as shown in the
accessURL(s) above; in fact, they could share the same accessURL since they
also differ in the value of the REQUEST parameter..."

Since REQUEST param has been removed, all this text should be revisioned,
and {metadata} resource declared in VOSI capabilities..


[side point: logical operators]
It is said in the doc: "The constraints from multiple values of a parameter
are combined with logical OR operator. The constraints from different
parameters are combined with a logical AND operator."

Given the number high number of params, should we start thinking (for a
future version) on a mechanism to define logical operators for the
combination of multi-valued params in multi-queries? I'm thinking on the
potential use case of working with inclusion AND operators for a list of
ranges in the POS params (overlapping in spatial dimension), for example.
Moreover, this will help to combine different multi-valued params at the
same time..

---

Cheers !




--
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618


2014-07-11 18:55 GMT+02:00 François Bonnarel <
francois.bonnarel at astro.unistra.fr>:

> Hi DAL folks,
>
>      A new version of the specification of the SIAV2 protocol, provided by
> our editors, Pat and Doug, is available there:
> http://www.ivoa.net/documents/SIA/20140707/index.html
>      The document has been upgraded to the status of proposed
> recommendation due to rather mature discussion within the group.
>      However, as there is some new material in the proposed spec ( eg new
> input parameters) we ask the group to restart its internal review for a
> period of two weeks starting from now.
>      Interop RFC period will start on Friday, July, 25th.
> Best regards
> François Bonnarel
> Marco Molinaro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140714/51ae3bf8/attachment-0001.html>