(back to main)
By design, SimDB "is a" TAP service. It is a TAP service in that it presumes that metadata is stored in a relational database and ADQL queries can be sent to it to query about its contents. It specialises TAP in that it defines what the data models is according to which the database is designed. I.e. all tables/columns etc are fully specified and all SimDB implementations must folow that data model.

We use TAP in full generality rather than a predefined parameterised query language because it offers greatest flexibility. Targeted clients can always wrap the ADQL interface with parametrised forms if they so desire.

In a later stages/versions we may consider allowing other query langugages, for example XQuery. In version 1.0 we want to apply the existing IVOA query language.

The SimDB/TAP_SCHEMA is derived form the SimDB data model described [[][elsewhere]]. It is derived following a prescribed set of object-relational mapping rules.

TODO

Following issues must be discussed, sometimes together with DM WG and Theory IG

• TAP representation of the data model
  • how to formally specify the data model in a spec? Suggestion: filed-in VOTable containing complete TAP_SCHEMA.
  • how to specify inheritance in TAP model? Views?
• SimDB as specialisation of TAP
  • only sync+ADQL MUST be supported
  • Data model

Comments: TAP Representation

In addition to a VOTable that can be returned by a tableset-query, we should also provide a sample Registry document that has the VODataService table set filled in.

-- RickWagner - 19 May 2009

(back to main)