| |
| META TOPICPARENT |
name="IVOATheorySimulationDatamodel" |
Page with discussion items about the SNAP data model
Some questions (in bold) with their motivation and current answer (as of the last edit of the page):
- Does TargetObjectType belong in the model?
- I believe yes, but that it should be a fuzzy description of the stated goal of the experiment, not a full, exact characterisation (see below) of the actual accomplished target. The real Target Object at "Level N" often requires analysis to produce "Level N+1" results that state the actual properties (see cluster finder providing a halo catalogue out of a simulation). We need examples of what to put in target object type, as well as Google-like, free text searches of the descriptions.
- What types of characterisation are available and necessary?
- Full (a posteriori) characterisation is when all values are explicitly given. From thereon one may get more and more vague by giving histograms (representing a probability density distribution), and then various less and less descriptive statistics. For small numbers (1,2,3) of objects one could however fully characterise the experiment already in the metadata using the actual value of objects.
- Do we need a datatype in InputParameter?
- This is hardly necessary for discovery and moreover can be obtained from the protocol for the experiment. The same is true for cardinality. Important are the name, the description+UCD and the value. In the domain model the only thing an InputParameter is is a reference to the Parameter (off the protocol) and the value. The description we keep as one may search for text in it, same for UCD. One hardly will search for cardinality. I keep it in the data model (and XML schema), but with minoccurs="0".
- Do we need a separate field for initial conditions, and how do we specify it?
- I believe yes, though it can be seen as a special kind of input parameter. If possible it should point to a snapshot that is registered. If not, can it be a generic anyURI pointing to a "download" web service (after all we currently do not specify storage explicitly)?
|
|
>
> | Target Object: Optional? |
| | |
|
>
> | Suggestion: The model must be able to describe simulations for which there is no target object. |
| | |
|
>
> | Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere.
I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model.
-- RickWagner - 13 Feb 2008
Algorithm and Representation: Part of the Protocol?
Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings?
To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment?
-- RickWagner - 13 Feb 2008 |
| |
<--
--> |
