Comparing protocols

Arnold Rots arots at cfa.harvard.edu
Sat Sep 28 12:35:48 PDT 2013


With apologies if you receive multiple copies of this message.

It occurred to me that the discussion we had yesterday on
the relative merits of SIAP, ObsTAP, and DataLink only had
moderate relevancy and lost sight of the bigger picture.

The problem is that within the IVOA people and groups have
been designing protocols that make sense within their own
context, but very little attention has been paid to the end-to--end
use case scenarios - with the emphasis on "end-to-end."

The question of how flexible or easy to use a particular interface
protocol is really needs to be assessed in the context of the full
scenario that real-life users follow.
I must admit that it is not clear to me how either ObsTAP/DataLink
or SIAP fit into the various scenarios and what their effect would be
on the the total number of steps that users have to go through in
order to get their data.
And the issue is, of course, that there is no single use case scenario.

There are users who will simply be interested in retrieving their, let's
say, ALMA observations. How easy and how many steps does it take
to get where they want to get, using the different protocols?
Then there are users who will get there through the VAO Portal.
And those who enter through Aladdin, and so on.
In how many scenarios do we envision users to start querying and
retrieving data through IVOA protocols and how well or how poorly
does that work depending on which protocol is chosen?
And how does that depend on the users' objectives?
I would like to see flow diagrams for the different cases to get a better
sense of the ramifications of choosing one protocol over another
in the context of the larger picture of the full end-to-end scenario.

Just quibbling over the relative merits of protocols in the limited
context of their own characteristics does not address the real issues.
We really need to focus on the users' perspective, minimizing
steps and increasing protocols' ability to support intuitive use.
If we don't do that, we relegate ourselves to irrelevancy.
To complicate the issue further, it is, of course, not the user-friendliness
of the protocol per se that matters. What really counts is the interface
through which the users use the protocols.
Which protocols make it easiest to develop user-friendly GUIs while
at the same time supporting those who swear by the Command Line?


Finally a comment on one of my favorite subjects: distinguishing
between the spectral and redshift/Doppler velocity axes.
None of the protocols currently supports this and that is a problem.
It means that users in their queries cannot indicate whether they
are interested in multi-band image cubes or in cubes where the
third axis is Doppler velocity, they cannot express whether they
want spectra for, say, SED or line equivalent width analysis, or
Doppler profiles.
It is going to annoy users no end if they get offered large numbers
of datasets that they are not interested in and thought they didn't
ask for.
And note that making this distinction means that it allows one to
construct hypercubes that contain Doppler velocity profiles in multiple
spectral lines.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20130928/f8f3254e/attachment-0001.html>


More information about the dal mailing list