[Obscore1.1] WD comments / New content comments

[Louys Mireille]

Hello Mark , hello DM listners,
here are some comments and answers about the WD. I have a compiled a new 
version of the WD  that I will circulate very soon.
Cheers, Mireille.
  Le 24/06/2015 22:07, CresitelloDittmar, Mark a écrit :
> Mireille,
>
> Thank you for your efforts on this document!
>
> I gave it a full re-read on the plane back from Sesto.
> Below are some comments for discussion, in 2 groups
>   1) about the additions for 1.1
>   2) about the original content
>
>
>
> 1: New content
> ============
>
> First, I agree with Marcus'? comment in Sesto, that the document 
> should have specific new use-case(s) added for the new content.
>
Appendix A of the document shows various use-cases . I have updated and 
added a few for images , data cubes and time series.
most recent additions are now in purple font.
>
> pg 7: "This effort (version 1)"...
>   Perhaps some rephrase/rearrangement
>   Version 1.0 was focused on public data. ...
>   Version 1.1 adds information on ..
>
changed
> pg 8:
>    The two paragraphs; 'The first version of this model, ..." and 
> "This effort (version 1).." are repeated from pg 7.
removed
> pg 9:
>    Is the architecture diagram accurate?
>
I changed it by removing VOpipe
> pg 25: Axes dimensions
>   Outside of the pixelated image context, what values do these hold?
>   For example, the sparse cube (ie: event list).  do each of these hold
>   the #events? or are s_dim1,s_dim2 ==  the span along that axis? and
>   if so, in what frame?
>   It seems that #events is closest to the description as the number of 
> samples.
>
changed : I have included Doug 's suggestion to allows #events to be an  
as an estimated size for  t_dim in case of an event list.
this is unprecise , I agree , but seems the best work around in case of 
unpixelated data.

> pg 40: Utypes
>   the 'numBins' node in the utype confuses me in conjunction with the 
> 'number of samples' description.  'Bins' implies pixelated axes, while 
> 'Samples' is more a number of measurements thing, which MAY correspond 
> to image pixels or MAY be individual measurements (events).
see above
>
> B3.5: creation date
>    Shouldn't we update this to clarify that this is not strictly ISO 
> 8601, but rather, the FITS standard which is 8601 without the "Z" 
> 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).
>
added the reference to DALI
> B5: Data Access
>    Refers to SSA for the Access object content.  Which document is 
> supposed to be the 'parent' in the Access standard hierarchy?
>
first defined in SSA , then re-used in ObsCore/ ObsTAP
> B6.1.1:
>    The description seems very pixelated data specific.
>
yes , absolutely . I think it is quite natural that in the discovery 
process , one might want to guess the number of points available for an 
observation on the sky.
For a user, I imagine the next step after discovery might be a preview , 
as an image or as an histogram or a graphical representation of some 
sort showing the properties of the dataset.

Would it be possible to describe a use-case scenario , where a user 
wants to discover x-ray event-lists and select them using various binned 
representations ? or are there specific criteria , like snr , etc  that 
are not covered in Obscore , but should be specified in the Use-cases of 
the Cube DM ?