Some questions (in bold) with their motivation and current answer (as of the last edit of the page):

• back to SNAP DM 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

Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*.

-- GerardLemson - 14 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

Comment: I do agree with this in principle as it does represent the world better. The main problem with this more normalized approach is that the serialisation requires more indirection. This is especially true if we want to register Protocls separately from experiment in individual XML documents so we can not use ID/IDREF. How to deal with this properly is an issue that appears now and then in the IVOA discussions, but has not been resolved in a standardised manner. Suggestions include using the XML trick of xlink, or using the standardised ivo:/... [[][IVO Identifiers]], which have to be interpreted then by the (SNAP) registry that accepts these documents.

To avoid these complications, the snap model combined the definition (belonging to SNAPProtocol) and the usage (by snap experiment) in one type contained by SNAPExperiment.

We need to get opinions on this from the community and try out solutions and tools (SNAP portals) that assist users in this process.

--IVOA.GerardLemson- 14 Feb 2008

Target Process: ObjectType?

Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process.

Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles.

Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process.

It seems easier to allow processes to have properties, than to add many derived quantities to the representations.

Comment: I added TargetProcess recently when realising that the goal of an experiment may be to study a given process iso a given (type of) object. I did not work it out beyond adding a semantic label and some more attributes. I think your proposal of re-using objecttype is reasonable and concise. Another example I can see is studying the effects of different cosmologies on LSS evolution where obvious properties are the cosmological parameters.

Proposed resolution: follow Rick's suggestion, have TargetProcess inherit from ObjectType.

Data Model Sketch

Here is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.

-- RickWagner - 14 Feb 2008