draft

[Miguel Cerviño]

hello,

I agree with the coments by Bernard, in particular

>  Notice that the second ucd word "comp.code" is not mentionned in  
> the list of
> suggested UCDs at the end of the document. Two questions here:
>    * can the atom "code" be used with a meaning different from what  
> it has in
> other ucd words (meta.code) ?
>    * is not it possible to use the already existing ucd  
> "meta.software" instead?

Yes!
I think that meta.software could do a quite better job:
    - it avoid collisions with "codification" or other flags
    - it also allows to reuse the same fileds (name, parameters  
etc..) for
         VOTables describing pipe-lines (data reduction and simulations)
         that would be useful for future virtual telescopes...

> 6.2 Results Formats
>     why not adding VOTable here which was agreed after Victoria to  
> be data
> format used by theory specific services to send data products ?
>

Also agree. However, it is supposed that at the end, whatever the
data-format, it should be included in a VOTable, isn't it?
Any case, the "theoretical results" i am produced for synthesis  
models are in
ascii-VOTable.


> Finally, I have a suggestion which may be worth being discussed :
> as a goal of the present technical note is to provide clues to  
> register codes
> and simulations and if the content of the note is more or less  
> agreed in
> Moscow, would it be worth setting up a tentative "theory  
> registry" (or ask
> people managing one of the registries to implement the theory  
> extensions); the
> aim of it would be to have a testbench for trying to register existing
> simulation codes and data in the framework of the technical note  
> and for
> simulating queries aiming at locating simulation codes/data.
> May be this would have to be discussed with big projects such as VO- 
> Tech.

I aslo aggree :)
Since I will not be in moscow, here there is some comments:

At the ESA-registry there is and area for register TSAP (theoretical  
simple access protocol)
services. The problem is that there is no services registered there  
and there is no application
that uses this registry at the moment (as far as I know, VOSpec use  
their own registry)

I think that the real problem is to define the protocol to access  
theoretical data since:
a) Theoretical data usually do not make use of COOSYS (that I think,  
is mandatory in VOTables
with data)
b) The parameter space of simulations is different that the one of  
observations (mainly defined by possitions or object names)
So it is need to make a first query about the parameter space of the  
service before to make
the query over the service, and before retrieve the desired  
simulations (3 steps are involved instead two).

I do not exactly remenber, but in victoria meeting Pedro Osuna was  
going present a
version of TSAP?. Any case, I think that it would be better to define  
the access protocol
and then use this protocol for "identify" theoretical services. I  
think that it
has the additional advantage that Applications would began to  
implement this kind
of protocol even if there is no theoretical databases/workflows...  
so, once the theoretical
services will be ready, it will be not needed to wait too much time  
before theoretical
results can be accessible from VO Applications...
(it is my suggestion).


cheers

	miguel