Putting the pieces together...

[Doug Tody]

Hi Tom -

> 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.

When you use SSA you will get back a spectrum (or SED) which conforms to the
SSA data model.  It won't matter what format the data is in so long as your
application can parse it, since all formats encode the same data object.
The data model merely defines how the spectrum is put together and what
the elements are, so that you can write software to deal with it.  It is
no different from getting a spectrum from an archive or data analysis
system now, except that more effort has done into formally documenting
the science data model of the spectrum, and the representation in terms
of some external data format.

 
> 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.

I agree, too much of the discussion has been at that level.  That is
why I thought your use case was right on the money.  We need to do some
end-to-end real world applications to get things back to reality.

	- Doug