Dear theory group, I just want to make two comments about
previous e-mails regarding semantics and population synthesis issues
mainly.
Respecting Franck e-mail,
As far as I understand UDCs,
> - Is the item a required information or an optinal one for
> registration ?
It should used for describe the data (the model
in our case), the registration of services is
a different issue: It is not needed any UDC for a
registration! The register only provides the
possible services, but it do not carry too much about
what is inside the service (data types,
udcs, etc), but what is the protocol that you use to
access it: TSAP, SSAP, etc...
I just revised previous e-mails, and I think
that, for the moment, it will not possible to ask the
registry for a " radiative transfer code using the Ali
method" as example, as well as it is not
possible to ask to the register for a IUE spectra of
NGC 1068 taken during 1994... (the
register do not search in each VOService, only says
which VOService are aviable...)
(Any case, although the registry do not work in such a
way, the exercise will
we an interesting effort for the future, and I think
that it is interesting to build services
that would work sometime in this way)
In the other hand, UCD is a list of "concepts",
but not a list of manes! i.e.: Cloudy
whould be a "value" of a field with given UCD words.
> - Are multiple choice possible or not ?
¿what do you mean?
> - Do the values associated to the UCDs have to be choosen from a
> given list or not and if yes, from which list ?
You can find the current list of UCDs at:
http://www.ivoa.net/Documents/latest/
UCDlist.html
And the process to add UCDs in the list at (IVOA
recomendation):
http://www.ivoa.net/Documents/latest/
UCDlistMaintenance.html
However, THERE IS NO LIST of the values associated
with it: the same UCD would have
different values (that will depends at the end on
the developer of the service). The UCD
only tries to delimiter the "concept", but not its
value. Any search in UCDs aims to
look for concepts (example theory)
Note about "synthesis model" in "algorithm": I do not know exactly
were synthesis models (or an isocrhone, or an atmosphere models)
would fit
I think that may be it is good as value related with the SUBJECT:
"stars" for isochrones, and "stellar clusters" (or may be better,
"stellar populations")
for synthesis models. Any case, the types of algorithms used in
synthesis models are: Isocrone synthesis or Fuel Comsuption theorem
(that was yet included). In the other side, Monte Carlo simulations
are a "way" to use the algorithm. (Althought Monte Carlo simulations
has their own meaning as a particular algorithm).
Any case, from the UCD point of view, there will be no problem, since
the algorimth is a posterior characterzation of the main class, subject.
>
> Apart these modifications we see several difficulties up to now :
> 1 - for the algorithms, the list may become very very long and so
> unusable for an efficient search in the registries. A solution has
> to be find...
>
I think that the final goal is not to include all the "algorithms" as UDCs words. The idea of the list would be better understood as a list
of possible values where we must try to classify in a few classes of concepts (that will be the final UCD)
> 2 - Bernard Debray mentionned a very nice problem adding to the
> twiki page "Stellar synthesis Populations" in "physical processes".
> This is neither a "physical process", nor an "algorithm", nor a
> "subject". But that is the way everybody call such codes.
I think that whatever people would cal it,
correct or incorrectly, the issue here is how a "machine" will
recognize it ;)
No human will examine the register, but
machines... The important point (that is a different issue) is how a
machine
translate the human words (natural language)
to the VOServices, etc...
Maybe it is ussefull to visit the UCD builder
at ADS to understand the point:
http://cdsweb.u-strasbg.fr/UCD/cgi-bin/
descr2ucd
> Should not we add a new item "Category of code" to cover large
> domains of codes with a finite list of possibilities as :
I completely aggre, I think that it is just
the things we need now: to find class of concepts this case, the UCD
will be
"category of code" and the list below, the
possible values
(an important note: In the list, some
developer would give a value of the category "hydrodynamic" and
other, "hydrodynamic simulation" of
"simulación hidrodinámica", and I think that IVOA do not care about
these issues...,
but I am not completely sure)
> - Large structures formation
> - Hydrodynamic
> - MHD
> - Stellar synthesis populations
> - PDR
> - Numerical Relativity
> - Radiative transfer
> - ...
>
> In some cases, the value associated could be the same as in
> "physical processes" but not always as for "stellar population
> 3 - The item "Result parameters" seems unuseful for the
> registration of codes. It may be useful for the registration of
> simulation results but it is completly linked to the datamodel
> describing the simulation results. So I suggest to forget it for
> the moment.
I agree, but before to register a code, I think that is more important to define what the code do!
What is the goal? include codes in the register that only the code developers will use? define the data model? or try to define both at the same
time, given that they are intrinsically related?
(by the way, I just included an item called "output",
with subitems like photometric evolution, spectral energy
distribution or luminosity distribution function...
I think we have forgot that most of possible search will be done looking for the final result!, may be it was some way included in the other items, but
not explicitly)
>
> 4 - I added a new item "Description" where it would be possible
> to add an ASCII text describing the code. This exist yet in the
> registration of any VO service in the present registries. I do not
> know if the registries will allow to search by words in such
> description. Does anybody know if we plan to have in the VO a tool
> as "spotlight" in the Mac OS X which is able to find any document
> when we give it a few words contained in this document ?
>
In the VOTable definition, there is a FIELD called DESCRIPTION for this propose. However, I think that you refer to an "human readable" text more
suitable for publications, isn't it?
After Victoria meeting I was wondering a bout a
similar issue, but more focused in have some "latex ready tex" that
can be directly cut&paste
in scientific production. In particular, it is also related with "credits" and it also affects the modification of VOtables by any application. I think that
the issue is in fact to define a field that should be "human redeable". In UCDs, there is the word "meta", and I have seen in any VOTable someting
like "meta.human". Any case, completely agree with the point, although I would prefer to include in such UCD a detailed scientific descriptions, that
means, also references.
Any case it is intimately connected with the
Application group: At the end, users will not look inside VOTables,
but they will use applications to work
with them, so any attempt in this direction will have no result if we are not coordinate with the App. group...
Cheers
Miguel Received on 2006-06-20Z10:32:18