Spectra DM for theoretical spectra?

[Gerard]

Hi Carlos 
> 
> So nice that you give an example! thanks for it :-)
> 
> And no, it doesn't seem difficult.
> 
> The problem here is that there is not a way to know, a 
> priori, if the first parameter of simulator1 has the same 
> meaning or a completely different one than the first 
> parameter of simulator2.
> 
> (That's not a problem of SimDB, I have it too in S3, for instance)
> 
> You can do that mach using the same <label>s pointing to some 
> existing vocabulary using it as a reference. Actually that 
> vocabulary seems to be what is needed wether or not it is 
> used from inside SimDB or some other way.
> 
> (and I'm sorry if I'm using the word "vocabulary" in a loosy way ;)
> 
I agree. These vocabularies are for now required to infer whether two
parameters (may) in two different models
have the same meaning. To be completely sure they mean the saem one will
have to read the descriptions of the two models, but at least having a
common vocabulary allows one to find two codes that have a parameter whose
meaning is declared to be the same.

Eventually, IF we can create more complex models (ore possibly ontologies)
Utype might be used for this.
But for now in SimDB we assume the existence of a semantic vocabulary, even
more precisely, one expressed in SKOS (following the recommendations of the
Semantics WG).

Anyway, instead of creating a new data model for each model that people wish
to support, we could first try to describe them as instances of the
SimDB:Protocol.
And to describe actual experiments with their results we can do the same.
This would in fact be VERY USEFUL as a validation of the model and as input
(to Franck LePetit!) on contents for the semantic vocabulary we need.

Cheers

Gerard



> 
> On Wed, 3 Jun 2009, Gerard wrote:
> 
> > Hi Carlos
> >
> >>
> >> I think that there is a minimum set given by:
> >>
> >> Teff: effective temperature of the star
> >> Logg: logarithm of the gravity
> >> Metallicity (for some authors this is the fraction of elements 
> >> heavier than Hidrogen and for other it is something 
> different, I can 
> >> ask for a better definition to some real astronomer :-)
> >>
> >> Some models need more parameters, but this would be a nice start 
> >> (those are the ones that I use for most of the services that I'm 
> >> using).
> >>
> >> In any case, I'm going to do a better list and I send it to you
> >>
> >> Maybe other people need other parameters... for instance, recently 
> >> some people from a group in France emailed me asking for a 
> data model 
> >> to describe their theoretical spectra in the VO and they 
> sent me some 
> >> quite complicated examples of what they were doing, I'll 
> ask them too
> >>
> >> (by the way, I would wish to keep this list simple, 
> containing only 
> >> those parameters so important that "nothing can be done without 
> >> them", and then having the usual discussion on how that 
> list can be 
> >> extended or not and if something sofisticated is needed for the 
> >> general case)
> >>
> >
> > All of this can be modelled in SimDB, using the 
> SimDB:InputParameter 
> > and SimDB:ParameterSetting classes.
> >
> > In XML you could describe this somewhat like the following 
> (and let's 
> > not argue about the term <simulator> which you might prefer to be 
> > <model> or who knows what)
> >
> > First you describe your simulation code (model code):
> >
> > <simulator>
> > <name>My favorite stellar model</name> ...
> > <inputParameter>
> > <name>Teff</name>
> > <description>effective temperature of the star</description> 
> > <label>Some term from a semantic vocabulary that allows one to 
> > indicate physical concepts and observables.</label> 
> </inputParameter>
> >
> > <inputParameter>
> > <name>Logg</name>
> > <description>logarithm of the gravity</description> 
> <label>Some other 
> > term from a semantic vocabulary that allows one to indicate 
> physical 
> > concepts and observables.</label> </inputParameter>
> >
> > <inputParameter>
> > <name>Metallicity</name>
> > <description>fraction of elements heavier than Hidrogen 
> </description> 
> > <label>Some other term from a semantic vocabulary that 
> allows one to 
> > indicate physical concepts and observables.</label> 
> </inputParameter>
> >
> > </simulator>
> >
> > This has to be defined only once, and now all runs 
> (models?) can refer 
> > to this code and list parameter settings:
> >
> > <simulation>
> >  <simulator>My favorite stellar model</simulator>  
> <parameterSetting>
> >    <parameter>Teff</parameter>
> >    <value>1234</value>
> >  </parameterSetting>
> > ...
> > </simulation>
> >
> >
> > Now one may argue that this is not as explicit as for example
> >
> > <MyFavoriteModel>
> > <Teff>1234</Teff>
> > <Logg>1</Logg>
> > </MyFavoriteModel>
> >
> >
> > But that model ONLY works for MyFavoriteModel, whereas the 
> SimDB version
> > works for all models that have input parameters.
> > Moreover, the simulation code itself is explicitly 
> described in the model
> > itself.
> > I don't think this is very difficult?
> >
> > It may be possible for a selected sub discipline to define 
> an explicit set
> > of parameters for which "nothing
> > can be done without them". Possbily stellar atmospheres, 
> evolution. These
> > were actually singled out in last year's EuroVO DCA theory 
> workshop and it
> > was suggested that they get together and try to define this 
> kind of explicit
> > models.
> > There was interest amongst participating scientists to 
> contribute to such an
> > effort. I can give names and email addresses if this is of interest.
> >
> > But note that this group is not defined because they 
> produce synthetic
> > spectra.
> > But because they use similar types of models (or SimDB:Protocols in
> > SimDB-speak).
> >
> > For example people producing galaxy spectra will have a 
> different opinion
> > about what input parametesr they can not do without.
> >
> >
> >
> >
> > Gerard
> >
> >
> >
> >
>