[Obscore1.1] WD comments: Original content

[François Bonnarel]

Hi Mireille, all
     A few comments on some specific parts of this version (but mostly 
they were valid on the previous one also)

a )    Observation/Obsdataset data model as the main class.
    The current draft states

    "Consistency with the IVOA Cube data model which represents 
N-Dimensional datasets has
been improved. Therefore the main data model node of ObsCore DM, which 
focuses on a
data product, is named “ObsDataset” as in Cube and IVOA DataSet Metadata 
model. The
term Observation as a class is left to describe more precisely the 
process of observing and
will be developed in the dedicated astronomical Provenance data model."

      My comment : it is true that "Observation" is not synonymous from 
"ObsDataSet". But "observation" is both a collection of one or several 
ObsDataset and the process which generates them. Due to current 
discussion around the Provenance data model (see Sesto special session 
on this) Provenance is now a term mostly reserved to processing and not 
to the Observation configuration, so we should slightly change this 
statement.


b ) spectral axis "unit"
      Appendix B.6.2 states

     "Note that for the ObsTAP implementation, the Spectral axis 
coordinates are constrained as a wavelength quantity expressed in meters 
as mentioned in section 4.17"

       This is a little ambiguous and it should be precised that only 
the spectral axis characterization (coverage, resolution, etc...) is  
expressed in meters and that it is not the case of the data axes 
themselves which must stay as they have been provided. em_ucd and 
em_unit are there to describe these native features.

c ) redshift/velocity datasets

       B.6.3 tackle the special case of so-called "velocity cubes" or 
"redshift cubes".  I want to emphasize that in general a "velocity (or 
redshift)" cube is a convenient representation of a spectral cube and 
should not be confused with data spanned on the redshift or dopller 
velocity  axis, in the sense it is used in STC2 by Arnold rots and 
collaborators.

          In velocity cubes, As in FITS standard, a transformation is 
made between channels in frequency or Wl using an arbitrary rest 
frequency. And in that case a flux measured at Doppler velocity "so and 
so" can be coming from a shifted line but also from continuum with no 
shift at all  or complety different shift.
          Doppler datasets are a pre-analysis convenience when dominance 
of a spectral line in the data  is suspected.
          Using em_ucd and em_unit to give the different flavors of data 
axes in that case is fine.

         But to describe  a real doppler axis desentangled and distinct 
from spectral axis is another story and requires two distinct sets of 
attributes (not the same Data Model class). Full ImageDM (including 
STC2) will be able to describe this eventually. ObsCore is not tackling 
this feature.

          I recommend to integrate B.6.3 in B.6.2 "Spectral axis" to 
rename "B.6.3 Doppler/Redshift axis" in "B.6.2.6 Special case of 
DOppler/redhsift datasets"

Cheers
François

Le 10/07/2015 22:01, Louys Mireille a écrit :
> Hi all again ,
>
> For the strategy to present the articulation between Obscore 1.1 , the 
> previous ObsCore 1.0 and the coming Dataset metadata , I agree this 
> should be clearer.
> The strategy is to be discussed among authors.
> I will be mostly away from my email in the next weeks, so I circulate 
> an intermediate version that takes into account all comments on the 
> "New content" first.
> All recent modifications are in purple , in addition to the green 
> parts I changed before SESTO.
> Your comments are welcome for this intermediate version.
>
> More comments on the rephrasing strategy below.
> Thanks and best wishes , Mireille.
>
> Le 24/06/2015 22:07, CresitelloDittmar, Mark a écrit :
>> .... second part
>>
>> 2: Original content
>> ===============
>>
>> One of the challenges in doing the DatasetMetadata/Cube work was in 
>> determining exactly what ObsCore was in relation to the other models 
>> (Spectral/Char/STC).  It seems that we have an opportunity to clarify 
>> that relation while we have the document open... so long as that work 
>> does not delay the delivery of the primary purpose of the update.
>>
>> I think it would be beneficial to add/change language to emphasize 
>> that ObsCore is a 'flattened view' of an Observation/Dataset model.
>>   example: pg 10
>>   ".. the purpose of this document is twofold: 1) to define a simple 
>> data model to describe observational data, "
>>
> I think Obscore is a real  Data model , it is designed with classes 
> from Characterisation, Spectrum , SSA ( Access)  and is modeled in UML .
> The way these classes are used in a TAP service named ObsTAP is the 
> flattened version of the ObsCore DM .
>
> I see ObsCore as a prototype of  Dataset metadata DM , ( less classes 
> and less attributes) ; historically Dataset metadata has been created 
> as a refactorisation and homogeneisation of the existing Data models ( 
> Spectrum, Char, STC, etc) .
> I think the historical path is needed as it explains the development 
> of the ideas with time.
> It is not natural to think general first and then apply the general 
> view . Iterations and refinements are needed and this is what happened.
>
> We should highlight the consistency obtained in the DatasetDM , but 
> probably not only in the various specs citing each others , but in a 
> general page that could show the dependencies between the different 
> modeling efforts.
>
>>   could be rephrased to clarify this point.
>>
> agreed
>>   example: pg 11; second paragraph of section 3 can better clarify 
>> the relation of ObsCore to these other models.
>>
>>
>> The diagrams/UML in the document are to illustrate the mapping of 
>> this view to the corresponding IVOA standard model(s). Ultimately, I 
>> think it would be more clear if there were 2 sides to the diagram, 
>> with some indicator matching the respective elements:
>>   on the left: ObsCore table column element
>>   on the right: corresponding model element
>>
>>   ivoa.ObsCore.table_name  ----  ObsDataset -> Target -> Name
>>   ivoa.ObsCore.s_resolution_min  ----  ObsDataset -> Char -> 
>> SpatialAxis -> Resolution -> Bounds -> Limits -> LoLimit
>>
> I think the table in B5 already shows this mapping, and Table 6 and 7 
> at the end of the document too.
>> I'm not sure how that would be shown graphically, and may be more 
>> work than benefit.
>>
>> If Section 3 is representing the 'placeholder' model which ObsCore 
>> views, this could be made more clear.  ie: if Section 3 is fulfilling 
>> the same purpose as the upcoming DatasetMetadata document
>
>