GerardLemson_SimDB_Notes < IVOA

---+++DM
Should support discovery, therefore should contain all concepts that may be of interest.
These should be available to user as search terms or as metadata informaiton in the results of queries.

   * !SimDB in UML, ok?
   * !SimDB in XMI, ok?
      * UML follows a profile, is the profile ok?
      * Profile is mapped to interemediate XML representation (following schema!), is that a good idea?
   * UML is documented usin an HTML document, with a particular format. Is that OK?
   * The logic behind the !SimDB model (!SimDB/DM) will be written up in a Note. 
     Together with HTML, will that be sufficient for reuse by others (e.g. !SimDAP, S3)?
   * We define UTYPEs for all elements in the model (see the HTML doc). We follow a particular syntax, is that ok? 
     [NB use of a "/" as package/package and package/class separator can be easily changed to a "."]
   * We subdivide the model in packages (ala namespaces in XML) to demarcate common definitions in the model
     and relations between (groups of) these. Is that ok?
   * We require externally defined _semantic (SKOS?) vocabularies_. These define lists of valid values that certain special types
     of attributes MUST (SHOULD?) be chosen from. Some of these already exists, others must still be defined. Is that ok?
     NB there is a TIG effort underway to define new lists targeted to simulations. 
   * We provide a representation (mapping) of the data model to XML schemas. We follow a particular set of rules.
     Are the particular rules we use ok? [TBD link to "rules" in Note]
   * We provide a representation (mapping) of the data model to relational database schemas. 
     We follow a particular set of object relational mapping rules.
     Are the particular rules we use ok? [TBD link to "rules" in Note]
   * Is the use of the data model as a data model for a database ok?
   * We have a normalised model and a proposal for a denormalised version of it (can be completely derived using XSLT
     both forward and beckward). Can we specify them together as a single model, or should they be separate specs?
   * The approach using a hierarchy of models: conceptual(or analysis/domain)-logical-physical, is that ok?
     See [[http://en.wikipedia.org/wiki/Data_modeling#Conceptual.2C_logical_and_physical_schemes][Wikepedia entry]]





<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.
   * We use a _WebService_ class as generalisation to accessURL in standard DAL protocols, to implement
     the issue that on the one hand many results are too large to download simply and 2) we want to
     support all interesting custom services as well as standardised ones such as !SimDAP.
   * We allow a kind of _characterisation_ of results. We use here the proposed Characterisation domain model
     as presented for example in [[http://www.ivoa.net/internal/IVOA/InterOpMay2007DataModel/CharacterisationInTheDomain.ppt][this presentation]].
   * We use in several places special attributes that SHOULD (MUST?) take values in a shared semantic vocabulary of terms. 

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: r2 - 2009-05-03 - GerardLemson