This is the data model for describing simulations, the code that produced them and other related resources. It is to be used
by protocol specifications for discovering theory data products and web services with which these can be accessed. An example
of these are the Simulation Database (SimDB) spec and the family of protocols to be defined in the Simulation Data Access
Layer (SimDAL).
This data model is a specification of the IVOA Theory Interest Group.
The following sub-sections present all packages in the model, listed here in alphabetical order.
Each sub-section contains a description of the package and a table containing its various features.
This package holds on to SimDM/Service and classes used in its definition. It represents functions for accessing the physical
resources described by the model such as the results of simulations and post-processing experiments.
This package contains the SimDM/Experiment class, its subclasses and and other types contained by these. It is a sub-package
of the resource package.
This package defines some very basic "meta" types such as the basic DataType enumerations etc.
This package contains SimDM/ObjectType and classes used in its definition.
These classes allow users to describe structured objects that are used in, or produced by the SImDM/Protocols.
This package contains the SimDM/Protocol and classes used in its definition.
This is a root package of the SimDM data model.
It contains all packages defining the main entities of the model as subpackages.
It contains the SimDM/Resource and SimDM/Party root entity classes and various data types and enumerations. It depends on
the object package.
The following sub-sections present all types in the model, listed here in alphabetical order.
Each sub-section contains a description of the type and a table containing the various features of the type.
For object and data types these features are (where applicable) :
The AccessibleResource class represents an association between the containing SimDM/Service and the SimDM/Resource-s that
are being made accessible by that service.
This class represents numerical algorithms available in a SimDM/Protocol.
In Simulators an algorithm may approximate a physical process. Examples from cosmological simulations are different algorithms
to implement gravity: direct particle-particle interaction, particle-mesh, or various types of tree based algorithms.
In post-processors such as cluster finder this class can represent a partiular cluster definition such as friends-of-friends
or spherical overdensity.
The AppliedAlgorithm class represents the application of a particular algorithm in an experiment.
Some simulation codes allow one to choose between different algorithms for representing a particular process. For example
some N-Body codes allow one to choose between Tree-only or Tree+ParticleMesh codes.
To indicate which algorithms were actually used in an experiment one adds an instance of this AppliedAlgorithm class to the
collection on the experiment.
The AppliedPhysics class represents the association between a physical process on a Simulator and this class' parent Simulation.
Many simulation codes allow one to turn on or off modules corresponding to different physics. For example certain SPH codes
allow one to turn off the hydrodynamics, leaving only gravity as the physical process being simulated.
This enumeration contains the possible values for the cardinality attribute of a Field definition.
This class connects a Party to a resource.
It indicates the role the party plays on the resource, for example creator, owner or publisher.
The ContactRole enumeration contains the different roles a SimDM/Party can play in the creation or publishing of a SimDM/Resource.
The CustomService class represents a custom SimDM/Service for accessing SimDM/Resource-s. It is not assumed that a predefined
protocol is implemented. Its main role is to distinnguish it from SimDAL and other services implementing potential, future
IVOA standards.
But many interesting custom services giving access to simulation results exist and can be reistered and discovered through
this class.
Represents an individual object of a given object type produced by an experiment. Is required if we want to represent object-object
collection hierarchies. NB the name DataObject is used iso Object, as the latter may lead to name clashes in serialisations.
In this model any artefact produced by a Protocol can be represented by an appropriate ObjectType and relations can exist
between them. Some of these relations are many-to-one, i.e. between object collections and parent ojects. If such relations
must also be represented in the output of an Experiment, it must be possible to represent individual objects.
A typical example is a cosmological simulation produccing N > 1 snapshots. We may want to represent each individual snapshot
in the result, together with statistical information about the collections of particles contained in each.
The object can give values to properties related to objects of its type.
In principlpe this model now would allow one to describe an experiment in all details, with each individual object listed.
This is as should be for a conceptual model, but in particular applications we envision that limits be put on the size of
results. For example it does not make sense to store the complete results of a large cosmolgical simulation in this way, as
the storage of property values is inefficient.
The DataType enumeration lists the available values for the datatype attributes used in the definition of metadata fields
such as Property and InputParameter.
The values represent rather abstract data types. For example no distinction is made between different representations of integer
(short, int, long) or floating point (float, double) types. Instead the mathematical number fields integer and real are used,
together with rational and complex.
Alternative representations or usages of this model might add such details.
The SimDM/Experiment represents the execution of a computer program represented by a SimDM/Protocol. It defines how the program
was run by providing values to parameters for example. It describes the goal of the experiment in terms of the physical objects
and processes that are being simulated and it contains the collection of results.
Represents a generic field like object.
Associates an individual Object to an InputDataSet.
Thus if for example only 3 individual snapshots out of a collection of N snapshots produced by a cosmological simulation are
post-processed, the actual snapshots used can be indicated using this associative object.
Type of data objects that the protocol needs in its execution.
Many experiments require pre-existing data sets for their execution.
This class represents such an association for its parent SimDM/Experiment.
It is assumed to contain 1 or more objects of a specified SimDM/InputDataObjectType defined on the SimDM/Protocol used by
the container SimDM/Experiment.
In those cases where the actual input data set is represented by a SimDM/OutputDataset, for example in a SimDB, we can represent
the input data by a corresponding reference. Whereas that would be optimal, it may not always be practical. In cases where
this is not so, this reference is replaced with an accessURL attribute on this class. This would allow a user to find out
whether a product exists in the database with that same url, make the link indirect but arguably more correct.
This class represent an input parameter on a protocol.
In general,a simulation codes needs the user to set values to parameters that govern the running of the code. These may be
parameters describing the physics in a simulation, or they may be numerical parameters governing the approximation of the
process by a particular algorithm.
Instance of a composition Relationship between an ObjectType and a collection of objects.
Instance of a reference Relationship between two ObjectType-s.
This class represents and abstract object type, and can thus be seen as a meta-modelling construct.
It allows model instances that represent complex object definitions.
This class represents the type of data object that the container SimDM/Protocol can produce.
This concept includes any type of data object the protocol deals with.
It can range from the smallest data units such as individual N-Body particles or pixels in a synthetic spectrum, up to the
largest which may be a collection of snapshots in an N-body simulation ,each of them containing collections of particles.
It defines also the actual SimDM/OutputDataset-s that a SimDM/Experiment's has produced.
Since a SimDM/OutputDataObjectType is-a SimDM/ObjectType, it can be related to other objects using SimDM/Relationship-s.
In this way a hierarchy of data types can be described.
For example a spectrum can be a such a data object and will be composed of pixels. A FOF group catalogue will be composed
of FOF groups which are aggregations of particles.
This class represents 1 or more instances of a single SimDM/OutputDataObjectType-s produced by an SimDM/Experiment.
No assumption is made how a SimDM/OutputDataset is represented in the real world. It may consist of one or multiple files,
or possibly one or more tables in a database, or subsets thereof. The exact storage is not currently modelled.
The class represents an actual collection of objects without (necessarily) listing these all. Instead it is to be used to
allow statistical summaries/characterisation of these products.
A special feature is that a SimDM/OutputDataset may define a dependency on another, 'parent' data set. This reflects to possibility
in the SimDM/Protocol to model relationships between different SimDM/OutputDataObjectType-s.
This is implemented using two references, one to the parent SimDM/OutputDataset, the other to the SimDM/Relationship.
Represents a (natural) grouping of SimDM/InputParameters.
Especially in protocols with large numbers of parameters it may be useful to group these
for browsing purposes for example. As browsing is likely an important mode of access to SimDM/Resource-s stored in a SimDB
for example, this possibility was introduced.
But the main use should be reserved for semantic groupings. For example all parameters together defining the cosmology a certain
simulation is run in. Or the parameters setting "merely" numerical properties such as smoothing lengths.
Associative class, representing a selection of a parameter in a parameter grouping.
To run an Experiment, one usually needs to assign values to parameters defined on the corresponding Protocol. This class makes
the association between the Experiment and the parameters, indicating which parameter is given what value.
Input parameters can be given any datatype from the DataType enumeration and hence it is in principle impossible to assign
a single datatype to the value attribute storing the parameter setting in this model. Whereas we might use a generic string
data type, this will in many implementations limit the use of query expressions that one might use for numerical values for
example.
As a work around the current design has two attributes, one of type real, one of type string. The former should be used for
numerical InputParanmeters, the latter for all others.
Information that describes a Party, that is a person/individual or possibly an organisation.
This class represents a physical processes that is modelled in a simulation code.
Simulating a physical process generally corresponds to solving equations of motion numerically, evolving the simulated system
from one state to the next.
Represents an experiment that corresponds to the execution of a PostProcessor protocol. It manipulates a pre-existing result
to produce new results, but without introducing new physics.
This concrete subclass of SimDM/Protocol represents protocols that deal with post-processing results of earlier experiments.
We do not specify the details of this type much further. Main difference with eg the SimDM/Simulator type is that NO new physical
processes are introduced/simulated in the processing of the previous results. Examples are cluster finders, visualisation
tools etc.
A SimDM/Project is an aggregation of SimDM/Resource-s that belong together, for example because they have been produced together
in the course of a scientific project.
Examples are parameter studies where a large number of simulations is run with slightly varying parameter settings. But also
a single large simulation with a number of post-processing results can be gathers in this way.
It is assumed that SimDM/Project are generally "big enough" to qualify to be represented as a full-fledged Registry/Resource
in an IVOA Registry. This possibility was on of the reasons to add this concept to the model.
Associative class between a SimDM/Project and its constitutent SimDM/Resource-s.
The properties of an object. Similar to the FIELD in a VOTable
This class represents a naturla grouping of properties on the object type.
Is used for presentation purposes in a browsing environment.
Assocuiative object that represents a member in a property group.
Assign a value to a property of a data object.
A SimDM/Protocol represents software code that can be used to run astrophysical simulations or to post-process simulation
results. A SimDM/Protocol defines the method by which SimDM/Experiment-s can be performed, like a blue-print, or template.
The SimDM/Protocol concept is separated out from the execution of its code in SimDM/Experiment, which allows us to reuse it
for all experiments using the same code.
The concept is a direct gemeralisation of the concept by the same name in Martin Fowler's book "Analysis Patterns: Reusable
Object Models" (Addison-Wesley Professional, 1996).
A structured data type, indicating a numerical value and corresponding unit. The latter will require some standard dictionary
for a uniform usage. This is here not modelled
This class assists in the definition of an object hierarchy by associating different objects. The type of relationship is
borrowed loosely from UML, and can represent a composition, aggregation or reference, as defined by the relationshipType attribute.
An example is the composition relationship between a image and its pixels, or the aggregation of a FOF group and its constituent
particles.
Type of relationship between an ObjectType and the related object type.
This class represents the main resources defined by the Simulation Data Model in the same way as the Registry/Resource class
represents resources in registries. It is the base class of specialisations SimDM/Protocol, SimDM/Experiment, SimDM/Project
and SimDM/Service.
These resources are the root entities that would get registered in a Simulation Database for example. They are also represented
by root element declarations in XML schema serialisations of the model.
This class is a thin copy of the Registry/Resource and borrows some of its elements. It *is-not-a* Registry Resource in the
sense of inheritance. In particular a SimDM/Resource has a more refined and targeted content model. Also, SimDM/Resource-s
are in general (much) more fine grained than Registry/Resource-s and would not qualify to be registered in an IVOA Registry.
It will howevere be possible to transform certain SimDM/Resource-s into Registry/Resource-s.
This class represents a web service that can be used to access SimDM/Resource-s registered in for example a SimDB. The precise
way in which the web service gives access to these results not specified in detail. It includes simple downloads, and services
implementing standards such as SimDAL.
SimDM/Service is related to SimDM/Resource and can be used for more general purposes than simply giving access to results
of a single experiment. It may be a web service that can handle results of any experiment performed by a particular SimDM/Protocol,
or give access to all resources in a SimDM/Project.
The main goal of introducing SimDM/Service in the model is so that users can find web services based on requests for specific
tyes of simulations etc. For example users may wish to find web services giving access to hydro simulations of clusters of
galaxies with particular properties.
.
It is assumed that web services registerd in a SimDB are also registered in a Registry which will store the more detailed
capbilitieis and other service metadata. Therefore such details are not introduced here.
Represents a SimDM/Service conforming to a SimDAL protocol.
This is a place holder class that may in future version of the model be defined in more detail when SimDAL services themselves
have been fully specified.
This class represents the execution of simulation codes. Its protocol is therefore a SimDM/Simulator iso a general SimDM/Protocol.
It extends SimDM/Experiment by adding descriptions of the physical processes that were simulated
This class represents the simulation software that one uses to run a simulation. It is a special case of a SimDM/Protocol.
It is different from other SimDM/Protocols in that it explicitly defines the physical processes that are (can be) simulated.
This indeed is the defining characteristic of the SimDM/Simulator: it simulates/models physical processes. This in contrast
to a "mere" SimDM/PostProcessor which takes the input data and analyses it without adding new physics. It does not imply that
simulators can not use existing results. For example consider semi-analytical galaxy formation routines which work on existing
halo (merger) catalogues.
This enumeration lists possible statistics that can be used to characterise a collection of Property-s in a result. The literals
in this enumeration in general correspond to the result of simple statistical operation on this collection (when a posteriori)
or on the corresponding operation on the a priori probability distribtion (assuming this can be defined) of its values.
There is overlap between this enumeration and the 'stat' family of UCDs in the UCD controlled vocabulary (http://www.ivoa.net/Documents/REC/UCD/UCDlist-20070402.html).
Where this enumeration is used one might consider using a vocabulary based on those terms.
This class allows users to provide a statistical characterisation of a collection of objects in a specified SimDM/OutputDataset.
It represents both 'a priori' and 'a posteriori' characterisations. With a priori characterisation we indicate possible and/or
nominal [?] values the variable may take, it defines the possible range of values of the SimDM/Property. In contrast, an a
posteriori characterisation of a property in an collection provides summarising, likely statistical, information on the values
that were actually measured (i.e. observed, simulated) by the objects in the collection.
The a priori characterisation is most similar, in fact a generalisation of the Characterisation model of the IVOA Data Model
working group.
In the current model we stick to simple (numerical) quantities for characterising a collection of objects. For example the
equivalent value of a support from the CharacterisationDM is absent, as it is not terribly useful for discovery and querying,
even more so of course for concepts equivalent to sensitivity.
Represents the scientific goal associated to a SimDM/Resource. This can be the goal of an experiment or project, or the type
of object that a particular protocol will always produce. Is made concrete by suclasses representing objects or processes.
We model a Target as "being an" ObjectType, which allows one to give a more detailed representation of its properties. The
target is important as it represents one of the main questions scientists will ask about an experiment: what kind of astrophysical
object or system or process was being simulated or modelled.
This class represents the actual system that is being simulated. Instances of this object should correspond to physical objects
and/or systems. They should be the answer to queries such as, "what does this simulation simulate?"
This class represents the fact that some simulations are run with the goal (Target) to investigate physical processes, rather
than simulation specific objects or systems. Instances of this class can be used to describe this. For example one may study
"turbulence", or "gravitational cluster" or "galaxy formation".
| UTYPE |
description |
| SimDM |
This is the data model for describing simulations, the code that produced them and other related resources. It is to be used
by protocol specifications for discovering theory data products and web services with which these can be accessed. An example
of these are the Simulation Database (SimDB) spec and the family of protocols to be defined in the Simulation Data Access
Layer (SimDAL).
This data model is a specification of the IVOA Theory Interest Group.
|
| SimDM:/meta/ |
This package defines some very basic "meta" types such as the basic DataType enumerations etc. |
| SimDM:/meta/Cardinality |
This enumeration contains the possible values for the cardinality attribute of a Field definition.
|
| SimDM:/meta/DataType |
The DataType enumeration lists the available values for the datatype attributes used in the definition of metadata fields
such as Property and InputParameter.
The values represent rather abstract data types. For example no distinction is made between different representations of integer
(short, int, long) or floating point (float, double) types. Instead the mathematical number fields integer and real are used,
together with rational and complex.
Alternative representations or usages of this model might add such details.
|
| SimDM:/meta/Quantity |
A structured data type, indicating a numerical value and corresponding unit. The latter will require some standard dictionary
for a uniform usage. This is here not modelled
|
| SimDM:/meta/Quantity.unit |
The unit (if applicable) for this quantity. Should correspond to a recognised unit, possibly a skosconcept? |
| SimDM:/meta/Quantity.value |
The numerical value for this quantity. |
| SimDM:/object/ |
This package contains SimDM/ObjectType and classes used in its definition.
These classes allow users to describe structured objects that are used in, or produced by the SImDM/Protocols.
|
| SimDM:/object/Field |
Represents a generic field like object. |
| SimDM:/object/Field.cardinality |
The cardinality of this parameter or property |
| SimDM:/object/Field.datatype |
the data type of this parameter or property |
| SimDM:/object/Field.description |
Short description of this parameter or property |
| SimDM:/object/Field.isEnumerated |
indicates if this parameter or property only accept values coming from a list of valid values defined by the validValue collection |
| SimDM:/object/Field.name |
the name of this parameter or property.
Ex: omegaLambda, particleMass, linking length
|
| SimDM:/object/Field.validValue |
List of possible values : only defined when isEnumerated = true |
| SimDM:/object/ObjectType |
This class represents and abstract object type, and can thus be seen as a meta-modelling construct.
It allows model instances that represent complex object definitions.
|
| SimDM:/object/ObjectType.description |
Short description of this object type. |
| SimDM:/object/ObjectType.name |
The name of this object type. |
| SimDM:/object/ObjectType.property |
Collection of properties. |
| SimDM:/object/ObjectType.propertyGroup |
Collection of property groups. |
| SimDM:/object/ObjectType.relationship |
Collection of relations to object types that may be contained or aggregated by this object type or referenced by it. |
| SimDM:/object/Property |
The properties of an object. Similar to the FIELD in a VOTable |
| SimDM:/object/Property.label |
The concept represented by this property. This concept should be narrower than the broadestSKOSConcept. |
| SimDM:/object/PropertyGroup |
This class represents a naturla grouping of properties on the object type.
Is used for presentation purposes in a browsing environment.
|
| SimDM:/object/PropertyGroup.description |
Description of this group. |
| SimDM:/object/PropertyGroup.member |
Collection of members of this parameter grouping. |
| SimDM:/object/PropertyGroup.name |
Name of this paarameter grouping. |
| SimDM:/object/PropertyGroupMember |
Assocuiative object that represents a member in a property group. |
| SimDM:/object/PropertyGroupMember.property |
Reference to the actual property this class associates to a property group. |
| SimDM:/object/Relationship |
This class assists in the definition of an object hierarchy by associating different objects. The type of relationship is
borrowed loosely from UML, and can represent a composition, aggregation or reference, as defined by the relationshipType attribute.
An example is the composition relationship between a image and its pixels, or the aggregation of a FOF group and its constituent
particles.
|
| SimDM:/object/Relationship.cardinality |
The cardinality/multiplicity of the child object in the containing object. |
| SimDM:/object/Relationship.description |
Describes the relation between the parent and child object type. |
| SimDM:/object/Relationship.name |
Name of the variable representing the relationship on the containing parent object type. |
| SimDM:/object/Relationship.relatedObjectType |
Reference to the ObjectType that is the child in the hierarchical parent-child relation. |
| SimDM:/object/Relationship.relationshipType |
This attributes indicates the type of relaion between the parent and the related object. |
| SimDM:/object/RelationshipType |
Type of relationship between an ObjectType and the related object type.
|
| SimDM:/object/ValidValue |
This represents a value for an enumerated parameter or property |
| SimDM:/object/ValidValue.description |
A description of this value. |
| SimDM:/object/ValidValue.title |
Short name / alias for this value (useful in GUI) |
| SimDM:/object/ValidValue.value |
the value as string : can be converted to the correct datatype of the asociated parameter or property |
| SimDM:/resource/ |
This is a root package of the SimDM data model.
It contains all packages defining the main entities of the model as subpackages.
It contains the SimDM/Resource and SimDM/Party root entity classes and various data types and enumerations. It depends on
the object package.
|
| SimDM:/resource/Contact |
This class connects a Party to a resource.
It indicates the role the party plays on the resource, for example creator, owner or publisher.
|
| SimDM:/resource/Contact.party |
Reference to the Party that the Contact associates to the Resource. |
| SimDM:/resource/Contact.role |
The role this contact plays in the Resource |
| SimDM:/resource/ContactRole |
The ContactRole enumeration contains the different roles a SimDM/Party can play in the creation or publishing of a SimDM/Resource. |
| SimDM:/resource/Party |
Information that describes a Party, that is a person/individual or possibly an organisation. |
| SimDM:/resource/Party.address |
the contact mailing address
All components of the mailing address are given in one string, e.g. "3700 San Martin Drive, Baltimore, MD 21218 USA".
|
| SimDM:/resource/Party.email |
the contact email address |
| SimDM:/resource/Party.name |
the name or title of the contact person.
This can be a person's name, e.g. "John P. Jones" or a group, "Archive Support Team".
|
| SimDM:/resource/Party.telephone |
the contact telephone number
Complete international dialing codes should be given, e.g. "+1-410-338-1234".
|
| SimDM:/resource/Project |
A SimDM/Project is an aggregation of SimDM/Resource-s that belong together, for example because they have been produced together
in the course of a scientific project.
Examples are parameter studies where a large number of simulations is run with slightly varying parameter settings. But also
a single large simulation with a number of post-processing results can be gathers in this way.
It is assumed that SimDM/Project are generally "big enough" to qualify to be represented as a full-fledged Registry/Resource
in an IVOA Registry. This possibility was on of the reasons to add this concept to the model.
|
| SimDM:/resource/Project.resource |
Collection of associatiions to the resources that make up this project. |
| SimDM:/resource/ProjectResource |
Associative class between a SimDM/Project and its constitutent SimDM/Resource-s. |
| SimDM:/resource/ProjectResource.resource |
Reference to another SimDM/Resource that is included in the containing SimDM/Project. |
| SimDM:/resource/Resource |
This class represents the main resources defined by the Simulation Data Model in the same way as the Registry/Resource class
represents resources in registries. It is the base class of specialisations SimDM/Protocol, SimDM/Experiment, SimDM/Project
and SimDM/Service.
These resources are the root entities that would get registered in a Simulation Database for example. They are also represented
by root element declarations in XML schema serialisations of the model.
This class is a thin copy of the Registry/Resource and borrows some of its elements. It *is-not-a* Registry Resource in the
sense of inheritance. In particular a SimDM/Resource has a more refined and targeted content model. Also, SimDM/Resource-s
are in general (much) more fine grained than Registry/Resource-s and would not qualify to be registered in an IVOA Registry.
It will howevere be possible to transform certain SimDM/Resource-s into Registry/Resource-s.
|
| SimDM:/resource/Resource.contact |
The collection of contacts for a Reource. |
| SimDM:/resource/Resource.created |
The UTC date and time this resource was created in the real world. |
| SimDM:/resource/Resource.description |
A description of this resource. |
| SimDM:/resource/Resource.name |
For Protocol :
The name by which this simulator is commonly known.
Ex: Gadget, Flash
For Project :
the name of the project
For Experiment :
the name of this experiment
|
| SimDM:/resource/Resource.referenceURL |
a URL to a web page describing the resource. |
| SimDM:/resource/Resource.status |
a tag indicating whether this resource is believed to be still actively maintained. |
| SimDM:/resource/Resource.target |
This collection of Target, describing the different targets/goals/objectives of this Experiment.
|
| SimDM:/resource/Resource.updated |
The UTC date and time this resource was updated in the real world. |
| SimDM:/resource/Target |
Represents the scientific goal associated to a SimDM/Resource. This can be the goal of an experiment or project, or the type
of object that a particular protocol will always produce. Is made concrete by suclasses representing objects or processes.
We model a Target as "being an" ObjectType, which allows one to give a more detailed representation of its properties. The
target is important as it represents one of the main questions scientists will ask about an experiment: what kind of astrophysical
object or system or process was being simulated or modelled.
|
| SimDM:/resource/TargetObjectType |
This class represents the actual system that is being simulated. Instances of this object should correspond to physical objects
and/or systems. They should be the answer to queries such as, "what does this simulation simulate?"
|
| SimDM:/resource/TargetObjectType.identityName |
If the target object type referes to a real object, this attribute allows one to indicate which object. This is performed
by a URI that should identify the object in the Ontology of SimbadIdentifiedNames
In some cases a real identified object in the universe is being modelled. If that is the case, this attribute allows that
object to be identified. We assume a list of such objects may be provided through some means, embodied by the IdentifiedObject
data type.
Ex: Galaxy, Antennae, M31.
|
| SimDM:/resource/TargetObjectType.label |
Represents a concept in a SKOS vocabulary of astronomical and astrophysical object types. |
| SimDM:/resource/TargetObjectType.multiplicity |
Indication on how many objects of this type are being modelled. |
| SimDM:/resource/TargetProcess |
This class represents the fact that some simulations are run with the goal (Target) to investigate physical processes, rather
than simulation specific objects or systems. Instances of this class can be used to describe this. For example one may study
"turbulence", or "gravitational cluster" or "galaxy formation".
|
| SimDM:/resource/TargetProcess.label |
A term from the AstroJournalSubjectKeywords ontology. |
| SimDM:/resource/dal/ |
This package holds on to SimDM/Service and classes used in its definition. It represents functions for accessing the physical
resources described by the model such as the results of simulations and post-processing experiments.
|
| SimDM:/resource/dal/AccessibleResource |
The AccessibleResource class represents an association between the containing SimDM/Service and the SimDM/Resource-s that
are being made accessible by that service.
|
| SimDM:/resource/dal/AccessibleResource.accessURI |
Direct URI for accessing the referenced SimDM/Resource using the parent service.
The parent service has a baseURL through which one can access the service interface. From there one may be able to browse
through all SimDM/Resource-s that are made available, but a specific (data access) protocol to reach a given SimDM/Resource
or how to browse these SimDM/Resource-s is not defined by this model. IF it is possible to access the SimDM/Resource directly
through the SimDM/Service, for example to download or browse its contents, this attribute gives the corresponding URI.
|
| SimDM:/resource/dal/AccessibleResource.description |
Description of how the particular SimDM/Resource referenced by this object is made available by the parent SimDM/Service. |
| SimDM:/resource/dal/AccessibleResource.resource |
This reference points to the SimDM/Resource that this SimDM/AccessibleResource class associates to the SimDM/Service. The
end point can be any SimDM/Resource.
|
| SimDM:/resource/dal/CustomService |
The CustomService class represents a custom SimDM/Service for accessing SimDM/Resource-s. It is not assumed that a predefined
protocol is implemented. Its main role is to distinnguish it from SimDAL and other services implementing potential, future
IVOA standards.
But many interesting custom services giving access to simulation results exist and can be reistered and discovered through
this class.
|
| SimDM:/resource/dal/Service |
This class represents a web service that can be used to access SimDM/Resource-s registered in for example a SimDB. The precise
way in which the web service gives access to these results not specified in detail. It includes simple downloads, and services
implementing standards such as SimDAL.
SimDM/Service is related to SimDM/Resource and can be used for more general purposes than simply giving access to results
of a single experiment. It may be a web service that can handle results of any experiment performed by a particular SimDM/Protocol,
or give access to all resources in a SimDM/Project.
The main goal of introducing SimDM/Service in the model is so that users can find web services based on requests for specific
tyes of simulations etc. For example users may wish to find web services giving access to hydro simulations of clusters of
galaxies with particular properties.
.
It is assumed that web services registerd in a SimDB are also registered in a Registry which will store the more detailed
capbilitieis and other service metadata. Therefore such details are not introduced here.
|
| SimDM:/resource/dal/Service.baseURL |
The base URL of this SimDM/Service.
In case the web service implements a standard IVOA protocol such as SimDAL, this base URL can be used in the same way as other
typical IVOA S*AP services. Parameters defined by the standard may be added to the base URL so that a proper HTTP GET request
can be created for accessing the web service directly.
|
| SimDM:/resource/dal/Service.registryId |
The IVO identifier by which this service is registered in an IVOA Resource Registry. Each SimDM/Service should be registered
in such a registry and this identifier allows one to obtain the full description of this service as defined by the Registry
standard.
|
| SimDM:/resource/dal/Service.resource |
Collection of SimDM/AccessibleResource that reference SimDM/Resource-s that are made available in this SimDM/Service. |
| SimDM:/resource/dal/SimDALService |
Represents a SimDM/Service conforming to a SimDAL protocol.
This is a place holder class that may in future version of the model be defined in more detail when SimDAL services themselves
have been fully specified.
|
| SimDM:/resource/experiment/ |
This package contains the SimDM/Experiment class, its subclasses and and other types contained by these. It is a sub-package
of the resource package.
|
| SimDM:/resource/experiment/AppliedAlgorithm |
The AppliedAlgorithm class represents the application of a particular algorithm in an experiment.
Some simulation codes allow one to choose between different algorithms for representing a particular process. For example
some N-Body codes allow one to choose between Tree-only or Tree+ParticleMesh codes.
To indicate which algorithms were actually used in an experiment one adds an instance of this AppliedAlgorithm class to the
collection on the experiment.
|
| SimDM:/resource/experiment/AppliedAlgorithm.algorithm |
Reference to the actual algorithm that is applied |
| SimDM:/resource/experiment/AppliedPhysics |
The AppliedPhysics class represents the association between a physical process on a Simulator and this class' parent Simulation.
Many simulation codes allow one to turn on or off modules corresponding to different physics. For example certain SPH codes
allow one to turn off the hydrodynamics, leaving only gravity as the physical process being simulated.
|
| SimDM:/resource/experiment/AppliedPhysics.physics |
Reference to the Simulator's Physcis module that is used in the Simulation. |
| SimDM:/resource/experiment/DataObject |
Represents an individual object of a given object type produced by an experiment. Is required if we want to represent object-object
collection hierarchies. NB the name DataObject is used iso Object, as the latter may lead to name clashes in serialisations.
In this model any artefact produced by a Protocol can be represented by an appropriate ObjectType and relations can exist
between them. Some of these relations are many-to-one, i.e. between object collections and parent ojects. If such relations
must also be represented in the output of an Experiment, it must be possible to represent individual objects.
A typical example is a cosmological simulation produccing N > 1 snapshots. We may want to represent each individual snapshot
in the result, together with statistical information about the collections of particles contained in each.
The object can give values to properties related to objects of its type.
In principlpe this model now would allow one to describe an experiment in all details, with each individual object listed.
This is as should be for a conceptual model, but in particular applications we envision that limits be put on the size of
results. For example it does not make sense to store the complete results of a large cosmolgical simulation in this way, as
the storage of property values is inefficient.
|
| SimDM:/resource/experiment/DataObject.collection |
TODO : Missing description : please, update your UML model asap.
|
| SimDM:/resource/experiment/DataObject.property |
TODO : Missing description : please, update your UML model asap.
|
| SimDM:/resource/experiment/DataObject.reference |
TODO : Missing description : please, update your UML model asap.
|
| SimDM:/resource/experiment/Experiment |
The SimDM/Experiment represents the execution of a computer program represented by a SimDM/Protocol. It defines how the program
was run by providing values to parameters for example. It describes the goal of the experiment in terms of the physical objects
and processes that are being simulated and it contains the collection of results.
|
| SimDM:/resource/experiment/Experiment.appliedAlgorithm |
Collection of AppliedAlgorithm objects, indicating which Algorithms available on a Protocl were used in the execution of
the Experiment.
|
| SimDM:/resource/experiment/Experiment.executionTime |
The date/time at which the experiment was completed |
| SimDM:/resource/experiment/Experiment.inputData |
The collection of InputData objects, indicating results of other Esperiments that may have been used in the execution of this
Experiment.
|
| SimDM:/resource/experiment/Experiment.outputData |
The collection of SimDM/OutputDataset-s created by a SimDM/Experimental.
We anticipate that experiments produce data sets of different SimDM/OutputDataObjectType-s. For each of these types a separate
SimDM/OutputDataset, is provided on the SimDM/Experiment.
|
| SimDM:/resource/experiment/Experiment.parameter |
The collection of ParameterSetting objects that describe the values assigned to parameters of the Protocol used in the execution
of this Experiment.
|
| SimDM:/resource/experiment/Experiment.protocol |
Reference to the Protocol used in the exeuciton of this Experiment.
Subclasses of this Experiment will in general override/"subset" this reference to subclasses of Protocol.
|
| SimDM:/resource/experiment/InputDataObject |
Associates an individual Object to an InputDataSet.
Thus if for example only 3 individual snapshots out of a collection of N snapshots produced by a cosmological simulation are
post-processed, the actual snapshots used can be indicated using this associative object.
|
| SimDM:/resource/experiment/InputDataObject.object |
Reference to an actual object that is being used in an experiment. |
| SimDM:/resource/experiment/InputDataset |
Many experiments require pre-existing data sets for their execution.
This class represents such an association for its parent SimDM/Experiment.
It is assumed to contain 1 or more objects of a specified SimDM/InputDataObjectType defined on the SimDM/Protocol used by
the container SimDM/Experiment.
In those cases where the actual input data set is represented by a SimDM/OutputDataset, for example in a SimDB, we can represent
the input data by a corresponding reference. Whereas that would be optimal, it may not always be practical. In cases where
this is not so, this reference is replaced with an accessURL attribute on this class. This would allow a user to find out
whether a product exists in the database with that same url, make the link indirect but arguably more correct.
|
| SimDM:/resource/experiment/InputDataset.description |
Describes the role that the input data set plays in the experiment. |
| SimDM:/resource/experiment/InputDataset.object |
Collection of object associations that identify explicitly which objects from a collection of objects are used as input data
in an experiment.
|
| SimDM:/resource/experiment/InputDataset.product |
The SimDM/OutputDataset produced by an earlier SimDM/Experiment that is used as input data for the current one. |
| SimDM:/resource/experiment/InputDataset.type |
Reference to the type definition for this SimDM/InputDataset. This must refer to a SimDM/InputDataObjectType defined on the
SimDM/Protocol according to which the SimDM/Experiment is performed.
|
| SimDM:/resource/experiment/InputDataset.url |
URL by which the input data set can be obtained. |
| SimDM:/resource/experiment/ObjectCollection |
Instance of a composition Relationship between an ObjectType and a collection of objects. |
| SimDM:/resource/experiment/ObjectCollection.collection |
TODO : Missing description : please, update your UML model asap.
|
| SimDM:/resource/experiment/ObjectCollection.collectionDefinition |
reference to the relationship definition on the ObjectType that is represented by the ObjectCollection. The referenced Relationship
MUST have relationshipType='composition'.
|
| SimDM:/resource/experiment/ObjectReference |
Instance of a reference Relationship between two ObjectType-s. |
| SimDM:/resource/experiment/ObjectReference.object |
The object referenced by the ObjectReference's parent DataObject. |
| SimDM:/resource/experiment/ObjectReference.referenceDefinition |
Reference to the relationship definition on the ObjectType that is represented by the ObjectReference. The referenced Relationship
MUST have relationshipType='reference'.
|
| SimDM:/resource/experiment/OutputDataset |
This class represents 1 or more instances of a single SimDM/OutputDataObjectType-s produced by an SimDM/Experiment.
No assumption is made how a SimDM/OutputDataset is represented in the real world. It may consist of one or multiple files,
or possibly one or more tables in a database, or subsets thereof. The exact storage is not currently modelled.
The class represents an actual collection of objects without (necessarily) listing these all. Instead it is to be used to
allow statistical summaries/characterisation of these products.
A special feature is that a SimDM/OutputDataset may define a dependency on another, 'parent' data set. This reflects to possibility
in the SimDM/Protocol to model relationships between different SimDM/OutputDataObjectType-s.
This is implemented using two references, one to the parent SimDM/OutputDataset, the other to the SimDM/Relationship.
|
| SimDM:/resource/experiment/OutputDataset.accessURL |
Represents an optional reference to a URL from which the SimDM/OutputDataset can be obtained. No statement is made on whether
this should represent a simple file for download, or a link to a web page with information how to obtain it.
|
| SimDM:/resource/experiment/OutputDataset.characterisation |
This collection contains the SimDM/StatisticalSummary of the different SimDM/Property-s of the objects in the parent's SimDM/OutputDataset.
|
| SimDM:/resource/experiment/OutputDataset.numberOfObjects |
Gives the number of objects in this SimDM/OutputDataset |
| SimDM:/resource/experiment/OutputDataset.object |
TODO : Missing description : please, update your UML model asap.
|
| SimDM:/resource/experiment/OutputDataset.objectType |
This reference to SimDM/DataObjectType indicates the type of data object stored in this collection. |
| SimDM:/resource/experiment/ParameterSetting |
To run an Experiment, one usually needs to assign values to parameters defined on the corresponding Protocol. This class makes
the association between the Experiment and the parameters, indicating which parameter is given what value.
Input parameters can be given any datatype from the DataType enumeration and hence it is in principle impossible to assign
a single datatype to the value attribute storing the parameter setting in this model. Whereas we might use a generic string
data type, this will in many implementations limit the use of query expressions that one might use for numerical values for
example.
As a work around the current design has two attributes, one of type real, one of type string. The former should be used for
numerical InputParanmeters, the latter for all others.
|
| SimDM:/resource/experiment/ParameterSetting.inputParameter |
Reference to the actual input parameter whose value is being set. |
| SimDM:/resource/experiment/ParameterSetting.numericValue |
Attribute that holds on to the actual parameter value in case the referenced input parameter is a numerical type. |
| SimDM:/resource/experiment/ParameterSetting.stringValue |
Attribute that holds on to the actual parameter value in case the referenced input parameter is not a numerical type. |
| SimDM:/resource/experiment/PostProcessing |
Represents an experiment that corresponds to the execution of a PostProcessor protocol. It manipulates a pre-existing result
to produce new results, but without introducing new physics.
|
| SimDM:/resource/experiment/PostProcessing.primaryExperiment |
The primary experiment whose results are being post-processed by this PostProcessing step. Simplifies looking up the original
experiments, but is in principle redundant with the inputData.
|
| SimDM:/resource/experiment/PostProcessing.protocol |
The post-processing protocol according to which the post-processing experiment is performed. Overrides the protocol reference
on Experiment.
|
| SimDM:/resource/experiment/PropertyValue |
Assign a value to a property of a data object. |
| SimDM:/resource/experiment/PropertyValue.numericValue |
It the property to which this value is assigned is numerical, use this attribute to represent the value. |
| SimDM:/resource/experiment/PropertyValue.property |
The property to which the value is assigned. |
| SimDM:/resource/experiment/PropertyValue.stringValue |
If the Property to which this value is assigned is not numeric, this attribute should be used to represent the value. |
| SimDM:/resource/experiment/Simulation |
This class represents the execution of simulation codes. Its protocol is therefore a SimDM/Simulator iso a general SimDM/Protocol.
It extends SimDM/Experiment by adding descriptions of the physical processes that were simulated
|
| SimDM:/resource/experiment/Simulation.appliedPhysics |
This collections associates this SimDM/Simulation to the SimDM/Simulator's SimDM/Physics that was actually used. This element
represents the possibility in most simulator codes to turn on or off specific physical processes in a simulation run. Examples
are the option to have a pure dark matter simulation in an SPH code. Or a hydro code without gravity.
The collection of SimDM/AppliedPhysics objects references thos modules that were actually used.
|
| SimDM:/resource/experiment/Simulation.protocol |
Reference to the SimDM/Simulator that was used to run this SimDM/Simulation.
Thie reference overrrides(subsets) the corresponding 'protocol' reference from SimDM/Experiment to SimDM/Protocol, indicating
that the type of the protocol reference must be a SimDM/Simulator, not just any SimDM/Protocol.
|
| SimDM:/resource/experiment/Statistic |
This enumeration lists possible statistics that can be used to characterise a collection of Property-s in a result. The literals
in this enumeration in general correspond to the result of simple statistical operation on this collection (when a posteriori)
or on the corresponding operation on the a priori probability distribtion (assuming this can be defined) of its values.
There is overlap between this enumeration and the 'stat' family of UCDs in the UCD controlled vocabulary (http://www.ivoa.net/Documents/REC/UCD/UCDlist-20070402.html).
Where this enumeration is used one might consider using a vocabulary based on those terms.
|
| SimDM:/resource/experiment/StatisticalSummary |
This class allows users to provide a statistical characterisation of a collection of objects in a specified SimDM/OutputDataset.
It represents both 'a priori' and 'a posteriori' characterisations. With a priori characterisation we indicate possible and/or
nominal [?] values the variable may take, it defines the possible range of values of the SimDM/Property. In contrast, an a
posteriori characterisation of a property in an collection provides summarising, likely statistical, information on the values
that were actually measured (i.e. observed, simulated) by the objects in the collection.
The a priori characterisation is most similar, in fact a generalisation of the Characterisation model of the IVOA Data Model
working group.
In the current model we stick to simple (numerical) quantities for characterising a collection of objects. For example the
equivalent value of a support from the CharacterisationDM is absent, as it is not terribly useful for discovery and querying,
even more so of course for concepts equivalent to sensitivity.
|
| SimDM:/resource/experiment/StatisticalSummary.aPriori |
If 'true', this attribute indicates that the statistical characterisation of a SimDM/Propertyis aPriori. That is it indicates
that the value says something about what the publisher believes are the possible values the SimDM/Property can assume. An
"p priori" characterisation is therefore a translation of the effects that the input configuration (SimDM/ParameterSetting,
SimDM/InputDataset), the "provenance-of-the-actual-experiment" therefore) is EXPECTED to have on the final result, represented
by the SimDM/OutputDataset-s and the SimDM/Property-s of their constituent objects.
Alternatively, if the value is "false", it indicates that the statistical charecterisation is 'a posteriori', i.e. it says
something about the actual values that were assumed. This requires in general some level of post processing beyond simply
storing the result, but in general using simple statistics such as mean and standard deviation that are not modelled as a
separate SimDM/Experiment.
|
| SimDM:/resource/experiment/StatisticalSummary.axis |
The SimDM/Property of the SimDM/ObjectType that is being characterised.
In the IVOA DM's characterisation model this is represented by specified objects, such as spatialaxis, timeaxis etc. Here
we do not know in advance which kind of property is characterised, hence this explicit reference.
|
| SimDM:/resource/experiment/StatisticalSummary.numericValue |
Summarising value of a numerical SimDM/Property in a collection of objects |
| SimDM:/resource/experiment/StatisticalSummary.statistic |
This attribute indicates which statistic is used to statistically summarise the referenced SimDM/ObjectType's SimDM/Property. |
| SimDM:/resource/experiment/StatisticalSummary.stringValue |
In case a string-typed property is summarised this attribute should be used to give the value. This would likely be applicable
to a restricted set of statistics such as nominal value.
|
| SimDM:/resource/protocol/ |
This package contains the SimDM/Protocol and classes used in its definition. |
| SimDM:/resource/protocol/Algorithm |
This class represents numerical algorithms available in a SimDM/Protocol.
In Simulators an algorithm may approximate a physical process. Examples from cosmological simulations are different algorithms
to implement gravity: direct particle-particle interaction, particle-mesh, or various types of tree based algorithms.
In post-processors such as cluster finder this class can represent a partiular cluster definition such as friends-of-friends
or spherical overdensity.
|
| SimDM:/resource/protocol/Algorithm.description |
Short description of this algorithm. |
| SimDM:/resource/protocol/Algorithm.label |
Short name by which this algorithm is known in the SKOS vocabulary of numerical algorithms. |
| SimDM:/resource/protocol/Algorithm.name |
A common name given to this algorithm.
|
| SimDM:/resource/protocol/InputDataObjectType |
Type of data objects that the protocol needs in its execution. |
| SimDM:/resource/protocol/InputDataObjectType.definition |
If not null, this reference provides the definition of the input data object type as being a predefined SimDM/OutputDataObjectType
of another SimDM/Protocol.
It's implication is that the current SimDm/Protocol requires the results of another SimDM/Protocol for its execution.
If this reference is null the input data object type must be defined using the properties inherited from the base object type.
|
| SimDM:/resource/protocol/InputDataObjectType.label |
Label indicating the type of data object represented by this InputDataObjectType through reference to a SKOS concept. |
| SimDM:/resource/protocol/InputParameter |
This class represent an input parameter on a protocol.
In general,a simulation codes needs the user to set values to parameters that govern the running of the code. These may be
parameters describing the physics in a simulation, or they may be numerical parameters governing the approximation of the
process by a particular algorithm.
|
| SimDM:/resource/protocol/InputParameter.label |
A label to be given to this input parameter from an appropriate SKOS vocabulary. |
| SimDM:/resource/protocol/OutputDataObjectType |
This class represents the type of data object that the container SimDM/Protocol can produce.
This concept includes any type of data object the protocol deals with.
It can range from the smallest data units such as individual N-Body particles or pixels in a synthetic spectrum, up to the
largest which may be a collection of snapshots in an N-body simulation ,each of them containing collections of particles.
It defines also the actual SimDM/OutputDataset-s that a SimDM/Experiment's has produced.
Since a SimDM/OutputDataObjectType is-a SimDM/ObjectType, it can be related to other objects using SimDM/Relationship-s.
In this way a hierarchy of data types can be described.
For example a spectrum can be a such a data object and will be composed of pixels. A FOF group catalogue will be composed
of FOF groups which are aggregations of particles.
|
| SimDM:/resource/protocol/OutputDataObjectType.label |
Name that this type of particle is given in an appropriate SKOS vocabulary. |
| SimDM:/resource/protocol/ParameterGroup |
Represents a (natural) grouping of SimDM/InputParameters.
Especially in protocols with large numbers of parameters it may be useful to group these
for browsing purposes for example. As browsing is likely an important mode of access to SimDM/Resource-s stored in a SimDB
for example, this possibility was introduced.
But the main use should be reserved for semantic groupings. For example all parameters together defining the cosmology a certain
simulation is run in. Or the parameters setting "merely" numerical properties such as smoothing lengths.
|
| SimDM:/resource/protocol/ParameterGroup.description |
Short description of the purpose of this group. |
| SimDM:/resource/protocol/ParameterGroup.member |
Collection of associative member objects, indicating which parameter is part of the group. |
| SimDM:/resource/protocol/ParameterGroup.name |
Name given to this group. |
| SimDM:/resource/protocol/ParameterGroupMember |
Associative class, representing a selection of a parameter in a parameter grouping. |
| SimDM:/resource/protocol/ParameterGroupMember.parameter |
Reference to the selected input parameter. |
| SimDM:/resource/protocol/Physics |
This class represents a physical processes that is modelled in a simulation code.
Simulating a physical process generally corresponds to solving equations of motion numerically, evolving the simulated system
from one state to the next.
|
| SimDM:/resource/protocol/Physics.description |
Short description of the physical process represented by this class. |
| SimDM:/resource/protocol/Physics.label |
The SKOS concept identifying this process in a standardised SKOS vocabulary. |
| SimDM:/resource/protocol/Physics.name |
Name by which this physical process is represented in the simulator code |
| SimDM:/resource/protocol/PostProcessor |
This concrete subclass of SimDM/Protocol represents protocols that deal with post-processing results of earlier experiments.
We do not specify the details of this type much further. Main difference with eg the SimDM/Simulator type is that NO new physical
processes are introduced/simulated in the processing of the previous results. Examples are cluster finders, visualisation
tools etc.
|
| SimDM:/resource/protocol/Protocol |
A SimDM/Protocol represents software code that can be used to run astrophysical simulations or to post-process simulation
results. A SimDM/Protocol defines the method by which SimDM/Experiment-s can be performed, like a blue-print, or template.
The SimDM/Protocol concept is separated out from the execution of its code in SimDM/Experiment, which allows us to reuse it
for all experiments using the same code.
The concept is a direct gemeralisation of the concept by the same name in Martin Fowler's book "Analysis Patterns: Reusable
Object Models" (Addison-Wesley Professional, 1996).
|
| SimDM:/resource/protocol/Protocol.algorithm |
This collection indicates which algorithms are available on the protocol.
|
| SimDM:/resource/protocol/Protocol.code |
link where the code can be downloaded, if available
|
| SimDM:/resource/protocol/Protocol.inputType |
Collection of object types that the Protocol may need for its execution. |
| SimDM:/resource/protocol/Protocol.outputType |
The collection of SimDM/OutputDataObjectType-s that can be produced by the parent SimDM/Protocol. |
| SimDM:/resource/protocol/Protocol.parameter |
Collection of input parameters for this protocol. |
| SimDM:/resource/protocol/Protocol.parameterGroup |
Collection of parameter groups. This is a utility colection, indicating that a particular grouping of parameters is natural.
Useful for browsing the protocol's contents.
|
| SimDM:/resource/protocol/Protocol.version |
the version of the simulator code that was used |
| SimDM:/resource/protocol/Simulator |
This class represents the simulation software that one uses to run a simulation. It is a special case of a SimDM/Protocol.
It is different from other SimDM/Protocols in that it explicitly defines the physical processes that are (can be) simulated.
This indeed is the defining characteristic of the SimDM/Simulator: it simulates/models physical processes. This in contrast
to a "mere" SimDM/PostProcessor which takes the input data and analyses it without adding new physics. It does not imply that
simulators can not use existing results. For example consider semi-analytical galaxy formation routines which work on existing
halo (merger) catalogues.
|
| SimDM:/resource/protocol/Simulator.physicalProcess |
Collection of physical processes that can be simulated using this simulator.
|
This section lists the profiles used by this data model.
Each pofile is described as if it were a model in its own right.
Packages are listed as in section 2. above.
Types defined in a profile are listed as in section 3.
This profile defines the domain specific UML dialect for the IVOA data modelling efforts.
This package stores predefined data types for use in defining attributes of types in the data model.
These types are generic and does not represent specific implementation types.
Hence for example we do not make a distinction between 2,4,8 byte integers or floats.
The numerical types instead correspond to the commonly used number fields: N,Z,Q,R,C.
Most types are primitive, i.e. they represent a single value and have no structure.
This datatype represents an identifier for an object in the data model. It consists of 3 attributes that each are assumed
to work in a particular context or representation of a data model instance.
