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 URI to a publication describing this
experiment. TBD higher maxOccurs
necessary?
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 resource 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.
The collection of snapshots representing
the result of this experiment.
Indication of the type of object that is
being produced in this experiment.
Indication of the type of process that represented
and/or studied 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.
The numerical algorithms(s) used in the experiment.
Parameter definitions and values used in
the running of this experiment.
A web service that provides access to this SNAP experiment's results in some form.
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.
It is especially relevant for various post-processing results
such as halo finders, or for example semi-analytical galaxy formation routines.
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 process that plays a role in an experiment, either as an object of study in
itself, or because it is part of the simulated processes.
Maybe maxOccurs=unbounded?
A parameter setting. It should suffice to only give name
and value, where the name is contrained to be an input parameter
name on a protocol. Could use a referencing IVO-ID then ...
TBD!
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.
A parameter definition of a protocol
The name by which this parameter is referred to in the protocol.
The datatype of this parameter. As this is a
software protocol, the datatypes are software
datatypes.
The cardinality of this parameter.
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 IVO compatible (see ...) identifier with which the service is registered.
May be null in case the servie is not registered.
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.
Represents meta-data regarding physical processes used
in simulators. An instance of this object corresponds to an exact evolution
equation.
Name by which the publisher refers to this algoruthm in the experiment.
Short description of the algorithm.
The (evolution) equation in TeX form.
Represents a numerical algorithm for modelling physical
processes in a simulation.
Name by which the publisher refers to this algoruthm in the experiment.
Short description of the algorithm.
URL to a document describing this algorithm in more detail.
An "ontological" label, indicating the type of numerical algorithm that is used.
An aggregation of annotated SNAPResource-s that together
form a project.
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 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.