Here a short summary of our ideas concerning SimDB: 
what it is supposed to be, what its current state is, and 
what further work is needed and which working groups we need 





1. We propose to create a specification for a Simulation Database (SimDB)
(could be called Simulation Registry, -Portal)

2. SimDB is an online service offering query capabilities to a database
containing meta data describing results of simulations and their 
post-processing as well as about the codes used in these algorithms.

3. A SimDB also contains information about web services giving access
to the simulation results themselves. The more detailed specification 
of such services is the goal of the SimDAP-specification.
 
4. SimDB is based on a logical data model (SimDB/DM), fully specified in UML2.
SimDB/DM contains (SimDB/)Resource-s. A SimDB/Resource is a "complete" description 
of an Experiment (Simulation, Post-Processing), or a Protocol (Simulator code, 
Post-Processing code, or a Project (collection of experiments performed to 
pursue a particular scientific goal. 
NB The SimDB/Project corresponds most closely to an IVOA Registry/Resource.

5. From SimDB/DM we derive physical models for use in their respective contexts:
 - The "public tables" of a relational data model, for implementing the database 
   in a RDBM system so that SQL (c.q. ADQL) queries can be easily implemented.
   NB really views on top of a set of tables
 - XML schema, defining an XML dialect for describing full SimDB/Resource-s.
   These can be sent to SimDB-s with the goal of registering new SimDB/Resource-s.
   These can be obtained form a SimDB if a request for a particular reource is made.
These two representations form the normative part of our specification.
 - We derive UTYPEs for the elements of the model.
 
6. We present XSLT scripts that derive these physical representations directly
from the XMI serialisation of the UML model according to predefined mapping rules.

7. We also derive Java classes with JPA and JAXB annotations to make it 
easy to implement a SimDB from the specification.

8. We suggest an implementation path to transform an existing relational database 
   to SimDB. Based on taking the global-as-view approach literal.

ISSUES/QUESTIONS/TODO:

 -- We need to iron out the wrinkles from the data model and check its relevance. 
   => We need input from domain experts (i.e. theorists) to see whether their
      work and results can actually be described by the model.
   => We need input from the DM WG (i.e. people with data modelling experience)
      on various aspects of the data model).
 

 -- Should a SimDB be stand alone, or should it be possible to have relations
    between SimDB/Resource-s in different SimDB-s?
    The answer to this has repercussions for the way we can/must represent UML
    references in XML and RDB. It may have repercussions for the functioning of
    a SimDB in case it is supposed to be stand alone (mirroring through harvesting
    of external resources may be required).
   => We would like to discuss these issues with the Registry WG who have experience
      with these
    
 -- Should a SimDB be read-only, i.e. represent the work of the groups publishing 
    their own results, or can external parties register their results in a near-by
    SimDB? I.e., is SimDB S*AP like, or Registry like (an extension?), 
    or something in between?
   => We'd like to discuss this with Registry and DAL WGs.
    
 -- We need a common vocabulary for certain attributes in the model that refer
    to astrophysical concepts and are likely prime targets for queries. we want
    to use existing ones, and may need to define new ones.
   => We would like to discuss this with the Semantics WG.

 -- We need a way to express formally that SimDB services offer a particular
    ADQL query interface, has a particular database schema etc. This may be necessary
    at runtime as well.
   => We think we need to discuss these issues with Registry and DAL(TAP) WGs.

 -- SimDB is a service that ADQL queries can be sent to and may(?) be thought
    of as a TAP service. However we'd rather not wait until TAPs specification 
    is done before starting out. 
   => We would like to discuss the issues arising from this within the context
      of TAP and likely also ADQL, i.e. need discussions with DAL and VOQL. 

 -- We see that our approach is working and viable and think it can be of use to
    other data modelling efforts.
   => We believe that it would be good if the DM WG could start efforts to
      come up with a set of meta-specifications on:
      - a UML profile defining a domain specific language for logical data models 
        in the IVOA.
        . mandating the use of XMI
        . (An internal XML representation of models mirroring the profile, 
          that can be automatically
          derived: To be independent of MXI (and have simpler representation 
          to write XSLT against).
        . ways to deal with ontologies(/semantic vocabs/thesauri/...)
      - mapping rules to transform these logical models to physical models as
        . XML Schema
        . Relational Data Model
        . UTYPE
        . (Java, C#, Python: to assist in manipulating these other representations
          in code).
        . (HTML documentation)