[Obscore Update] requirements from SIAv2 data access protocol

[CresitelloDittmar, Mark]

Mireille/Francois,

Thanks for pinging this back to the top of my mail list :)


On Thu, Jul 31, 2014 at 3:27 AM, François Bonnarel <
francois.bonnarel at astro.unistra.fr> wrote:

>  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
>
>
> Sounds good. I think it is important that these additional new class
> attributes could be referred somewhere by the time SIAV2 comes to
> recommandation.
>
>
I agree, this content looks fine for ObsCore.
If I recall, the goal is to have this ObsCore 1.1 update in place to be
referenced by the SIAV2 document.. correct?

 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.
>
>  This is a very good and important point. Inclusion of this class in
> ImageDM is important for future interoparability of several protocols
> So if adopted this class should be integrated in ImageDM diagrams
>

I will be working heavily on the next draft over the next weeks...
I agree that this summary class would be populated from the greater ImageDM
content.  I don't want to hi-jack this thread, so we
should discuss how that connection is made separately.

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.

I don't have any strong opinion about the lengthy, but very descriptive
'DimensionsAndMappingSummary'.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140731/945176da/attachment.html>