This document presents a mapping of the SNAP data model developed by the theory interest group. That model is a proposal to the DM working group for modelling a subset of astrophysical simulations. Those simulation This mapping is performed as much as possible (i.e. modulo mistakes, typos, out-of-synchs) according to the prescription for mapping UML data model to XML Schema presented in http://www.ivoa.net/internal/IVOA/VOResource010RevNotes/ModelBasedSchema.ppt and described in the SNAP Data model document in [LINK]. History of this document: 2007-09-09: First semi complete mapping of the data model. 2007-09-12: After upload as attachements to SNAP simulation data model page, updated the schemaImports. Note that it would be good to have a proper location for the IVOA Identifier schema. A protocol for running SNAP experiments. A SNAPProtocol is a Resource in the sence of the Resource model. The fundamental root entity of the SNAP model. The SNAP model represents experiments that produce snapshots of the universe. This is the base type of a set of more specialised types such as Simulation, GroupFinder etc. A SNAPProtocol is a Resource in the sence of the Resource model. The protocol according to which this experiment was executed. Publisher-designated ID. The ID by which this SNAP experiment is known to its archive and the services applicable to it. Will be used to add to the baseurl of anyservice that is applicable to it. A URI to a publication describing this experiment. TBD higher maxOccurs necessary? The collection of snapshots representing the result of this experiment. Indication of the type of object that is being simulated in this experiment. The type of object that is being used as fundamental building block in the experiment for representing the simulated world. Examples are particles for N-body simulations, mesh cells for mesh simulations etc. Parameter definitions and values used in the running of this experiment. A representation of a subset of space-time. Currently modelled to support constant-time, space-like slices only. An identifier specified by the publisher of this experiment. This is the identifier by which IVOA registered (SNAP)services will recognize this particular snapshot. TBD We could have this as a suffix to the SNAPExperiment's publisherDID. The physical (i.e. not comoving for example) size of the snapshot. TBD Need to come up with a way to specify this for multi-dimensional volumes. Use Quantity as a place holder datatype for such instances. The simulation timestamp for this snapshot. Its datatype (Quantity) is a place-holder for a proper way of representing simulation timestamps. The base class representing objects with properties. For a subject such as simulations where we can not pre-define the objects that play a role we need a method for publishers to define custom objects. The name by which this object type is referred to in the containing experiment. A plain text short description of this object type. Collection of properties. There must be at least 1, other wise the objects is irrelevant. Identifier to be used for references to this objects within the document itself. The label in the ontology of AstroObjects [TBD add link] The label in the "ontology" of subject keywords in the major astronomical journals. Indication, not necessarily exact, how many objects of this object type are around in the simulation. This element allows one to indicate that a specific, identified, real-world object is being represented by this SNAPExperiment. For example, if an exact simulation of a particular object, say the Magellanic-Stream was performed, this element allows one to say so. Label indicating what kind of representation object this is by referring to a standard list ("ontology") of possible object types. Some representation objects may have astronomical meaning (as opposed to say "mesh cell"). Examples are for example if a globular cluster is modeled with an n-body point particle representing a complete star. In this case an extra label can be provided indicating what kind of physical object is represented. A property that an object can have. The name by which this property is known in the experiment. The datatype of this property in the experiment. As the latter is software based, the datatype is a software datatype. Distinctions are therefore drawn between (real*4/4byte) floats and (real*8/8 byte) doubles etc. The cardinality of this property in the experiment. A labvel assigned to this property to provide its meaning in the IVOA standard UCD system. A short description of this property. A parameter The name by which this parameter is used in the experiment. The datatype of this parameter. As this is a software experiment, the datatypes are software datatypes. The cardinality of this parameter. The value given to this parameter. TBD Could specify its datatype as anyType, but prefer we handle it ourself. A short description of this parameter. Represents a collection of fundamental data objects representing the world. Though the data themselves are not represented in the meta-data model, this type holds on to metadata about the collections. The number of objects in this collection. Collection of objects characterising the objects in this collection by giving summaries of the various properties of the objects in the collection. The reference to the object type of the objects stored in this collection. As this object type will be defined in the same document an IDREF to its ID can be used. Represents means of characterising collections of objects, more in particular a particular property of the objects in the collection. This can be done both by specifying possible values this property can take (a priori characterisation) and by characterising the values actually taken up by the properties in the collection (a posteriori characterisation). [TBD This is applicable to numerical properties (having Quantity-s as value) only.] The lowest value the characterised property can possibly take in the containing collection. This is an "a priori" characterisation. The highest value the characterised property can possibly take in the containing collection. This is an "a priori" characterisation. The typical value the characterised property takes in the containing collection. Can be thought of as the location element in the Characterisaiton data model. This is an "a priori" characterisation. The lowest value of the characterised property actually taken by an object in the containing collection. This is an "a posteriori" characterisation. The largest value of the characterised property actually taken by an object in the containing collection. This is an "a posteriori" characterisation. The mean value of the characterised property over the containing collection. This is an "a posteriori" characterisation. The standard deviation of the characterised property over the containing collection. This is an "a posteriori" characterisation. Reference to the actual property that is being characterised by this object. Reference is to the ID attribute of the Propertry type. We can use an ID/IDREF implementation as the referenced element will have to be in the same document as the referring element, for they both belong to the same root element, which is a SNAPExperiment. A webservice that can be used to do something with the results of this SNAP experiment. Examples of this are some standard services like cut-out, projection etc. An API can be defined for all of these that can be derived from the base service which accepts the publisherDID-s for the SNAPExperiment and a Snapshot. The base URL from which the complete HTTP GET can be built for standard SNAP services, or which leads to a web page from which the web application can be started for custom services. The base URL where one can reach information about the web service. A short description of the service. Label indicating whether this is a standard type SNAP service, or a custom one. A simulator protocol producing snapshots of the universe. URL where the source code can be retrieved. Represents an original SNAP simulation. Corresponds to the "Level-0" data products. Important for its description are the physcial processes that are being modeled and the numerical algorithms The physical processes used in this simulation. The numerical algorithms(s) used to represent the physical processes in the simulation. Represents meta-data regarding physical processes used in simulators. The label identifying this process in terms of the IVOA ontology of physical processes The label identifying this process by the entry in the list of the subject keywords of the major astronomicl journals. The algorithm(s possibly more than 1) used to model this physical process. TBD DM question: should this be here, or directly hanging off the Simulation object itself ? Represents a numerical algorithm for modelling physical processes in a simulation. Represents a party that can play a role in the context of this model. A party can be a person or an organisation. Represents a value-type. properties and parameters have such values. Represents a numerical value type. The value of the quantity. The unit (if applicable) of this quantity. List of primitive datatypes that a parameter can have. These are software datatypes (i.e. float and double iso only real). List of valid values for indicating the cardinality of a property. Values have usual meaning. Defines a number of standard services that can deal with SNAP results. A simple download service. To be defined what parameters belong to this. A service thta produces a spatial cut-out of a snapshot. This can be of a nbumber of shapes: sphere, box, maybe more general. To be defined what parameters belong to this. Create a mesh-like representation of an existing snapshot. The latter may consist of particles, but the service can also do a regridding of an existing mesh. To be defined what parameters belong to this. Identify clusters in a snapshot. Can be done both for mesh-like and for n-body simulations. To be defined what parameters belong to this. A service to create a visualisation, i.e. 2D image of a snapshot. To be defined what parameters belong to this. A custom service.