Comments on the Simulation Data Model

[Rick Wagner]

Hello,

Here is my second message, focusing on the contents of the data model  
Note.

> My comments below, which mainly try to explain (in the wordy way I  
> can not
> avoid)
> my motivations for particular choices.

>> My final comment is a suggestion for the contents of the Note
>> on the data model:
>>
>> 1) An overview of the model, including the packages and major
>> classes (Experiment, Protocol, Snapshots, etc.).
>>
>> 2) A discussion of how characterization is treated in the model.
>>
>> 3) XML Schemas for the top-level container classes (Protocol,
>> Experiment, etc.).
>>
> Agreed with this.
>
>> 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.

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.

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

>> 3, 4 and 5 can go in as appendices, and the automatically
>> generated documentation can either be an appendix or stay as
>> stand-alone document. Once TAP is sorted out, writing the
>> SimDB standard should mostly consist of writing an XML Schema
>> that subclasses the TAP registry schema, and providing
>> whatever description of the database schema is required for TAP.
>>
>
>
> Cheers
>
> Gerard

Likewise,
Rick