[SEMANTICS] Simulation Categories and Standard Vocab words

[Miguel Cerviño]

Dear Laurie, and all

About your previous e-mail, I agree with you in most items :),  
however I have some comments:


About the use of the "meta" atom to define the UDCs for theory for  
the first four items:

1 - Name of the code
2 - Name of the developer / team / contact
3 - Version of the code
4 - Description of the code (ASCII text)

there has been a discussion in ucd-sci mailling list that would be  
interesting:
http://www.ivoa.net/forum/ucd-sci/0607/0133.htm

Anycase, about the use of meta.name vs. meta.id to describe the "name  
of the code" I think that meta.id makes a better job, since some  
times a code is identified not by its name, but by a reference  
(example: Bruzual & Charlot 1991 code is called GRISEL, but almost  
nobody knows it!) So, meta.id can be either the name of the code (if  
any) or a reference to a paper or web page that identifies the code.

About the use of meta.curation for describe the  "name of developer  
team", I am not sure to be a good solution: currently I am  
implementing a VO service with synthesis models
(in agreement with several groups of model developers). In this  
situation I would we the responsable of the curation of the database,  
but I am not the developer of the models
included in the service (this description should be in the provenance  
field of the VOTable, but not necessarelly in a service registry)
I think that meta.curation has a very specific role in the VO. so,  
many be, the name of developer would be described better by   
"meta.ref". It also includes "meta.ref.url" for possible www pages of  
the developer, that would be different than the group that put the  
results in the VO, (may this solution would be useful for the  
additional items included in Franck's mail: 12 Web Adress and 13  
Provenance)



About the distinction between "physics" and "process", I think that   
Laurie'ssuggestion about keep two different categories for physics  
and process is quite good. And it helps to describe stellar  
population synthesis-like codes. However, I would be a bit more  
specific for some process like:

process.evolution.spectrophotometric
process.evolution.chemical

However, I do not find place for an UCD for the Star Formation  
History or the Initial Mass Function (phys.SFH, phys.IMF?) as  
example. Any suggestion?


> 7 - Algorithm

Just a coment: Fuel Consumption theorem is a recipe (as well as  
isochrone synthesis) to perform the isochrone integration (a exchange  
of variable from mass in isochrones to time in tracks for fast  
evolutionary phases). Any case, it is not relevant now and I think that
comp.algorithm without more detail is enough for population synthesis...


> Code language and .parallelism.
> ---

I totally agree about the "protocol" atom. It would be also useful  
for the Web&Grid service
group. Anyone knows how they would handle the possible Grid services?

About the language.... It is really needed? I mean, it is an useful  
information for VO
or it would define a code? I think that language aspects would be  
relevant for
interop, but any case it should be used when in the registry of the  
service, not in
the VOTable with the results of the code. May be I am wrong....


> Single or Multiple Entries in each Category
> ----
>
> I think that we should not place limits on any of the categories  
> (except
> for maybe Version and Time Evolution) to just one entry.  Could cause
> problems down the road as simulations get more and more powerful in  
> size
> and especially scope.

I also agree. Multiple entries are needed for example for synthesis  
codes (that use
the results of other codes like atmosphere libraries and evolutionary  
tracks) of
SED fitting tools (that would use different synthesis models). Also  
it is useful for
the description of pipeline process, isn't it?


cheers

	Miguel