Spectra DM for theoretical spectra?

[bonnarel]

Let's try something Carlos...
  Give me the exact list of attributes you want to describe a theoretical
spectrum and we try to build an extension to SSA with appropriate "utypes
proposal" to describe them ...
Cheers
François
-----Message d'origine-----
De : Carlos Rodrigo Blanco [mailto:crb at laeff.inta.es] 
Envoyé : mercredi 3 juin 2009 11:34
À : Alberto Micol
Cc : theory at ivoa.net; dm at ivoa.net
Objet : Re: Spectra DM for theoretical spectra?


All right, I see that I'm getting lost about some concepts and vocabulary 
in the vosphere... I'll try to catch up.

then I understand that the characterization DM aims to describe all the 
"characteristics" of an observation (WHAT is in the observation) and the 
provenance aims to describe the origin of the observation (HOW it was 
acquired, why, who, whatever)

Then I agree that for a theoretical spectrum a (Teff,logg,metallicity) set 
is closer to be provenance that to the be characterization.

But I still don't see it IS either.

My question would be:

In SSAP an spectrum is identified by the position in sky of the 
corresponding object, that is, RA and DEC. Are they included in 
provenance? I undertand that what is included in provenance is more "the 
region of the sky that was observed by the astronomer was a rectangle with 
these four corners and it was observed this day with this instrument, 
etc". But the actual RA,DEC used by SSAP (POS parameter) are some 
coordinates associated to that spectrum and not really included in 
provenance. Am I right? (please, correct me if I'm wrong)

The point that I want to stress is that, for theoretical spectra (and, of 
course, from my point of view), the point (Teff,logg,metallicity) is the 
equivalent to (RA,DEC). They are the coordinates in some "parameter space" 
of the spectra, not (or not only) some description about how the spectrum 
was obtained.

What I see equivalent to my idea of provenance is "these theoretical 
spectra were calculated using kurucz code, calculating a grid with this 
edges and this step for each axe, considering rotation or not, considering 
the presence of a disk or not, etc".

I don't really see clearly yet if this makes a difference or not and maybe 
the provenance data model is the perfect place to consider these things.

But, in Alberto's words, I don't see (teff,logg...) as the equivalent to 
instrument/telescope, but more the equivalent to data_axes (position,time) 
for observed spectra.

Of course the problem with theoretical spectra is that the parameter space 
(the one used to identify an spectrum, the one used to search for spectra) 
is not allways the same because different developers. And that's a problem 
on its own (the one that started this conversation), either if we call it 
provenance or something else.

Carlos

  On Wed, 3 Jun 2009, Alberto Micol wrote:

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