GerardLemson_SimDB_Notes < IVOA



<br/>
<hr/>
We aim to construct a specification (!SimDB) for a protocol enabling discovering and accessing interesting simulations.

Approach
   * We build this spec around a data model describing simulations, i.e. a _meta-data model_.
   * We start with an abstract, application independent model (_domain momdel_ or _analysis model_)
      * Following "standard" modelling apporaches: analysis -> logical -> physical
   * MAYBE we derive from the domain model a separate applicationd _dependent_, _logical model_ (currently logical and domain model are the same)
   * !SimDB/DM is designed in [[http://en.wikipedia.org/wiki/Unified_Modeling_Language][UML]]
      * UML is stored in [[http://en.wikipedia.org/wiki/XML_Metadata_Interchange][XMI]]
      * Model is drawn using [[http://www.magicdraw.com][MagicDraw]] Community Edition 12.1 and stored in its XMI format
      * We follow a predefined UML [[http://en.wikipedia.org/wiki/Profile_(UML)][profile]]
      * The particular profile can be found [[http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/IVOA%20UML%20Profile%20v-3.xml][here]]
         * ALso in appendix to the Note
      * Profile is mapped to "intermediate representation", XML schema file 
        [[http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/specification/uml/intermediateModel.xsd][intermediateModel.xsd]] 
      * UML aims to be comprehensive, i.e. contains all documentation etc.
   * We use the (intermediate representation of the) (logical) model to derive physical representations that can be used in implementations:
      * A relational schema, basis for a specialised TAP protocol
         * we use object-relational mapping rules (implemented in an XSLT script) to derive the relational schema directly from the UML
         * ISSUES
            * treatment of inheritance hierarchies
      * An XML schema (actually a set of XML schema documents), defining valaid SimDB/XML documents
         * We use mapping rules to derive the XML schema directly from the UML. rules similar to those used in registry/VOTable schemas.
         * ISSUES
            * Mapping _references_.
      * an [[][HTML document]], for human consumption
      * a list of UTYPEs, to be used for example in VOTable results of ADQL queries to !SimDB/TAP 
         * we use rules to derive the UTYPEs directly from the UML 
         * the UTYPEs are defined in the HTML document

Contents of model.
   * Model in [[http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/specification/uml/SimDB_DM.xml]]
   * Use of packages: simdb, protocol, experiment, object, dal
   * Anchored in _Resource_, base class of _Experiment_(_Simulation_,_PostProcessing_), _Protocol_ (_Simulator_,_PostProcessor_), _Project_, _WebService_
      * NB to Registry+DM: !SimDB/Resource similar to, but not identical with Resource Model's _Resource_. 
        Some of them (Protocol, Project, WebService, some Experiments) could be Registry/Resources as well. 
        We propose to create particular representations of these in terms of the Resource data model.
   * 

Usage of model
   * Model is heavily normalised, hence the possible need for a _denormalized_ version of the model (e.g. [[http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/specification/uml/SimDB_DM_denormalised.xml]])
      * NB to DM: IF we produce a logical model separate from the domain model, how should we treat this? 
        2 separate models, 1 model? How do we relate one to the other? UTYPE as part of profile? (that is current proposal here).








<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
This topic: IVOA > GerardLemson > GerardLemson_SimDB_Notes
Topic revision: r1 - 2009-05-03 - GerardLemson