<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Mireille,<br><br></div><div>Thank you for your efforts on this document!<br></div><div><br></div>I gave it a full re-read on the plane back from Sesto.<br></div>Below are some comments for discussion, in 2 groups<br></div>  1) about the additions for 1.1<br></div>  2) about the original content<br><br></div><br><div><br>1: New content<br>============<br></div><br></div><div>First, I agree with Marcus&#39;? comment in Sesto, that the document should have specific new use-case(s) added for the new content.<br><br></div><div><br></div><div>pg 7: &quot;This effort (version 1)&quot;...<br></div><div>  Perhaps some rephrase/rearrangement<br></div><div>  Version 1.0 was focused on public data. ...<br></div><div>  Version 1.1 adds information on ..<br><br></div><div>pg 8:<br></div><div>   The two paragraphs; &#39;The first version of this model, ...&quot; and &quot;This effort (version 1)..&quot; are repeated from pg 7.<br></div><div><br></div><div>pg 9:<br></div><div>   Is the architecture diagram accurate?<br><br></div><div>pg 25: Axes dimensions<br></div>  Outside of the pixelated image context, what values do these hold?<br></div><div>  For example, the sparse cube (ie: event list).  do each of these hold<br></div><div>  the #events? or are s_dim1,s_dim2 ==  the span along that axis? and<br></div><div>  if so, in what frame?<br></div><div>  It seems that #events is closest to the description as the number of samples.<br><br></div><div>pg 40: Utypes<br></div><div>  the &#39;numBins&#39; node in the utype confuses me in conjunction with the &#39;number of samples&#39; description.  &#39;Bins&#39; implies pixelated axes, while &#39;Samples&#39; is more a number of measurements thing, which MAY correspond to image pixels or MAY be individual measurements (events).<br></div><div><div><br></div><div>B3.5: creation date<br></div><div>   Shouldn&#39;t we update this to clarify that this is not strictly ISO 8601, but rather, the FITS standard which is 8601 without the &quot;Z&quot; tag.   There was a discussion on this some time ago, and that is the language folded into the DatasetMetadata model (Section 6.4.1.1).<br><br></div><div>B5: Data Access<br></div><div>   Refers to SSA for the Access object content.  Which document is supposed to be the &#39;parent&#39; in the Access standard hierarchy?<br></div><div><br></div><div>B6.1.1:<br></div><div>   The description seems very pixelated data specific.<br><br><br></div><div><br></div>2: Original content<br>===============<br><br></div>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.<br></div></div></div><br></div>I think it would be beneficial to add/change language to emphasize that ObsCore is a &#39;flattened view&#39; of an Observation/Dataset model.<br></div></div><div>  example: pg 10<br></div><div>  &quot;.. the purpose of this document is twofold: 1) to define a simple data model to describe observational data, &quot;<br><br></div><div>  could be rephrased to clarify this point.<br><br></div><div>  example: pg 11; second paragraph of section 3 can better clarify the relation of ObsCore to these other models.<br></div><div><br><br>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:<br></div></div><div>  on the left: ObsCore table column element<br></div><div>  on the right: corresponding model element<br><br></div><div>  ivoa.ObsCore.table_name  ----  ObsDataset -&gt; Target -&gt; Name<br></div>  ivoa.ObsCore.s_resolution_min  ----  ObsDataset -&gt; Char -&gt; SpatialAxis -&gt; Resolution -&gt; Bounds -&gt; Limits -&gt; LoLimit<br><div><div><br></div><div>I&#39;m not sure how that would be shown graphically, and may be more work than benefit.<br><br></div><div>If Section 3 is representing the &#39;placeholder&#39; model which ObsCore views, this could be made more clear.  ie: if Section 3 is fulfilling the same purpose as the upcoming DatasetMetadata document.<br><br><br></div></div></div>