Putting the pieces together...

[Thomas McGlynn]

Doug Tody wrote:
> (I am moving my response to this to DAL since this is mainly a discussion
> of SSA).
> 
> Hi Tom -
> 
> This is an excellent way of looking at the problem of how we actually
> use the VO in a typical data analysis scenario.  At this level we have
> three main elements:
> 
>     o	User application (VSPlot).
>     o	Registry.
>     o	DAL Service (SSA).
> 
> Most of the functionality you identify on the VO side is provided by SSA.
> This is what SSA is all about - making it possibly to write actual data
> real world analysis applications that access spectral data via the VO.
> 
> On the data modeling side the key thing here is the SSA data model.  While
> the goal is to keep this "simple" (focused only on one class of data,
> limited to 1D spectra, etc.) it also needs to be real enough to actually
> be useful, e.g., define a useful set of spectral coordinate types, flux
> vector types, deal with background, errors, and so forth.
> 
> On the DM side, we can provide something useful for actual data analysis
> given only the SSA data model.  Already though things start to emerge
> which we would like so standardize more broadly, e.g., data provenance,
> data characterization (part of what is currently called the "observation"
> data model).  This is a good way to develop things: start with something
> useful that actually works end-to-end, and as the technology develops,
> refine it to include more sophisticated standard query facilities,
> standardized component data models and metadata, etc.
>
....
Hi Doug,

I'm less concerned about the SSAP itself (other than time
it is taking to get an actual SSAP document to work with).  The SSA does
address both structures and protocols.  So I'm reasonably confident
that using the SSA I'll be able to find and extract spectral
data files from providers.  I have a good sense of the kind of
code I'm going to write in that area.


But the SSA doesn't say beans about using the spectra. What does it mean
to say that we have an SSA data model? Is that different from the
spectrum data model?  What does it mean to have any data model in terms
of the software I'm going to write?  I don't think it means that all
of the data files are in the same format.  Or does it?  Does it mean
that there is some standard software package that can read these data?
How do these quantity and measurement models fit in? Do these things mean the
the data provider has provided a suite of tools that
can access files or columns with tables?  Presumably I can <use> the
data model in some way but I don't have a clue how.

As a developer of a piece of software that's going to try to plot
spectra that 'have' the spectral data model, I need to write code that
gets information from the files.  How does the data model help me
do that?  I mean this not in some abstract sense of organizing concepts
but understanding the lines of code I might write.

I'm not suggesting that data models, UTYPEs, UCDs and all of this
aren't useful, but that the discussion of them has focused so much
on the underlying abstractions in the data, that how they
connect with and are used in VO applications is completely opaque,
at least to me.   Personally I suspect that if we had some more concrete
sense of how these data elements and structures were going to
be used we'd have a lot easier time defining what they should look like.



	Regards,
	Tom