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 Received on 2006-07-26Z20:03:32