SimDB with undefined fields?

[Rick Wagner]

Hi Miguel,

> After several talks in the interop I had began to mapping my uses  
> cases in a SimDB way, but there I found some problems. My uses  
> cases have the following in common:
>
> - Input data (and params) are not know "a priory" but supposed to  
> be obtained from other VO services
> (real VO interop ;)
>
> [Examples: Photoionization code with input continuum obtained from  
> a theoretical spectra service
>                      Single stellar population models built from  
> cluster/stellar libraries (theoretical or observational ones)
>                            and isochrones that may be available "at  
> that moment" in the VO]
>
> In this case the workflow is:
> a) client ask the service the possible parameters
> b.1) service ask the registry to look for "different" registered  
> services that are used as input in my service
> b.2) the service return the client the list of models that can be  
> build with the parameter range that
>           can be built in that moment.
> c) .... the standard protocol (whatever it means) follows
>
> It means, in my real science cases (that are the most trivial ones  
> by people I working with) I need to
> ask recursively to the registry, and only after that I can fill my  
> input parameters and other fields
> included in SimDB. The problem is that most of the fields  
> (excepting the version number of my code and
> the bibliographic references) can only filled "at the moment" the  
> user makes his/her query, but not before.
>
> Maybe I had lost something, but this kind of cases can be addressed  
> with SimDB?


This use case is probably going to take us a few iterations to make  
sure that the sequence of service operations, and the role each  
service is going to play, is clear. But first, let's review SimDAP,  
to make sure we're using the same terms. (You'll note that I'm  
referring to SimDAP, the data access protocol, not SimDB, the  
simulation data base. SimDB is for looking for searching for  
different kinds of simulations, SimDAP is for getting data. These two  
things are very related, but the problem is big enough that we broke  
it up.)

SimDAP would provide access to existing or dynamically generated  
theory data (this is in common with S3). The SimDAP operations  
include both optional standard operations (download, cutout,  
preview), and the ability to define custom operations in the service  
metadata. These operation would have the usual suite of parameters,  
such as min/max, true/false, selection, left edge/right edge, etc. A  
description of the custom operations could be found in either the  
Registry, or from the service using GetCapabilities.

 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.

 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.

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?

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.

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.

Please correct my vision of how the services interact. Also, I am  
still working on an XML Schema for us to test building service  
descriptions with.

Ciao,
Rick

-------------------------------------------------------------------
Rick Wagner, Graduate Student Researcher
San Diego Supercomputer Center
9500 Gilman Drive
La Jolla, CA  92093-0505
Email:  rwagner at physics.ucsd.edu
WWW:    http://lca.ucsd.edu/projects/rpwagner
(858) 246-0745 Phone
-------------------------------------------------------------------
Bureaucracies must be continuously fed paperwork to stay alive.

--Rick Wagner
-------------------------------------------------------------------