Spectra DM for theoretical spectra?

[bonnarel]

I almost fully agree with Alberto, there.

That is if we are facing the simulated observation (simulated spectrum
Or image), the simulation experiment which gave this dataset is definitely
part of the provenance. So in the case of a simulation described according
to SimDB datamodel, the provenance of the dataset should hook a lot of
material from SimDB.

 But Alberto, where does the confusion come from with our colleagues?

In SimDB itself there is a characterization class. As Rick states it
describes distributions of values for quantities (they say properties)
Measured on ObjectCollections (part of the so called Snapshot), such as
metallicity or  RMS Mach number. Also such things as resolution which makes
some confusion also. SimDB Characterization metadata gives min/max mean,
mode or statistical moments for these distribution of values.( I did not
understand that they will describe the input parameters of the simulation as
well... )

   SO if we are facing a simulated dataset we have the following situation:
      A spectrum as  an IVOA Char + Provenance description
       This provenance provides hooks to SimDB description of the
simulation. This Description contains itself a SimDBCharacterization
description of the Simulated reality (star, particules, etc...) but is not
limited to it . 

      You may read in one of the compilation mails I sent you this morning
how the two Charac are related.
      In my opinion, development of level 4 of IVOA characterization could
fulfill the needs of SimDB (statistical). I may explain this in more
details.
Some other people (including Gerrad and Rick I suppose) prefer to derive the
two charac (IVOA one and SimDB one) from a more abstract common model

Cheers 
François
-----Message d'origine-----
De : Alberto Micol [mailto:alberto.micol at eso.org] 
Envoyé : mercredi 3 juin 2009 10:56
À : rwagner at physics.ucsd.edu
Cc : theory at ivoa.net; dm at ivoa.net
Objet : Re: Spectra DM for theoretical spectra?


Rick Wagner wrote:
> 1) What we are calling Characterization in the simulation data model, 
> is restricted to only provenance information. For example, the star 
> formation rate or RMS Mach number may be represented, and these are 
> physical properties measure from the data (in my cases).

I'd like to stress what already mentioned by Francois: the importance of 
using the correct vocabulary.
I take the example here above to illustrate the problem (sorry Rick, 
nothing against you,
yours just happens to be the last email about this, see also Carlos' 
post): in one sentence three different
concepts are used somewhat intermingled: Characterisation, Provenance, 
and measured properties.

Given that in the IVOA world (or 'vosphere' to take Sebastien's nice 
expression) both Characterisation and  Provenance DMs
already exist (one already recommended, the other being worked out), I 
would ask Theory to try to avoid any confusion
and not to use Characterisation what we are already used to call 
Provenance, etc.

I'm trying to depict the problem here, and later I'll make some 
suggestions on the vocabulary
and on a possible way to solve the issue, that is, enabling a full 
description of a theoretical spectrum.
Please bear with me... I need to clarify my terminology to get understood...

Observation flow:
Real Universe --> Observation --> Telescope --> Data/Metadata --> 
Measurements

e.g.
input: a spectrum of star is observed by a camera and from it
output: the metallicity, log g, eff. temperature are obtained/measured;


Simulation flow:
in the Theoretical World, it is conceptually reversed, the 
"Measurements" actually
become the Input parameters in a flow that looks very much reversed:

Input parameters --> Virtual Telescope --> Simulation --> Modelled Universe

e.g.
Input parameters are metallicity, log g, eff temperature
output: a modelled spectrum is obtained.


It is a reversed flow, it is like mathematically inverting a function:
   function(domain)  ->  image
   inverse function(image) -> domain

the "image" of the function called "observing"
becomes the "domain" of the function called "simulating", and viceversa.


So far, CharDM, ProvenanceDM and SpectrumDM have focused their attention 
onto the HOW,
and have intentionally avoided to describe the WHAT is observed.
It would be too difficult to describe anything that could be observed [a 
star,
a galaxy, a cluster, a cloud, a bird, a girl (try to model it! ;-) ), etc.]


Maybe some confusion raises from the fact that the WHAT
of the real world becomes the Input parameters in the Simulated World
(e.g. the eff temp, the log g, the metallicity of a star).

The distinction though is that in the Real World the WHAT is in the end 
a measurement, an
estimate of the Truth, and hence has got an associated error, while in 
the Theoretical World
the Input parameters _are_ the Truth (and error is virtually zero).
If TheoryWG comes up with a good set of models for the Input Parameters, 
please bear in mind
the above, because the same model, with some care, could be re-used to 
model the real world's WHAT!


Coming back to terminology/vocabulary:

Carlos Rodrigo Blanco wrote:
> I'm not so sure that we are talking about provenance and not 
> characterization.
>
> I feel that the sentence "description of a dataset or an observation 
> in the Physical parameter space of the data" describes precisely what 
> we are talking about.
>
> The physical n-dimensional space where a theoretical spectra is 
> located is a space parametrized by some parameters as Teff, Logg, 
> metallicity, etc.
>
> when I go to the characterization data model I read:
>
> ---
> This document defines the high level metadata necessary to describe 
> the physical parameter space of observed or simulated astronomical 
> data sets, such as 2D-images, data cubes, X-ray event lists, IFU data, 
> etc..

Characterisation DM: Care was taken *not* to describe "what" was 
observed/simulated,
CharDM describes the N-dimensional space subtended by an 
observation/simulation product
specifying which part of the N-dimensional space [whose axes are the 
_data_ axes: space, time,
wavelength...] was covered, with which sampling, and which resolution, 
all at various levels of
detail (from an indicative number (location) down to finer details like 
detector sensitivy,
transmission curve, etc).


The ProvenanceDM describes the process that resulted in an 
observation/simulation
(e.g., among other things, the telescope/instrument configuration, but 
also the PI program, etc.)


Rick Wagner wrote:
> However, there are some properties, such as resolution (spatial, or 
> frequency) which are known beforehand. For this reason, there is a 
> boolean "a priori" attribute on the Characterization class. This 
> distinction may need to be made more clear, in order to align our 
> model with the Characterization Data Model.

The SpectrumDM combines a number of "How"DMs (CharDM, ProvenanceDM, 
Curation, etc.)
though it allows some little digression into the realm of "Derived 
Quantities", that is
quantities that are measured out of the described spectrum, and into the 
realm of what
the PI already knows about the target ("a priori"). For example, for 
REDSHIFT,
two different utypes and FITS keywords exist at this effect, one for the 
"a priori" knowledge
one for the "a posteriori" measured quantity).


As many have already stated I also think that the Input parameters are 
the equivalent
to the telescope/instrument settings, they are the Virtual Telescope 
settings, and
as such the word Characterisation should strongly be avoided, in favour 
of Provenance.


A possible recipe to solve the problem:

Given the multitude of simulators that create spectra (stellar 
atmospheres, galaxy clusters,
bl lacs, etc.) it is not possible to have one ProvenanceDM that covers 
them all; I think
that each of those sets of Input Parameters should be modelled separately;
then it would be nice to enable ProvenanceDM to reference anyone of them;
similary SSAP (or its subset TSAP) could easily make use of all that.
 
Sorry for the long email, but I think it is useful to clarify things
(and, viceversa, please clarify things that I might have gotten wrong)

Alberto