SimDB with undefined fields?

[Miguel Cerviño]

Hi Rick,

thanks for the answer.

> From what I understand of your description above, this would be  
> sufficient for publishing a set of isochrones, or for running a PDR  
> code such as Franck's. It would even work for defining a service  
> that takes a remote URL as input data, provided the receiving  
> service understood the data.

I think that it should work, I mean, It would more correct "define a  
service that takes input data and parameters from a remote URL", but   
it is equivalent to say that that the input params are obtained from  
the result of a query to a URL, and so the the "value" of the input  
data is "the result of the query to the URL". Is it?


> From here, please, help me out. How many services, or servers are  
> you picturing? From your list above, I see three:
>
> Service A:
>  Publishes a set of isochones. These could be found using one of the  
> List operations from SimDAP, or a predefined query on some  
> characterizations.
>

yes, but the service can be also a protocol itself (there are service  
that provides isochrones "on the fly"
(like CMD by Girardi et all at http://stev.oapd.inaf.it/cgi-bin/cmd  )


> Service B:
>  Provides access to a model. May I call this a Protocol, or a  
> Simulator? Is this some software that takes some input parameters  
> and creates data?

Yes, In fact it is completely similar to Service A except in the  
physical results: it can be static or dynamic (a common example a  
library of stellar spectra composed by observed stars mixed up with  
theoretical spectra)

> Service C:
>  Searches for services like A and B, and presents their search  
> parameters to the user, and then passes Service A's data to Service  
> B, and then Service B's results back to the user.

No, the one I thinking about Service C search for services A and B,  
analice how service A and B can be combined and show the possible  
"physical" combinations  to the user  (i.e. include their expertise  
and science in
the service ;)). And then ask service A and service B data and creates  
new data from it (e.j. the SED of a cluster
in a Dirac's Delta mode of star formation)


Any case, also for cosmological simulations (I think Milenium  
simulations include it) it is also interesting a Service D that would  
include star formation histories (i.e. combine the results from  
service C). This service D would make extensive use of service C (and  
implicitly of service A and B, but not directly)


> If I have this description correct, SimDAP could come in when  
> interacting with Service A and Service B. A dynamic interface, such  
> as S3, could be used for Service C. But, while this is very useful  
> for generating simplified step-by-step interactions with the  
> service, it is very hard to describe the specifics in the service  
> metadata. In fact, there is nothing particular to theory data in S3.  
> It could be used for any kind of custom, self-describing service.

Yes, I completely agree that S3 concept is by far more general (and so  
powerful ;). It is here because theory
data fits in the protocol (but not only theory data, I agree). But it  
is a different discussion.
I think that  the points here are:

a) As you point out, to have a XML schema for us to test building  
service descriptor with.
b) the mapping of these descriptors in a datamodel


I hope that I had described the workflow correctly now :)

cheers

m