saada logo

 
  SAADA OVERVIEW
Home  
News  
Tutos and Links  
Download  
  Tutorial
Getting started  
Doing More  
SaadaQL  
The Web Interface  
VO Publishing  
Tips & Troubelshooting  
  COMMUNITY
Mailing List  
Saada Sites  
How to Contact us ?  
  DEVELOPER CORNER
Contributors  
Next Step  
Old Releases  
Inside Saada  
Using UWS  

 

SourceForge.net Logo


HOME ART > DEVELOPER CORNER > Old Releases > Saada 1.4.2 > TUTORIAL > Using your SaadaDB > SaadaQL
Constraints using UCDs

UCD (Unified Content Descriptors) is a categorization of any parameter present in a column of a table or catalogue in a predefined scheme. (see CDS UCD pages). Saada handles queries expressed with UCDs. But some features will be available with Saada 1.5.




 In the SaadaDB the data are stored in collections. All the collections have the same columns for each category given (spectra, picture, ...). Those columns are populated with values calculated by Saada or by values copied out from original data. So it may be possible to make selections of one or several collections. In fact there is a constraint, as far as you must only use collection level columns.

Such requests can not include constraints using the original keywords of the products. Those keywords can only be used if the outreach of the request is limited to one class that is to say, a dataset of a same collection with a similar format. (consult the following page classification).

A consequence of this organization is the fact that we can not select data in the whole base by using the native attributes.

 However, we can get round this limitation by using the UCDs. This requires the edition of the meta data associated to attributes.

  • An UCD can be set for each attribute of each database.
  • Each attribute which possess an UCD can be declared as being used in a request based on UCDs (Saada 1.5).
  • To each attribute one can associate another attribute containing the related error (Saada 1.5).
  • A unit can be affected to each attribute. You can choose this unit in a list of units supported by the Saada converter borrowed in CDS.

The use of a unit which is not listed is supported by converters if its elementary components (length, time ...) are identified.

 The definition of the UCDs is universal so they can be used to select data whatever the keywords are. SaadaQL suggests a clause showing the constraints with the UCDs.

  • The request
    Select IMAGE From * In *
    WhereUCD{[meta.id] = 'target' [none]}
       

select all the pictures of the base which do have at least one attribute with a UCD meta.id whose value is "target". In this case the units will be ignored.

  • The request
    Select ENTRY From * In *
    WhereUCD [src.veloc.hc] > 100000 [m/s]}

select the entries in all tables of the database. Those entries must have a radial velocity higher than 100000 m/s. The value of the operand (e.g. 100000) will be converted in the native units of each table consulted.

 Several columns of a table can match a given UCD. In that case the logical operator is applied.

  • If a table behaves two columns (v1 et v2) with the UCDsrc.veloc.hc and if those columns are given in km/s, the following clause :
    WhereUCD{  [src.veloc.hc] > 100000 [m/s]}
     

will be translated in that way :

<WHERE v1 > 100 OR v2 > 100
 

 In the example given previously we notice that the presence of several columns with the same UCD may alter the requests. That’s the reason why we advice you to declare only one column for an UCD used for requests based on UCDs (Saada 1.5).

  • The satellite XMM-NEWTON behaves 3 cameras X (M1, M2 and PN) giving a flux (UCD phot.flux) in addition with one merged flux (EP). If those four columns can be used by the UCDs, the following constraints
    WhereUCD{ [phot.flux] > 1e-14 [erg/sec/cm2] }
     

will be translated in SQL

WHERE ep_flux > 1e-14 OR m1_flux > 1e-14 OR m2_flux > 1e-14 OR pn_flux > 1e-14
 

In fact this is wrong because the merged value (ep_flux) is considered with the same level than the instrumental values (m1_flux, m2_flux and pn_flux)) which have been used to calculate it (we know nothing about the algorithm). We can raise this ambiguity if we only allow the attribute ep_flux to be used in those requests. We can also try to better define UCDs (phot.flux ;instr instead of a simple phot.flux).

 Our experience with those UCDs requests showed that we need to limit the complexity of the requets to get more comprehensive results. A limited set of operators have been defined for this reason.

operator operand role
= String or numeric equals to
 != String or numeric not equals to
> numeric greater than
>= numeric greater than or equals to
numeric lower than
<= numeric lower than or equals to
[] (numeric, numeric) in range, bounds excluded
[=] (numeric, numeric) in range, bounds included
][ (numeric, numeric) out of range, bounds excluded
]=[ (numeric, numeric) out of range, bounds included
  • In the clause WhereUCD the brackets are forbidden
  • The text columns can be used for every operator. Nevertheless the classification operation are done in the lexival order. For instance ’03’ < 2, whereas 3 > 2.

 The units must appear in the request. Use the word none if no unit is asked.

  • Request with no unit
    WhereUCD {
       [meta.id] = 'target' [none]
       }
  • Request with a unit
    WhereUCD {
       [phot.flux] > 1e-14 [erg/cm2/sec]
       }
  • If the unit is not recognized the request is going to fail.
  • If a unit is given tables which do not have a unit for a given UCD will be ignored by the query engine.
  • If there is no unit given, all the tables having this UCD are queried whatever the native units are.

 Constraints based on the UCDs can also consider associated errors (saaada 1.5). The association between a value and its error is set by hand with the UCD editor.

  • Erros are supposed to be expressed with the same units as parent values.
  • The columns with no related error are considerd as with null errors.
  • The ’*’ character placed after the operator indicates that errors must be taken in account (Saada 1.5).
Constraint traduction
=* val [=] (val-error, val+error)
 !=* val ][ (val-error, val+error)
>* val > val-error
>=* val >= val-error
<* val < val+error
<=* val <= val+error
[]* (val1, val2) [] (val1-error, val2+errror)
[=]* (val1, val2) [=] (val1-error, val2+errror)
][* (val1, val2) ][ (val1-error, val2+errror)
]=[* (val1, val2) ]=[ (val1-error, val2+errror)
last update 2007-08-09