Difference: IVOATheorySimDB_Check (1 vs. 9)

Revision 92012-06-26 - root

 
META TOPICPARENT name="IVOATheorySimDB"
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:

Definition of SimDB as a DAL service

(starting with SNAP)
Item OK NOT OK Comment
SNAP is a DAL protocol for simulations1     Initiated in theory workshop in Cambridge Feb 2006
SNAP follows SSA: data model + protocol2     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 Volute     Decision "tiger team", early 2008
       

1 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).

2 First attempt was SIAP based, but by Victoria interop SSA was the preferred (input from DAL group) approach.

SimDB data modelling methodology

Item OK NOT OK Comment
SimDB/DM represented in UML class diagram1     Follows decision in Cambridge interop 2003.
SimDB/UML is self documenting2     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 XMI44      
|!SimDB/DM uses a predefined UML profile[[ ][5]] | | | 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.
       
       
       
       
       
       

1 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).

2All entities and classes must be properly documented. SimDB/Note gives background and context, UML model should be sufficient to define complete model.

4 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

5Aimed 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).

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      
       

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      
       
       

SimDB and Registry

Item OK NOT OK Comment

Revision 82009-05-03 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Changed:
<
<
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).
>
>
The tables on this page summarise decisions taken during first the SNAP, then the SimDB projects.
Added:
>
>
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:

Definition of SimDB as a DAL service

(starting with SNAP)
Item OK NOT OK Comment
Changed:
<
<
SNAP is a DAL protocol for simulations1     Initiated in theory workshop in Cambridge Feb 2006
SNAP follows SSA: data model + protocol     Victoria interop, 2006
>
>
SNAP is a DAL protocol for simulations1     Initiated in theory workshop in Cambridge Feb 2006
SNAP follows SSA: data model + protocol2     Victoria interop, 2006
Added:
>
>
       
 
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 Volute     Decision "tiger team", early 2008
       
Changed:
<
<
1
>
>
1 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).
 
Added:
>
>
2 First attempt was SIAP based, but by Victoria interop SSA was the preferred (input from DAL group) approach.

 

SimDB data modelling methodology

Item OK NOT OK Comment
SimDB/DM represented in UML class diagram1     Follows decision in Cambridge interop 2003.
SimDB/UML is self documenting2     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 XMI44      
|!SimDB/DM uses a predefined UML profile[[ ][5]] | | | 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.
       
       
       
       
       
       

1 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).

2All entities and classes must be properly documented. SimDB/Note gives background and context, UML model should be sufficient to define complete model.

4 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

5Aimed 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).

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      
       

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      
       
       

SimDB and Registry

Item OK NOT OK Comment
Changed:
<
<

>
>
Added:
>
>
 
<--  
-->

Revision 72009-05-03 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Changed:
<
<
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 of developers (GL, Laurent Bourges, Rick Wagner, Claudio Gheller, Franck LePetit, Herve Wozniak with input from Patrizia Manzato, Mireille Louys, Igor Chillingarian, Norman Gray and participants of a small workshop, Apruil 2007 in Garching).
>
>
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:

Changed:
<
<

Approach to SimDB (starting with SNAP)

>
>

Definition of SimDB as a DAL service

Added:
>
>
(starting with SNAP)
 
Item OK NOT OK Comment
Changed:
<
<
SNAP is a DAL protocol for simulations1     initiated in theory workshop in Cambridge 2006
SNAP follows SSA:data model + protocol     (Victoria interop, 2006)
>
>
SNAP is a DAL protocol for simulations1     Initiated in theory workshop in Cambridge Feb 2006
SNAP follows SSA: data model + protocol     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      
Added:
>
>
SimDB development uses Volute     Decision "tiger team", early 2008
 
       
Deleted:
<
<
       
 
Changed:
<
<
1 bla
>
>
1
 

SimDB data modelling methodology

Item OK NOT OK Comment
Changed:
<
<
SimDB/DM represented in UML class diagram     UML aspect follows decision in Cambridge interop 2003. Class diagram seems obvious (?)
>
>
SimDB/DM represented in UML class diagram1     Follows decision in Cambridge interop 2003.
 
SimDB/UML is self documenting2     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.
Changed:
<
<
SimDB uses MagicDraw Community Edition 12.1 for the XMI     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
SimDB/DM uses a predefined UML profile     Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal (Appendix in Note) + formal (a UML2 profile generated by ESO, updated in course of design).
Propose an intermediate XML format for representing DMs following profile.     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.
>
>
SimDB uses MagicDraw Community Edition 12.1 for the XMI44      
|!SimDB/DM uses a predefined UML profile[[ ][5]] | | | Simplicity, standard approach to domain specific languages. |
Added:
>
>
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.
 
       
       
       
       
       
       
Added:
>
>
1 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).
 
Changed:
<
<
2All entities and classes must be properly documented. SimDB/Note gives background and context, UML model should be sufficient to define complete model.
>
>
2All entities and classes must be properly documented. SimDB/Note gives background and context, UML model should be sufficient to define complete model.
 
Added:
>
>
4 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

5Aimed 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).

 

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      
       

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      
       
       

SimDB and Registry

Item OK NOT OK Comment


<--  
-->

Revision 62009-05-03 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
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 of developers (GL, Laurent Bourges, Rick Wagner, Claudio Gheller, Franck LePetit, Herve Wozniak with input from Patrizia Manzato, Mireille Louys, Igor Chillingarian, Norman Gray and participants of a small workshop, Apruil 2007 in Garching).

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:

Deleted:
<
<
  • definition of SimDB as a DAL service
  • data modelling methodology
  • data model contents
  • SimDB as a TAP service
  • SimDB and Registry
 
Added:
>
>

 

Approach to SimDB (starting with SNAP)

Changed:
<
<
Item OK NOT OK Comment
SNAP is a DAL protocol for simulations     initiated in theory workshop in Cambridge 2006
>
>
Item OK NOT OK Comment
SNAP is a DAL protocol for simulations1     initiated in theory workshop in Cambridge 2006
 
SNAP follows SSA:data model + protocol     (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      
       
       
Added:
>
>
1 bla

 

SimDB data modelling methodology

Changed:
<
<
Item OK NOT OK Comment
>
>
Item OK NOT OK Comment
 
SimDB/DM represented in UML class diagram     UML aspect follows decision in Cambridge interop 2003. Class diagram seems obvious (?)
Changed:
<
<
SimDB/UML is self documenting     All entities and classes must be properly documented. SimDB/Note gives background and context, UML model is in principle sufficient. This was decision of core designers (GL, RW, LB), presented in 2008 Trieste Interop
>
>
SimDB/UML is self documenting2     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     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
SimDB/DM uses a predefined UML profile     Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal (Appendix in Note) + formal (a UML2 profile generated by ESO, updated in course of design).
Propose an intermediate XML format for representing DMs following profile.     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.
       
       
       
       
       
       
Added:
>
>
2All entities and classes must be properly documented. SimDB/Note gives background and context, UML model should be sufficient to define complete model.

 

SimDB/DM contents

Changed:
<
<
Item OK NOT OK Comment
>
>
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      
       
Added:
>
>
 

SimDB/TAP

Changed:
<
<
Item OK NOT OK Comment
>
>
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      
       
       
Changed:
<
<
>
>
 

SimDB and Registry

Changed:
<
<
>
>
Item OK NOT OK Comment
 


<--  
-->

Revision 52009-05-02 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Changed:
<
<
Tables contain points that have been discussed during the SimDB project (including preceding SNAP part).
>
>
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 of developers (GL, Laurent Bourges, Rick Wagner, Claudio Gheller, Franck LePetit, Herve Wozniak with input from Patrizia Manzato, Mireille Louys, Igor Chillingarian, Norman Gray and participants of a small workshop, Apruil 2007 in Garching).
 
Changed:
<
<
Approach to SimDB
>
>
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:
Added:
>
>
  • definition of SimDB as a DAL service
  • data modelling methodology
  • data model contents
  • SimDB as a TAP service
  • SimDB and Registry

Approach to SimDB (starting with SNAP)

 
Item OK NOT OK Comment
Added:
>
>
SNAP is a DAL protocol for simulations     initiated in theory workshop in Cambridge 2006
 
SNAP follows SSA:data model + protocol     (Victoria interop, 2006)
Changed:
<
<
SimDB requires registry-like approach Discussed in April 2007 SNAP meeting of core participants (up till then), Garching
>
>
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
Changed:
<
<
SimDB is a protocol for finding interesting simulation and postprocessing experiments and their results      
>
>
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      
       
       
Changed:
<
<
SimDB data modelling methodology
>
>

SimDB data modelling methodology

 
Item OK NOT OK Comment
SimDB/DM represented in UML class diagram     UML aspect follows decision in Cambridge interop 2003. Class diagram seems obvious (?)
SimDB/UML is self documenting     All entities and classes must be properly documented. SimDB/Note gives background and context, UML model is in principle sufficient. 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     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
SimDB/DM uses a predefined UML profile     Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal (Appendix in Note) + formal (a UML2 profile generated by ESO, updated in course of design).
Propose an intermediate XML format for representing DMs following profile.     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.
       
       
       
       
       
       
Changed:
<
<
SimDB/DM contents
>
>

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      
       
Changed:
<
<
SimDB/TAP
>
>

SimDB/TAP

 
Item OK NOT OK Comment
       
SimDB is a TAP service     first discussed April 2007 Garching
Changed:
<
<
SimDB's TAP_SCHEMA predefined     Allows for integration: same ADQL can be sent to all SimDB services.
>
>
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      
       
       
Changed:
<
<
>
>

SimDB and Registry

 


<--  
-->

Revision 42009-05-02 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Tables contain points that have been discussed during the SimDB project (including preceding SNAP part).

Approach to SimDB

Item OK NOT OK Comment
SNAP follows SSA:data model + protocol     (Victoria interop, 2006)
SimDB requires registry-like approach Discussed in April 2007 SNAP meeting of core participants (up till then), Garching
Changed:
<
<
SNAP->!SimDB+!SimDAP     formally announced in 2008 Trieste interop, agreed by "tiger team" before
>
>
SNAP separated into SimDB and SimDAP     formally announced in 2008 Trieste interop, agreed by "tiger team" before
 
SimDB is a protocol for finding interesting simulation and postprocessing experiments and their results      
SimDB implements "queryData" part of "simple" DAL protocols      
"getData" part is implemented by SimDAP or custom services      
       
       

SimDB data modelling methodology

Item OK NOT OK Comment
SimDB/DM represented in UML class diagram     UML aspect follows decision in Cambridge interop 2003. Class diagram seems obvious (?)
SimDB/UML is self documenting     All entities and classes must be properly documented. SimDB/Note gives background and context, UML model is in principle sufficient. 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     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
SimDB/DM uses a predefined UML profile     Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal (Appendix in Note) + formal (a UML2 profile generated by ESO, updated in course of design).
Propose an intermediate XML format for representing DMs following profile.     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.
       
       
       
       
       
       

SimDB/DM contents

Item OK NOT OK Comment
Changed:
<
<
       
>
>
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      
       

SimDB/TAP

Item OK NOT OK Comment
       
Changed:
<
<
SimDB is a TAP service     first discussed April 2007 Garching
>
>
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      
Changed:
<
<
SimDB/TAP's OR mapping rules uses      
>
>
SimDB/TAP's OR mapping rules uses      
 
       
       


<--  
-->

Revision 32009-04-30 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Tables contain points that have been discussed during the SimDB project (including preceding SNAP part).

Approach to SimDB

Item OK NOT OK Comment
SNAP follows SSA:data model + protocol     (Victoria interop, 2006)
SimDB requires registry-like approach Discussed in April 2007 SNAP meeting of core participants (up till then), Garching
SNAP->!SimDB+!SimDAP     formally announced in 2008 Trieste interop, agreed by "tiger team" before
SimDB is a protocol for finding interesting simulation and postprocessing experiments and their results      
SimDB implements "queryData" part of "simple" DAL protocols      
"getData" part is implemented by SimDAP or custom services      
       
       
Changed:
<
<
SimDB/DM represented in UML     Follows decision in Cambridge interop 2003!
SimDB/UML is self documenting     SimDB/Note gives background and context, UML model is in principle sufficient (decision of core designers), presented in 2008 Trieste Interop
SimDB/DM's UML stored as XMI document     XMI is standard XML format for representing UML documents
SimDB uses MagicDraw Community Edition 12.1 for the XMI     freely available tool, ESO has commercial version
>
>
SimDB data modelling methodology
Item OK NOT OK Comment
SimDB/DM represented in UML class diagram     UML aspect follows decision in Cambridge interop 2003. Class diagram seems obvious (?)
Added:
>
>
SimDB/UML is self documenting     All entities and classes must be properly documented. SimDB/Note gives background and context, UML model is in principle sufficient. 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     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
SimDB/DM uses a predefined UML profile     Aimed to simplify models and promote interoperability by presenting uniform DM langugage fo the IVOA. Restriction + extension of UML, currently informal (Appendix in Note) + formal (a UML2 profile generated by ESO, updated in course of design).
Propose an intermediate XML format for representing DMs following profile.     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.
 
       
       
Added:
>
>
       
       
       
       
 
Changed:
<
<
On the contents of the data model
>
>
SimDB/DM contents
 
Item OK NOT OK Comment
Added:
>
>
       
 
"getData" services can be foud in SimDB      
       
Added:
>
>
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      
       
       
 


<--  
-->

Revision 22009-04-30 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"
Added:
>
>
Tables contain points that have been discussed during the SimDB project (including preceding SNAP part).
 
Changed:
<
<
>
>
Approach to SimDB
Deleted:
<
<
 
Item OK NOT OK Comment
Added:
>
>
SNAP follows SSA:data model + protocol     (Victoria interop, 2006)
SimDB requires registry-like approach Discussed in April 2007 SNAP meeting of core participants (up till then), Garching
SNAP->!SimDB+!SimDAP     formally announced in 2008 Trieste interop, agreed by "tiger team" before
SimDB is a protocol for finding interesting simulation and postprocessing experiments and their results      
SimDB implements "queryData" part of "simple" DAL protocols      
"getData" part is implemented by SimDAP or custom services      
 
       
       
SimDB/DM represented in UML     Follows decision in Cambridge interop 2003!
Changed:
<
<
SimDB/UML is self documenting     Note gives background and context, UML model is in principle sufficient
SimDB/DM's UML formally stored as XMI document     XMI is standard XML format for representing UML documents
SimDB uses MagicDraw Community Edition 21.1 for the XMI      
>
>
SimDB/UML is self documenting     SimDB/Note gives background and context, UML model is in principle sufficient (decision of core designers), presented in 2008 Trieste Interop
SimDB/DM's UML stored as XMI document     XMI is standard XML format for representing UML documents
SimDB uses MagicDraw Community Edition 12.1 for the XMI     freely available tool, ESO has commercial version
 
       
       
Added:
>
>
On the contents of the data model
Item OK NOT OK Comment
"getData" services can be foud in SimDB      
       
 


<--  
-->

Revision 12009-04-30 - GerardLemson

 
META TOPICPARENT name="IVOATheorySimDB"

Item OK NOT OK Comment
       
       
SimDB/DM represented in UML     Follows decision in Cambridge interop 2003!
SimDB/UML is self documenting     Note gives background and context, UML model is in principle sufficient
SimDB/DM's UML formally stored as XMI document     XMI is standard XML format for representing UML documents
SimDB uses MagicDraw Community Edition 21.1 for the XMI      
       
       


<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback