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 > Tutorial > Doing More > Managing Metadata
Mapping UCDs, Utypes and Units



 You must not map all ingested products but only classes. Even if you load millions of products but in one class, you will just have one mapping to do.

 All class keywords can be tagged by hand with UCDs, UTYpe, Unit, and a queriability flag. This feature is not supported at collection level yet. These tags can either by typed by hand (with some risk) or drag and dropped from a dictionary.

  • Open the class meta-data panel by a double click on that class on the data tree.
  • Open the meta-data popup by right clicking anywhere on the panel and select the Tag Meta Data item.

Metadata Popup

  • A tab panel gets open with 3 tabs (UCDs, UType and Units). Drag and drop the value you want to set on the meta-data row to be tagged. This row becomes highlighted. Don’t mind with the column where the value is dropped. The system recognized it by itself. Sometime a popup window asks for a choice about the comment. It proposes to merge the initial description of the keyword with this of the tag. Notice that the comment can be edited by hand anyway.

Mapping

  • Keywords must be declared as queriable to be used by the query engine in UCDs/UTypes based constraints (see). Queriable flags can be toggled on/off by a double click.
  • Once the tagging is over, open the meta-data popup by right clicking anywhere on the panel and select the Save Meta Data item. If the database has already been deployed, click on Deploy Web App. to update the meta data at the Tomcat server level.

 Why keywords must be declared as queriable

* If a table has 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]}
 

can be translated in 2 ways :

<WHERE v1 > 100 OR v2 > 100
 

or

<WHERE v1 > 100 AND v2 > 100
 

There is no indisputable reason to choose the OR or the AND operator. In other words, if a queried class as multiple keywords with the same UCDs, the query translation gets ambigous. To avoid that, only one keyword is used in a query translation. The issue is to know which one. The rule is that the first keyword having the requested UCD or UType and being queriable is used. We advice to declare only one column queriable for a given UCD or UType. Notice that the queriable flag is used by both UCDs ans UTYpes.

  • Another reason to choose one keyword to be queriable is given here. The satellite XMM-NEWTON has3 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] }
 

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

last update 2008-05-23