The SaadaDB datamodel has an object flavour. The mapping of a SaadaDB as a set of VO services needs some attention.

 Mapping Saada collection/classes

The Saada data model is based on the concepts of collections , classes which and N-M relationships. In other words, Saada has an object flavour, whereas VO basic services are well suited for tabular data. VO queries on sources, images, spectra or other can be handled by SaadaQL queries. In fact SaadaQL can do quite more things. For instance SaadaQL correlation patterns have no equivalence in any VO protocols (2007). SaadaQL returns OID sets which can easily transformed in VOtables. The issue is to map datasets defined by collections and classes into VO resource. Each combination of collection/class/category can be seen as resource. Thetable below shows the mapping rule.

 There is of course no reason to publish in the VO all possible resources. That makes no sense and that is confusing for people readin registries.

 Example A SaadaDB with two collections coll1 and coll2, each one with 2 classes class11 and class12 for coll1 and class21 and class22 for coll2 has 7 possible distinct ressources :

The number of combinations will of course explode when the number of classes increases.

 Thumbrules.
 The natural entity to be publish in the VO is the collection. Collections are supposed to gather data having good reasons to be together.
 Resources published at collection level will only return collection level columns (attributes). If you want your resources to deliver all columns, try to have only one class in the collection. That can be achieved by using an appropriate mapping (see). In that case you have to publish your resource as [collection(classe)]. That wonly works for one collection.

 The VO portal proposes all resources with just one collection or one collection plus one class ni adddition with the whole database.