Spectra DM for theoretical spectra?

[Gerard]

Hi Miguel and Rick 
My view on your mails below.


Miguel wrote:
> ...
> >
> > I had heard in the interop, that if there is a DM of any quantity 
> > (like spectra) it must be used this DM, but in the case of 
> theoretical 
> > spectra I find it incomplete (there is no place where I can 
> said how 
> > the model has been computed and its inputs, that is fundamental to 
> > understand what is modeled...).
> >
> > Is there any way to take the best of both DM? How?
> > It is spectra DM mandatory for theoretical spectra or may I 
> make use 
> > of SimDB there?

Rick answered:
> 
> This exact topic came up in a discussion about 
> characterization between Gerard, Pat Dowler, Mireille Louys 
> and myself. Briefly, (from my memory) the consensus we 
> reached was that some theory data may need to be presented 
> using both models; but, which model to use would also depend 
> on the data was being accessed.
> 
> Some more information...
> 
> For clarity, I am going to use the term "synthetic 
> observations" to refer to images and spectra generated from 
> theory data or models.  
> Another common term is "virtual telescope", but I worry about 
> this phrase causing confusion with the more fundamental 
> expression "virtual observatory".
> 
> Currently, the simulation data model has two concrete classes 
> of Protocols (i.e., software): Simulators; and PostProcessor. 
> Each of these can be used (with a set of ParameterSettings) 
> to create an instance of a Simulation or PostProcessing, 
> respectively. The PostProcessor class is very generic, and is 
> intended to describe a large range of possible analysis 
> tools, such as halo finding, extractions or projections.
> 
> Now, for the exact reasons you stated above, we may wish to 
> add another type of Experiment, SyntheticObservation. The 
> results of this would not be a Snapshot, but rather an 
> SyntheticImage or SyntheticSpectra class, that could be 
> linked to an instance based on the Spectral Data Model, or a 
> future Image Data Model.
> 
>  From here, we describe from the theory perspective, how and 
> why the data was created, and what we find interesting about. 
> Also, if we wish to use a service type like SSA or SIA, we 
> have the information we need, plus a means to add theory 
> specific metadata.
> 
> Please, do not take this as the result of any kind of 
> decision. This is just my memory of another conversation 
> around a white board.
> 
> For now, the decision to be made is whether not we need these 
> classes for our initial data model. Or, can we wait, and add 
> them later. My preference is that we wait, and extend the 
> model in a later version.  
> But, this is a very important topic, and I'm glad you brought it up.
> 

During one of the theory sessions at last week's interop there was indeed a
short discussion on how to deal with theory spectra. This was part of the
discussions surrounding SimDB, SimDAP and S3 and how they are related. The
question was, should one use SimDB also for describing theoretical spectra.
The answer was "no, SSA+Spectrum DM deals with them".

The background for this answer lies in the history of the theory group.
SimDB (starting as SNAP) was supposed to deal with large simulations. Upon
explicit questions it had been repeatedly stated by those interested in
theory spectra that SSA, by incorporating TSAP (=theory spectra access
protocol) was sufficient for theory spectra. 
But new requirements may force us to reconsider this, and Miguel's is a good
example: what to do if one would like to describe one's theory (synthetic)
spectra, but finds the spectrum DM insufficient?

Recently we have discussed making space in SimDB (and since last week
SimDAP) for other types of simulations, those falling under S3, sometimes
called "micro(physics) simulations", or models, or .... 
>From the point of view of the SimDB data model this seems to be possible
without too many adjustments. 
As Rick argues we might introduce appropriate subclasses for SimDB:Protocol
and SimDB:Experiment (approximate UTYPE notation). We may need corresponding
generalisation of SimDB:Snapshot (which we had discussed already).

In the context of the merging of SimDAP and S3 and their relation to SimDB I
guess we SHOULD consider adding such classes if required. Whether
SyntheticObservation is the appropriate class I don't know, depends on the
nature of the code producing the SyntheticImage and/or SyntheticSpectrum
etc.

Even if we do this, I don't think that necessarily means that this replaces
the use of SSA/Spectrum Data Model ofr synthetic spectra. Nor that one MUST
make a choice between an SSA or SimDAP/S3 protocol. One could implement
both. In a SimDB SSA might be a type of WebService that provides access to
registered synthetic spectra together with the other types.


Cheers

Gerard