UCD problem in SSA/SpectrumDM

[Douglas Tody]

Hi -

I am in meetings and have not been able to read all this email or
Bruno's report but will try to catch up this weekend.  Some quick
comments:

On Fri, 4 Dec 2009, Petr Skoda wrote:
> But they simply do not understand the goals and structure of the protocols. 
> They do not see examples understandable to them (its not about SSA or SIAP 
> but IVOA activities in general.

Yes I think this is true - about IVOA in general.  It is a big enough
change from the previous generation that it will take some time (and
perhaps more evolution) for it to be routine.  Better examples and
demonstration applications will help a lot.  The framework itself is
not yet sufficiently fully implemented or robust.

> the SSA is often given as an example of the working standard.
> But have someone really tried to prepare the service according to what is 
> written ? Or is it just "obvious" what was meant by some statement in the SSA 
> and SDM ?

First, for something this complex (not just SSA, but the production
VO framework in general) I don't think doing it from scratch from
the technical specifications is practical for the vast majority
of users.  We need user tools and frameworks, working examples,
user documentation, and so forth.  We are just getting to the point
where these are starting to appear.

In any case, speaking of a third party implementing SSA from scratch,
this actually was done by MAST, quite successfully.  The main issue
was not SSA but (in their case) updating archival data to be more
consistent with the VO standards, in particular the Spectrum data
model.

> I am afraid that there seems to be simple the problem ot two cultures - the 
> astronomers I know and I am working with are speeaking different language 
> that the majority of VO project scientists...
>
>> I agree that having more user documentation would be very helpful
>> for something as complex as SSA, however perhaps at some point this
>> should go into a FAQ or something (a user guide is also a possibility),
>> instead of the spec itself.
>
> I suppose the statements in the standard should crystal-clear without the 
> ambiguities .... So what sense has the postponing the explanations to FAQ?

"Postpone" is not accurate, as a FAQ is a living document much more
than a formal spec, and can be updated at will.  More importantly, the
approach is essentially orthogonal to the spec, approaching things from
a completely different perspective.  A good FAQ, plus working examples,
can be enormously helpful to understand something complex.  We all
already know this as I think everyone reading this will be familar with
going straight to the FAQ to get quick answers to common questions.
For anything complex all of these (spec, reference implementations
and working examples, FAQ, q&a) are essential to support a complex
new technology for a user community.

Of course in the case of SSA improving the spec is a priority, but
we have not yet fully exploited what we have and this experience is
important to help inform a major new version.  It is essential that
a spec be accurate and clear (and stable with well timed updates),
but we are not likely to have very much impact at this point with a
few changes to the spec.  Most important is to have a half dozen or
so major spectral archives correctly and robustly interfaced to the
VO, to make it worthwhile for the client developers to update their
software and begin to fully utilize what is availabale.

 	- Doug