Comments on the Simulation Data Model

[Gerard]

Hi Rick 

> >> 4) VOTable serializations of the the container classes. 
> (This is of 
> >> particular interest to me, since I've been working on that 
> as part of 
> >> the SimDAP Note.)
> >>
> > Why do you think this is necessary?
> > So far we considered to use TAP as one side of the protocol , and 
> > consequently to use its prescription for specifying the tabular 
> > representation of the model.
> > This may come in a variety of forms, VODataService, 
> TAP_SCHEMA tables, 
> > possibly VOTable.
> > But the later is not the main one for TAP as far as I see.
> 
> Not for TAP, but the data model should be usable across as 
> many theory services as possible. For SimDAP, if the service 
> returns a list of experiments, or snapshots, it should use 
> the same data model, rather than define its own classes and 
> attributes. Instead, we've been working on how SimDAP should 
> map the simulation data model classes onto the  VOTable 
> Resource, Info and Param elements of a response. We can 
> provide these mappings in the SimDAP document, or they could 
> be part of the data model document.
> 
It would be nice if more services would "use the data model", sure.
But what that precisely means has not really been discussed much in the
IVOA.
In the SimDB note the mapping of the model to representations to be used by
the TAP and REST interfaces will be given.
This is because those interfaces are part of the specification.

The difference with the data model usage for SimDAP is that in SimDB the
complete data model is used.
I.e. the representations for TAP and REST are in information ocntent
equivalent to the UML data model.
I expect and have gathered form our previous discussion, that this is
overkill for SimDAP.
I would hope, and am pretty sure it is possible that the model used by
SimDAP is derived from the SimDB/DM.
We discussed in the past phrasing it as a view/query over the database
schema.
Alternatively as an XSLT transformaiton of the model into an appropriate XML
form


> Of course, this goes back to our discussion in Trieste about 
> splitting the work SimDB into a document on the data model, 
> and a document on the TAP interface. In my mind, there are 
> three documents that need to be written: Simulation Data 
> Model (SimDM); Simulation Database (SimDB); Simulation Data 
> Access Protocol (SimDAP). The SimDM document should define 
> the data model independent of the access protocol, and 
> provide as many serialization formats as we think are appropriate.
> 
> While there doesn't need to be separate documents, I think 
> it's the simplest mechanism to make the data model 
> independent, and increase its usability across different services.
> 
I am trying to keep SimDM and SimDB in one document.
But am separating it in a data model part and a protocol part, very much as
you suggest.

> >> 5) The table and catalog definitions can in as a reference 
> for anyone 
> >> building a VODataService using the model.
> > Is this equivalent to what I suggested in the previous comment?
> 
> I believe so. What I'm hoping is that a VODataService 
> description of the database schema is included in any 
> document covering the data model. This way, we can build 
> services with a common schema, even if the TAP standard is 
> delayed. And when TAP is accepted, we'll have less work to do 
> to finish the SimDB standard.
> 
This will be done.
I would hope though that the VODataservices description of a TAP service is
equivalent to the TAP metadata.

Cheers

Gerard