[Obscore1.1] WD comments: Original content

[Laurent Michel]

Le 15/07/2015 13:35, François Bonnarel a écrit :
> 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.

Does it worth to mention a incipient model (provenance)? We could say something like
"The term Observation as a class is left to describe more precisely a part of the process of observing."

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

Agree

>
> 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
>>
>>

-- 
jesuischarlie

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34