SimDB with undefined fields?
mcs at iaa.es
Tue Jun 2 01:44:02 PDT 2009
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
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
> 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 :)
More information about the theory