IVOATheorySimDB_Check < IVOA

The tables on this page summarise decisions taken during first the SNAP, then the !SimDB projects. 
These issues were discussed mainly in a small core group ("tiger team") of developers who on and off 
included  Laurent Bourges, Igor Chillingarian, Claudio Gheller,  Norman Gray,Franck !LePetit, Mireille Louys, 
Patrizia Manzato, Rick Wagner, Herve Wozniak (and others who have not been forgotten).

For the further development of !SimDB (and possibly !SimDAP) it may be useful to list these and possibly reevaluate them. The issues are subdivied in a few subjects:

   * [[#SimDBDefinition][definition]] of !SimDB as a DAL service
   * [[#DataModellingMethodology][data modelling methodology ]]
   * [[#DataModelContents][data model contents]]
   * [[#SimDBTAP][SimDB as a TAP service]]
   * [[#SimDBRegistry][SimDB and Registry]]

#SimDBDefinition
---+++ Definition of !SimDB as a DAL service
(starting with SNAP)
|*Item*|*OK*|*NOT OK*|*Comment*|
| SNAP is a DAL protocol for simulations<sup>[[#SimDBDefinition1][1]]</sup>| | | Initiated in [[IVOA.CambridgeTheoryWorkshopFeb06][theory workshop]] in Cambridge Feb 2006  |
| SNAP follows SSA: data model + protocol<sup>[[#SimDBDefinition2][2]]</sup> | | | Victoria interop, 2006 |
| | | | |
|SNAP data model complex, queryData requires registry-like approach|||Discussed in April 2007 SNAP meeting of core participants (up till then), Garching|
|SNAP separated into !SimDB and !SimDAP  | | |formally announced in 2008 Trieste interop, agreed by "tiger team" before |
|!SimDB is a protocol for finding interesting simulations and postprocessing experiments and their results | | | |
|!SimDB implements "queryData" part of "simple" DAL protocols | | | |
|"getData" part is implemented by !SimDAP or custom services| | | |
|!SimDB development uses [[http://code.google.com/p/volute/wiki/TheoryHome][Volute]] | | |Decision "tiger team", early 2008 |
| | | | |


#SimDBDefinition1<sup>1</sup> The idea was to follow SIAP and apply it to N-body simulations. Later expanded to  include other 3+1D simulations such as Adaptive Mesh Refinement (AMR).

#SimDBDefinition2<sup>2</sup> First attempt was SIAP based, but by Victoria interop SSA was the preferred (input from DAL group) approach.



#DataModellingMethodology
---+++ !SimDB data modelling methodology
|*Item*|*OK*|*NOT OK*|*Comment*|
|!SimDB/DM represented in UML class diagram<sup>[[#DataModellingMethodology1][1]]</sup> | | | Follows decision in Cambridge interop 2003. |
|!SimDB/UML is self documenting<sup>[[#DataModellingMethodology2][2]] | | |  This was decision of core designers (GL, RW, LB), presented in 2008 Trieste Interop|
|!SimDB/DM's UML stored as XMI document (ASCII) | | | XMI is standard XML format for representing UML documents. |
|!SimDB uses !MagicDraw Community Edition 12.1 for the XMI<sup>[[#DataModellingMethodology4][4]]4</sup> | | |  |
|!SimDB/DM uses a predefined UML profile<sup>[[
#DataModellingMethodology4][5]]</sup> | | | Simplicity, standard approach to domain specific languages. |
|Propose an intermediate XML format for representing DMs following profile. | | | Originated in VO-URP development. In practice very useful. Very much more readable than XMI. in principle hand-editable. Core of VO-URP TAP/XSD/HTML/UTYPE/Java/DDL/... generation.|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |

#DataModellingMethodology1<sup>1</sup> Though the decision in Cambridge never went into any detail, we use Class Diagram as that is best able to represent the static structure of data models that need to be represented in different formats (XML, TAP_SCHEMA, etc).

#DataModellingMethodology2<sup>2</sup>All entities and classes must be properly documented. !SimDB/Note gives background and context, UML model _should_ be sufficient to define complete model.

#DataModellingMethodology4<sup>4</sup> Freely available tool, ESO has commercial version. Should not be necessary to specify a tool, as XMI should deal with that, but in practice useful to "insist" on one


#DataModellingMethodology5<sup>5</sup>Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal representation (Appendix in Note) and formal implementation (a UML2 profile generated by ESO, updated in course of design). 


#DataModelContents
---+++ !SimDB/DM contents
|*Item*|*OK*|*NOT OK*|*Comment*|
| !SimDB aims at describing "large/3+1D simulations"| | | In principle only Snapshot iso more generic Result class is explicitly 3+1D |
|"getData" services can be foud in !SimDB | | | |
| | | | |

#SimDBTAP
---+++ !SimDB/TAP
|*Item*|*OK*|*NOT OK*|*Comment*|
| | | | |
|!SimDB _is a_ TAP service| | | first discussed April 2007 Garching|
|!SimDB's TAP_SCHEMA predefined | | | Allows for integration: same ADQL can be sent to all !SimDB services.|
|!SimDB/TAP_SCHEMA derived from !SimDB/DM using predefined OR-mapping rules| | | |
|!SimDB/TAP's OR mapping rules uses  | | | |
| | | | |
| | | | |

#SimDBRegistry
---+++ !SimDB and Registry
|*Item*|*OK*|*NOT OK*|*Comment*|




<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
This topic: IVOA > IvoaTheory > IVOATheorySimDB > IVOATheorySimDB_Check
Topic revision: r8 - 2009-05-03 - GerardLemson