metadata

MetaData Management

The TAP meta-data are not detailed enough to automatically select what is relevant to be displayed and to say how to use it.

We need to hard-code some rules that must be applied to meta-data either loaded from the current service or themselves hard-coded.

All this logic must be implemented in a specific module formerly named reservoir sémantique

Service Descriptor

In order to avoid full URL hard-coded in the JS we can have a dictionnary hosting the main parameters attached to services.

{
  "SIMBAD": {
    "url": "http://simbad.u-strasbg.fr/simbad/sim-tap/sync",
    "format": "votable",
    "lang": "adql",
    "request": "doQuery"
  },
...
}

This dictionary must be accessed wit specific methods TBD. The point is to refer to the servers by using nicknames which will be also used as labels on the GUI.

Column Descriptors Management

The TAP protocol provides an accurate description of the exposed columns.

• The column descriptors are modeled as AttribueHandler instances
• The AttribueHandler are stored on demand
• The selection of the AttribueHandler to be displayed rely on rules described below
• The meta-data that are not in the TAP AttribueHandler are hard-coded

Workflow

When the user wants to access a table (table browsing or constraint setup):

1. Look whether the AttribueHandler od the asked table are already in the ObjectMap
   1. If yes: no further actions
   2. If no:
      1. Run a query getting the table AttribueHandler
      2. Store them in the ObjectMap
      3. Add the selected_values and the default_values
      4. Select those that must be displayed by default
      5. Store them in the ObjectMap

Storing AttribueHandler in the ObjectMap

Model changes:

• Both select_values [] and default_value must be added to the current AH implementation.
• A new field will be added to the ObjectMap: tables->table_name->disp_columns. It contains the AHs to be selected and possibly displayed. This list is set with default values, but it can be updated by some user selection.

Workflow:

• Run the appropriate query on the TAP schema
• Build one AH per column
• Set both selected_values and default_values field
• Store them in tables->table_name->columns as a dictionary with db_name as key.
• Select those to be selected to either be displayed or used for browsing anchors.
• Populate the tables->table_name->disp_columns with them.

Setting AH selected_values and default_values fields

• The semantic tank contain a hard-coded dictionary with these values
• Only the columns having preset selected_values or default_values are in that dictionary.

ex:

"preset_ah_values" : {
    "calib_level": {
        "selected_values": [1,2,3],
        "default_value": 2
    },
    ...
}

These values will be used by the constraint editors to tell the users what can they get or not.

Selecting the columns to be selected with the tqble queries.

There are 2 categories of columns to be selected:

• The join keys: They are not displayed as such but they are used to build anchors on sub-tables. They are identified with the ObjectMap keys.
• The values of interest: There a few categories of parameters that are interesting for most of the users:
  • object names
  • object positions
  • object luminosity
• The semantic tank will provide a mechanism based on the UCDs to select at most one column per category.
  • UCDs is a shared vocabulary defining the column content.
  • TAP (can) provides UCDs for all exposed columns.
• Each category is set with a list of UCDs ordered by descending importance:

{
"name":["meta.id;meta.main", "meta.id"],
"longitude": ["pos.eq.ra;meta.main", "pos.gal.lon;meta.main","pos.eq.ra", "pos.gal.lon",
"latitude": ["pos.eq.dec;meta.main", "pos.gal.lat;meta.main","pos.eq.dec", "pos.gal.lat",
"luminosity": [.....]
}

• The column selection will be made per category
• The analyzer iterate on the UCD list for each column. Columns are selected when the list value matches the column UCD.