[Obscore Update] requirements from SIAv2 data access protocol

[Louys Mireille]

Dear DataModel participants,

Here is a short summary on a discussion started at Madrid Interop that 
would benefit from a larger audience .

*Additionnal fields in the ObsCore data model for dataset dimensionality 
and dimensions . *

ObsCore DM  has been focused on describing a core set of metadata common 
to most data products distributed for astronomical observations.
In the current version of the ObsCore data model : 1.0 , the dimensional 
information as well as axes order and WCS calibration are not taken into 
account.
However there is a clear use-case for providing these metadata :the 
SIAv2 protocol which distributes N-dimensional data sets as Image, cubes 
, for instance and which needs to expose dimensions and axes in the 
query response.

In order to keep the general approach applied for the Obscore data model 
, we suggest to define an additionnal class with the following data 
model fields :

     1. Number of subarrays (usually but not always 1)
      "num_array"    integer

     2. Number of array axes (dimensionality) of the main array
       "num_axes"   integer

     3. Length of each axis
        "axis_length"  integer array, e.g., "512 512 3" is the simplest 
representation

     4. Number of wcs axes  (may differ from num_axes)
         "num_wcs_axes"  integer

     5. Coordinate type on each WCS axis
        "axis_type"    whitespace delimited list of axis types
         e.g RA-TAN DEC-TAN WAVELENGTH

These form a coarse grain description of the Dataset dimensions and 
Mapping that could be called 'DimensionsAndMappingSummary'.
This class can be referenced in Obscore, from the general Observation 
class, and in ImageDM from ObsDataset, or in the specialised Image 
classes : NDImage, SparseData if necessary.

Such a definition keeps the genericity of the Obscore DM. It should be 
reused for full interoperability in Image/Cube DM as a summary class.
This is also the case for many classes in the CharacterisationDM .
Here 'DimensionsAndMappingSummary' is a bridge between the two models at 
a coarse level of description of the 'Data' object.

The various fields are familiar to developers and users dealing with 
FITS keywords, and therefore are easy to populate for a data provider.

*Update of the ObsCore specification.
this new class , once agreed on a proper name , can be aggregated in 
Observation in ObsCore , or ObsDataset in Image.

*Insertion in the Image/Cube DM
the same class can be used in Image/CubeDM . The appropriate level in 
the Image/DM hierarchy needs more thoughts and examples, to check what 
would be the most appropriate , between ObsDataset or the derived 
classes , like NDImage , etc.

I picked up 'DimensionsAndMappingSummary' as a class name and would be 
happy to get your feed back , whether it is understandable
with its attributes' list and if any shorter name can be proposed.

Thanks , Mireille.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140709/c47bc838/attachment.html>