(r7) IvoaTheory_SNAPDataModelDiscussion < IVOA

IVOA Web>IvoaTheory>IVOATheorySimulationDatamodel>IvoaTheory_SNAPDataModelDiscussion (revision 7) (raw view)~~EditAttach~~

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.

-- IVOA.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?

-- IVOA.RickWagner - 13 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.

<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

---++ 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.

<img src="%ATTACHURLPATH%/CADACSimDataModel.png" alt="CADACSimDataModel.png"  width="791" height="511"  />

-- IVOA.RickWagner - 14 Feb 2008

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
png	CADACSimDataModel.png	r2 r1	manage	89.6 K	2008-02-14 - 06:04	RickWagner

Topic revision: r7 - 2008-02-14 - RickWagner

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema